Thanks a lot. Now I am sure of the timer for INVITE after sending a CANCEL request is necessary.
BR, Johnny On 4/30/07, Rayees Khan <[EMAIL PROTECTED]> wrote: > > Inline > > regards > Rayees > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of johnny > kao > Sent: Saturday, April 28, 2007 12:30 AM > To: [email protected] > Subject: [Sip-implementors] Question about termination of a early dialog > > Hi, > > 1 . RFC3261 says on page 77: "Independent of the method, if a request > outside of a dialog generates a non-2xx final response, any early > dialogs created through provisional responses to that request are > terminated." > > Does it only describe the behavior of UAS? Consider the situation below: > > UAC generates a CANCEL request, it could receive no responses for the > initial INVITE request (if UAS followed the RFC2543). Thus, can I > suppose that the early dialog of the UAC is terminated while the CANCEL > issued? > > The dialog is not terminated at this point in time. It does point to > details of the same in section 15 of RFC. > > > 2. Page 54 says: "However, a UAC canceling a request cannot rely on > receiving a 487 (Request Terminated) response for the original request, > as an RFC 2543-compliant UAS will not generate such a response. If > there is no final response for the original request in > 64*T1 seconds, the client SHOULD then consider the original transaction > cancelled and SHOULD destroy the client transaction handling the > original request." > > But the retransmission of the INVITE is stop by the provisional response > it received, how the UAC implements this feature? Re-start the timer of > the INVITE? > > Most of the servers do so. RFC 3261 does state the following > > "Note that both the transaction corresponding to the original request > and the CANCEL transaction will complete independently. However, a UAC > canceling a request cannot rely on receiving a 487 (Request Terminated) > response for the original request, as an RFC 2543- compliant UAS will > not generate such a response. If there is no final response for the > original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), > the client SHOULD then consider the original transaction cancelled and > SHOULD destroy the client transaction handling the original request." > > As soon as a CANCEL request is sent a timer is started that lasts 64*T1 > to wait for 487 response for INVITE. > > > THX > Johnny, TW > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > > > ---------------------------------------------------------------------------------- > IMPORTANT The information contained in this e-mail any > attachments is intended only for the named recipient and may be > privileged or confidential. > > If you are not the intended recipient, please notify us immediately > on +44 (0)1908 425000 and do not disclose, copy, distribute > or take any action based on the contents of this e-mail. > > You should understand and accept that, when communicating with us > by e-mail, it is not a totally secure communication medium. > > We accept no liability for any direct, indirect or consequential loss > arising from any action taken in reliance on the information contained > in this e-mail and give no warranty or representation as to its accuracy > or reliability. > > DIGITALK has the facility to monitor and read both incoming > and outgoing communications by e-mail. In line with industry efforts > to reduce the proliferation of Un-Solicited SPAM messages, > DIGITALK uses various methods including Reverse-DNS > lookups and ban-lists to prevent malicious content reaching our users. > > This message and any attachments has been scanned for known > viruses. However, we would advise you to ensure the content is > indeed virus free. We do not, to the extent permitted by law, accept > any liability (whether in contract, negligence or otherwise) for any virus > infection and/or external compromise of security and/or breach of > confidentiality in relation to transmissions sent by e-mail. > > VAT No: GB 876 3287 81. Reg No: 3080801 > Place of Registration: England > Registered Office Address: 2 Radian Court, Knowlhill, Milton Keynes > ----------------------------------------------------------------------------------" > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
