Yes; draft-ieff-sipcore-reinvite-03.txt attempts to address some of the issues. My favorite is the sections 3.5/4.5 text indicating to treat (from a glare perspective) UPDATE without SDP as though it contained an offer. Thus if I understand correctly, an UPDATE without SDP SHOULD trigger 491 if step 1 contained offer SDP and step 3 was sent from UE2 to UE1.
Concerning your example (assuming step 1 contained offer SDP), I currently find the draft to be ambiguous concerning sending 491, 500, or 200. The ambiguity relates to not having a precise definition of glare and some vendors preferring to send 491 instead of 500. Concerning your example... yes; the UPDATE 2xx is allowed (even though potentially not following a SHOULD). However at step 4, session-expires 600 becomes active; and at step 5 session-expires 1800 becomes active. From: Harbhanu [mailto:[email protected]] Sent: Friday, May 21, 2010 10:07 AM To: Brett Tate; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: [Sip] Reg. session timer+earlyupdate Hi Brett, I just came across an interesting draft in this regard - draft-ieff-sipcore-reinvite-03.txt. Please refer. IMO this does attempt to address a lot of UPDATE-[re-]INVITE pain areas ... 1. UE1 --- INVITE SE-1800 --> UE2 2. UE1 <--- 183 ------------------ UE2 3. UE1 --- UPDATE SE-600 --> UE2 4. UE1 <--- 200 UPDATE -SE600 -- UE2 5. UE1 <--- 200 INVITE SE-1800 -- UE2 AFAICU, as per this draft the UAS will take care of sending - 1. Either 2xx of INVITE and wait till its ACK for sending success response of UPDATE & might also send a 409... 2. Or 2xx of UPDATE before sending 2xx of INVITE. Similarly, UAC also do have clearly defined expectations ... That said, the UPDATE -2xx here is absolutely allowed and so does the INV 2xx... Although not explicitly specified in this draft, but for the given scenario both UAC and UAS SHOULD run timer with value 600. Atleast UAC MUST. Please correct me, if I am wrong. Thanks! Authors of draft-ieff-sipcore-reinvite-03.txt: IMO this draft can consider this glare scenario as well, i.e. session timer, to make it more a comprehensive text. Excellent effort anyways!! Regards, Harbhanu ******************************************************************************************************************************************************************************************* This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ________________________________ From: Brett Tate [mailto:[email protected]] Sent: Tuesday, May 18, 2010 7:49 PM To: Harbhanu; [email protected] Subject: RE: [Sip] Reg. session timer+earlyupdate Similar to many other of SIP RFCs, RFC4028 has race condition issues. Thus the UAC, UAS, and proxies might not be in agreement concerning session-expires value, activation, and/or refresher. Based upon RFC4028, it is basically the latest negotiated 2xx sent/received. Within the call flow provided, the INVITE 2xx's Session-Expires value is latest. However since there can be race conditions associated within UPDATE, UPDATE 2xx, and INVITE 2xx, the UAC, UAS, and proxies might not all be in agreement concerning which 2xx was the latest. From: Harbhanu [mailto:[email protected]] Sent: Tuesday, May 18, 2010 9:44 AM To: Brett Tate; [email protected] Subject: RE: [Sip] Reg. session timer+earlyupdate May be your expectation is correct, but here the issue is in defining the behavior of UA for the following scenario. I will rephrase the issue...Which value should the UAC and UAS take for SE and interval timer, when either of them is acting as refresher ? i.e. 1. UAC refresher, then SE and refresh time for UAC and SE value at UAS? 2. UAS refresher, then SE and refresh time for UAS and SE value at UAC? Please consider the consistency of behavior incase there is a crossover of 2xx of UPDATE and that of INVITE. *************************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ________________________________ From: Brett Tate [mailto:[email protected]] Sent: Tuesday, May 18, 2010 6:10 PM To: Harbhanu; [email protected] Subject: RE: [Sip] Reg. session timer+earlyupdate The UAS is compliant; thus sending BYE (because think UAS is acting incorrectly) is not correct behavior. If the following is the section 9 snippet in question, notice that the dialog's previously negotiated session-expires value has no relevance; the "MUST NOT" is associated the header received within the request. If you are referring to another "MUST NOT" (within this section or another), please send the paragraph. " If the UAS wishes to accept the request, it copies the value of the Session-Expires header field from the request into the 2xx response. The UAS response MAY reduce its value but MUST NOT set it to a duration lower than the value in the Min-SE header field in the request, if it is present; otherwise the UAS MAY reduce its value but MUST NOT set it to a duration lower than 90 seconds. The UAS MUST NOT increase the value of the Session-Expires header field. " From: [email protected] [mailto:[email protected]] On Behalf Of Harbhanu Sent: Tuesday, May 18, 2010 4:35 AM To: [email protected] Subject: [Sip] Reg. session timer+earlyupdate Hi, We were unable to locate the specific behavior of session timer handling in UA, for the following scenario: 1. UE1 --- INVITE SE-1800 --> UE2 2. UE1 <--- 183 ------------------ UE2 3. UE1 --- UPDATE SE-600 --> UE2 4. UE1 <--- 200 UPDATE -SE600 -- UE2 5. UE1 <--- 200 INVITE SE-1800 -- UE2 6. UE1 ------------------------- BYE --> UE2 7. UE1 <--- BYE 200 ------------------ UE2 Here, UE1 sends a BYE since UE2(UAS) has increased the value of session expires, which it MUST NOT (4028-Section-9, Page-16). Please let me know whether this behaviour is correct or not. Thanks in advance. Regards, Harbhanu
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications.
