Comcast and incoming call

[decibel]

It seems that every time Comcast has an outage, 3CX 15.5 loses the ability to receive calls until I restart services. The first time it happened I reached out to our VoIP provider and they informed me that this is a known issue with 15.X. Can someone verify this? And if so, is there a way to script a services restart after internet services are restored?

 

[decibel]

*crickets*

I find it hard to believe that my little question stumped the fine group of folks on this forum.

 

[leejor]

It may simply be that no regular forum user has Comcast service, and has experienced the same issue.

Until someone from 3CX can confirm that it is a known PBX issue (is it confirmed that previous versions are unaffected?), you might want to narrow down exactly what the issue is. Is it a registration issue...3CX unable to re-register, and "gives up" after a while. is it something to do with loosing all internet connectivity (i assume that is what is happening), perhaps something involving the Modem/router and its; interaction with 3CX?

Does the trunk show as not registered after an outage?

Personally...I'd be on their backs if the internet were going down that often.

 

[giwm]

We have Comcast... but Metro (fiber). No issues there, but we also have Comcast coax as a failover so our internet hasn't really FULLY gone down. I'd look closely at your firewall.

 

[decibel]

A bit more explanation.

The system has been installed of a few months and in that time, Comcast has went down three times. The first was due to the Level3 issues a few weeks back, the second was the winter storm that hit Atlanta 2 weeks ago and the third was early Wednesday morning. When internet service is restored, everything appears to be okay. The trunk shows as registered and users can make outgoing calls with no problems. Only incoming calls are affected. Logs show that the SIP provider (siptruck.com in this case) can not deliver calls. Simply restarting services solves the issue. A call into the provider is what led my to try restarting services. They informed me that it is a known issue when using Comcast as the ISP.

Would love to find out what the reason is but restarting services seems to be a decent workaround. So the question remains, is there a way to monitor the incoming internet connection and automatically restart service if the connection goes down and comes back up. The system is running on Debian.

 

[leejor]

The trunk shows as registered and users can make outgoing calls with no problems. Only incoming calls are affected. Logs show that the SIP provider (siptruck.com in this case) can not deliver calls.

So the trunks sows as registered (and I assume that your trunks settings require that it does register), that would seem to indicate that you and you VoIP provider were/are able to communicate (along with the fact that you can make outgoing calls). So, the question is, why can't they send calls to you. Are they sending to the wrong IP address? Is it being blocked by your ISP, or something else in between? Does a call attempt even show in the Activity Log?

I assume that you have a static IP, and this isn't an FQDN update issue.

 

[decibel]

Yes static IP address. No incoming call shows in the activity log. Weirdest thing. And as soon as the SIP server restarts, calls start coming in again.

 

[jvivona]

Are you DIGEST authenticated by any chance? We see this every so often because the digest auth times out on the SIP provider - and they don't know where to send the call because the reg hasn't been received. Check your registration timeout as well - bring it down to a smaller number (we use 600 instead of our provider's recommended 7200) - this will cause a re-registration to happen more often.

If it happens again - instead of restarting - what happens if you go into the SIP trunk, disable it and then re-enable it. If that brings it back up - it's your registration with the trunk provider.

We have LOTS of on-premise customers on Comcast and we're not seeing this issue. We don't see this issue in our hosted PBX datacenter environment.

 

[decibel]

Should have mentioned that. Reregistering doesn't solve it. Registration timeout is 120. I don't believe we are DIGEST authenticated but I'm also not 100 percent certain what that means.

 

[jvivona]

hmmm.. So digest is when you send a USER / Password to the Trunk provider - instead of being IP Based. the 2 commonly used options in the SIP Trunks are: IP Based and Register / Account Based (i.e. Digest Authentication).

You might check with your provider and see if they offer the other option (whatever you aren't using) and try it out to see if it's any better / more reliable

 

[decibel]

In that case, yes I am using digest authentication. I'll reach out to them and see if IP based registration is an option.

 

[leejor]

While you're at it, you might want to ask if they have records of your registrations...when they start and stop, to see if the registrations were never received after the internet came back up. Or...did they have an incorrect IP? I'm still a bit surprised that the trunk shows as registered (green) when this happens.

 

[decibel]

Me too. And as previously mentioned, the provider says it is a known issue. So much so that when I explained what was happening to the support tech, the knee jerk, instant response was to restart services. He made it sound like something they see regularly.

 

[YiannisH_3CX]

Hello @decibel

Please note that this is not a known issue to us and we have no reports of this happening. The first thing you need to check after this happens again is if call Invites arrive at the PBX. Wireshark will help you with that. Just run wireshark and make an inbound call. If you do not see the Invite there is not a lot we can do since without an Invite there is no call to be processed by the PBX. If the Invite arrives at the PBX then you should see the reason that causes the call to fail. You could also manually re-register the trunk after Internet comes back and check if the registration is successful