Thanks Brett for the information. I have few more doubts on this:). 1) UAS restarts the session timer on receiving the UPDATE/reINVITE as a session-refresh request once the call is established. However in case of early dialog there is no session-timer running but a request has arrived at UAS through UAC. In such a case (with SDP & 100rel & Session-Expires) is it valid for UAS to honour the Session-Expires in the early UPDATE ( i.e., should UAS renegotiate Session-timer)? Can it just not ignore the Session-Expires in early UPDATE and send 200 OK for UPDATE without the including the Session-Expires header? [ I am still confused for this particular case. Please reconfirm even if answered in previous mails. Actually the doubt is regarding inclusion of SE header in 200 OK for early UPDATE] 2) In case of confirmed dialog if UAS gets UPDATE (but not, one more reINVITE) with SE header while the UAS is processing reINVITE refresh request, then should UAS send the 4xx-5xx response to such an UPDATE? [ As per the discussion so far the answer to this question is NO. If it is otherwise please let me know]. Thanks, Praveen Dandin Brett Tate <[EMAIL PROTECTED]> wrote: inline
Hi Paul/Harsha/Brett, What I understood from the discussion is : If one session timer negotiation is under process (received through INVITE ), processing the another session timer offer received in UPDATE everytime will affect the session-timer functionality of UAS. Is my understanding correct? [Brett] Yes; however it is also affected INVITE 200 response. I have few more queries on this: 1) Suppose UAC sends INVITE with SDP offer and Session-Expires value and receives SDP answer in 180. Now UAC sends UPDATE with second SDP offer and Session-Expires header in it. Now if UAS tries to send 200 OK for UPDATE with the SDP answer (for second offer) without the Session-Expires does it not violate atomicity of request processing as mentioned in section 8.2 of RFC 3261: " Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed." ?? [Brett] It does not violate the "atomic" rules that you mention. And for clarity since you mention offer/answer stuff, the 180 with SDP must be sent using 100rel to avoid the UPDATE with SDP from violating the offer/answer rules. 2) There is no mention of overlapping/ pending refresh requests in the RFC 4028. How it should be handled? For example, what should be done if an UPDATE is received while the another UPDATE refresh request is under process at UAS ( when both requests have Session-Expires values).? [Brett] The answer is mostly within rfc3311 section 5.2. For a glare type situation not specifically listed, responses like 491 or 500 with retry-after can be used although not required. Additionally they are not needed if rfc4028 recommendations are followed. 3) How can the above issue (2) be handled in case of early dialogs and confirmed dialogs? [Brett] It UPDATE 200 response is returned, it is handled per contents of the UPDATE 200 response. 4) Can UAS send the negative (4xx-5xx) response to the UAC if it receives the UPDATE with Session-Expires in early dialog? [ here note that INVITE also requested session-timer by including the Session-Expires header]. [Brett] As mentioned in prior emails, this is not a reason to reject the UPDATE. However devices can reject whatever they want to reject although they might not the like the interop/service consequences. 5) Is there any RFC statement which says that "An outstanding session-expires mechanism should not prevent another from occurring." ?. If so, please let me know. [Brett] No. 6) Can Session-Expires be added in early UPDATE? If yes, then what is its purpose? [Brett] It can be added to UPDATE basically anytime a device chooses to add it. However what subsequently occurs is based upon rfc4028, rfc3311, and rfc3261. --------------------------------- Get the freedom to save as many mails as you wish. Click here to know how. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors