sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

CDR preserve original call direction
by Ahmed Fouad 10 Feb '22

10 Feb '22

Hi, I've enabled ACC and CDR logging and it's working fine for the logging but I noticed something wrong in the CDR table , the call source and destinations are depending on the BYE message not the initial invite dialog ACC table +-----+--------+--------------------------------------+---------------------+---------------+---------------------------+--------------+--------------+--------------------------------------+ | id | method | callid | time | src_ip | src_domain | src_user | dst_ouser | dst_domain | +-----+--------+--------------------------------------+---------------------+---------------+---------------------------+--------------+--------------+--------------------------------------+ | 216 | BYE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09 06:57:51 | x.x.x.x | domain.com | DST_CLID | SRC_CLID | domain.com | | 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09 06:55:17 | x.x.x.x | domain.com | SRC_CLID | DST_CLID | dst_domain.com | The INVITE is the correct one with SRCIP x.x.x.x and domain.com but the BYE reversed the order since the the DST_CLID who sent the BYE so it's now logged as the source and the final CDR log looks like +--------+--------------+---------------------------+--------------+--------------------------------------+---------------------+---------------------+----------+-----+-------+--------+-------+---------+ | cdr_id | src_username | src_domain | dst_username | dst_domain | call_start_time | call_end_time +--------+--------------+---------------------------+--------------+--------------------------------------+---------------------+---------------------+----------+-----+-------+--------+-------+---------+ | 195 | DST_CLID | domain.com | SRC_CLID | domain.com | 2022-02-09 06:55:12 | 2022-02-09 06:57:51 | the CDR as shown is reversed regarding the source/dst username I tried to enable the direction ACC direction flag but didn't help and here is my current paramters modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 0) modparam("acc", "detect_direction", 0) modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "cdr_enable", 1) modparam("acc", "cdrs_table", "cdrs") Can you please advise how to configure ACC/CDR to log the CDR with the correct initial INVITE call flow regardless of the BYE direction ?

3 5

10 Feb '22

Hi there, I have a weird issue with kamailio (latest docker image kamailio-ci:5.5.2-alpine) and http_async_client. Before posting a lot of logs, let me describe what I want to achieve. I have a Kamailio and a SIP Phone. The SIP phone sends a REGISTER to kamailio, then in my routing block, I check if I have an Authorization header. Since I don't have an Authorization (first message), I use "www_challenge()". This replies to the SIP phone, and then the SIP phone sends a new REGISTER with the correct Authorization header. So far so good. Now, when I get the REGISTER with Authorization header, I want to ask an HTTP endpoint if this user is allowed to connect and check the password using http_async_query(). The problem is that when the transaction resumes, the tmx module is unhappy and throws this error : 30(36) CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch (-1) for a final response in MODE_ONFAILURE And a 500 error is sent back to the sip phone. The AUTH_REPLY route is still called and I can use the $http* values. Do you see something that I am doing wrong or missing in my logic? Is pausing/resuming to use the async http client is allowed if I'm handling a REGISTER transaction? Here's a simplified version of my routing block (not far from reality): ##### SNIP request_route{ route(AUTH); route[AUTH]{ if (is_method("REGISTER"){ if(no_auth_header){ www_challenge("$td","1"); exit; } else{ t_newtran(); http_async_query("http://xxx.xxx.xxx.xxx:9000/auth?foo=bar", "AUTH_REPLY"); } } } route[AUTH_REPLY]{ xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); } } ##### END SNIP Best regards!

4 15

Kamailio doc request
by Mustafa Rahman 10 Feb '22

10 Feb '22

2 1

Failure route with t_relay()
by Max Kemel 08 Feb '22

08 Feb '22

Hey, I am trying to make a re-transmission mechanism from the failure route, I've tried to use $dp and $du as a relay, but variables are not accepted in t_relay(), When using ip and port straight forward t_relay("144.0.0.0", "1111"), I am getting: [t_fwd.c:1752]: t_forward_nonack(): no branches for forwarding [tm.c:1753]: _w_t_relay_to(): t_forward_noack failed Is there a way to re-transmit the call to the same carrier again? Thanks in advance, and have a great day, Max Kemel

2 1

Failure route mechanism with counter
by Max Kemel 08 Feb '22

08 Feb '22

Hey, I would like to use a failure route with a retry mechanism, which provides a MAX_NUM_OF_RETRIES (max number of times reaching the failure route), Which can be achieved by a simple global counter, from what I've seen, the Counters module doesn't provide a GET function in script, What is the easiest solution for this kind of behavior? Thanks a lot, Max Kemel

2 1

Timers firing too soon
by Alberto Izquierdo 04 Feb '22

04 Feb '22

Hi all, I'm using Kamailio timers to execute a series of calls with a certain delay. I have found out that from time to time, the timers are triggered too soon, sometimes they are triggered 2/3 seconds before they should. I have read in the documentation that it is normal to have a bit of delay in some of the timers, but it doesn't mention anything about this behavior. Is this normal? Thank you.

1 0

Debian kamailio.init vs. kamailio.service
by Juha Heinanen 04 Feb '22

04 Feb '22

By comparing pkg/kamailio/deb/bullseye dir kamailio.init and kamailio.service files, it appears to me that they are not equal alternatives. Is this correct interpretation? -- Juha

1 0

Homer7 and Kamailio 5.3
by Angelo Sipper 03 Feb '22

03 Feb '22

Hi to all, We have a Kamailio 5.3 that sends all traffic to a homer7 using siptrace module with parameters force_send_sock and hep_mode_on,1 and hep_version,3 and trace_mode,1. Everything works fine getting all traffic to Homer7 but, in case Homer7 is not reachable, Kamailio then no longer accepts traffic or registrations and it is like it crashes. When we revive Homer7 and is it again reachable accepting traffic, Kamailio then works again fine without any restart or actions. Any ideas why this may be happening? Is there anything we need to add to the config to avoid this behavior as having Homer7 now is a single point of failure for Kamailio? Thank you! Kind Regards, Angelo

6 11

uac problem with 5.3.8
by Richard Robson 03 Feb '22

03 Feb '22

we have been running 5.3.4 with the uac_auth_mode() function ans it has been working we have upgraded to 5.3.8 and with the same script we are getting an error with the uac module saying it was unable to find the cmd auc_auth_mode I have tried this with uac_auth as well with the same result. it looks like the uac module is not loaded or is not loading but running a core.modules reports the uac module can anyone shed any light on this problem? is it a version pecific problem?

3 4

Updating $du for uac REGISTERs in event_route[tm:local-request]
by Raffaella Seuß 03 Feb '22

03 Feb '22

Hello all, I tried to update $du for REGISTERs sent by the uac module in event_route[tm:local-request]. (I want to overwrite the auth_proxy under some conditions.) However, the requests are still sent to the auth_proxy defined in uacreg. Am I missing something here, why doesn't it work? It's basically just: event_route[tm:local-request] { if (is_method("REGISTER")) { # ... $du = "sip:PROXY_IP:PROXY_PORT"; } } My Kamailio version is 5.5.2. With kind regards, Raffaella Seuß foncloud GmbH & Co KG Hahlweg 2a 36093 Künzell Tel: / Fax: +49 661 968990-99 Email: raffaella.seuss(a)foncloud.net Web: www.foncloud.net P.S.: Wussten Sie schon? Unter https://www.foncloud.net/wissen finden Sie zahlreiche Informationen und hilfreiche Artikel rund um unsere Produkte und Services. Registergericht: Amtsgericht Fulda, Persönlich haftende Gesellschafterin der foncloud GmbH&Co.KG: Global Brain Network GmbHGeschäftsführer der Global Brain Network GmbH: Peter Krug Sitz der Gesellschaft: Künzell. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users