One device’s TCP SIP and UDP RTP audio leaving wireless carrier from different IP addresses?
Hello! Several users of our product have reported no audio when using our VoIP mobile app on cellular networks. Our server product and our mobile app rely on the TCP SIP socket?s source address being the same as the audio?s source address. When the addresses don?t match, the server has no way to know the two addresses are a single device. We have a packet capture from one user?s server that shows a single mobile device communicating from two different IP addresses: one for the TCP SIP connection (166.181.252.181), and a second one for the UDP RTP audio (166.181.255.39). In this capture, our server sends audio to 166.181.252.181 and discards the inbound audio from 166.181.255.39. The port numbers in the audio packets from the 39 address match the port numbers negotiated over the TCP connection with the 181 address, which is why I believe them to be the same device. We retested today with the same customer device but connecting to a different server. In today?s test, the capture shows that the TCP SIP connection arrived from 166.181.251.203 and the UDP RTP arrived from 166.181.255.32. All of these addresses are in a block assigned to ?Wireless Data Service Providers' Corporation (SPCo)?. The user reports their carrier as US Cellular, which is a voting member of SPCo. Does anyone have a technical contact at US Cellular we can ask about this? Has anyone observed this multiple-address NAT being employed by other service providers? Thank you! Scott Ventura Senior Software Engineer Allworx This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
Scott, As per the RFC the IP for the RTP does not need to be the same IP address as of the SIP signalling. When mobile providers do CGNAT they do it based on source ip + source port + destination ip + destination port. What's happening here is their CGNAT device is seeing the traffic for RTP is a different session and they open one up for you they use one of the IP's that they have in their pool. Since the client is behind NAT you can't rely on the IP in the SDP. You have two options. 1) See if your software can figure out the correct IP for RTP based on the destination port that that you told the software to connect to you on and not rely on the IP for where the SIP signalling is coming from. 2) Use IPv6. You can also get a phone on US Cellular, open multiple sessions on multiple ports and see if you can figure out their algorithm and how they decide what IP to use. You may want to restrict the available rtp ports to those that you know will cause the RTP and SIP signalling to use the same source address. On Tue, May 5, 2020 at 5:22 PM Ventura, Scott D <SVentura at allworx.com> wrote:
Hello!
Several users of our product have reported no audio when using our VoIP mobile app on cellular networks. Our server product and our mobile app rely on the TCP SIP socket?s source address being the same as the audio?s source address. When the addresses don?t match, the server has no way to know the two addresses are a single device.
We have a packet capture from one user?s server that shows a single mobile device communicating from two different IP addresses: one for the TCP SIP connection (166.181.252.181), and a second one for the UDP RTP audio (166.181.255.39). In this capture, our server sends audio to 166.181.252.181 and discards the inbound audio from 166.181.255.39. The port numbers in the audio packets from the 39 address match the port numbers negotiated over the TCP connection with the 181 address, which is why I believe them to be the same device.
We retested today with the same customer device but connecting to a different server. In today?s test, the capture shows that the TCP SIP connection arrived from 166.181.251.203 and the UDP RTP arrived from 166.181.255.32.
All of these addresses are in a block assigned to ?Wireless Data Service Providers' Corporation (SPCo)?. The user reports their carrier as US Cellular, which is a voting member of SPCo.
Does anyone have a technical contact at US Cellular we can ask about this? Has anyone observed this multiple-address NAT being employed by other service providers?
Thank you!
Scott Ventura
Senior Software Engineer
Allworx
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (2)
-
dovid＠telecurve.com -
SVentura＠allworx.com