Hi all, Is it possible to send a CANCEL request for non-INVITE requests as well? In section 9 its written CANCEL is best suited for INVITE. However the standard does not restrict CANCEL only for INVITE. Moreover, In 9.1 its written cancel SHOULD NOT be sent for requests other than INVITE. But to mandate a MUST NOT should be written. Any thoughts on this.
Thanks, Arun On Sep 15, 2013 9:32 PM, "Guan Xsun" <guanxian...@gmail.com> wrote: > Thank you very much!!! > > > 2013/9/13 ankur bansal <abh.an...@gmail.com> > > > Hi Casey , > > > > Like Satish mentioned 487 comes immediately but assuming it lost in > > network or UAS is RFC2543-compliant(cant generate 487). > > > > Even then we cannot terminate dialog on getting 200ok(Cancel) due to > these > > reasons : > > > > 1. Cancel can be triggered before any provisional response (having > to-tag) > > comes .Means on receiving 100 trying also Cancel can be trigerred . > > Means UAC side dialog is still not (early)established.So how we can > > terminate it ? > > > > 2. As per RFC 3261 , Dialog is terminated only when BYE comes/goes or > > failure final response(like 487 in this case ) comes . > > > > > > Now think what can happen if we release dialog on getting cancel 200ok : > > > > 1. As you might be aware that dialog and transaction state machine run > > independtly . > > So terminating dialog after getting 200ok of cancel ,will not clean > > Invite Tx till final response comes for Invite . > > Even if BYE sent in early dialog , it does not impact INVITE > > transaction . > > Hence sipstack will be waiting for final response for Invite for > 64*t1 > > . > > > > Hope this helps . > > > > Thanks & Regards > > Ankur Bansal > > > > > > On Fri, Sep 13, 2013 at 4:25 PM, satish agrawal <satish.agr...@gmail.com > >wrote: > > > >> Hello Casey, > >> > >> As per RFC 3261 section 9.2 > >> > >> If the UAS did not find a matching transaction for the CANCEL > >> according to UAS first processes the CANCEL request, it SHOULD > >> respond to the CANCEL > >> with a 481 (Call Leg/Transaction Does Not Exist). If the transaction > >> for the original request still exists, the behavior of the UAS on > >> receiving a CANCEL request depends on whether it has already sent a > >> final response for the original request. If it has, the CANCEL > >> request has no effect on the processing of the original request, no > >> effect on any session state, and no effect on the responses generated > >> for the original request. If the UAS has not issued a final response > >> for the original request, its behavior depends on the method of the > >> original request. If the original request was an INVITE, the UAS > >> SHOULD immediately respond to the INVITE with a 487 (Request > >> Terminated). A CANCEL request has no impact on the processing of > >> transactions with any other method defined in this specification. > >> > >> In your case the UAS SHOULD immediately respond to the INVITE with a > >> 487 "Request Terminated" message. > >> > >> Regards, > >> Satish > >> > >> > >> > >> > >> On Fri, Sep 13, 2013 at 3:37 PM, Guan Xsun <guanxian...@gmail.com> > wrote: > >> > >> > heHi, > >> > A SIP client create a dialog by sending INVITE and then will > cancel > >> it. > >> > Whether the dialog can be finished when the dialog receive the 200 > OK > >> > from cancel or it needs receive the 487 message ? > >> > > >> > Best Regards! > >> > Casey > >> > _______________________________________________ > >> > Sip-implementors mailing list > >> > Sip-implementors@lists.cs.columbia.edu > >> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > >> > >> > >> > >> -- > >> Thanks & Regards > >> Satish Agrawal > >> New Delhi-24. > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@lists.cs.columbia.edu > >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > >> > > > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
