24 Aug
2017
24 Aug
'17
4:05 p.m.
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
24 Aug
24 Aug
4:28 p.m.
Hi,
On Thu, Aug 24, 2017 at 10:05 PM, Abdul Basit <basit.engg(a)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
25 Aug
25 Aug
3:55 a.m.
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(a)sipgate.de> wrote:
Hi,
On Thu, Aug 24, 2017 at 10:05 PM, Abdul Basit <basit.engg(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
4:28 a.m.
Abdul Basit <basit.engg(a)gmail.com>om>:
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_cancel…
--
Mikko Lehto
6:51 a.m.
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(a)iki.fi> wrote:
Abdul Basit <basit.engg(a)gmail.com>om>:
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7 a.m.
Hi,
On Fri, Aug 25, 2017 at 10:28 AM, Mikko Lehto <mslehto(a)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_branc…
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
2681
days inactive
2682
days old
5 comments
3 participants
participants (3)
-
Abdul Basit -
Mikko Lehto -
Sebastian Damm