Hi,
I am trying to capture and distinguish two types of cancels generated by kamailio. 1- Cancel when Invite timeout 408 2- Cancel generated when call lands on multiple devices and any one of them answer the call. This type of cancel comes with (rfc3326) Reason: SIP;cause=200;text="Call completed elsewhere"
How can I capture and isolate these proxy generated CANCEL events?
-- regards,
abdul basit
Hi,
On Thu, Aug 24, 2017 at 10:05 PM, Abdul Basit basit.engg@gmail.com wrote:
I am trying to capture and distinguish two types of cancels generated by kamailio. 1- Cancel when Invite timeout 408
You can catch this one in failure route. Whenever an INVITE times out and you have set t_on_failure(someroute) before, you end up in the failure route named someroute.
2- Cancel generated when call lands on multiple devices and any one of them answer the call.
I don't know whether those actually run through any route.
How can I capture and isolate these proxy generated CANCEL events?
What's the purpose of distinguishing those two CANCELs?
Regards Sebastian
Hi Sebastian,
Thank you for your reply. I have handled CANCEL in case of 408 in failure route as you suggested. This part has been done.
However, for proxy generated CANCEL, i need to intimate that call was answered else where and have to add this event in custom event logs. I am receiving 487 in onreply-route but its true for all types of CANCELs. If i know the CANCEL type, i can log EDR (events detail records).
I am trying to look around for event_route but no success yet.
event_route [tm:local-request] { # Handle locally generated requests xlog("L_INFO", "Routing locally generated $rm to <$ru>\n");}
-- regards,
abdul basit
On 25 August 2017 at 01:28, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Thu, Aug 24, 2017 at 10:05 PM, Abdul Basit basit.engg@gmail.com wrote:
I am trying to capture and distinguish two types of cancels generated by kamailio. 1- Cancel when Invite timeout 408
You can catch this one in failure route. Whenever an INVITE times out and you have set t_on_failure(someroute) before, you end up in the failure route named someroute.
2- Cancel generated when call lands on multiple devices and any one of
them
answer the call.
I don't know whether those actually run through any route.
How can I capture and isolate these proxy generated CANCEL events?
What's the purpose of distinguishing those two CANCELs?
Regards Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Abdul Basit basit.engg@gmail.com:
However, for proxy generated CANCEL, i need to intimate that call was answered else where and have to add this event in custom event logs. I am receiving 487 in onreply-route but its true for all types of CANCELs. If i know the CANCEL type, i can log EDR (events detail records).
Hi Abdul
Maybe t_is_canceled() works for your scenario:
http://www.kamailio.org/docs/modules/5.0.x/modules/tm.html#tm.f.t_is_cancele...
yes.
I tested with t_is_canceled() in failure_route. But it executes in case user CANCEL in addition to proxy generated CANCELs for 408 and answer elsewhere RFC 3326.
Need to know how to isolate them.
-- regards,
abdul basit
On 25 August 2017 at 13:28, Mikko Lehto mslehto@iki.fi wrote:
Abdul Basit basit.engg@gmail.com:
However, for proxy generated CANCEL, i need to intimate that call was answered else where and have to add this event in custom event logs. I am receiving 487 in onreply-route but its true for all types of
CANCELs.
If i know the CANCEL type, i can log EDR (events detail records).
Hi Abdul
Maybe t_is_canceled() works for your scenario:
http://www.kamailio.org/docs/modules/5.0.x/modules/tm.html# tm.f.t_is_canceled
-- Mikko Lehto
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi,
On Fri, Aug 25, 2017 at 10:28 AM, Mikko Lehto mslehto@iki.fi wrote:
Maybe t_is_canceled() works for your scenario:
Without having tested this, I would expect, that the transaction is not cancelled but answered.
You might be able to catch it with t_on_branch_failure: https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_on_branch...
Maybe those cancels go through there, too, and if you set an AVP when getting the 200 OK on another branch, you could use those two informations to get what you need.
Sebastian
-
Abdul Basit -
Mikko Lehto -
Sebastian Damm