Hi,
Is it mandatory to use the same method ( UPDATE or re-INVITE ) while an UA is
handling the glare condition ?
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 |
|--------------------->|
Is step 6 valid ?
IMO, its valid because rfc 3311 says - "the UAC SHOULD attempt the UPDATE once
more", and not MUST.
Secondly, we are talking about modifying a session, I don't see any reason why
UA2 should be expecting the same method to do so.
Please provide your valuable thoughts.
Thanks,
Pranab
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
