Thanks!

 

From: ext Sumit Jindal [mailto:[email protected]] 
Sent: Thursday, November 24, 2011 1:09 AM
To: Aman Aggarwal
Cc: Pavesi, Valdemar (NSN - US/Irving);
[email protected]
Subject: Re: [Sip-implementors] UPDATE delay to send 200ok final
response

 

Hi Valdemar ,

 

I am pasting few lines from 3261. Hope this will clarify your doubt.

 

17.1.2.1 Overview of the non-INVITE Transaction
 
   Non-INVITE transactions do not make use of ACK.  They are simple
   request-response interactions.  For unreliable transports, requests
   are retransmitted at an interval which starts at T1 and doubles until
   it hits T2.  If a provisional response is received, retransmissions
   continue for unreliable transports, but at an interval of T2.  The
   server transaction retransmits the last response it sent, which can
   be a provisional or final response, only when a retransmission of the
   request is received.  This is why request retransmissions need to
   continue even after a provisional response; they are to ensure
   reliable delivery of the final response.
 

Regards,

Sumit Jindal

 

On Thu, Nov 24, 2011 at 11:51 AM, Aman Aggarwal
<[email protected]> wrote:

Hi Valdemar,

That is possible. On receiving 100 Trying, UPDATE retransmissions would
stop. However, you have to start a guard timer at application level to
handle a scenario when no response is received from the server.

regards,
Aman Aggarwal
Aricent.


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Pavesi, Valdemar (NSN - US/Irving)
Sent: Wednesday, November 23, 2011 8:59 PM
To: [email protected]
Subject: [Sip-implementors] UPDATE delay to send 200ok final response

Hello ,


We have to send update to change the session :

a)      We want it
1  50.987832   10.48.4.2             10.52.39.194          SIP/SDP
Request: UPDATE sip:10.52.39.194:5060;transport=UDP, with session
description
2   50.987832   10.52.39.194          10.48.4.2             SIP/SDP
Status: 200 OK, with session description



b)      But the remote sip endpoint  have a kind of SAVE-GUARD mechanism
that will allow to change the session just after 3.5 seconds

  1815 50.987832   10.48.4.2             10.52.39.194          SIP/SDP
Request: UPDATE sip:10.52.39.194:5060;transport=UDP, with session
description
  1820 51.491327   10.48.4.2             10.52.39.194          SIP/SDP
Request: UPDATE sip:10.52.39.194:5060;transport=UDP, with session
description
  1824 52.501307   10.48.4.2             10.52.39.194          SIP/SDP
Request: UPDATE sip:10.52.39.194:5060;transport=UDP, with session
description
  1828 53.987731   10.52.39.194          10.48.4.2             SIP/SDP
Status: 200 OK, with session description



c)       Do you think we can have it ?

  1815 50.987832   10.48.4.2             10.52.39.194          SIP/SDP
Request: UPDATE sip:10.52.39.194:5060;transport=UDP, with session
description
  1828 50.987835    10.52.39.194          10.48.4.2             SIP/SDP
Status: 100 trying
 .
 3.5 seconds later
 .
 .
 1828 53.987731   10.52.39.194          10.48.4.2             SIP/SDP
Status: 200 OK, with session description



++

21.1.1 100 Trying

  This response indicates that the request has been received by the
  next-hop server and that some unspecified action is being taken on
  behalf of this call (for example, a database is being consulted).
  This response, like all other provisional responses, stops
  retransmissions of an INVITE by a UAC.  The 100 (Trying) response is
  different from other provisional responses, in that it is never
  forwarded upstream by a stateful proxy.
++++


Regards!
Valdemar
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors





========================================================================
=======
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
========================================================================
=======


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors





 

-- 
Regards,
Sumit Jindal

_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to