[SIPForum-discussion] Simultenous UPDATE Handling

[ayyanar.kalimuthu at wipro.com]

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
		
		



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100601/50e89491/attachment-0002.html>