Asterisk 11 cannot deliver caller and callee voice sound on specific WIFI network.
WIFI phone ==> 4G LTE phone (Can hear sound/Working)
== Using SIP RTP CoS mark 5
-- Called SIP/01036504100
-- SIP/01036504100-00000594 is ringing
-- SIP/01036504100-00000594 answered SIP/01010001004-00000593
-- Locally bridging SIP/01010001004-00000593 and SIP/01036504100-00000594
> 0x7f5a401b6800 -- Probation passed - setting RTP source address to 1XX.63.12.134:7076
> 0x7f5a401b6800 -- Probation passed - setting RTP source address to 1XX.63.12.134:7076
> 0x7f5a3800bf90 -- Probation passed - setting RTP source address to 2XX.62.163.73:51658
3G phone ==> 4G LTE phone (Can hear sound/Working)
== Using SIP RTP CoS mark 5
-- Called SIP/01088143268
-- SIP/01088143268-00000596 is ringing
-- SIP/01088143268-00000596 answered SIP/01036504100-00000595
-- Remotely bridging SIP/01036504100-00000595 and SIP/01088143268-00000596
> 0x7f5a3800bf90 -- Probation passed - setting RTP source address to 3X.7.29.226:2779
> 0x7f5a40017050 -- Probation passed - setting RTP source address to 2XX.62.163.73:51944
> 0x7f5a3800bf90 -- Probation passed - setting RTP source address to 3X.7.29.226:2779
Another WIFI phone ==> 4G LTE phone (Can't hear sound/Not Working)
== Using SIP RTP CoS mark 5
-- Called SIP/01036504100
-- SIP/01036504100-00000598 is ringing
-- SIP/01036504100-00000598 answered SIP/01088143268-00000597
-- Remotely bridging SIP/01088143268-00000597 and SIP/01036504100-00000598
> 0x7f5a40116470 -- Probation passed - setting RTP source address to 5X.237.58.102:7076
> 0x7f5a40116470 -- Probation passed - setting RTP source address to 5X.237.58.102:7076
> 0x7f5a38027a20 -- Probation passed - setting RTP source address to 2XX.62.163.73:52040
> 0x7f5a38027a20 -- Probation passed - setting RTP source address to 2XX.62.163.73:52040
I was thinking maybe I only open UDP between 10,000 and 20,000. However, I was wrong. asterisk -rvvvvv doesn't show me what is the problem.
Examine SIP and RTP debug logs on the console by turning them on: sip set debug on, and rtp set debug on.
This way you could find out which leg of the RTP audio stream is not going to where it should. This is caused mainly by NAT issues (see the NAT section of sip.conf.
If You can't see incoming RTP packets from the phone, then probably a firewall is blocking the traffic or there is a NAT issue.
I changed user's nat value to "force_rport,comedia" and now both users can hear voice.
nat=force_rport,comedia
It was strange, nat = yes and nat = force_rport,comdia should be same, but second one was working on Asteirks 11.
Related
I was recantly experimenting with espnow in micropython. Sudenly I rann Into A Problem wenn trying to run this code:
import network, espnow, time
wlan_sta = network.WLAN(network.STA_IF)
wlan_sta.active(True)
e = espnow.ESPNow()
e.active(True)
peer = b'\xff\xff\xff\xff\xff\xff' # MAC
e.add_peer(peer)
while True:
e.send(peer, "ESP")
time.sleep(1.1) # Sekunden
i get the Error OSError: -3
The Code worked on my Esp32 but not on the 8266 no clue why.
I tried reflashing my esp but that did not help either.
According to the documentation you need to call wla_sta.disconnect() after setting wlan_sta.active(True). This is the example from the docs:
import network
import espnow
# A WLAN interface must be active to send()/recv()
sta = network.WLAN(network.STA_IF) # Or network.AP_IF
sta.active(True)
sta.disconnect() # For ESP8266
e = espnow.ESPNow()
e.active(True)
peer = b'\xbb\xbb\xbb\xbb\xbb\xbb' # MAC address of peer's wifi interface
e.add_peer(peer)
e.send("Starting...") # Send to all peers
for i in range(100):
e.send(peer, str(i)*20, True)
e.send(peer, b'end') # The example in the docs is missing the `peer` argument.
If I run that example as written (well, correcting the second call to e.send as shown in the above code) and the corresponding receiver code, it all works just fine on a pair of esp8266's running v1.19.1-espnow-6-g44f65965b.
Update I think your problem is that the esp8266 may not support the broadcast address. While the documentation suggests that the esp8266 should be able to send to the broadcast address:
All active ESP-Now clients will receive messages sent to their MAC address
and all devices (except ESP8266 devices) will also receive messages sent to
the broadcast MAC address (b'\xff\xff\xff\xff\xff\xff') or any multicast MAC
address.
All ESP-Now devices (including ESP8266 devices) can also send messages to the
broadcast MAC address or any multicast MAC address.
It appears that this isn't the case. I'm able to use the example code from the docs when operating in unicast mode, but attempting to call e.add_peer with the broadcast address results in the same error you've reported.
I've opened issue #11 with this problem.
In Conclusion you can say that It IS posibille to use ESPnow on the esp 8266 in SingelCasting Mode but not in MultiCasting
I'll start by saying that I definitely want to disable Nagle's Algorithm. The application that I am testing for is a real time P2P app in which packets are small and extremely time sensitive. This test also serves to compare UDP and TCP for possible networking solutions.
I am able to open the TCP socket and send messages back and forth, but I have not been able to disable Nagle's Algorithm. I have tried:
static const int yes = 1;
if (setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &yes, sizeof(yes))) {
fprintf(stderr, "Error setting tcp nodelay\n");
return -2;
}
on both the listening and connecting sockets. This does not fail. I also elevated the priority of the receiving thread to DISPATCH_QUEUE_PRIORITY_HIGH.
The test I am running starts with a packet that contains "start", followed by numerous packets that contain "data" and one final packet containing "stop". These packets are almost always combined into one or few packets, such as:
Received Peer Message: startdatadatadatadatadatadatastop
or
Received Peer Message: startdatadatadata
Received Peer Message: datadatadatastop
Is there a difference in the way that TCP_NODELAY is set on iOS? I was able to set it on Linux with the above code successfully.
I want to read a video stream from a UDP address using libavcodec functions. To do so, I use the following code:
char *url = "udp://127.0.0.1:1000";
AVFormatContext *oc = NULL;
avformat_open_input(&oc, url, NULL , NULL);
If we run this code, then function "avformat_open_input" starts listening on the given UDP address, and it looks like the program is halted if there is no video stream at the given UDP address.
Now, I want to write a code to first check the given UDP address quickly to see whether there is any data on it or not, if there is no data then the program should neglect running "avformat_open_input", otherwise it should run this function so that I can avoid the halting situation.
Any idea how I can do this? Thanks!
I'm trying to study and understand operations of the Linux tcp/ip stack, specifically how 'ping' sends packets down and receives them.
Ping creates raw socket in AF_INET family, therefore I placed printk in inet_sendmsg() at net/ipv4/af_inet.c to print out the socket protocol name (RAW, UDP etc.) and the address of protocol specific sendmsg function which correctly appears to be raw_sendmsg() from net/ipv4/raw.c
Now, I'm sending a single packet and observe that I'm getting printk form inet_sendmsg() twice.This puzzles me -- is it normal (has something to do with interrupts etc. ?) or there's something broken in the kernel?
Platform - ARM5te, kernel 2.6.31.8
Looking forward to hearing from you !
Mark
I'm attempting to receive a UDP Broadcast under Mono for Android and I am seeing no data coming in. This is somewhat perplexing because it works fine on the Galaxy Tab 7 and Galaxy Tab 10 (Android v 3.2) I have, but fails on an HTC G2 (Android v2.3.4).
The code is straightforward:
public void BeginDiscover()
{
var packet = new DiscoverPacket();
lock (m_syncRoot)
{
var localEndpoint = new IPEndPoint(m_local, 0);
using (var udp = new UdpClient(localEndpoint))
{
var remoteEndpoint = new IPEndPoint(IPAddress.Broadcast, DiscoverPort);
udp.Send(packet.Data, packet.Data.Length, remoteEndpoint);
Thread.Sleep(100);
}
}
}
I have verified that the manifest includes this line:
<uses-permission android:name="android.permission.INTERNET" />
Though this is happening in Debug, so that should be implicitly set anyway.
Other very strange observations:
Again, this is working just fine on another type of device
The handler listening for UDP broadcasts (which list listening for the response) does see this outbound packet. The code for this listener is also straightforward:
[listener code]
private void Start()
{
m_discoverListener = new UdpClient(DiscoverPort);
m_discoverListener.BeginReceive(DiscoverCallback, m_discoverListener);
}
private void DiscoverCallback(IAsyncResult result)
{
try
{
var ep = new IPEndPoint(IPAddress.Any, DiscoverPort);
var data = m_discoverListener.EndReceive(result, ref ep);
// filter out what we send
var add = AddressWithoutPort(ep.Address);
if (add == m_local.ToString()) return;
// parse discover response
// [clipped for clarity]
}
finally
{
m_discoverListener.BeginReceive(DiscoverCallback, m_discoverListener);
}
}
Wireshark running on a separate PC on the same network does see the discover request packet (from above)
The "discovered" device is also seeing it, because Wireshark is also seeing the reply
The Android device UDP listener is not receiving the response packet
The only major differences between devices that I can think of (other than different OEMs implementing the platform) is that the G2 has a cellular radio built in and the Galaxy Tab does not. In my specific test case, I have no SIM card in the phone, though, so no cellular connection is being made. Note that the code above is explicitly using the local endpoint that is on the WiFi network.
Is there a known issue with UDP on the G2 specifically or generally on older implementations of the Android platform?
It took a bit of work as the UDP response in question is coming from a microcontroller on the device and I wanted to make absolutely certain that it wasn't an issue on the micro end (though I suspected it wasn't). I created a PC-based simulator for the microcontroller device that handles my Android UDP request and that sends back the exact same UDP response that the microcontroller does, then verified all of the traffic looks fine with Wireshark.
The net result is that I see he exact same behavior with the simulator. The Galaxy Tab 7 and 10 devices receive the UDP response no problem. The HTC G2 never does. This leads me to conclude that one of the following is true:
a) The HTC G2 specifically has an implementation bug preventing it from receiving (or at least passing along) UDP broadcasts on the network
or
b) The older Android build has his bug.
Until I find different hardware with the same Android version as the G2 (v2.3) I can't tell which is the case. In either event, it's a bug that makes this (and potentially other) hardware unusable for my specific solution.
I have a couple of applications on the market based on UDP communication.
I have problems with HTC phones not receiving the UDP broadcast packets sent from another device... if sent from the same device, the packets arrive.
so, I think the problem is in HTC, and I found a possible solutions online (even though I have not tried it):
http://www.flattermann.net/2010/09/fix-udp-broadcasts-on-htc-phones-running-stock-firmware/