[SIPForum-discussion] Simultenous UPDATE Handling

[Dasu B]

Hi,

Here is the scenario diffrent and Suspend/resume case is the diffrent(which
follow RFC3311) as i understand.
and Here call switching from audio to video and Update is sending from both
party at same time.

491 pending message will come that scenario where Ack is not receiving of
200ok request.
Ideally Media offer send from A -party in update message to B-Party but here
is sending from both.
Might be A-party releasing the call with Bye message.

Raj, If you attach the call trace,it will easy to understand.

Thanks
Dasu
On Tue, Jun 1, 2010 at 8:39 AM, <ayyanar.kalimuthu at wipro.com> wrote:

>  Hi,
>
> This is clearly an offer clash scenario(Refer RFC 3311), which is supposed
> to end with an error. However, the initial dialog established remains
> undisturbed. As Nitin pointed out in the previous mail, the scenario 2 will
> be applied nere. UPDATE is rejected with 491 Request Pending message.
>
> Regards,
> Ayyanar
>
>  ------------------------------
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *raj kumaradass
> *Sent:* Monday, May 31, 2010 5:09 PM
> *To:* Nitin Kapoor
> *Cc:* discussion at sipforum.org
> *Subject:* Re: [SIPForum-discussion] Simultenous UPDATE Handling
>
>
> Apologise that i have missed an Ack in the signals flow. Here's the right
> one below:
>
> UE-A
>     UE-B
>
>
>       ---------------------INVITE(SDPoff - audio codecs) ------------>
>
>       <--------------------180(Ringing)
> ---------------------------------------
>
>       <---------------------200 OK(SDPans - audio codecs) ---------
> *
>       ----------------------- Ack
> -------------------------------------------------->*
>
>       ---------------------UPDATE(SDPoff - Video codec) ---------->
>
>       <--------------------UPDATE(SDPoff - Video codec) ------------
>
>
> I think, now the question would be uncluttered with the above flow. Is it
> acceptable to process the UPDATE as a response for the UPDATE req sent? Or
> should it be NACKed with error response?
>
>
> thankS,
> ...Raj
>
>
> On Fri, May 28, 2010 at 11:21 PM, Nitin Kapoor <nitinkapoorr at gmail.com>wrote:
>
>> Raj,
>>
>> Here is what my understanding says.
>>
>> In this kind of scenarios, additional rules apply to processing an UPDATE
>> request with an offer when the gateway has sent a 200 OK response to an
>> INVITE request but has not yet received an ACK. The following scenarios
>> generate an error response.
>>
>> 1) If the initial INVITE request contains an offer but does not require
>> provisional responses be sent reliably, then the SDP in the 200 OK is
>> treated like an answer. If the UAS then receives an UPDATE request before an
>> ACK response to the 200 OK, the UAS sends a 500 Server Internal error
>> response with a Retry-After header.
>>
>> 2) If the initial INVITE does not contain an offer and does not require
>> provisional responses be sent reliably, then the SDP in the 200 OK is
>> treated like an offer. If the UAS then receives an UPDATE request before
>> receiving an ACK to the 200 OK, the UAS sends a 491 Request Pending
>> response.
>>
>> Now i might be wrong too. so lets wait for the others opinion.
>>
>> Thanks,
>> Nitin Kapoor
>>
>>
>>   On 28 May 2010 16:07, raj kumaradass <rajkumaradass at gmail.com> wrote:
>>
>>>  Greetings,
>>>
>>> Would like to know how the below scenario be handled, where both the ends
>>> of a call send UPDATE msg(inorder to switch from established audio call to
>>> video) simultaneously and the timing is more of alike a UPDATE response
>>> received for a UPDATE req sent on both the entities.
>>>
>>>
>>> UE-A
>>>                                                UE-B
>>>
>>>       ---------------------INVITE(SDPoff - audio codecs) ------------>
>>>
>>>       <--------------------180(Ringing)
>>> ---------------------------------------
>>>
>>>       <---------------------200 OK(SDPans - audio codecs) ---------
>>>
>>>       ---------------------UPDATE(SDPoff - Video codec) ---------->
>>>
>>>       <--------------------UPDATE(SDPoff - Video codec) ------------
>>>
>>>
>>> Also please suggest if any standards/links which details out on handling
>>> similiar scenarios.
>>>
>>>
>>> thankS,
>>> ...Raj
>>>
>>> _______________________________________________
>>> This is the SIP Forum discussion mailing list
>>> TO UNSUBSCRIBE, or edit your delivery options, please visit
>>> http://sipforum.org/mailman/listinfo/discussion
>>> Post to the list at discussion at sipforum.org
>>>
>>>
>>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100602/5bc62c50/attachment-0002.html>