[SR-Users] Kamailio - Asterisk: Handling loss of SIP BYE and dangling channels

[Alex Balashov]

Benjamin,

On 01/08/2016 03:25 PM, Benjamin Fitzgerald wrote:

> 1. Sorry to be unclear, the Asterisk channel does not stay up
> indefinitely. We do have a max timeout but since a large portion of our
> business is based on conference calling, the timeout is rather large. I
> will definitely change the RTP timeout as my first attempt.

Yes, but I was referring specifically to the RTP timeout. If the mobile 
endpoint goes away, it will stop sending RTP. If Asterisk detects that 
no RTP has been received in x seconds, it should hang up the channel, 
after prophylactically sending a BYE for the call in the direction of 
Kamailio/the mobile peer.

I had been under the impression that Asterisk has a fairly conservative 
default RTP timeout anyway, but it seems I may be mistaken:

https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L740

https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L624

(Not sure which SIP channel driver you're using.)

> 3. I'm not sure this will work in my case because the endpoint is
> reachable, but client state is not in sync with the server: i.e.
> Kamailio/Asterisk think it's in a call but the endpoint does not. If
> sending OPTIONS could tell me if the endpoint thinks it's in a call or
> not, then this could potentially work.

Would sending a BYE to both peers not have the effect of synchronising 
them forcefully to a state of "the call is hung up"?

If you're concerned about sending a BYE to an endpoint that thinks the 
call is already hung up, don't be. In that case, it'll simply be 
rejected. You can't negatively affect the state of a dialog that's 
already dead.

Curious, however: when you say "Kamailio/Asterisk think it's in a call", 
how does this apply to Kamailio?

Stateful SIP proxies are transaction-stateful, not dialog-stateful.

Thus, by default, Kamailio doesn't know anything about "calls", but only 
the SIP transactions of which they are made up, and only for so long as 
those transactions are active. The 'dialog' module allows Kamailio to be 
call-stateful, at the cost of additional statekeeping complexity, but 
you should only use this capability if you need it for something (e.g. 
limiting concurrent calls, keepalive/timeout as described previously, etc.)

> On a side note, is there a SIP message that I can send to a client to
> have it report its state? (Registered, Auth Failed, In a call, etc.)

There's no standard query mechanism like this that I am aware of; the 
only way of disseminating such state information with which I'm familiar 
is presence, which is proactively pushed out by the endpoints and 
requires server-side support.

> 4. I do know about SIP Session Timers but chose to not use them during
> the initial deployment (because of Asterisk channel timeout which I know
> realize is too large). Maybe this will help in conjunction with the
> above methods.

SSTs are rather bureaucratic and, in my experience, often incorrectly 
implemented or unsupported. In the SST conception of things, the roles 
in keepalive ping-pong are negotiated entirely between the UAs, and it 
is up to the UAs to maintain those roles. This goes wrong easily enough 
that server-side solutions such as periodic reinvites and other "pings" 
(like the Kamailio dialog module's OPTIONS pings) are a rather popular 
alternative.

> Would you mind expanding on endpoint defense? Specifically with mobile
> client applications? I agree this would be the ideal solution, I'm just
> not sure where to start here.

By "endpoint defence" I simply meant that detecting dead peers should be 
up to the SIP endpoints (mobile SIP client and Asterisk, by the sound of 
it) first and foremost, and that any proxy-side measures should be a 
secondary layer.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/