Ali,
It all depends on whether you are creating a transaction in the course
of redirect processing.
If you do create a transaction (i.e. with t_newtran()), and the CANCEL
arrives before you have sent a final dispositive reply (2xx or higher),
then the normal CANCEL processing will do the right thing and generate
both a 200 OK for the CANCEL and a 487 Request Terminated for the
INVITE:
route {
...
if(is_method("CANCEL")) {
if(!t_relay_cancel()) {
xlog("L_INFO", "No matching transaction for CANCEL\n");
sl_send_reply("500", "Internal Server Error");
}
exit;
}
}
If no transaction is created, i.e. you just receive the INVITE, do a
lookup, and sl_send_reply() a response, then there is nothing to CANCEL
and nothing needs to be handled.
If you have already sent a final reply after having created the
transaction manually (the first scenario above), the transaction is
terminated and there is likewise nothing to CANCEL.
-- Alex
On Tue, Jan 28, 2020 at 02:18:53PM +0000, Ali Taher wrote:
> Hello Alex,
>
> You mean handle the cancel from Kamailio side ? can you give me hint how to
> do it ?
>
> Regards,
> Ali Taher
>
> From: sr-users <[email protected]> On Behalf Of Alex
> Balashov
> Sent: Tuesday, January 28, 2020 4:07 PM
> To: Kamailio (SER) - Users Mailing List <[email protected]>
> Subject: Re: [SR-Users] SIP Redirect CANCEL handling
>
> You should handle the cancel.
> —
> Sent from mobile, with due apologies for brevity and errors.
>
>
> On Jan 28, 2020, at 8:45 AM, Ali Taher
> <[email protected]<mailto:[email protected]>> wrote:
>
> Hello Alex,
>
> Kamailio sent 300 multiple choice back to SBC even after the SBC sent the
> CANCEL request , knowing that SBC sent the CANCEL 4 times as Kamailio didn’t
> respond to it , which is normal as in the routing logic I’m only handling
> INVITE packets (if (is_method("INVITE"))).
> So I’m confused whether I have to handle it or not.
>
> Regards,
> Ali Taher
>
> From: sr-users
> <[email protected]<mailto:[email protected]>>
> On Behalf Of Alex Balashov
> Sent: Tuesday, January 28, 2020 3:37 PM
> To: Kamailio (SER) - Users Mailing List
> <[email protected]<mailto:[email protected]>>
> Subject: Re: [SR-Users] SIP Redirect CANCEL handling
>
> Unless you have created a transaction in the course of processing the
> redirect, there is no transaction to terminate, and accordingly no 487 to
> generate. However, these decisions are made by the default CANCEL handling
> (with hooks into TM) from the stock Kamailio config. You should not need any
> special logic of your own here.
>
> —
> Sent from my iPad
>
>
>
> On Jan 28, 2020, at 8:29 AM, Ali Taher
> <[email protected]<mailto:[email protected]>> wrote:
>
> Hello,
>
> I’m using Kamailio as sip redirect server where SBC forwards the calls to
> Kamailio which sends the routing back to SBC in 3xx response.
>
> Now, I need to handle CANCEL requests sent from SBC to Kamailio. Here is the
> scenario:
> the client sends CANCEL request to SBC which responds with 200 OK and 487
> Request Terminated and then sends CANCEL request to Kamailio.
> I’m not sure how Kamailio should handle the CANCEL request here, should it
> send only 200 OK back to SBC or also should send 487 request terminated?
>
> Regards,
> Ali Taher
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> [email protected]<mailto:[email protected]>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> [email protected]<mailto:[email protected]>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> [email protected]
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
