<div dir="ltr"><font color="#3366ff"><font><font face="tahoma,sans-serif">Hello,<br><br>In SIP, session timers can be used to periodically ping the UAC (using a re-INVITE or UPDATE) to know if it&#39;s alive or not. Then action can be taken - terminating the call.<br>


<br></font></font></font><font color="#3366ff"><font><font face="tahoma,sans-serif">Kamailio has the SST (SIP Session Timer) 
module which only enforces a minimum session timer value for UACs, but 
not a maximum one. It doesn&#39;t ping the UACs neither. This is fine because the RFC stops here. A nice improvement to Kamailio would be to augment the SST module with a feature which enforces a maximum session timer value and pings UACs. Another suggestion would be to rely on nathelper&#39;s keepalive results to take a decision after a keepalive times out, but then we&#39;d have to terminate all dialogs in which the UAC that is not responding is present, since nathelper&#39;s keepalive are out-of-dialog. No very neat, but functional.<br>

<br></font></font></font><font color="#3366ff"><font><font face="tahoma,sans-serif">And I don&#39;t think the dialog module can do anything about this problem.</font></font></font><br><font color="#3366ff"><font><font face="tahoma,sans-serif">
<br>I know that what I am suggesting may not be defined in RFCs, and so are some features of SIP servers, but in my opinion should be implemented as it adds a great value to Kamailio.</font></font></font><br>
<font color="#3366ff"><font><font face="tahoma,sans-serif"><br>We cannot rely on RTP timeout since a UAC may use a silence-detection codec and be silent for some time, or may put a call on hold for a while, not sending RTP packets in both cases. This is why RTP timeout detection is not reliable. Anyway, mediaproxy timeouts ONLY AND ONLY in the case it doesn&#39;t receive RTP packets from BOTH UACs, not only one, for the reasons mentioned. I don&#39;t know about rtppoxy, maybe others can tell more about it.<br>

<br>One solution if you really need to solve your problem would be to put a B2BUA in the SIP path, such as Asterisk or FreeSwitch. They enforce a maximum session timer which UACs can use to ping themselves every now and then, and Asterisk can even ping the UACs and terminate the call if one of them doesn&#39;t respond. The downside: lower performance and higher cost. Asterisk is very heavy and Kamailio can handle many, many more calls, so you&#39;ll have to load balance to several Asterisk servers if you have a single Kamailio machine handling thousands of simultaneous calls.<br>

<br>Kamailio developers out there, what about boosting the SST module with new features? Or creating an SSTX module?<br clear="all"></font></font></font><div dir="ltr"><font color="#3366ff" face="tahoma, sans-serif"><br>
</font><div>
<font color="#3366ff" face="tahoma, sans-serif">Reda</font></div></div><br>
<br><br><div class="gmail_quote">On Tue, Mar 20, 2012 at 07:35, SamyGo <span dir="ltr">&lt;<a href="mailto:govoiper@gmail.com" target="_blank">govoiper@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi,<div><br><div>Yes that is the behaviour when the media isn&#39;t flowing through a regulatory tool (in-terms it sees the media and know call is actually going on rtpproxy/media-proxy)  but in the absence of any such tool SIP server is not aware that the call-media is still in progress or is dead ! so it always assume that the call is active and hence the BYE signals are never originated from server end to shutdown the call.<br>



<br>I am definitely not an expert but I am guessing that dialogue module do some keepalive tests for an ongoing session and not sure what it do if either end fails to respond !!</div><div><br></div><div>Regards,</div><div>



Sammy</div><div><div><div><br><div class="gmail_quote">On Tue, Mar 20, 2012 at 11:04 AM, Vineet Menon <span dir="ltr">&lt;<a href="mailto:mvineetmenon@gmail.com" target="_blank">mvineetmenon@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i guess it should time out...the other end...since it has no way of knowing that the other end is no more present...<div><br clear="all">Regards,<br><br>Vineet Menon<div><div><br><br><br>
<br><br><div class="gmail_quote">On 20 March 2012 11:30, Rabary <span dir="ltr">&lt;<a href="mailto:teddy@gulfsat.mg" target="_blank">teddy@gulfsat.mg</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





Hi mailing,<br>
<br>
Newbie to kamailio, I follow this tuto <a href="http://nil.uniza.sk/sip/kamailio/adding-mysql-support-kamailio-31-debian-lenny" target="_blank">http://nil.uniza.sk/sip/<u></u>kamailio/adding-mysql-support-<u></u>kamailio-31-debian-lenny</a> for the registration SIP via mysql database and it works fine, but I saw that when during the call we disconnect the called UAC from network or turn the power off the caller UAC don&#39;t hangup.<br>






Is there any tool for how to hangup call when the UAC on the other side has no network connection or it isn&#39;t power on durring a call ?<br>
I heard for mediaroxy or rtpproxy but I don&#39;t know if them can do what I except to haveand we also use ip routing to make kamailio server to communicate with the UAC so we don&#39;t use NAT.<br>
<br>
Our topology is:<br>
kamailio (with public IP address) ---&gt; cisco switch ---&gt; LAN ---&gt; UAC (with private IP address)<br>
<br>
Thanks in advance.<span><font color="#888888"><br>
<br>
-- <br>
Inutile d&#39;imprimer ce mail<br>
<br>
<br>
______________________________<u></u>_________________<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" target="_blank">http://lists.sip-router.org/<u></u>cgi-bin/mailman/listinfo/sr-<u></u>users</a><br>
</font></span></blockquote></div><br></div></div></div>
<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" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div></div></div></div>
<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" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>