[VoiceOps] One device’s TCP SIP and UDP RTP audio leaving wireless carrier from different IP addresses?

Clint Mojzes clintm at ringcentral.com
Tue May 5 17:36:25 EDT 2020


That’s odd. Never seen it before. What happens if you switch the SIP transport to UDP? Sounds like the carrier may be struggling to keep up with NAT overload demands on their network.


From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of "Ventura, Scott D" <SVentura at allworx.com>
Date: Tuesday, May 5, 2020 at 2:23 PM
To: "voiceops at voiceops.org" <voiceops at voiceops.org>
Subject: [VoiceOps] One device’s TCP SIP and UDP RTP audio leaving wireless carrier from different IP addresses?

[EXTERNAL]
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20200505/b45efb34/attachment.htm>


More information about the VoiceOps mailing list