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

Tue Jun 4 13:04:06 EDT 2024

  Hi Nathan-

In our RFC8108 experience (so far), SSRC changes are a common  
occurrence but codec type rarely changes. **  As you mention, it's  
simply a "new stream", for example a handoff between cell towers.

Regarding an IP addr/port change with SSRC staying the same, as I  
recall one problem we were seeing is in some cases there are  
concurrent changes in RTP payload type, timestamps and/or sequence  
numbers. I believe that's why we still have it as a config option -  
i.e. user has to enable this and decide how to treat those changes.

-Jeff

** in any case, we implement a new codec and jitter buffer on each new  
SSRC to avoid any audio artifacts. Also interesting to note that  
sometimes a prior SSRC resumes

Quoting Nathan Anderson via VoiceOps <voiceops at voiceops.org>:

> Hmm.  I haven't yet read it end-to-end & so maybe I've missed  
> something, but I'm not seeing anything within the cited RFC that  
> allows for arbitrary SSRC changes to occur mid-stream for a  
> particular medium.  As far as I can tell, it just talks about  
> multiplexing multiple streams within a session (== each stream  
> should have its own unique SSRC), and also about changing codecs  
> mid-stream (== essentially one stream ends and a new one begins, so  
> a new SSRC *should* be generated).  But each SSRC should remain  
> valid and constant for the entire life of any given stream within  
> the session.
>
>    Even if it were valid, though, for an SSRC to suddenly change  
> without the parameters of the medium also changing, I'm not clear on  
> how that would present a problem?  You're essentially tracking 5  
> things: source IP, source port, dest IP, dest port, RTP SSRC.  If  
> only one of the two IPs changes but the other remains the same & so  
> does the SSRC, it's obviously still the same stream...right?
>
>    -- Nathan
>
>      FROM: Jeff Brower [mailto:jbrower at signalogic.com]
> SENT: Monday, June 3, 2024 10:10 PM
> TO: Richard Jobson
> CC: Nathan Anderson; 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
>
>    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/
>>
>>
>>         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/4da9730d/attachment.htm>