Configure 3CX to terminate call if registration expires

[dawi]

Is it possible to configure 3CX to automatically terminate active calls when the SIP registration has not been renewed? In other words, if the device doesn't renew the registration on time, before expiry, the call gets terminated by the PBX.
I want to test the case where the SIP phone/device has not re-registered on time. Some PBXs implement the behavior of killing the call. Can 3CX be configured to do that?

 

[leejor]

In other words, you want a way to limit all outbound calls to a certain length?

I have not seen anything specific regarding that, not to say it doesn't exist, but I assume you have done some testing. With re-registration times, for the most part, they are dictated (suggested) by the server you register with. You can manually set la time, but in some cases, only a lower value will override the value sent by the provider. If it is set too low then the provider will complain that you are re-registering too often which could overwhelm the server if implemented by too many users. So, if for example, the provider want you to register every 45 minutes and you manually set 1 hour, the PBX may (I haven't tested this) still re-register every 45 minutes being aware that if it doesn't, then a trunk risks not being able to accept calls.

Because a call is already in progress, I would see it as being highly unlikely that it would be forced to drop. I'm sure that the majority of users would have a problem with that.

 

[dawi]

Thanks for the response but let me clarify, I am talking about SIP devices, not trunks.
Say I have device A and device B registering with 3CX with an expiry of 300 seconds.
A and B are in a call. B for some reason fails to re-register within the 300 sec period. I want to see if there is a way 3CX would kill the call between A and B after the 5 minute mark.
This is mostly to test a bug fix. Our device was failing to re-register on time, under certain conditions, only when it was in a call. It re-registered fine when idle, but not when in a call. Our testing using 3CX never caught this bug because 3CX doesn't care that the device's registration was already expired. With another SIP PBX we have seen that this same condition was causing the call to be terminated. When we debugged, we realized it is the PBX that is killing the call because B didn't re-register on time. I can see this policy being used to protect against failed endpoints. In our case it was not a failed endpoint, it was just failing to renew the registration *while in call*.
I am trying to use 3CX to validate our fix.

 

[leejor]

It may be that when a device is engaged, no re-registration is sent, until the device is idle, as it isn't required. That is my speculation, I'm sure that this somewhere in the SIP specifications. Had a quick look though this but nothing stood out. http://tools.ietf.org/html/rfc3680 From experience, using linksys/Cisco devices, the re-registration time, in the majority of these devices, defaults to 3600 seconds (one hour), and even with that figure remaining in the settings, the device will still re-register every 1800 seconds as that is what the 3CX PBX wants (the default)

Say I have device A and device B registering with 3CX with an expiry of 300 seconds.

What has determined the 300 second figure? Is this manually input into the device, or what has been "set" by the server?

Came across this... http://sipforum.org/pipermail/discussion/2006-April/000424.html

And this..... http://sipforum.org/pipermail/discussion/2013-March/009725.html

 

[dawi]

300 sec is the expiry time granted by the PBX. Our device offered 1800, the PBX overrides with 300 in the register response. But that's besides the point, even if the offered expiry matches the allowed expiry, the same issue happens.

As you said, when the device is engaged, no re-registration is sent, until it becomes idle. We have decided that this behavior is indeed a bug. Even if it is not "required" by the RFC, it causes interoperability problems with at least one other SIP server, so likely it will be problematic with others. Best to fix it and always renew the registration on time, engaged or not engaged.

So I gather there is no way to cause 3CX to do this enforcement of terminating the calls for devices which have not renewed their registration on time?

 

[leejor]

As you said, when the device is engaged, no re-registration is sent, until it becomes idle.

What I said, is that it may be this way, I have not done any tests myself to confirm the behaviour. Up to this point, it is not something that I've had a reason to investigate.

If you have tested SIP devices, and found that when engaged, they do not send a re-registration until the call ends, then I would have to assume that is design intent and not a bug as many products are at the "mature" stage with several bug fixes behind them.

3CX would have to provide clarification on how they expect this to work, both from the perspective of a device registering to the PBX, as well as the PBX registering a trunk to a provider.

I wonder how this would work if two remote extensions were engaged in a lengthy call, with no audio passing through the PBX. Once the PBX had established the connection between the devices, until it has to reach one of the devices again, should it care if either device re-registers in the mean time? You seem to be concerned that a call may not "drop" when you believe it should, perhaps in the middle of a conversation. I would really think that this would be a real issue for most users.

 

[lneblett]

If the concern is a hung endpoint, then 3CX does have a max call length feature in the advanced settings. While not what you are looking for specifically, it may help.

You might also look at RFC4028 which discusses SIP session timers and how they are used in calls and see if you can use.

The issue I see is that if there is a hung endpoint, then is it always a fact that the device is not sending any data that would cause for the registration to be valid?

I have had a few hung calls, but at remote client sites whereupon I would disconnect the call via 3CX and all was fine afterwards. It has been extremely rare in my experience, but then I suppose it could be more prevalent than I think and the clients may not know or notice and as a result I am not called. However, the devices did show as registered.