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 <[email protected]>:
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:[email protected]]
SENT: Monday, June 3, 2024 10:10 PM
TO: Richard Jobson
CC: Nathan Anderson; [email protected]
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 <[email protected]>:
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]
[email protected]
https://www.linkedin.com/in/uc-expert-monitoring/
FROM: VoiceOps <[email protected]> on behalf of
Nathan Anderson via VoiceOps <[email protected]>
DATE: Monday, June 3, 2024 at 6:46 PM
TO: [email protected] <[email protected]>
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:[email protected]] ON
BEHALF OF Richard Jobson via VoiceOps
SENT: Monday, June 3, 2024 11:08 AM
TO: [email protected]
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
[email protected][1]
https://www.linkedin.com/in/uc-expert-monitoring/
Links:
------
[1] http://www.teraquant.com/
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
