<br><br><div class="gmail_quote">On Wed, Oct 31, 2012 at 12:15 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.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">On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu <<a href="mailto:dan@ag-projects.com">dan@ag-projects.com</a>> wrote:<br>
><br>
> On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote:<br>
><br>
>> Hi Saul,<br>
>><br>
>> We were thinking at re-INVITE pinging from OpenSIPs level towards the caller and callee. There will be 2 modes (at least this is the current plan).<br>
>> 1) remember all the time the last SDPs from each side and re-use them when pining the other sides (just to trick the SDP negotiation)<br>
>> 2) start with a lateSDP negotiation on one side and do normal SDP on the other side (to avoid SDP storing), but this means at least one of the parties should support late SDP negotiations<br>
>> 3) open to other suggestions....<br>
><br>
> I think this invites trouble as it is prone to race conditions. If any of the clients send a re-INVIVITE of their own while OpenSIPs does it's pinging, it will fail as there is already an active unanswered re-INVITE in progress. The client will be confused as it didn't send another re-INVITE itself and the negative reply to its own re-INVITE will probably just prompt the client to terminate the session thinking there is some issue with it.<br>
><br>
> I cannot see this working without a full B2BUA, where OpenSIPs would queue the client requests if there is a ping in progress and only forward them after it has finished the ping transaction.<br>
<br>
</div>Yes, it is prone to race conditions :(<br>
The UAS should detect such race and reply with 491 Request Pending in<br>
order to clear out this race, but I wonder how many SIP implementation<br>
are implementing this properly:<br>
<a href="https://tools.ietf.org/html/rfc3261#section-21.4.27" target="_blank">https://tools.ietf.org/html/rfc3261#section-21.4.27</a><br>
<a href="https://tools.ietf.org/html/rfc3261#section-14.2" target="_blank">https://tools.ietf.org/html/rfc3261#section-14.2</a><br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>In my experience, very few implementations handle a negative response to a re-INVITE well (491 included).<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>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>The various implementations for re-INVITE and OPTION support make this an interesting problem.<br><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>
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>