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/

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to