<div dir="ltr">Hi Alex,<div><br></div><div>Thanks for your quick response. </div><div><br></div><div>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.</div><div><br></div><div>2. Since Asterisk is also a serving as PSTN gateway, I like this because it allows me to control calls with SIP endpoints separately. We have no issues with all PSTN calls and I'd like to keep it that way :)</div><div><br></div><div>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. 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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div style="font-family:Helvetica;font-size:medium">Benjamin Fitzgerald</div><div style="font-family:Helvetica;font-size:medium">LETS Corporation</div><div style="font-family:Helvetica;font-size:medium">(925) 235-1154</div><div style="font-family:Helvetica;font-size:medium"><span style="text-align:-webkit-auto"><a href="mailto:ben@letscorp.us" style="color:rgb(17,85,204)" target="_blank">ben@letscorp.us</a></span></div><div style="font-family:Helvetica;font-size:medium"><br></div><div style="font-family:Helvetica;font-size:medium"><br></div><div><img src="https://drive.google.com/a/letscorp.us/uc?export=view&id=0BypXJ2tJXo79c0ZaNXJVUWFlMVk"><br></div><br style="font-family:Helvetica;font-size:medium"><span style="font-family:Helvetica;font-size:medium">*******Confidential Notice: </span><br style="font-family:Helvetica;font-size:medium"><span style="font-family:Helvetica;font-size:medium">This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete this message from all computers and contact Orion Systems/LETS Corp immediately by return e-mail and/or telephone at </span><a value="+19255665600" style="color:rgb(17,85,204);font-family:Helvetica;font-size:medium">(925) 566-5600</a><br></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 8, 2016 at 12:08 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Benjamin,<br>
<br>
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).<br>
<br>
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:<br>
<br>
1. You make it sound like the Asterisk channel stays up indefinitely in such a situation. Why is that?<br>
<br>
The normal behaviour is for Asterisk to hang up the call after some number of seconds without incoming RTP.<br>
<br>
It's likely that tuning the RTP timeout setting to something conservative[1] would solve a lot of your problems off the bat.<br>
<br>
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:<br>
<br>
<a href="http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#timeout-avp-id" rel="noreferrer" target="_blank">http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#timeout-avp-id</a><br>
<br>
<a href="http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#default-timeout-id" rel="noreferrer" target="_blank">http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#default-timeout-id</a><br>
<br>
<a href="http://www.kamailio.org/wiki/cookbooks/4.3.x/pseudovariables#dlg_ctx_attr" rel="noreferrer" target="_blank">http://www.kamailio.org/wiki/cookbooks/4.3.x/pseudovariables#dlg_ctx_attr</a><br>
<br>
3. The 'dialog' module also has a dead peer detection / keepalive scheme based on sequential OPTIONS pings:<br>
<br>
<a href="http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp1898328" rel="noreferrer" target="_blank">http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp1898328</a><br>
<br>
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.<br>
<br>
4. There are various other signalling-oriented UA-side mechanisms intended to solve this problem as well, such as SIP Session Timers (RFC 4028).<br>
<br>
...<br>
<br>
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.<br>
<br>
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.<br>
<br>
-- Alex<br>
<br>
[1] Notwithstanding RTP interruptions due to VAD, hold, etc.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
303 Perimeter Center North, Suite 300<br>
Atlanta, GA 30346<br>
United States<br>
<br>
Tel: <a href="tel:%2B1-800-250-5920" value="+18002505920" target="_blank">+1-800-250-5920</a> (toll-free) / <a href="tel:%2B1-678-954-0671" value="+16789540671" target="_blank">+1-678-954-0671</a> (direct)<br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a></font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br></div>