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
