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

Mon Jun 3 23:26:28 EDT 2024

I'm growing more and more confused by the problem description, and feel like we
are missing some crucial details...

If the calls are truly being terminated over the carrier's own IMS core, then
NAT actually should not be involved.  Most U.S. carriers run single-stack IPv6
on their IMS APN.  So the leg of the call between end-user device and IMS core
is 100% IPv6-native.  If the call is then getting passed to you via IPv4, the
carrier must have some kind of SBC + media proxy at their edge that sits
between the IPv6 IMS network and however the peering is set up between you and
the carrier(s) in question (over IPv4 public internet, or private IPv4
point-to-point circuit, or perhaps VPN over IPv4 public internet with IPv4 also
used within the tunnel?).

Also, if the call is genuinely coming from carrier's IMS core, I don't see what
the UC app you keep referencing that the end-user might happen to be running
has to do with anything.  If the same caller were to call a DID of yours from
the iPhone's native phone app, I'd expect/assume you would experience the same.

Finally, if this is truly a call coming from the carrier's IMS core, then the 
WiFi handoff scenario I postulated earlier isn't even applicable.  I said that
only makes sense in the context of "scenario #2", that is, when the call is
made by an app over regular internet data directly to a SIP server or proxy
that *you* run, and does *not* touch the carrier's IMS core at all.  In that
scenario, the user's public internet address would be changing each time it
bounced between the mobile network and WiFi.  But actual WiFi Calling / VoWiFi
works by having the phone establish an IPsec VPN tunnel between itself (while
connected to a WiFi network) and the carrier's internet-facing ePDG gateway,
within which it communicates directly with the native IPv6 IMS core.  Thus
whether a mobile voice call is happening via a mobile radio tower or over WiFi,
the phone is still talking to the carrier P-CSCF

From: Richard Jobson [mailto:richard at teraquant.com]
Sent: Monday, June 3, 2024 7:32 PM
To: 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 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,

For your convenience, please click here to schedule a time for us to talk.

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. 

--

NOTICE: This electronic mail transmission may contain confidential information
and is intended only for the person(s) named. Any use, copying, or disclosure
by any other person is strictly prohibited. If you have received this
transmission in error, please notify the sender via e-mail.

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 .

Many Thanks & Best Regards,

For your convenience, please click here to schedule a time for us to talk.

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. 

--

NOTICE: This electronic mail transmission may contain confidential information
and is intended only for the person(s) named. Any use, copying, or disclosure
by any other person is strictly prohibited. If you have received this
transmission in error, please notify the sender via e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20240603/d788d0c1/attachment-0001.htm>