[VoiceOps] Has anyone seen this? Voice UCaaS application on iPhone generated call: switching source IP address mid-call with no SIP signaling to indicate
Nathan Anderson
nathana at fsr.com
Tue Jun 4 03:23:07 EDT 2024
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?
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
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
https://www.linkedin.com/in/uc-expert-monitoring/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240604/d1880ab6/attachment-0001.htm>
More information about the VoiceOps
mailing list