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

[Alex Balashov]

On 01/08/2016 04:32 PM, Benjamin Fitzgerald wrote:

> I think #1 fixed it for me! Thank you so much! I changed the RTP timeout
> on a test account SIP account and immediately it resolved the issue.

Excellent! Happy to help.

> You're right, sending a BYE would effectively synchronize them
> however I did not think keepalive using OPTIONS scheme would send a
> BYE message in the event of a dead RTP session. That's why I thought
> this scheme may not work.

No, indeed it would not; Kamailio has no awareness of RTP whatsoever. 
All such schemes, including this one, as well as SSTs, are aimed at 
detecting dead peers purely from signalling (that is, SIP) alone.

The way the OPTIONS keepalive flow works, for example, is:

UA A          Proxy           UA B
==================================
                ---- OPTIONS ---->
                <---- 200 OK -----
<--- OPTIONS ----
--- 200 OK ---->

If UA B goes away:

UA A         Proxy            UA B
==================================
               ---- OPTIONS ---->
               [no response]
               ...

               ------- BYE ------->
<---- BYE -----
--- 200 OK --->

The BYEs are crafted by Kamailio to (a) look to UA A like they came from 
UA B and (b) to look to UA B like they came from UA A. This is because a 
proxy cannot, formally speaking, endogenously originate in-dialog 
requests. So, it's definitely a spoof-hack, but it works.

This mimics the more typical B2BUA-based approach of periodically 
hitting both ends with empty reinvites whose effect is nullary (i.e. no 
SDP amendments or remote dialog URI changes), and whose sole purpose is 
to see if a 200 OK response is returned. If not, you can assume the 
endpoint's dead or unreachable.

All proxy-side measures are going to operate on SIP solely.

> I suppose I phrased this incorrectly as Kamailio thinks the endpoint
> is in a call, when really it is just Asterisk and I am personally
> associating the state with these transactions.

Well, it's understandable that you think in call-centric terms; we all 
do. It just becomes important when illuminating distinctions tied up in 
protocol semantics. It's a task requiring some pedantry.

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