[VoiceOps] Has anyone seen this? Voice UCaaS application on iPhone generated call: switching source IP address mid-call with no SIP signaling to indicate

[Jeff Brower]

  Hi Richard-

I second your comment "this might be a systematic problem of wider  
interest". We have a number of LEA customers asking for a config  
option in our software to ignore IP address/port changes if SSRC stays  
the same. The problem with this though is RFC8108, which allows SSRC  
changes within a session. Tradeoffs.

-Jeff

Quoting Richard Jobson via VoiceOps <voiceops at voiceops.org>:

> Hi Nathan
>
>    Thank you for your analysis & especially your “Hmm, maybe with  
> scenario #2”, - roaming off Wi-Fi on to cellular ..
>
>    I thought this might be of interest to the community as there are  
> only so many Wireless IMS Network operators & UC/CCaaS apps are so  
> popular, this might be a systematic problem of wider interest.
>
>    these iPhone-originated calls are made by a vendor UC/CCaaS app  
> over standard VoLTE/IMS Network via our ITSP softswitch/feature svr  
> (same vendor as the UC App) our UCaaS core. It might be internet on  
> the access/mobile side (as you say Wi-Fi) but its the carrier's IMS  
> core/private network to us.
>
>    It is NAT & IPv4
>
>    Many Thanks & Best Regards,
> Richard Jobson
> Teraquant Corporation
> ph: 719 488 1003
> d/l: (719) 766-8523
> www.teraquant.com[1]
> richard at teraquant.com
> https://www.linkedin.com/in/uc-expert-monitoring/
>
>    Network Monitoring and Service Assurance - Speech Quality Experts  
> (PESQ/POLQA) and Active Testing - Reporting – HPBX - Session Border  
> Controllers – SASE and SD-WAN - Big Data Analytics, fraud detection  
> and protection. 
>
>       FROM: VoiceOps <voiceops-bounces at voiceops.org> on behalf of  
> Nathan Anderson via VoiceOps <voiceops at voiceops.org>
> DATE: Monday, June 3, 2024 at 6:46 PM
> TO: voiceops at voiceops.org <voiceops at voiceops.org>
> SUBJECT: Re: [VoiceOps] Has anyone seen this? Voice UCaaS  
> application on iPhone generated call: switching source IP address  
> mid-call with no SIP signaling to indicate
>
>
>       Slightly confused (based on your references to "Wireless IMS  
> Network SBC") whether these iPhone-originated calls are just  
> standard VoLTE/IMS calls being made by the native phone app and  
> being carried by the carrier's IMS core, or whether these are SIP  
> calls being sent to your own UCaaS core by your app over the  
> carrier's regular internet/data APN.
>
>       If you are saying that you have direct-IP voice peering with  
> one or more wireless carriers, and that iPhone users on those  
> networks are calling numbers of yours & you are seeing the source IP  
> of RTP traffic change mid-call, then I don't see how that can be  
> anything *but* a carrier issue.  That said, I also don't see how  
> that can be an iPhone-specific problem, either, or how you managed  
> to arrive at that conclusion.  If you were to more closely look at  
> logs related to calls where this is happening, I'd expect that you  
> would find that 1) the problem is specific to a particular carrier,  
> not a particular phone model, and 2) you'll find many calls coming  
> from that one carrier across multiple phone models exhibiting the  
> issue.  As to WHY the carrier might be doing this...I haven't the  
> foggiest.
>
>       If you are saying you have iPhone users running an app of  
> yours that is making outgoing SIP calls directly through your ITSP  
> network over the carrier's internet APN, then ...I don't see how  
> that could be anything but a carrier issue, either, honestly.  You  
> didn't mention whether this was IPv4 or IPv6 though.  I'd be  
> surprised if you saw this happening when the traffic is arriving to  
> you via IPv6.  However, for IPv4 traffic, it would not surprise me.   
> Vast majority of carriers in the U.S. are handing out RFC1918 space  
> IP addresses to end-user devices & putting them behind a  
> masquerading NAT.  You'd expect that the NAT would try to retain the  
> same source IP for the duration of a given session, but I would not  
> be shocked to discover that the NAT configuration or the NAT engine  
> itself is broken in some way, leading to this symptom.  (I'd also  
> not be surprised to learn that the carriers simply couldn't care  
> less if SIP traffic over the internet to their subscribers is  
> unreliable, even though they've largely gotten to the point where  
> voice services are no longer their primary money-maker...industry  
> inertia and all that.)  If you don't already have your own ITSP  
> service natively reachable over IPv6 yet, you might consider finally  
> getting around to doing so...most of the major mobile carriers in  
> the U.S. are dual-stacking these days, so if carrier-side IPv4 NAT  
> is the cause, this would work around it for vast majority of users  
> I'd think.
>
>       Maybe you are trying to describe a different scenario than  
> either of these, but I'm having trouble coming up with another one.   
> And in either case, I'm confused how you narrowed it down to  
> iPhones, and not to a particular carrier?
>
>       (Hmm, maybe with scenario #2, is it possible the customer's  
> phone is moving between the mobile data network and a local WiFi  
> network while in the middle of a call?  You'd hope the phone would  
> be smart enough to either keep the existing session on the same  
> network interface that it began on [though that might be difficult  
> in the case where it *started* on WiFi & the WiFi network  
> disappeared / moved out of range], or at least properly notify the  
> app that the network interface is changing, in which case the app  
> could have a fighting chance of getting a re-INVITE sent out?  If  
> you look at the source IPs involved, are they always the carrier's  
> IPs, or are you seeing the traffic move between completely unrelated  
> networks/ASes?)
>
>       -- Nathan
>
>         FROM: VoiceOps [mailto:voiceops-bounces at voiceops.org] ON  
> BEHALF OF Richard Jobson via VoiceOps
> SENT: Monday, June 3, 2024 11:08 AM
> TO: voiceops at voiceops.org
> SUBJECT: [VoiceOps] Has anyone seen this? Voice UCaaS application on  
> iPhone generated call: switching source IP address mid-call with no  
> SIP signaling to indicate
>
>       Just curious as to whether the community thinks this is a  
> network configuration issue or a Mobile app issue
>
>       This is either …
>
>
> 1.        Something to do with the app on the iPhone
>
>       2.       Or is the Wireless IMS Network SBC that is changing  
> the srce IP Addr mid-call
>
>       3.            Or RTP has been routed to a different Wireless  
> IMS Network SBC mid-call
>
>       this behavior is totally noncompliant to the RFC.
>
>       The Oracle SBC in our ITSP network maintains the call up  
> because the SSRC remains the same. However, when this happens, a  
> second or third time it gets complicated .
>
>       Richard Jobson
> Teraquant Corporation
> ph: 719 488 1003
> d/l: (719) 766-8523
> www.teraquant.com
> richard at teraquant.com[1]
> https://www.linkedin.com/in/uc-expert-monitoring/



Links:
------
[1] http://www.teraquant.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240604/21903c9d/attachment.htm>