On 9/14/24 9:04 AM, Brandon Martin wrote:
On 9/13/24 11:20, Michael Thomas wrote:
On 9/13/24 7:19 AM, Matt Hoppes wrote:
Yes. We run lots of SIP UDP over many networks without issue. I
feel like bloat is exactly an application for using UDP?
With TCP won't that cause more bloat/delay? That being said, we
generally see about 3-6 ms between end points and our PBX systems,
so I'm not really worried about delay or bloat... just the XFinity
firewall trashing active sessions.
I'm was just wondering if UDP is still viable for SIP these days. I'm
talking about the bloat of accreted features in SIP blowing out MTU
on a message basis. In any case, running it over UDP sounds
suspiciously like it could be tickling firewall timeouts. SIP is so
low volume that it hardly matters for the client side and even for
the server side it's not like TCP is a big deal. You really should be
running TLS in any case. Who knows how well DTLS is support on
proxies, or whether it's supported at all.
My understanding is that some of the "really big boys" still prefer to
run SIP over UDP because it allows them to somewhat seamlessly handle
signaling endpoint failover without a ton of TCP connection state
tracking by delegating it to the routing layer. I don't think most of
those folks (aside from maybe the 1st-party bundled consumer network
operators who obviously won't break their own product) are handling a
ton of registrations, though, and are instead just passing around
INVITEs between largely statically- (or otherwise pre-) configured
places.
If your SIP messages blow up the MTU, it should resort to IP-layer
fragmentation. Of course we all know how well this works in practice.
Do any IPv4 routers actually fragment in-path, anymore?
For consumer endpoints, I do think SIP over TLS over TCP is the way to
go. Nothing's going to unintentionally break that. If it does break,
it's probably just outright blocked, and even then you can probably
just run it over port 443 and have it work outside of TLS MITM
environments like larger enterprises.
Obviously the media is still UDP and subject to meddling.
My understanding is that RTP in VoLTE uses DTLS for SRTP. I only know
this second hand and not from an operator, so feel free to correct me.
But it would all be rather pointless if the signaling traffic was
unencrypted and more importantly unauthenticated -- if they're using
DTLS I can't imagine that they are actually using real certs for
identity for the endpoints, and are just using it to do key exchange. My
google-fu has been pretty bad trying to figure out how this is
implemented though. If they aren't authenticating end to end for SRTP,
it seems like it would make for a trivial MITM attack against the
signaling layer, especially given UDP.
I wonder if QUIC would change people's attitudes about this. Honestly
I'd rather have the security over the few extra milliseconds of
signaling latency.
By failover are you talking about a proxy going down or something? Isn't
that something well understood in HTTP-land? I wonder if SIP over HTTP
is a thing yet :)
Mike
