The important part of the specs in this regard is how the delay before
retry is determined, since it is what reduces the probability of
repeatedly getting glare. Its clear that either side can decide not to
retry at all, and later decide to do something else.
I don't see that your other vendor will have any luck arguing that you
must use UPDATE.
Thanks,
Paul
On 4/27/12 1:56 AM, Pranab Bohra wrote:
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
