17 sep 2013 kl. 09:59 skrev Arun Arora <arun.arora....@gmail.com>: > 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. As a developer you SHOULD treat SHOULD as a MUST :-)
The reason why it's left open is propably to let new RFCs specify other usages of CANCEL, but so far INVITE is the only usage I am aware of. /O > > 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 --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors