sr-users November 2018

sr-users@lists.kamailio.org

68 participants
88 discussions

Redirects - are q values required to implement serial forking?

by Mike Montgomery

We have a situation where we get a redirect from a carrier with a list of carriers to send the transaction to in the contact header. None of the carriers in the contact header have q values assigned. We have implemented our redirect handling logic using the UAC_REDIRECT module (get_redirects()) with help from TM module (t-load_contacts(), t_next_contact()). (failure_route code is at bottom of this note) We find that when we receive a contact header with q values, we can launch requests serially using t_next_contact() and individually work through the contact list until we get a positive response. When we get a redirect with no q values in the contact header we find that all contacts get loaded and launched in parallel. Although not stated in the documentation, it appears that in order to implement serial contact redirect handling, q values must be present in the contact header. Based on this assumption, and knowing that the redirecting carrier cannot include q values, we have attempted to modify the contact header and find that we are unable to add q values to the contact header. We have attempted without success to use remove_hf("Contact”) followed by append_hf("Contact: $(avp(contact)) \r\n”); where $(avp(contact)) is the avp where we have rewritten the contact header to include q values. Any guidance on how to handle this issue is appreciated. _________________________________________________________- Our failure route code: if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####->LOAD CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); if (t_next_contacts()) { xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); }; t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in MANAGE_FAILURE --- Method $rm --- Contact Header $ct \n"); }; exit; } else { xlog("L_INFO","-----> NO REDIRECT --- Method $rm --- Contact Header $ct \n"); exit; } failure_route["serial"] { xlog ("L_INFO", "Entered failure_route(serial) /n"); if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> DOUBLE REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); $xavp(tm_contacts[*]) = $null; xlog("L_INFO", "XXX-> tm_contacts reset to Null $xavp(tm_contacts[0]=>uri)\n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####-> LOAD 2 CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); } if (!t_next_contacts()) { exit; } xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in failure_route(serial) --- Method $rm --- Contact Header $ct \n"); }; } Best Regards, Mike Montgomery Principal, Trusted Technical Services, Inc. o - 919 924 4703 x3000 m - 919 539 6133

5 years, 5 months

Adding Perl Module to kamailio-5.1.6

by AL S

I am trying to install Perl module on Ubuntu 18.04 / Kamailio kamailio-5.1.6 and getting the following response: $ sudo apt-get install kamailio-perl-modules Reading package lists... Done Building dependency tree Reading state information... Done kamailio-perl-modules is already the newest version (5.1.2-1ubuntu2). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: kamailio-perl-modules : Depends: kamailio (= 5.1.2-1ubuntu2) but it is not installable E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Is there a better way to add perl module? PS: libperl-dev already installed. Thanks, AL

5 years, 5 months

siptrace module doesn't close db connections

by Roman Dissauer

Hi, it seems that siptrace module doesn’t close db connections. I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled. siptrace config: modparam("siptrace", "db_url", DBURL) modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", 1001) modparam("siptrace", "trace_mode", 1) Here you can see the open connections from the kamailio host: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61'; client_addr | state | query --------------+-------+---------------------------------------------------------------- 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' (31 Zeilen) another example, other installation with same kamailio version 5.1.4: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1'; client_addr | state | query -------------+-------+---------------------------------------------------------------- 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' (39 Zeilen) Thanks Roman

5 years, 5 months

Single session start

by José Antonio Gutiérrez Delgado

Hi, I would like to know if it is possible to make the last register of a user the active register and if possible the only one. I'm with an Android application and sometimes I can not deregister properly before the new registration, for example when the network changes, so there are times when the hanging signals do not work correctly when there is more than one register for a user. Is it possible to avoid that there is more than one register for a user? Is it possible to configure the last register to delete the previous ones or to be a single register? Thanks in advance and I await your answers. -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

5 years, 5 months

Custom authentication

by João Sávio

Hello! I was reading the documentation of Kamailio, And, although there are some authentication modules, I couldn't find a way to implement a custom authentication for SIP Register. Something that allows me, for example, to call a web server and returns if the user is authenticated, or the user data. Am I missing anything? Do you know if it's possible to do this using another way? Thanks João

5 years, 5 months

high availability and load balancing

by eyas barhouk

hello dears, i'm using kamailio 5.1 as IMS , and i have the following servers: * p-cscf * i-cscf-1 ,icscf-2 * s-cscf-1,scscf-2 i need to do high availability and load balancing between my servers , but i have some questions like do i have to use keepalived or dispatcher module and what the benefits of each one of them ,and on load balancing method should i do it for the register requests or only for invite requests or just for every thing ?? if any one has an idea or any thing to guide me i will be thankful thanks in advance and regards

5 years, 5 months

Client Registration and Call over Kamailio

by serkan celik

Hi all, I am using Kamailio as a proxy in front of a 3rd part Open IMS (Not IMS modules in kamailio). I have defined Kamailio as an outbound proxy in Soft clients(I have configured IMS users info in Soft Clients). When I send register from client to IMS, Register message is sent to IMS over Kamailio. Kamailio forwards this received Register to the 3rd party IMS. Finally the client is registered into IMS over Kamailio. However when I try to make a call from registered users (both registered over Kamailio), IMS sends 403 Forbidden - "Not Registered! You must register first with a S-CSCF" to Kamailio. When I debugged the issue I found the reason why IMS sends 403. When IMS receives an Invite message from Kamailio it checks whether source IP which Invite is sent registered or not. As I make registration over Kamailio without changing contact header, IMS registers the user with the contact IP (which is the client IP). So to make a call from Soft client (IMS users) over Kamailio I also need to register Kamailio source IP as well.To deal with the issue I have changed the contact address of Register message coming from Soft client with Kamailio IP on Kamailio. Then IMS registered Kamailio IP as a contact when registering IMS user. But this time when I make a call from Soft client over Kamailio, IMS sends Termination Invite to Kamailio. So to finalize the call Kamailio has to route this termination Invite to the terminating IMS user . Is there any better approach to overcome this issue. Which is the better approach to use Kamailio in front of IMS. I want to both register and make a call from Soft clients over Kamailio to the IMS. Regards, Serkan CELIK

5 years, 5 months

systemd kamailio.service - RFC Wants=network-online.target

by Kevin Olbrich

Hi! The systemd kamailio.service file for debian (in my case, it's stretch) has the following unit options set: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > After=network.target It would be better to change this to: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > Wants=network-online.target > After=network-online.target Why? With network.target the service starts as soon as the network setup is started, not explicitly after configuring (=IP) it [1]. This creates a race condition on very fast hardware like mine (booting incl. all services takes 10s). Even with static IPs, kamailio often fails directly at boot because eth1 (connection to DB cluster) is not up. [I have never met this problem on systems which ran on HDDs.] Setting "network-online.target" as Wants + After makes sure, Kamailio is started after all interfaces are ready to serve. Units that strictly require a configured network connection should pull in > network-online.target (via a Wants= type dependency) and order themselves > after it. This target unit is intended to pull in a service that delays > further execution until the network is sufficiently set up. What precisely > this requires is left to the implementation of the network managing service. > Perfect example for this is the Shorewall package (firewall solution): [Unit] > Description=Shorewall IPv4 firewall > Wants=network-online.target > After=network-online.target > Conflicts=iptables.service firewalld.service RFC Kind regards Kevin [1] https://www.freedesktop.org/software/systemd/man/systemd.special.html

5 years, 5 months

cfg_lock_helper(): lock set not initialized

by Kjeld Flarup

Hi What does this error actually mean? I get it with 5.1.4 Nov 6 13:27:02 scantronpbx /usr/sbin/kamailio[2149]: ERROR: cfgutils [cfgutils.c:708]: cfg_lock_helper(): lock set not initialized (attempt to do op: 1 on: u1) -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

5 years, 5 months

Phone does not set "Expire-header" but "Contact expire", immediately expires

by Kevin Olbrich

Hi! I have a phone (Mitel 6930) that does not send an Expire-header but "expire" in Contact during REGISTER: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:pbx.example.com SIP/2.0 > Message Header > Via: SIP/2.0/TLS 192.168.6.16:5061;branch=xxxxxxxxxxxxxxxx;rport > Route: <sip:pbx.example.com;lr=lr;transport=tls> > Max-Forwards: 70 > From: "Example" <sip:121212_6666@pbx.example.com>;tag=b0cec92c3e > To: "Example" <sip:121212_6666@pbx.example.com> > Call-ID: aaaaaaaaaaaaaaaaa > CSeq: 1190442896 REGISTER > Accept-Language: de > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, > PRACK, SUBSCRIBE, INFO, PUBLISH > Allow-Events: talk, hold, conference, LocalModeStatus > Contact: "Example" <sip:121212_6666@192.0.2.1:62336 > >;+sip.instance="<urn:uuid:00000000-0000-1000-8000-08000FB888F5>";expires=300 > Supported: path, gruu > User-Agent: Mitel 6930/5.0.0.2041 > Aastra-Line: 1 > Aastra-Mac: AAAAAAAAAAAA > Content-Length: 0 This results in successful register, kamailio forwards REGISTER to asterisk (endpoint registered) and immediatly kamailio sends a new REGISTER with Expire set to 0 to asterisk: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:192.168.99.112:5060 SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.168.99.111:5060 > ;branch=z9hG4bK9f9e.599cf243000000000000000000000000.0 > To: <sip:121212_6666@192.168.99.112> > From: <sip:121212_6666@192.168.99.112 > >;tag=7e4f6993bfbf831f6b016fea6683cdca-b98a > CSeq: 10 REGISTER > Call-ID: 2bc5fd1061b31723-1350(a)192.168.99.111 > Max-Forwards: 70 > Content-Length: 0 > User-Agent: kamailio (5.1.6 (x86_64/linux)) > Contact: <sip:121212_6666@192.168.99.111:5060> > Expires: 0 The phone is then unregistered - the phone also shows "no service". It looks like Kamailio generates this message on it's own (and I don't know why). I am still learning to implement kamailio as proxy. Reading the docs, I would expect Kamailio to automatically eval the correct parameter: > If the processed message contains neither Expires HFs nor expires contact > parameters, this value will be used for newly created usrloc records. [1] What did I miss? Phones which use the Expire-header are working fine. Kind regards Kevin [1] default_expires - http://www.kamailio.org/docs/modules/5.2.x/modules/registrar.html

5 years, 5 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 November 2018