On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu <d...@ag-projects.com> wrote: > > On 29 Oct 2012, at 12:11, Bogdan-Andrei Iancu wrote: > >> Hi Saul, >> >> 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). >> 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) >> 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 >> 3) open to other suggestions.... > > 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. > > 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.
Yes, it is prone to race conditions :( The UAS should detect such race and reply with 491 Request Pending in order to clear out this race, but I wonder how many SIP implementation are implementing this properly: https://tools.ietf.org/html/rfc3261#section-21.4.27 https://tools.ietf.org/html/rfc3261#section-14.2 _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
