[SIPForum-discussion] Simultenous UPDATE Handling

[Venkatesh G]

Hi Raj,
 
     First of all, using UPDATE after confirmed dialog is NOT RECOMMENDED.
 
    For the case of receiving UPDATE instead of 200 OK for sent UPDATE, RFC 3311, Section 5.2 gives the answer.
In your case, UA-E MUST reject the UPDATE with 491 error response.
 
Regards..

--- On Mon, 31/5/10, raj kumaradass <rajkumaradass at gmail.com> wrote:


From: raj kumaradass <rajkumaradass at gmail.com>
Subject: Re: [SIPForum-discussion] Simultenous UPDATE Handling
To: "Nitin Kapoor" <nitinkapoorr at gmail.com>
Cc: discussion at sipforum.org
Date: Monday, 31 May, 2010, 5:09 PM



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




-----Inline Attachment Follows-----


_______________________________________________
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/20100601/64ab1f39/attachment-0002.html>