On Wed, Oct 31, 2012 at 12:15 PM, Ovidiu Sas <[email protected]> wrote:
> On Wed, Oct 31, 2012 at 3:03 PM, Dan Pascu <[email protected]> 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 > > In my experience, very few implementations handle a negative response to a re-INVITE well (491 included). These would make pinging a bit more complicated but may help avoid races: 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. 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. The various implementations for re-INVITE and OPTION support make this an interesting problem. _______________________________________________ > Devel mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel >
_______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
