End user switched back to the old ISP. We couldn't have work stoppage any more for something as simple as SIP registration.
How can such a large company have something so simple as SIP registration mangled up?
How can such a large company have something so simple as SIP
registration mangled up?
Very little incentive to fix it. The number of customers that are able to switch providers when something like this doesnât work is a fractional percentage of overall customer churn.
The MBAs say itâs cheaper to ignore it, so thatâs how it goes.
Of course, Comcast sells its own VoIP services, which Iâll bet work just fine; so they donât have a huge incentive to go out of their way to make their competitorsâ product work on their network.
Jim Shankland
Does this apply only to customers using their proprietary gateway or customers on a CGNAT service with them?
I have been a Comcast customer for years, with my own equipment, and have never had issues using Polycom SIP phones on RingCentral.
This is getting a little concerning for me as we are planning to roll out SIP phones direct to users at home soon.
Brandon Ambrose
Network Administrator
We run into it all the time when using the Comcast-provided "business
class" equipment and a non-Comcast SIP provider.
When we had a fiber hand-off from Comcast (about 3 years ago) and used a
non-Comcast SIP provider we had no issues.
-A
They do not do CGNAT, as far as I know. (Fixed wired broadband should never be behind CGNAT, but thatâs a topic for another thread 
)
Should only apply if you are using Comcastâs CPE for NAT. I had Comcast service some time ago, using their rental CPE in bridged mode, and had no issues with third party SIP.
They sell competing VoIP services.
My recent experience with Comcast Business is that it does not permit fixed-IPs with either bridged mode or customer modems.
Also they have a âfeatureâ called SecurityEdge which is now on by default (didnât used to be). It blocks all sorts of things but currently it is possible to go to the account website and turn it back off. Itâs pretty evil for anyone that wants to, e.g., run a DNS server (evil = not possible due to a number of things including caching things it shouldnât etc.). I donât know about SIP as I have not attempted to run SIP over that particular connection, but I wonder if it might interfere.
Just push these end users to use softphones. There are very few use cases where a hard phone is necessary.
1 Like
What kinds of third party SIP are you all having so much issue with? I manage a lot of accounts using the big, hosted providers and plenty of the endpoints sit behind Xfinity/Comcast boxes without issue.
The dropping registrations just sound like timer and firewall configurations. By rule, I try to always go bridged mode with Comcast provided boxes, but even when not I canât recall having an issue like this except via the normal things like ALG being enabled or some type of security inspections causing trouble. And TLS is the way 100%
Is it possible it's being run over UDP? Is UDP even practical with SIP these days given bloat?
Mike
Hell, we still convert people with 1980s Meridian phone systems. Those are not candidates to do anything but move to an IP handset.
A lot of people like their phone to work all the time, even when they have to reboot their PC.
Shane
What about a single mom who is working from home and so needs a wireless phone to keep with her while she's moving around the house taking care of the kids or doing some house hold activities during the day?
How would you implement that into a soft phone?
That aside though.... how would a softphone be any different for registration from a hardware phone? It's not a device issue, it's a protocol issue.
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.
Mike
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
Are you aware of whether or not Xfinity is doing CGNAT for either of you?
Googling, I get conflicting results, some saying they use CGNAT, some saying they
don't. If they do,
I wonder if their CGNAT routers have SIP ALG enabled or
disabled. Unfortunately, these are the sorts of questions I suspect first level
support can't help you with.
HA! I just ran into this; albeit Wave (Astound). While dealing with a (mis)configured
router/modem situation. The support person said; What's the sip ALG setting? I wonder
what that setting should be? I had to answer; It's primarily used for VIOP. It has no
affect on our current problem.
So yes. They probably have no idea.