sr-users August 2016

sr-users@lists.kamailio.org

80 participants
108 discussions

Configuring/Integrating Kamailio Open IMS with FHoSS
by Olvera, Victor 04 Nov '16

04 Nov '16

How does one configure Kamailio Open IMS and FHoSS? In other words, how does one configure IMS and FHoSS so that when soft calls are made they must be processed by the FHoSS before they go through the Open IMS server? Great regards, Victor Olvera

8 13

604 Does not exist anywhere - HSS User Unknown
by Rodrigo Moreira 23 Sep '16

23 Sep '16

Hi, After I am registred on Kamailio a try to make a call (INVITE), and S-CSCF returns the messege: 604 Does not exist anywhere - HSS User Unknown What I am doing wrong? Is the contact entry (Alice) wrong? How should the contact entry on the list? sip:alice@mydomain.com Best Regards., -- Rodrigo M. (37) 9132-4539 (34) 9889-3069 rodrigo.moreira2007

3 3

tls with ubuntu 16.04
by Jayesh Nambiar 19 Sep '16

19 Sep '16

Hi, Trying kamailio with Ubuntu 16.04 and I'm getting errors as follows: ERROR: tls [tls_init.c:490]: tls_pre_init(): Unable to set the memory allocation functions The error is identical to the one mentioned here: https://bugs.launchpad.net/ubuntu/+source/kamailio/+bug/1591992 Is there a solution to this. Thanks for any response. - Jayesh

2 21

Radius Authentication for kamailio-4.4.2
by Chan Kwang Mien 12 Sep '16

12 Sep '16

Hi, I have installed Kamailio-4.4.2 and radiusclient-ng-0.5.6 for Radius Authentication to a Free Radius Server. I have used the steps in http://www.kamailio.org/docs/openser-radius-1.0.x.html to enable Radius Authentication for Kamailio-4.4.2. However, when I restart kamailio and my SIP phone register to Kamailio, Kamailio did not Radius Authenticate to Free Radius Server. Can anyone advise me on other document for Radius Authentication for Kamailio ? Thanks. Regards, Kwang Mien

2 1

pua_dialoginfo: Tags only in "early" state PUBLISH
by Stefan Kohlhauser 12 Sep '16

12 Sep '16

Hello everyone! I've been playing around with the pua_dialoginfo. I noticed that the From- and To-Tags are only included in the PUBLISH's dialog-info of the "early" state. This is also true if include_tags of pua_dialoginfo is explicitly set to '1'. The reason for this behaviour is probably that in pua_dialoginfo.c in the function __dialog_sendpublish() the call to dialog_publish_multi() only happens with the tag parameters set for the "early" state. For all other dialog states the tag parameters are statically set to '0'. Even though the local- and from-tags are optional I tend to regard this as a bug. I would have expected for the tags to be included in the dialog-info for all states when include_tags is set. Or is there a reason for this behaviour? Best regards Stefan

2 1

4.4 topos ignoring Record-Route?
by Daniel Tryba 09 Sep '16

09 Sep '16

Looking into the topos module of 4.4.2 I see something unexpected, ACK and BYE are routed directly to the Contact in the 200 OK on an INVITE where the 200 OK has a Record-Route. Without the topos module the message flow is as expected: 109.235.32.57<->185.61.68.106<->109.235.32.55 With topos the ACK and BYE take a different route: 109.235.32.57<->185.61.68.106<->109.235.32.55 <->109.235.32.48 109.235.32.5x are proxies. 185.61.68.106 is the registrar To my understanding, in the callflow below the ACK should be send via the proxy that inserted Record-Route: <sip:109.235.32.55;lr> in the 200 OK. Am I wrong to conclude this or the topos module ignoring the routing? Also note the To/From are passed untouched in the ACK/BYE and the BYE to the called endpoint hasn't had its Via headers stripped. Call scenario: tryba/+31407110xxx calls 0880100XXX. Both are registered to 185.61.68.106 via proxies (resp. 109.235.32.57 and 109.235.32.55) >From 109.235.32.57 -> 185.61.68.106: INVITE sip:0880100XXX@sip.itco.nl SIP/2.0 Record-Route: <sip:109.235.32.57;r2=on;lr> Record-Route: <sip:109.235.32.57;transport=tcp;r2=on;lr> Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Route: <sip:109.235.32.57;transport=tcp;lr> From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl> Contact: <sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2> >From 185.61.68.106 -> 109.235.32.55: INVITE sip:+31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Route: <sip:loadbalancer@109.235.32.55;lr;received=sip:109.235.32.48:5060> From: <sip:+31407110XXX@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:+31880100XXX@sip.itco.nl> Contact: <sip:btpsh-57b6cc75-f42d-1@185.61.68.106> >From 109.235.32.55 -> 185.61.68.106: SIP/2.0 200 OK Via: SIP/2.0/UDP 185.61.68.106;rport=5060;branch=z9hG4bK7dd7.d4cdfe8014e0d5d806b4dc4a7422c8e0.1 Record-Route: <sip:109.235.32.55;lr> From: <sip:+31407110XXX@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:+31880100XXX@sip.itco.nl>;tag=as61fc6a47 Contact: <sip:%2b31880100XXX@109.235.32.48> >From 185.61.68.106 -> 109.235.32.57 SIP/2.0 200 OK From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl>;tag=as61fc6a47 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.e15a4ffb2c3a7f882117b80c85f75223.0;i=60c,SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bKb5004b60de287221 Contact: <sip:atpsh-57b6cc75-f42d-2@185.61.68.106> Record-Route: <sip:109.235.32.57;r2=on;lr>,<sip:109.235.32.57;transport=tcp;r2=on;lr> >From 109.235.32.57 -> 185.61.68.106: ACK sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK7dd7.a49ec0c055166a1935ff84cfca4d1a5c.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK24aff2df2ee7b43f From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl>;tag=as61fc6a47 Contact: <sip:tryba@10.0.3.169:5067;transport=tcp;alias=109.235.34.226~5067~2> >From 185.61.68.106 -> 109.235.32.48 ACK sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK7dd7.ac1b9a45042f9c26277afb9ec32bebe0.0 From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl>;tag=as61fc6a47 Contact: <sip:btpsh-57b6cc75-f42d-1@185.61.68.106> >From 109.235.32.57 -> 185.61.68.106 BYE sip:atpsh-57b6cc75-f42d-2@185.61.68.106 SIP/2.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl>;tag=as61fc6a47 >From 185.61.68.106 -> 109.235.32.48 BYE sip:%2b31880100XXX@109.235.32.48 SIP/2.0 Via: SIP/2.0/UDP 185.61.68.106;branch=z9hG4bK4dd7.4916bf7bcaa3b0346e43c3785a9be782.0 Via: SIP/2.0/UDP 109.235.32.57;branch=z9hG4bK4dd7.24da86af0a970ee399c9504933d8d751.0;i=60c Via: SIP/2.0/TCP 10.0.3.169:5067;rport=5067;received=109.235.34.226;branch=z9hG4bK0d8db1380c5011b6 From: <sip:tryba@sip.itco.nl>;tag=576aff337d33fbe5 To: <sip:0880100XXX@sip.itco.nl>;tag=as61fc6a47

2 19

Call forking with delay
by Igor Potjevlesch 08 Sep '16

08 Sep '16

Hello list, I have a proxy that manage fix calls and a proxy that manage mobile calls. I want to implement call forking so when I call to a fix phone the call goes to the fix proxy and it forks to the mobile proxy who manage the call and viceversa. I want the fix to ring 2 or 3 times before the mobile. In order to do so in my fix proxy I added a diversion field with the reason "forking" and in my mobile proxy I check if the reason is "forking" to wait with the fonction "async_route" from the ASYNC module. When I call the fix I can fork to the mobile with delay without any problem because in that case my fix proxy manage one call and my mobile proxy the other one. But when I call the mobile the call doesn't even get to my fix proxy because my mobile proxy has to make the original call to wait while he is forking the fix call to my other proxy. And i think that calling the async_route fonction makes both calls to wait. My code is: Fix proxy: if($tU==123456789){ add_diversion("forking"); append_branch("sip:987654321@proxy_mobile"); } Mobile proxy: if($tU==987654321){ $var(z) = "1"; append_branch("sip:123456789@proxy_fix"); } route[INVITE]{ if($dir == "forking"){ async_route("RELAY", "7"); }else if($var(z) == "1"){ async_route("RELAY", "7"); }else{ route(RELAY); exit; } } How can I differentiate in the second scenario when I call the mobile phone to fork to the fix phone? Thank you for your help. Igor.

2 3

UAC reg_contact_addr with rinstance
by DanB 08 Sep '16

08 Sep '16

Hey Guys, Have hit an issue when using uacreg. When working with Broadsoft (I know, life is not perfect), it appears that their SBC sitting in front of registration server is caching REGISTRATION requests and it will not be able to re-REGISTER in case of credential changes for example. This will break the registration process in registrar since that one flushes the registrations on password change. Their "standard" workaround it is using "rinstance" uri parameter in contact (each contact should be unique in order to be cached by their SBC). Checking it appears that I can only add rinstance statically in reg_contact_addr configuration parameter. Is there any chance to provide things like $avp or selects which I can later modify via mi maybe? Thanks in advance for any kind of tip! DanB

2 6

detect failed socket
by Péter Barabás 05 Sep '16

05 Sep '16

Hello, I want to refine the instant message handling in our application. It works really fine in most cases. I use the msilo module to store offline messages if the user is not registered with sending PUSH notification. But, there is a situation when I have problems: When I send a message to a user whose phone is in airplane mode. In this case his location record exists but the communication on the socket is not possible and the client timed out the request. Is it possible to check the socket towards the receiver user at the moment when the message arrives at Kamailio? I think if I would check that if the socket is not fine, I could send the message to the msilo directly and the client would not have wait for timeout to resend. Thanks. Peter

5 9

Kamailio - passing registration to another sip server
by Mike Patterson 05 Sep '16

05 Sep '16

I have configured Kamailio to pass a registration request to another VoIP provider. The reason I am doing this is to provide a sip port for users where the ISP is blocking SIP. I am able to pass the registrations to the VoIP provider but I'd like to have inbound calls working as well. I see the inbound invites coming into the Kamailio server but it appears that the server does not 'know' about the UA that is registered 'through' the server to the VoIP provider. Can anyone tell me how to fix this problem? Below is my config. Thank you, Mike #!KAMAILIO # # Edge proxy configuration # #!subst "/REGISTRAR_IP/xxxxxxxxxx/" #IP address of voip provider #!subst "/REGISTRAR_PORT/5060/" #!substdef "/FLOW_TIMER/20/" debug=2 log_stderror=no log_facility=LOG_LOCAL0 fork=yes children=4 alias="example.com" #mpath="/usr/lib64/kamailio/modules" mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules" tcp_connection_lifetime=30 # FLOW_TIMER + 10 auto_aliases=no mhomed=0 listen=udp:X.X.X.X:531 advertise X.X.X.X:531 alias="X.X.X.X:531" alias=X.X.X.X:531 alias="X.X.X.X:531" alias=X.X.X.X:531 port=531 ####### Modules Section ######## loadmodule "tm.so" loadmodule "sl.so" #loadmodule "outbound.so" loadmodule "rr.so" loadmodule "path.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "mi_fifo.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "rtimer.so" loadmodule "sqlops.so" # ----------------- setting module-specific parameters --------------- # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- tm params ----- modparam("tm", "failure_reply_mode", 3) # ----- rr params ----- modparam("rr", "append_fromtag", 0) ####### Routing Logic ######## request_route { route(REQINIT); if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } route(WITHINDLG); t_check_trans(); if (is_method("REGISTER")) { remove_hf("Route"); add_path(); $du = "sip:REGISTRAR_IP:REGISTRAR_PORT"; } else { if (is_method("INVITE|SUBSCRIBE")) record_route(); if ($si == "REGISTRAR_IP" && $sp == "REGISTRAR_PORT") { if (!loose_route()) { switch($rc) { case -2: sl_send_reply("403", "Forbidden"); exit; default: sl_reply_error(); exit; } } t_on_failure("FAIL_OUTBOUND"); } else { if ($rU == $null) { sl_send_reply("484", "Address Incomplete"); exit; } remove_hf("Route"); $du = "sip:REGISTRAR_IP:REGISTRAR_PORT"; } } route(RELAY); } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } route[REQINIT] { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } route[WITHINDLG] { if (has_totag()) { if (!loose_route()) { switch($rc) { case -2: sl_send_reply("403", "Forbidden"); exit; default: if (is_method("ACK")) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } sl_send_reply("404","Not Found"); } } else { if (is_method("NOTIFY")) { record_route(); } route(RELAY); } exit; } } onreply_route { if (!t_check_trans()) { drop; } if ($rm == "REGISTER" && $rs >= 200 && $rs <= 299) { remove_hf("Flow-Timer"); if ($(hdr(Require)[*])=~"outbound") insert_hf("Flow-Timer: FLOW_TIMER\r\n", "Call-ID"); } } failure_route[FAIL_OUTBOUND]{ if (t_branch_timeout() || !t_branch_replied()) { send_reply("430", "Flow Failed"); } }

4 9

2026

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 August 2016