Incoming calls stop working after a while, registering again fixes it

[martinezpt]

Hi,

I'm having issues with an unsupported Generic SIP Trunk. The provider is actually Vodafone, who uses SIP for their residential fiber optic installations in my country.
I am able to get the incoming and outgoing calls to work, with a Generic SIP Trunk (registration based).
However, incoming calls stop working after a while (maybe a day or less).
To get them working, I edit the SIP trunk and just click OK, which updates the "Register Sent" and "Register OK" dates and makes it work again.
If I don't manually do this, the "Register sent" and "Register OK" dates never change.
I've read many threads here, most of them many years old so I don't know how up to date the answers.

My questions are:
- Is the "Re-Register Timeout", the time between attempts to register or simply the time to wait before giving up on a registration attempt?
The answer I've found more convincing is that it is just the suggested value for the registration interval sent to the provider.
- Can I at least automate this task I've been doing multiple times a day, of simply editing/saving the trunk to force the re-registration?

Any help is appreciated. Thanks!

 

[YiannisH_3CX]

Hello @martinezpt

- Is the "Re-Register Timeout", the time between attempts to register or simply the time to wait before giving up on a registration attempt?

The Re-Register Timeout is the value the PBX is sending to the provider as a suggested time duration until the registration between them expires. Once the timeout value is established (the provider sets the re-registration timeout in the 200 OK message) the PBX will send a new registration attempt to the provider before the registration time expires.

- Can I at least automate this task I've been doing multiple times a day, of simply editing/saving the trunk to force the re-registration?

I think you should troubleshoot the reason this is happening rather than employing a workaround that re-registers the trunk. You could also choose a supported provider that has been tested with 3CX and it is known to work. https://www.3cx.com/partners/sip-trunks/

 

[martinezpt]

Thanks for the response.

I tried digging deeper and captured the forced registration (the one that happens when I edit and save the trunk).

Found something interesting, at least to me that I'm used to monitoring HTTP traffic, not SIP.

I'll try to summarize what I think is relevant here, removing headers I don't think are relevant and redacting some portions. I can post the whole capture if needed.

I see first an authenticated "REGISTER" request, with no "Expires" header, and a successful response. If I interpret this correctly, the service doesn't report an "expires" value (or reports 0).

REGISTER sip:{destination-host}:5060 SIP/2.0
Via: SIP/2.0/UDP {source-ip}:5060;branch=z9hG4bK-524287-1---1db47b38b5838156;rport
Call-ID: RkGcN_8_8rHp62Nyn-7Bhg..
Contact: <sip:{user}@{source-ip}:5060;rinstance=c84521af5faeb026>;expires=0
CSeq: 3 REGISTER
Authorization: Digest username="........

SIP/2.0 200 OK
Via: SIP/2.0/UDP {source-host}:5060;branch=z9hG4bK-524287-1---1db47b38b5838156;received={destination-ip};rport=31012
Call-ID: RkGcN_8_8rHp62Nyn-7Bhg..
CSeq: 3 REGISTER
Contact: <sip:+{user}@{source-ip}:5060;rinstance=c84521af5faeb026>;expires=0

Then, there's an unauthenticated call, with the "Expires" header with the value I've set on the trunk's "Re-Register timeout" that fails due to the missing authentication:

REGISTER sip:{destination-host}:5060 SIP/2.0
Via: SIP/2.0/UDP {source-ip}:5060;branch=z9hG4bK-524287-1---9a2b8c5238168f79;rport
Contact: <sip:{user}@{source-ip}:5060;rinstance=bb0cb7ce86b1c15b>
Call-ID: ENVi14RW-AhLqdmYqjVIBQ..
CSeq: 1 REGISTER
Expires: 120

SIP/2.0 401 Unauthorized 11030230330
Via: SIP/2.0/UDP {source-ip}:5060;branch=z9hG4bK-524287-1---9a2b8c5238168f79;received={destination-ip};rport=31012
Call-ID: ENVi14RW-AhLqdmYqjVIBQ..
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm=".....

And finally I see another REGISTER request, this time authenticated and also containing the "Expires header, to which the service replies with an "expires" value set to 900 (15 minutes)

REGISTER sip:{destination-host}:5060 SIP/2.0
Via: SIP/2.0/UDP {source-ip}:5060;branch=z9hG4bK-524287-1---5949c462feec5f6e;rport
Contact: <sip:{user}@{source-ip}:5060;rinstance=bb0cb7ce86b1c15b>
Call-ID: ENVi14RW-AhLqdmYqjVIBQ..
CSeq: 2 REGISTER
Expires: 120
Authorization: Digest username="....


SIP/2.0 200 OK
Via: SIP/2.0/UDP {source-ip}:5060;branch=z9hG4bK-524287-1---5949c462feec5f6e;received={destination-ip};rport=31012
Call-ID: ENVi14RW-AhLqdmYqjVIBQ..
CSeq: 2 REGISTER
Authentication-Info: nextnonce=.......
P-Associated-URI: <sip:{user}@{destination-host}>,<tel:{phone-number}>
Contact: <sip:{user}@{source-ip}:5060;rinstance=bb0cb7ce86b1c15b>;expires=900

A couple of questions:
- Is this the way for the service to report the "refresh" time? As a key-value in the Contact header?
- I posted the capture in the order it was presented in the capture file, but I wonder if the "CSeq" value has any relevance, in which case, what I think was the first request was actually the last.

Now, assuming the server sets the "refresh" time to 900 seconds, I can tell that I waited those 15 minutes, and the "Register Sent" and "Register OK" times didn't change. Nothing got logged in the Activity log around that time.

I know the provider is unsupported but I have no choice of provider in this case since this is the one that has the number we need to access and it's not possible to transfer it to a supported provider.

Any help is appreciated as always. Thanks.

 

[YiannisH_3CX]

What you are reporting is the expected behaviour when re-registering to a provider.
Since you clicked on Edit and OK this forces the PBX to un-register from the provider (expires value = 0) and then re-register.
The PBX will send the registration message and the provider will request authentication which in that case the PBX will resend the Registration message that will include Auth. details.
The Provider will then have to respond with 200 OK if everything checks out and in that moment the trunk will be registered.
The PBX will then read the expiration value the provider is sending and will re-register after 90% of the time specified. So if the provider is sending 900 then the PBX will send a re-register message after 810 seconds.

 

[martinezpt]

Thanks for confirming. What you said makes perfect sense.

What I can't understand is why it's not re-registering after the 15 minutes.
I've enabled Medium logging (which logs the registration event), manually forced the registration and watched the logs for 20 minutes and no registration event was sent after the first one.
I've been watching the logs for the past 4 hours and only one "re-registration" was done, after 3cx had an event for a change of the public IP address.

I've even enabled verbose logging and watched it for 20 mins after a manual registration and it showed nothing relevant around the time the re-registration should occur.

Any tips on how to debug this scenario?


By the way, just a tip for 3cx management: in my country, lots of traditional PSTN providers (Vodafone, etc.) are switching to fiber optic and providing phone services on top of it using VOIP. This makes using 3cx with these services extremely appealing as companies can just plug a 3cx box and move from traditional telephony to awesome solutions like 3cx with very little effort. Aside from this small issue, it was extremely easy to setup!
I know it's hard to support a provider that doesn't want to cooperate much (Vodafone sells a similar solution to 3cx with an expensive price tag) but it could be worth looking into.

 

[YiannisH_3CX]

I would recommend running a wireshark capture for 20 minutes to try and catch the PBX registration as it is easily missed in the Activity log. You can filter the capture with the providers iP or filter for registration attempts and see exactly what is being sent by the PBX and what the reply is from the provider.

 

[martinezpt]

Well I wasn't expecting to see what I saw: after running a capture twice, I found that the register request is being sent about every 13 mins as expected, with 200 OK response. Everything seems to be working fine, it's just not showing in the "activity log" and it's not updating the "Register Sent" and "Register OK" columns of the SIP Trunk.
Is this normal (not showing in the Activity Log and SIP Trunk)?

I've had a few times where I was missing incoming calls and it got fixed by re-registering which made me look at the last registration time and led to my conclusion that it wasn't re-registering... I think I will have to stop refreshing it manually and wait for issues to happen again to try to debug it.

 

[YiannisH_3CX]

The Activity log is set to Verbose should reflect the Register messages to the provider. The management console columns for the sip trunk show the register since state of the trunk and do not reflect every successful register message.
Since the trunk re-registers successfully then the issue must be something different. Wireshark should help you debug the issue when it re-occurs