[Sip-implementors] 491 response code handling

Nataraju A.B nataraju.sip at gmail.com

Fri Apr 27 02:26:31 EDT 2012
Previous message: [Sip-implementors] 491 response code handling
Next message: [Sip-implementors] 491 response code handling
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In addition, rfc6337 might be of helpful (offer-answer issues)

If UA2 expects re-INVITE instead of UPDATE, then 491 is not the correct
response code.

Any UA receiving 491 would retry after some time with the same request
(this is the expected behavior).

Yes it is expected to resend the same method after retry-after timer

times
out. You can refer sec 14.1 of 3261 for more granular details.

<3261>

If a UAC receives a 491 response to a re-INVITE, it SHOULD start a

timer with a value T chosen as follows:

1. If the UAC is the owner of the Call-ID of the dialog ID

(meaning it generated the value), T has a randomly chosen value
between 2.1 and 4 seconds in units of 10 ms.

2. If the UAC is not the owner of the Call-ID of the dialog ID, T
has a randomly chosen value of between 0 and 2 seconds in units
of 10 ms.
When the timer fires, the UAC ***SHOULD** *attempt the re-INVITE
once more, if it still desires for that session modification to take
place. For
example, if the call was already hung up with a BYE, the re-INVITE
would not take place.

</3261>

On Fri, Apr 27, 2012 at 11:26 AM, Pranab Bohra <pranab.bohra at

sasken.com>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:dworley at avaya.com]
> Sent: Thursday, April 26, 2012 11:37 PM
> To: Pranab Bohra; sip-implementors at lists.cs.columbia.edu
> Subject: RE: 491 response code handling
>
> > From: Pranab Bohra [pranab.bohra at sasken.com]
> >
> > 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
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

--
Thanks,
Nataraju A.B.

Previous message: [Sip-implementors] 491 response code handling

Next message: [Sip-implementors] 491 response code handling
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the Sip-implementors mailing list