It is fine to cancel in the proxy alone. There are at least two relevant bits in 3261; Section 9.2 says “a stateful proxy might respond to it and generate some CANCEL requests of its own” … But you don’t need to send any CANCELs since you haven’t sent anything out. And Section 16.10: While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. You as a proxy are acting as a UAS here and are authoritative to respond to the CANCEL. You have no pending client transactions (since you haven’t sent any out) so it’s fine to stop processing internally.
Regards, Alan > On 10 Oct 2016, at 12:40, Bogdan-Andrei Iancu <bog...@opensips.org> wrote: > > Hi Alan, > > Yes, the CANCEL is received before sending the INVITE to the UAS. > > Technically speaking (as coding), we can do both - handle the canceling > process in the proxy (200 OK to CANCEL and 487 to INVITE, without sending > anything further to UAS) , or to delay the CANCEL until the INVITE is send > out (and send the CANCEL out to UAS too). > > My question is more from the perspective of the SIP standard and best > practice for SIP. > > Thanks, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > On 10.10.2016 14:26, Alan Ford wrote: >> Hi Bogan-Andrei, >> >> To check your scenario: The CANCEL arrives from the UAC before the INVITE >> has been sent out the proxy to the UAS? >> >> CANCEL is a hop-by-hop message so ideally you would send back a 200 OK to >> the CANCEL from the proxy and internally stop yourself sending out the >> INVITE towards the UAS. >> >> If that is not possibly, then semantically you should send a CANCEL as soon >> as you receive the first provisional response for the INVITE you send out. >> Bear in mind you have to be prepared in that scenario for a 200 OK to the >> INVITE coming back before the CANCEL is processed by the UAS, and thus be >> prepared to then BYE the call. So stopping sending the INVITE out would be >> much easier ;-) >> >> Regards, >> Alan >> >>> On 10 Oct 2016, at 10:26, Bogdan-Andrei Iancu <bog...@opensips.org> wrote: >>> >>> Hello, >>> >>> What should be the correct and most efficient way for a proxy to handle an >>> incoming CANCEL for a INVITE still under processing. The detailed scenario >>> is : >>> >>> * INVITE is received, the transaction is created, 100 Trying is sent back >>> * the routing logic is invoked (this may take even 1 minutes due complex >>> I/O operations to determine the next hop) >>> * no INVITE was yet sent back >>> * a CANCEL request is received for the INVITE >>> >>> What a proxy should do at this point ? delay the CANCEL and send it further >>> once the INVITE is also sent out (does not seem to efficient) ? perform the >>> actual canceling and generate the 487 reply for INVITE (not sure if it is >>> legitimate for a proxy to do this) ? >>> >>> I scan the RFC4361 for any possible hints on the matter, but not much of >>> luck. Section 9.2 does not apply for a proxy and 16.10 does not cover this >>> scenario. >>> >>> >>> Thanks and regards, >>> >>> -- >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> Sip-implementors@lists.cs.columbia.edu >>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
