I have a strange issue with Asterisk (in this case 13.2 version) and WebRTC.
So, I have latest Asterisk 13.2, latest Crome (with Firefox - same problem) and sip.js (also tried with sipml5) and local network - no nat or firewall.
The problem: if call is answered immediately - everything works fine. But if there are some delay in answer (say, 10 seconds) - no audio in both directions.
In RTP debug I saw that if there is some delay - destination ip address is incorrect. After removing ice servers from client config - both addresses is correct, but still no audio.
Below is debug for call with audio:
rtp http://pastebin.com/EzfByCG5
sip http://pastebin.com/1Y08yF5s
and no audio call (answered after 10 seconds delay):
rtp http://pastebin.com/TNnFkz6M
sip http://pastebin.com/zG7pjcZD
Also in FreeSwitch everything works fine, no matter when call is answered.
Starting with Asterisk 12 you need to have pjproject libraries installed, otherwise you most likely won't have audio in your WebRTC calls and no warning whatsoever!
First question: have you ensured all firewall configs permit RTP streams from the chosen STUN / ICE server unconditionally?
My own experience is that audio issues with WebRTC are almost always related to STUN / ICE & Firewall.
Did you follow a tutorial for your set up? If so, which one?
Check the log...
Peer audio RTP is at port 192.168.88.187:50026
sip_route_dump: route/path hop: sip:889#df7jal23ls0d.invalid;transport=ws
[Feb 13 06:15:59] ERROR[1055][C-00000031]: netsock2.c:303 ast_sockaddr_resolve: getaddrinfo("df7jal23ls0d.invalid", "(null)", ...): Name or service not known
[Feb 13 06:15:59] WARNING[1055][C-00000031]: chan_sip.c:16158 __set_address_from_contact: Invalid host name in Contact: (can't resolve in DNS) : 'df7jal23ls0d.invalid'
I would use Freeswitch, no doubt :-)
Related
I'm developing software feature for a Session Boarder Controller(SBC).
I'm trying to establish a SIP call using two SIP clients and a Session Boarder Controller(SBC). Asterisk is used as the soft-switch.
When I call, the SIP signalling is working fine. But I am getting audio only in one direction. I captured rtp packets on all interfaces using wireshark. I observed that rtp packets in one direction is being dropped by asterisk.
Note: There is no send only attribute in any of the SIP/SDP messages.
I would like to know if there is any settings in asterisk that may cause this issue?
One more thing that I would like to know is that, from where a SIP client gets the RTP connection information. The port information is present in the media attribute
m=audio 16388 RTP/AVP 8 0 101
From where does the client get the transport IP address? is it from the "o=" field or "c=" field in the SDP or any other fields in the SDP or SIP?
You should troubleshoot the problem by capturing the complete call with Wireshark. Then look carefully at:
Client A initial INVITE: which port is it expecting media on (m= line) which address is it expecting media on (c= line)
SBC for Client A initial INVITE: If the SBC is anchoring the media (I assume so) check m / c lines
SBC for Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client A expecting media on
Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client B expecting media on
Are all nodes in this direction sending media on to the correct ports / ips (look at the RTP streams in wireshark)?
Then check the other direction (based on the SDP in the 183 or 200 (depending on your signaling flow)).
Note: In wireshark there is a nice feature which helps alot: Telephony --> VoIP Calls, which shows you the call flow more graphically
I am using csipsimple as sip client and asterisk server to set up call. Calls are made between 2 sip clients but voice is not getting transferred.
Calls are made between 2 sip clients using AMI.
I can give my asterisk cli log.
Can anybody please give me some idea to solve this issue?
Thanks
More info would be useful. First, make sure both clients are registered, and can use at least one common codec. In most cases, these aren't the problem. It's usually a NAT/Firewall issue. Are the two clients on the same subnet? Is there any firewall rules blocking the communication?
SIP signaling usually goes on udp:5060. But that seems working. Media is tricky. In each call, the ports for RTP audio changes, in the range specified in rtp.conf. This RTP traffic goes over UDP as well. By default it't 10000-20000.
If there is only routing done between the two endpoints, it should still be fine. NAT (Network Address Translation) is your main concern. Take a look at iptables, sip_nat_conntrack. To debug, use asterisk's sip set debug on command and look for the SIP headers and verify the correct IP addresses.
I'm building (yet another) manual signalling WebRTC chat via DataChannels (CoffeeScript, sorry JS guys). It works fine in local connections, but not over the internet behind a NAT (unfortunately I couldn't try NATless yet).
I don't want to maintain a TURN server, but I'm fine if only one peer must be publicly-reachable from the internet for the setup to work. Since I'm the only one with a reachable machine, we need me to host a TCP connection. In Firefox there are no TCP candidates reported so I guess ICE-TCP is not yet supported.
On Chrome, looking at the SDP offers/answers, the STUN servers correctly identified both peer's public IPs and added each server reflexive UDP candidate (see line 10 below) but there is no TCP server reflexive candidate, so the connection never succeeds. There is also a TCP candidate included (see line 9 below) but it's just a host candidate.
Here's a sample SDP offer (my public IP is 88.88.88.88):
01. v=0
02. o=- 7452583715680269460 2 IN IP4 127.0.0.1
03. s=-
04. t=0 0
05. a=msid-semantic: WMS
06. m=application 50816 DTLS/SCTP 5000
07. c=IN IP4 88.88.88.88
08. a=candidate:864190085 1 udp 2122194687 10.10.10.4 50816 typ host generation 0
09. a=candidate:2097250933 1 tcp 1518214911 10.10.10.4 0 typ host generation 0
10. a=candidate:3500406889 1 udp 1685987071 88.88.88.88 50816 typ srflx raddr 10.10.10.4 rport 50816 generation 0
11. a=ice-ufrag:2066nM5kqwFDQMBT
12. a=ice-pwd:thO7oP0H+H1VBHFNfT8SLFiI
13. a=ice-options:google-ice
14. a=fingerprint:sha-256 72:87:BF:AD:03:9C:09:A7:58:0C:3A:DF:.....:B7
15. a=setup:actpass
16. a=mid:data
17. a=sctpmap:5000 webrtc-datachannel 1024
I'm sure the internet can reach my machine via NAT and port forwarding is fine (my machine is the default host to NAT-forward to).
Why is there no TCP server-reflexive candidate reported in my offers/answers?
Does Chrome lack server-reflexive ICE-TCP candidate discovery?
Is it possible to manually add a server reflexive candidate given the public IP reported by the STUN server?
First, STUN can support TCP over a NAT in accordance with the new RFC and with the proposed updates for said RFC for DTLS. All this said, Chrome should still support SCTP over TCP and Firefox still does not according to bug 891551.
I also highly doubt that MEDIA will ever support a TCP connection and suspect that only SCTP will be supported for any TCP connection(relayed or not).
[Note: For history sake, I am keeping the rest of my answer intact but a good comment made by #adamfisk, showed me some errata.]
Original answer
STUN CANNOT work with TCP over a NAT.
Its RFC says as much in the application statement. Stun is only designed to work with UDP. This is why SCTP needs to be on built on UDP so that you can go around NATs. (Only Chrome gives the internal option of TCP).
You will have to set up port forwarding on one of the NATs if you want TCP traffic to go through it but STUN will not help you.
Sorry for the bad news :(
EDIT: This is simply a limitation of STUN, not of SCTP(so chrome could do nothing about it if they wanted to). FireFox does NOT support SCTP over TCP anyways. I am not 100% on TURN. The RFC seems to say that TCP is support only in the communication between the client and the server, not the actual relay. Check this out, Chrome may work with TCP through a TURN server from what T. R. Missner states at the bottom of the thread.
You MAY have to have port forwarding set up on both sides if you want to use TCP with an RTCDataConnection.
I have an RN-171 wifly module connected with a micro-controller.
I am using the UDP-protocol to communicate with the module. Also, I am using the firmware's UDP auto-pair feature to set the host ip. As soon as the module receives a UDP packet, it sets the host IP address to the ip from where it received the data. Now, this host ip cannot be changed without entering into the command mode.
I want the module to behave in the following way:
Every time it receives a UDP packet, it updates the host ip to the ip address from where that signal came from.
Also, I can use the TCP protocol but it only allows a single connection at a time. One more problem that I faced using the TCP protocol was that if I try to initiate a second TCP connection with the module, it not only refuses the second connection but also hangs the first stable connection. Even if the second connection initiation does not hang the module and it just gets refused, I will be ready to work with TCP.
I have been researching a lot on the web regarding this problem but since these modules are not widely used, they have a very limited support.
I've used RN-171 extensively and have many resolved tickets in their support system.
According to the WiFly Command Reference, Advanced Features and Applications User’s Guide, you cannot open more than one TCP port with the module. (the default number being 2000)
Unfortunately, regarding the UDP functionality, there's not much you can do. If you have a new host wishing to communicate over UDP, connect to the module over TCP, go into command mode and set the address using "$$$", "set ip host 0.0.0.0", "save", "exit" commands. Alternatively, instead of 0.0.0.0, you can enter the new host's own ip address: "$$$", "set ip host ###.###.###.###", "exit". Replace "###.###.###.###" with the ip address of the device.
This way, you won't get wrong host ip in case more than one device communicates over UDP at the same time. Also, by not using "save", the auto-pairing will still be saved to EEPROM memory. Also, you can send "ip flags 0x##" before "exit", this way you can also set bit[6] to 0 (UDP auto pairing disabled) temporarily by using the hex value that has this bit set to zero.
One of my problems that Microchip technical support tested around the summer of 2013 is that you cannot use RN-171 as an access point for other RN-171s since they have a firmware error preventing one from doing that and, as of firmware v4.41, released in January of 2014, there is no fix yet nor planned.
I myself do not recommend the latest firmware version v4.41, since it does not appear to work with most routers; however Soft AP mode on this works fine. On the other hand, v4.00.1 is much more compatible, however you should take care when cutting off the power since it has a potentially disastrous bricking problem if you cut the power when flash writing is in progress - the module may lock its memory forever.
I recommend registering and opening a Microchip ticket which usually will be answered within two business days and they're quite supportive. Their firmware update cycle is however quite long, and it usually takes a year or so for a new update.
Resolution, of sorts
The client computer that was showing this problem had Trend Micro Security installed. This security suite placed a service or driver on top of each network adapter in the system. I did not bother to debug further once this legacy app started working again.
Update 1
I disabled TCP window scale auto-tuning on Win7.
On Windows 7 if I unplug the ethernet cable directly connected to the server, the disconnection happens after about 5 seconds but the client process crashes. netstat on the server reports two TCP connections to the client that are no longer valid, because the client process did not gracefully shutdown and close the connections.
After putting the server in this strange state after the physical disconnect, If I restart the client process it hangs while connecting to the server (just as described in the original)
If I perform a physical disconnection on the XP side, the disconnect happens more quickly than on Win7. Some sort of keep alive value or behavior is different on XP. While ssh'd (via Putty) the ssh connection dies more quickly on XP than Win7 as well.
Original
I have a legacy TCP client/server app that appears to foul up the server only when the client is a Windows 7 machine.
The server is OpenEmbedded Linux running 2.6.11.
A Windows 7 client connects for a bit, and eventually gets to a state where the client disconnects after a second or two.
Once the server is in this state, If I immediately connect a Windows XP client, the XP client cannot connect either.
I cannot appear to get the server into the buggy state by connecting with an XP client alone.
I'd like to know what changes were made to the TCP/IP stack starting with Vista or Windows 7 so I can better debug the legacy code.
I'd also like to know what commands I can run on the Linux server that might better help me understand why the connections are failing.
Perhaps the best thing you can do is to fire up tcpdump or wireshark under linux and analyze the TCP SYN sent by both Windows XP and Windows 7. Wireshark allows you to break out bit-by-bit what TCP options are sent... for example, this is what you see from a debian lenny box making a TCP connection:
Transmission Control Protocol, Src Port: 58456 (58456), Dst Port: 23 (23), Seq: 0, Len: 0
Source port: 58456 (58456)
Destination port: 23 (23)
Sequence number: 0 (relative sequence number)
Header length: 40 bytes
Flags: 0x02 (SYN)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..1. = Syn: Set
.... ...0 = Fin: Not set
Window size: 5840
Checksum: 0x8b77 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (20 bytes)
Maximum segment size: 1460 bytes
SACK permitted
Timestamps: TSval 136991740, TSecr 0
NOP
Window scale: 6 (multiply by 64)
My suspicion is that you'll see differences in RFC 1323 Window Scaling, but I don't have an XP machine handy to validate this.
I gave a detailed response of how to analyze TCP connections using tcptrace under linux in this answer...
How can I measure the performance and TCP RTT of my server code?
I also suspect a Window Scaling issue. I cannot find a link just at the moment, but there were complaints when Vista first came out reporting that that something was screwing with some routers (belkins If I recall). They traced it down to a problem with one of the window sizes that Vista (and thereby Windows 7) changes by default. The routers would get hung up and need to be reset every few minutes.
You can issue some commands to turn off window scaling, see if your problem goes away.
From Here:
netsh interface tcp set global autotuninglevel=disabled
Edit:
Try disabling IPv6 on windows 7. Link on how to do that. With IPv4, it should act the same as windows XP. Load up wireshark on the two systems and compare the differences