<br><br><div class="gmail_quote">On Mon, Nov 5, 2012 at 7:40 AM, Dan Pascu <span dir="ltr"><<a href="mailto:dan@ag-projects.com" target="_blank">dan@ag-projects.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 31 Oct 2012, at 21:59, Ryan Bullock wrote:<br>
<br>
> These would make pinging a bit more complicated but may help avoid races:<br>
><br>
> 1. Have the ping aware of when the last INVITE was seen in the dialog (sent from anyone) and only issue its own re-INVITE if it has not seen an INVITE for X seconds in the dialog. Perhaps X could be a lower value if the previous re-INVITE had a negative reply (many clients locally end the call when they receive a negative reply to an INVITE, but may not issue a BYE). Add a little session timer awareness and you may be able to avoid most races.<br>
<br>
</div>This will not solve anything. Client behavior is unpredictable from the server point of view. You cannot estimate when the client will send the next re-INVITE in order to avoid the race.<br>
<div class="im"><br></div></blockquote><div><br>If session timers are negotiated for the call you actually do have an idea of how often refresh should be seen. If the timer passes and no refresh has occurred it should be a safe bet that the call is gone and it is safe to check its status via a re-INVITE. <br>
<br>What might be nice is if you could use the SST module and set an absolute duration on the call. I believe the SST module overwrites the dlg timeout AVP values so you can use one or the other, but not both (someone please correct me if I am wrong).<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> 2. Combine 1 with OPTIONS between INVITES. For example, send an OPTION ping every minute, but you also want to see a re-INVITE every 15 minutes. This could allow quick detection for clients that support OPTION properly and the re-INVITE would help detect dead calls when the client is a bit buggy.<br>
<br>
</div>It doesn't matter if you send in-dialog OPTIONs or INVITEs. Two in-dialog requests cannot overlap, no matter if it's an OPTION or an INVITE. The issue is the same regardless of the method you use.<br></blockquote>
<div><br>Nothing that I am aware of in the SIP RFC restricts parallel in-dialog transactions. However, since INVITEs (an UPDATEs) can modify the dialog and session information, it's hard to processes them in parallel. OPTIONs do not modify the dialog or session and can be processed in parallel. So, by sending OPTIONS frequently you get a cheaper, safer, but less reliable way to check the dialog, and then on top of that you do INVITES infrequently for those clients that don't always properly respond with a 481 for calls that are gone.<br>
<br>In my opinion the worry about 'breaking' calls is moot, as these clients are already broken and may have their calls terminated anyways if both sides attempt re-INVITEs at the same time (I see this all the time). The only difference is now, instead of Opensips leaving the call up forever because neither side ever sent a BYE, Opensips would have a more reliable method for checking if the call actually ended. This is needed to detect when calls have ended because of the clients already broken behavior.<br>
<br>Currently the only other options are to use Opensips in conjunction with rtpproxy/mediaproxy and to use media timeouts to determine when calls have ended, but that's an awful heavy solution compared to re-INVITES.<br>
<br>Buggy implementations will always have problems, but you can only do so much to work around them.<br><br>Regards,<br><br>Ryan<br><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br>