> The RFC 4028 allows 2 simultaneous session timer > negotiations i.e with Re-Invite and Update. So the following > combinations are possible for session refresh request.
<snip> > The session timers (session interval and session expires) > will be started based on the session expires header values > in the 2xx response of refresh request. > > The cross over of the response messages is also possible > (Response for the first refresh request received after the > response for the second refresh request). Correct. As discussed within the following and related threads, this is one of the potential SIP race conditions. https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-October/025881.html > The session expires in the 2xx response must be validated > by the stack as per the rules defied in RFC4028. > > What would be the most elegant way of handling such scenarios: Assume that the latest received/sent 2xx is the most accurate. If overly concerned that the race condition may cause the session to not be refreshed in time, you can do something like pick the lowest interval among the choices and act as the refresher. If you want to see the issue fixed or addressed as a BCP, you might raise the issue within the dispatch or sipcore working groups to see if anyone else wants this and similar race condition ambiguities resolved. If I recall correctly, this was not one of the issues fully addressed by RFC 6141 or RFC 5407. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
