I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating.
In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header"
I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); ....
However it always returns CSCF_RETURN_FALSE (or -1).
I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1
That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value.
Do you know any alternative solution? or do you know why msg->route value is 0 or NULL?
On Jun 7, 2025, at 9:32 AM, James Morrison via sr-users sr-users@lists.kamailio.org wrote:
I'm trying to find a way to differentiate between originating and terminating legs.
Do you mean to ask this in a very IMS-specific context, or more generally?
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com, https://www.csrpswitch.com Tel: +1-706-510-6800
Yes IMS-specific context. I want to have stat variables like rcv_rpls_invite_200_orig and rcv_rpls_invite_200_term. And I need to find a way to get it from current sip message.
Hello,
I usually look at where the call is originating from, that tells me where it’s going. If it’s coming from a user then it’s originating. Later on, if it’s going to a user it’s terminating.
Regards,
David Villasmil email: david.villasmil.work@gmail.com
On Sat, Jun 7, 2025 at 4:20 PM James Morrison via sr-users < sr-users@lists.kamailio.org> wrote:
I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating.
In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header"
I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); ....
However it always returns CSCF_RETURN_FALSE (or -1).
I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1
That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value.
Do you know any alternative solution? or do you know why msg->route value is 0 or NULL? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
Outside the IMS context, my usual approach for deciding whether this is an "inbound" call or an "outbound" call is to branch this based on whether the call is coming from a trusted origination gateway, versus from any other destination, e.g.
if(allow_trusted()) { # inbound call to user } else { # outbound call from user }
-- Alex
On Jun 7, 2025, at 10:34 AM, David Villasmil via sr-users sr-users@lists.kamailio.org wrote:
Hello,
I usually look at where the call is originating from, that tells me where it’s going. If it’s coming from a user then it’s originating. Later on, if it’s going to a user it’s terminating.
Regards,
David Villasmil email: david.villasmil.work@gmail.com
On Sat, Jun 7, 2025 at 4:20 PM James Morrison via sr-users sr-users@lists.kamailio.org wrote: I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating.
In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header"
I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); ....
However it always returns CSCF_RETURN_FALSE (or -1).
I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1
That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value.
Do you know any alternative solution? or do you know why msg->route value is 0 or NULL? __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com, https://www.csrpswitch.com Tel: +1-706-510-6800
I wish I had access to those info, but I'm trying to find weather it's origination or terminating based on the current sip message in kex/sl/tmx modules.
On Jun 9, 2025, at 7:24 AM, James Morrison via sr-users sr-users@lists.kamailio.org wrote:
I wish I had access to those info, but I'm trying to find weather it's origination or terminating based on the current sip message in kex/sl/tmx modules.
Well, then you have to think about what SIP attributes dictate whether it's origination and termination, and tells us what those are. Maybe you did, and I missed it?
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com, https://www.csrpswitch.com Tel: +1-706-510-6800
-
Alex Balashov -
David Villasmil -
James Morrison