May 2015 - sr-users - kamailio.org

Kamailio TLS
by Kethzer Docteur 12 Feb '16

12 Feb '16

Im trying to enable Kamailio TLS but the configuration is not running at all when I cahnge it liike this as follow. Kamailio 3.3 ubuntu 12.04 LTS #!define WITH_TLS #!ifdef WITH_TLS enable_tls=yes #!endif #!ifdef WITH_TLS loadmodule "tls.so" #!endif #!ifdef WITH_TLS # ----- tls params ----- modparam("tls", "config", "/etc/kamailio/tls.cfg") #!endif Please help -- Kethzer Docteur

4 3

Append to reply in default action of failure_route
by Efelin Novak 28 Dec '15

28 Dec '15

Hi, I would like to append a header to a 'winning' negative reply in failure_route and let the Kamailio do the default action (state fully forward the winning reply). When I use append_to_reply("Foo: bar\r\n"); and then call exit; in failure_route nothing is appended. When I use same append_to_reply then t_relay("505","Error"); and exit; the header is appended. When I use append and t_reply with dialog modul turned on I got a bug I'm solving here '[SR-Users] t_reply in failure route with dialog module'. So my question is how to put a header into a reply when I don't want to alter its code or text? I'm using Kamilio 4.0.4 on Debian 7.1 Thanks for an answer Efelin

3 3

kamailio 4.0.1 websocket configuration
by Rupayan Dutta 28 Dec '15

28 Dec '15

Hi All, I have build Kamailio 4.0.1 from source in CentOS 5.8(i386 architecture).I followed all instructions from http://www.kamailio.org/wiki/install/4.0.x/git.(Though Modules_k directory is not generated).I then edit kamailio.config file for websocket support as described in webocket.cfg file in exmples directory.But while starting kamailio it gives following error ERROR: load_module: could not open module : libunistring.so.0: cannot open shared object file: No such file or directory 0(30270) : [cfg.y:3567]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 318, column 12-57: failed to load module I checked websocket.so file in the specified directory and it is already there.Can you please help me what's wrong with it? please help. Rupayan Dutta

4 3

Kamailio - Asterisk, problem with SIP trunk mode
by Mickael MONSIEUR 02 Dec '15

02 Dec '15

Hello, First, i have 7 years experience with Asterisk, but I started a project with Kamailio, forgive me in advance if I say silly things...! ;-) I set up a classic Asterisk / Kamailio configuration: sip phones -> kamailio -> asterisk -> sip trunks/pstn. When a call comes from the PSTN side, if I configure Asterisk as follows: [012345678] type = friend username = 012345678 secret = xxxxxxx host = dynamic fromdomain = sip.mydomain.com fromuser = 012345678 Standard mode: exten => 012345678, 1, Dial(SIP/012345678) -> The call is redirected on the phone by Kamailio ! :-) ------------------------------------------------------------------------------------------------------------------------------------------------ Trunk mode: [mytrunk] type = friend username = mytrunkUser secret = xxxxxxx host = dynamic fromdomain = sip.mydomain.com fromuser = mytrunkUser exten => 012345678, 1, Dial(SIP/mytrunk/012345678) -> The call is rejected by Kamailio.... exten => 012345679, 1, Dial(SIP/mytrunk/012345679) -> The call is rejected by Kamailio .... My question is how to allow the routing of multiple numbers (trunk mode) in a SIP account with Kamailio? Best regards, Mickael

3 6

Issue with SNMPstats
by Igor Potjevlesch 24 Nov '15

24 Nov '15

Hello, I have configured the SNMPstats module fine in my machine because I get the SNMP information with the new KAMAILIO MIBS but I don't understand why the value of kamailio dialogs is always 0: KAMAILIO-MIB::kamailioCurNumDialogs.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInProgress.0 = Gauge32: 0 KAMAILIO-MIB::kamailioCurNumDialogsInSetup.0 = Gauge32: 0 KAMAILIO-MIB::kamailioTotalNumFailedDialogSetups.0 = Counter32: 0 However I can see the transactions: KAMAILIO-SIP-COMMON-MIB::kamailioSIPSummaryTotalTransactions.0 = Counter32: 54797 Should I configure an specific parametr of the SNMPstats module? Regards,

3 6

Kamailio IMS - VM
by Bruno Cruz 17 Nov '15

17 Nov '15

Hello everyone, My name is Bruno, I'm a student from Portugal studying IMS at the moment. I've been following tutorials online, trying to get Kamailio to work as an IMS core - I'm pretty much a newbie in this field. Unfortunantly I've been getting several errors and I can't seem to properly configure everything. I was wondering if there is a All-in-One VM that can be downloaded, with Kamailio ready to be used as an IMS core? Thanks in advance. Best regards, Bruno C.

4 8

Header field Contact not changed on kamailio 4.2
by Зуев Михаил 09 Nov '15

09 Nov '15

Hi all, I need to modify the host part of a contact header. I'm trying something like: route { ..... if (remove_hf("Contact")){ if (insert_hf("Contact: rn", "Contact")) xlog("Contact modified"); } if (!t_relay("YYY.YYY.YYY.YYY","5060")) { sl_reply_error(); } ...... } When i look SIP DUMP on YYY.YYY.YYY.YYY side i see older Contact field. I try subst_hf with regexp, subst and simply remove Contact, all this does not work. What i am doing wrong? -- С уважением Зуев Михаил

3 2

Announcement: Kamailio is now systemd-rtc-server
by Alex Balashov 03 Aug '15

03 Aug '15

For immediate release: ATLANTA, GA (1 April 2015)--Evariste Systems LLC, an Atlanta-based software vendor specialising in Kamailio-based service delivery solutions for the VoIP ITSP market, is pleased to announce that it, in collaboration with Red Hat Software and Ringfree Communications, has finalised the absorption of the Kamailio SIP Server into the 'systemd' system management platform for Linux. The new component shall be called 'systemd-rtc-server', or 'Systemd Real-Time Communication Server'. Alex Balashov, principal of Evariste and leader of the tri-vendor collaboration effort, will officially announce the handover of the reigns of the Kamailio project to the personal leadership of Lennart Poettering at the upcoming Systemd Real Time Communications World conference, to be held in Berlin on 27-29 May of this year. John Knight, Director of GNOME 3 Integration and part-time usability consultant at Ringfree Communications, based in Hendersonville, North Carolina,was quick to summarise the triumphs of the long-standing integration effort. Remarked Knight: "The industry has recognised for years that a SIP proxy is a basic building block in the 'init' subsystem of any Linux host. In this age of multimedia communication with voice and video, it was a travesty that systemd handled time synchronisation, network configuration, login management, logging, and console, but not SIP message routing." Sean McCord, a veteran partner at Atlanta-based integrator CyCORE & Docker, was quick to concur: "SIP calls are much easier to troubleshoot with binary logs. Combined with packet captures of TLS-encrypted WebRTC calls, systemd-journald is the ultimate call setup troubleshooting methodology of the responsive, kinetic enterprise." To support the integration of Kamailio into the ecosystem of every major Linux distribution, Evariste has released new 'dbus_api' and 'pulseaudio' modules for the project. Balashov stated, "We fully expect to use the D-Bus API to achieve gnome-session integration with systemd-rtc-server-usrloc, but we aren't going to leave Windows users behind; KamailioSvcHost.exe will support Domain Controller policies for G.722 in Active Directory forests." Despite an aggressive delivery timeline by the tri-vendor consortium behind systemd-rtc-server, industry commentators have widely lambasted the fact that it took so long for Kamailio to become integrated into systemd. Fred Posner, solutions architect at The Palner Group in Fort Lauderdale, Florida, recently wrote in a widely-publicised blog post: "sr-dev have been keeping their heads in the sand for too long. For years now, it has been completely obvious and self-evident to anyone with half a brain that all kinds of VoIP software should be included in systemd. It's a basic building block of the whole OS, having absorbed functionality previously provided by all kinds of packages like util-linux and wireless-tools." John Knight of Ringfree accepted the criticism readily, but advocated a forward-thinking orientation focused on breaking with the uncertainty of the past: "In the absence of a SIP component for routing calls to the PSTN, some people thought, 'systemd has no clear direction apart from the whims of its developers, and is a perpetually moving goal post.' Well, a SIP server should put an end to that whole discussion; that's exactly what was missing, and now that we have systemd-rtc-server, we've eliminated all doubts about the coherence, conceptual integrity and finality of systemd." -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

5 8

Interpretation of Contact header
by Joachim Büchse 30 Jul '15

30 Jul '15

Good day, I’m experiencing some problems with our VoiP providers handling of REGISTER requests. We are using a Gigaset PRO N720 as UAC behind a Juniper SSG 140 with SIP-Alg enabled. This setup kind of works with UDP but our provider wants us to use TCP. With TCP enforced incoming calls don’t work. I’ve done some wire tracing and to me it seems that the providers configuration is to blame, but then - there are many RFCs out there and many NAT and UAC bug workarounds. Anyway, I wanted to get the opinion of “the" experts about how the requests send to the UAS SHOULD be correctly interpreted. The REGISTER requests/responses look like this (outside of the firewall): Protocol TCP! client port 19091 <-> server port 5060 REGISTER sip:pbx.peoplefone.ch SIP/2.0 Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bKc1375589832468de63a719eac31156ec From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch> Call-ID: 2825358480@10_10_128_10 CSeq: 1 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> Max-Forwards: 70 User-Agent: N720-DM-PRO/70.089.00.000.000 Expires: 180 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 SIP/2.0 401 Unauthorized Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bKc1375589832468de63a719eac31156ec From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.b8fc Call-ID: 2825358480@10_10_128_10 CSeq: 1 REGISTER WWW-Authenticate: Digest realm="pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy" Server: kamailio (3.2.1 (x86_64/linux)) Content-Length: 0 REGISTER sip:pbx.peoplefone.ch SIP/2.0 Via: SIP/2.0/TCP 212.126.160.92:6717;rport;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch> Call-ID: 2825358480@10_10_128_10 CSeq: 2 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp> Authorization: Digest username="90780408050", realm="pbx.peoplefone.ch", uri="sip:pbx.peoplefone.ch", nonce="VNqJBVTah9m57ZGGs8b5XCTM3GyaExDy", response="764f371a08d258157a249f8d1b852514" Max-Forwards: 70 User-Agent: N720-DM-PRO/70.089.00.000.000 Expires: 180 Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY Content-Length: 0 SIP/2.0 200 OK Via: SIP/2.0/TCP 212.126.160.92:6717;rport=19091;branch=z9hG4bK9c27afea96e2af4baab2f8d144a588e0 From: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=2153084485 To: "Michel" <sip:90780408050@pbx.peoplefone.ch>;tag=a0440f545f39b2694d387b475a5f6bc9.6bda Call-ID: 2825358480@10_10_128_10 CSeq: 2 REGISTER Contact: <sip:90780408050@212.126.160.92:6717;transport=tcp>;q=0;expires=180;received="sip:212.126.160.92:19091;transport=TCP" Server: kamailio (3.2.1 (x86_64/linux)) Content-Length: 0 The ip:port the firewall is sending those requests from is ip 212.126.160.92 port 19091. So this does NOT match the port from the Contact header. For TCP this seems rather logical to me, as one cant be listening on a TCP port and use it for sending at the same time. The UAC closes this “register connection” with TCP FIN after the register, and so does the firewall. However unfortunately subsequent requests from the provider (ie UAS) come in on port 19091 (not port 6717 from the Contact header) and the firewall simply drops them. Observations: - the server does NOT include received=212.126.160.92 in the Via of the reponse. According to RFC3581 this is mandatory when rport is present in the request, so this is probably an error in the server. - the server does include received="sip:212.126.160.92:19091;transport=TCP” in the Contact of the response. I didnt see this in any RFC (which means nothing;-) but it could be an error. - after the client received the 200 OK it closes the TCP connection. - the server tries several times to re-contact the client (incoming TCP SYN). However not on port 6717 (defined in the Contact header) but on port 19091 (where the REGISTER came from). RFC3581 defines special behaviour when “rport” is defined in the request (i.e. response should go to the same port the request came from) - however it’s not so clear if this should apply to subsequent (INVITE/OPTIONS) requests from the server to the client. Those are strictly spoken not replies (or are they?). RFC5626 defines that a “proxy” should keep track of the flows over which it received a registration and send requests over the same flow. It is not clear if RFC5626 should be applied. The RFC5626 defines that a UAC includes an “ob” parameter in the Contact field if it whishes further requests over the same flow. Also the RFC mandates a client to add a "reg-id=x" in the Contact field. Both are not the case here, so in short I think RFC5626 should NOT be applied. In which case conecting to the originating port (instead of the Contact port) would be a server error. So in short and if I interpret the RFCs correctly, the client is reachable and should be contacted on Transport: TCP IP: 212.126.160.92 Port: 6717 If anyone who lives and breathes SIP could enlighten me if the UAS is right to call back on 19091 instead of 6717 I would really appreciate it;-)) Best regards, Joachim

3 4

usage of t_flush_flags() in event_route
by Andrew Pogrebennyk 20 Jul '15

20 Jul '15

Hi Daniel and others, I'm having a problem with acc module if I'm using the event_route/ branch-failure: say, the call comes from the app server and goes to the registered user. We arm the the failure route and per-branch failure route for the 302 redirect from the UA. We explicitly reset the accounting flags because we don't want to account the calls from the app server. The transaction is created implicitly by the t_relay(). Now if the UA responds with the 302 response and we are going to process that, we want to create an acc record for the new target from 302 message because this call may incur additional costs. I'm setting the accounting flags and calling t_flush_flags() but that doesn't work (no accounting record). Any idea if I'm doing something wrong or maybe there's a bug when changing the flags and then calling t_flush_flags from the event_route? Here are the module parameters: modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "db_url", PAIR_URL) modparam("acc", "db_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") modparam("acc", "multi_leg_info", "src_leg=$avp(i:901);dst_leg=$avp(i:902)") modparam("acc", "time_mode", 2) modparam("acc", "time_attr", "time_hires") modparam("acc", "cdr_log_enable", 0) FTR, we tried 4.1.6 and 4.1.8. And here is the event route (with flags defined like this: flags FLAG_ACC_DB:1, FLAG_ACC_MISSED:2, FLAG_ACC_FAILED:3, ...): event_route[tm:branch-failure:redirect] { route(ROUTE_STOP_RTPPROXY_BRANCH); if($T_rpl($rs) == 301 || $T_rpl($rs) == 302) { # initialise variables when entering failure route route(ROUTE_INITVARS); # these need to be avps because we need it in reply/failure-route $(avp(s:from_faxserver)[*]) = 0; $(avp(s:to_faxserver)[*]) = 0; $(avp(s:cf_from_pstn)[*]) = 0; $(avp(s:from_pstn)[*]) = 0; $(avp(s:proxylu_from_pstn)[*]) = 0; $(avp(s:lcr_flags)[*]) = 0; $(avp(s:em_call)[*]) = 0; $(avp(s:from_pbx)[*]) = 0; $(avp(s:p_to_device)[*]) = 0; $(avp(s:p_to_group)[*]) = 0; $(avp(s:is_primary)[*]) = 0; # now let's process a 30x $(avp(s:acc_state)[*]) = "cfb"; $(avp(s:orig_acc_caller_user)[*]) = $avp(s:acc_caller_user); $(avp(s:orig_acc_caller_domain)[*]) = $avp(s:acc_caller_domain); $(avp(s:acc_caller_user)[*]) = $avp(s:acc_callee_user); $(avp(s:acc_caller_domain)[*]) = $avp(s:acc_callee_domain); $(avp(s:caller_uuid)[*]) = $avp(s:callee_uuid); $(avp(s:callee_uuid)[*]) = $null; # the $var(no_acc) is 0 at this point but the flags may have been reset # if this is a call from PBX user - we do want accounting for the 302 redirect if(isflagset(FLAG_ACC_DB)) { xlog("L_NOTICE", "++++++ ACC flag is set - [% logreq -%]\n"); } else { xlog("L_NOTICE", "------ ACC flag is NOT set - [% logreq -%]\n"); } setflag(FLAG_ACC_FAILED); setflag(FLAG_ACC_DB); t_flush_flags(); # get last URI from destination-set and set it as R-URI $var(contact) = $T_rpl($ct); $var(contact) = $(var(contact){nameaddr.uri}); if($var(contact) == 0 || $var(contact) == $null) { xlog("L_ERROR", "Failed to fetch contact '$ct' from 301/302 - [% logreq -%]\n"); acc_db_request("480", "acc"); $var(announce_handle) = "callee_tmp_unavailable"; $var(announce_set) = $xavp(callee_real_prefs[0]=>sound_set); $(avp(s:announce_code)[*]) = 480; $(avp(s:announce_reason)[*]) = "Temporarily Unavailable"; route(ROUTE_EARLY_REJECT); } $ru = $var(contact); xlog("L_NOTICE", "Redirect from UAC intercepted - [% logreq -%]\n"); $(avp(s:forwarder_cli_userprov)[*]) = $T_rpl($tU); $(avp(s:forwarder_domain_userprov)[*]) = $T_rpl($td); $var(forward) = 1; $var(redirected_forward) = 1; route(ROUTE_LOAD_CALLER_PREF); route(ROUTE_FIND_CALLEE); } } Thanks. Andrew

2 5