Thanks. In this case the UPDATE is coming before the full dialog is setup (183=early dialog as far as I know) and I can see 2 issues that are confusing me.
First,, can B side respond to the timer offer with a new offer "before" answering the first one? Second,, 200OK for INV is the last to be sent so if it supersedes the UPD/200OK transaction what's the point of putting session timer in UPDATE anyway ... but if you omit then is it correct from a protocol perspective? Thanks again. On Feb 21, 2014 5:39 AM, "Brett Tate" <[email protected]> wrote: > > All is well but what happens with the Session Timer response? > > RFC 4028 basically allows the Session-Timer to be negotiated with every > INVITE/UPDATE request. The last 2xx response wins. > > If UPDATE 2xx sent/received within an INVITE, refreshing/expiring would be > done based upon the UPDATE 2xx's added/missing Session-Expires. When the > subsequent INVITE 2xx is sent/received, refreshing/expiring would be done > based upon the INVITE 2xx's added/missing Session-Expires. If I recall > correctly, the RFC provides some guidance to reduce the impacts of > potential race conditions. > > -- > > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
