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

[Dovid Bender]

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