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

[Alex Balashov]

Hi Benjamin,

To some extent, this is just a perennial, existential problem of using a 
proxy, so part of the answer is going to be that you need fundamentally 
reliable signalling, speaking from the vantage point of something which 
operates are a signalling relay (i.e. Kamailio).

However, I understand that reality does not mirror expectations. As the 
purveyor of a SIP service delivery platform based entirely on Kamailio, 
we run into this problem all the time, particularly since our system 
generates accounting records with billing involvement. There are some 
well-established and canonical solutions:

1. You make it sound like the Asterisk channel stays up indefinitely in 
such a situation. Why is that?

The normal behaviour is for Asterisk to hang up the call after some 
number of seconds without incoming RTP.

It's likely that tuning the RTP timeout setting to something 
conservative[1] would solve a lot of your problems off the bat.

2. The Kamailio 'dialog' module can spoof a BYE toward both endpoints 
based on an absolute dialog timeout (regardless of whether both dialog 
peers are still actively engaged), which can be set globally or on a 
per-dialog basis:

http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#timeout-avp-id

http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#default-timeout-id

http://www.kamailio.org/wiki/cookbooks/4.3.x/pseudovariables#dlg_ctx_attr

3. The 'dialog' module also has a dead peer detection / keepalive scheme 
based on sequential OPTIONS pings:

http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp1898328

If one or both of the peers don't respond to these, the dialog will be 
timed out, and if you've set $dlg_ctx(timeout_bye) = 1, this will result 
in a spoofed BYE toward both peers as well.

4. There are various other signalling-oriented UA-side mechanisms 
intended to solve this problem as well, such as SIP Session Timers (RFC 
4028).

...

Of course, all this depends on the maintenance of dialog state in 
Kamailio, which is an additional complication and a potential wrinkle if 
that data were to be lost.

So, it's a bit hard to say whether Kamailio is the _best_ place to solve 
this problem. The first line of defence really should be at the endpoint 
level on both sides of the proxy. Beyond that, Kamailio does offer some 
pragmatic solutions.

-- Alex

[1] Notwithstanding RTP interruptions due to VAD, hold, etc.

-- 
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/