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