Hi Folks, I think the correct behavior is to send the CANCEL message, as per SIP RFC, the cancel message is used for the cancelling the pending request/transaction and then BYE, if you want to tear down the session.
Snippet from RFC 3261, section 9: 9 Canceling a Request The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would "stop ringing", and then respond to the INVITE with a specific error response (a 487). Cheers, Aman On Fri, Jun 8, 2012 at 2:35 PM, Tarun2 Gupta <[email protected]>wrote: > Ravi > > My requirement is to clear the call since the immediate proxy is down and > not responding. My Application is sending Cancel for the ReInvite > immediately followed by Bye. > > So the correct behavior is to just send a Bye in case of a timeout? > > Regards, > Tarun Gupta > Aricent > > -----Original Message----- > From: Ravi Kumar [mailto:[email protected]] > Sent: Friday, June 08, 2012 2:21 PM > To: Tarun2 Gupta; 'SIP' > Subject: RE: [Sip-implementors] ReInvite times out, should a Cancel be > sent or not > > Hi Tarun, > If your intention is to ternimate call then CANCEL request is not required > to send, because CANCEL request will cancel INVITE transaction (for > re-invite will not cause call termination). > > Also as per RFC CANCEL request is to cancel INVITE transaction and in your > case it has timeout then which transaction your application wants to > cancel. > Because timeout means peer has not processed request and UAC should not > expect any response. > > RFC 3261 > 14.1 UAC Behavior > > If a UA receives a non-2xx final response to a re-INVITE, the session > parameters MUST remain unchanged, as if no re-INVITE had been issued. > Note that, as stated in Section 12.2.1.2, if the non-2xx final > response is a 481 (Call/Transaction Does Not Exist), or a 408 > (Request Timeout), or no response at all is received for the re- > INVITE (that is, a timeout is returned by the INVITE client > transaction), the UAC will terminate the dialog. > > For INVITE initiated dialogs, terminating the dialog consists of > sending a BYE. > > > Is your application after sending CANCEL request it is waiting for response > to CANCEL request and Re-INVITE request? Or send CANCEL request and then > immediate send BYE request? > > Regards, > Ravi Kumar > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Tarun2 > Gupta > Sent: Friday, June 08, 2012 1:20 PM > To: SIP > Subject: [Sip-implementors] ReInvite times out, should a Cancel be sent or > not > > Hi > > Consider the following scenario: > > > 1. A and B are in stable call. > 2. A presses hook-flash, ReInvite for hold sent. > 3. A - B call put on hold. > 4. A presses hook-flash again, ReInvite for resume sent. > 5. B does not respond (it is down) and ReInvite times out. > > How should the call be terminated. Should a Cancel be sent for ReInvite > followed by a Bye or Bye alone would suffice? At our end, A sends a Cancel > for ReInvite followed by Bye. Is it incorrect behavior? Can you please give > me some normative references to support your answer. > > Regards, > Tarun Gupta > Aricent > > > > > > > ============================================================================ > === > 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 > > > > > > > =============================================================================== > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
