Hi Dale, Thanks for your inputs, and yes, the direction of UPDATE in the figure is not correct. However, I am dealing with an inter-op issues here. The UA2 vendor suggested that UA1 should re-send UPDATE rather than re-INVITE. I believe re-sending the same request is not mandatory.
In such a situation, UA1 can follow either of the two recommendations in rfc 3311, not both - ================================================================= Section 5.1: Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. This is because an UPDATE needs to be answered immediately, ruling out the possibility of user approval. Such approval will frequently be needed, and is possible with a re-INVITE. OR Section 5.3: If a UAC receives a 491 response to a UPDATE, it SHOULD start a timer ........... ............ ..... When the timer fires, the UAC SHOULD attempt the UPDATE once more, if it still desires for that session modification to take place. ================================================================= The "UPDATE and re-INVITE crossover" example of rfc 5407 also shows that the UA re-sends the same request again. Is there any rfc that clears this doubt? Unless I can point to any standard, its going to be hard to convince the vendor about the present UA1 behavior. Cheers, Pranab -----Original Message----- From: Worley, Dale R (Dale) [mailto:[email protected]] Sent: Thursday, April 26, 2012 11:37 PM To: Pranab Bohra; [email protected] Subject: RE: 491 response code handling > From: Pranab Bohra [[email protected]] > > Is it mandatory to use the same method ( UPDATE or re-INVITE ) while > an UA is handling the glare condition ? No. The remote UA has rejected the request and remembers nothing of it. > 1. Let's say, UA1 and UA2 have set up an early dialog. > 2. UA2 sends ACK which would result in a confirmed dialog. > 3. UA1 initiates the UPDATE transaction to modify the session because > it has not seen the ACK to the initial INVITE yet. (because rfc 3311 > recommends that UPDATE should be used for early dialogs and re-INVITE in case > of confirmed dialogs) 4. UA2 has initiated re-INTIVE at the same time. > 5. UA2 responds back to the UPDATE that UA1 had sent in step 3 with 491. > 6. UA1 terminates the UPDATE transaction and tries to modify the session > again by sending another SDP Offer. (as per Sec. 14.2 of rfc 3261) But now > that it's a confirmed dialog, UA1 sends re-INVITE rather than UPDATE. > > UA1 UA2 > | early dialog | > |<============>| > | ACK | > |<---------------------| > | UPDATE | > |<---------------------| > | re-INVITE | > |<---------------------| > | 491 | > |<---------------------| > | re-INVITE | > |--------------------->| Beware that you have diagrammed the UPDATE in the wrong direction. Also, the diagram shows the ACK arriving at UA1 before the UPDATE is sent. You want a diagram like the one in RFC 5407 section 3.1.2: [mono-space:] State Alice Bob State | | | INVITE F1 | |----------------------------->| Pre | 180 Ringing F2 | Pre |<-----------------------------| Ear | | Ear |CANCEL F3 200(INVITE) F4| |------------ -------------| | \ / | Mora | X | | / \ | |<----------- ------------>| *race* Mora | | | ACK F6 200(CANCEL) F5| |------------ -------------| Est | \ / | | X | | / \ | |<----------- ------------>| Dale SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
