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
