sr-users September 2016

sr-users@lists.kamailio.org

87 participants
127 discussions

by Muhammad Shahzad

Hi, About 3 weeks ago i upgraded one of my production server with latest stable kamailio version 4.2.1-fad00a. Now i am getting a lot of complaints about missing CDR events in ACC table. I observe following problems, 1. There are only BYE records in acc table, no record for INVITE or ACK. 2. In kamailio logs when ACK is received against 200 OK response for INVITE, i see following errors, -- ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to parse >From uri ERROR: pv [pv_core.c:434]: pv_get_xto_attr(): cannot parse From URI NOTICE: <script>: [udp:<null>@1.0.0.127:5060]: Call from 'you(a)kamailio.org' to 'you(a)kamailio.org' has been hanged up by '<null>' at '1419364717.255484' -- Of course all these errors are bogus, I have checked all headers in ACK (not just FROM header), they all seem perfectly fine and valid. 3. Then the dialog times out, -- WARNING: dialog [dlg_handlers.c:1440]: dlg_ontimeout(): timeout for dlg with CallID '6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9' and tags '1D3ECD34F5731AB845BA3064AC95BB2D' '7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4' -- 4. Any further sequential requests complain about "unable to find dialog", e.g. -- NOTICE: <script>: Sequencial 'BYE' request received from caller ERROR: uac [replace.c:591]: restore_uri(): new URI [] shorter than old URI [ sip:00xxxxxxxxxx@sip.domain.com] WARNING: dialog [dlg_handlers.c:1174]: dlg_onroute(): unable to find dialog for BYE with route param '5ae1.d595' [7845:22877] -- 5. However the acc record for BYE is written to db and log file, -- NOTICE: acc [acc.c:318]: acc_log_request(): ACC: transaction answered: timestamp=1419364760;method=BYE;from_tag=7f55e81e0630-100007f-13c4-6009-2440a4-5fa31570-2440a4;to_tag=1D3ECD34F5731AB845BA3064AC95BB2D;call_id=6D8BD23CAC65AE3C1DE1D0B531F87B8CFEAA9CB9;code=200;reason=OK;src_user=00xxxxxxxxxx;src_domain= sip.domain.com ;src_ip=xx.xx.xx.xx;dst_ouser=+1xxxxxxxxxx;dst_user=1xxxxxxxxxx;dst_domain=yy.yy.yy.yy -- The same config was working fine with older version 4.2.0-97cab8. The kamailio config i am using is pretty much standard, -- #!define FLT_ACC 1 #!define FLT_ACCMISSED 2 #!define FLT_ACCFAILED 3 #!define FLT_DLG 4 ... modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "log_flag", FLT_ACC) modparam("acc", "log_missed_flag", FLT_ACCMISSED) modparam("acc", "failed_transaction_flag", FLT_ACCFAILED) # log to db modparam("acc", "db_flag", FLT_ACC) modparam("acc", "db_missed_flag", FLT_ACCMISSED) modparam("acc", "db_url", "DBURL") ... request_route { # per request initial checks route(REQINIT); # NAT detection route(NATDETECT); # handle requests within SIP dialogs route(WITHINDLG); # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); }; exit; }; #### only initial requests (no To tag) #### t_check_trans(); .... # account only INVITEs if (is_method("INVITE")) { setflag(FLT_DLG); # create dialog setflag(FLT_ACC); # do accounting setflag(FLT_ACCFAILED); # ... even if the transaction fails $avp(dlg_timeout) = 60; dlg_manage(); .... } -- Any ideas why its happening? Since it is 3 weeks old so may be problem has already been spotted and fixed by someone else. Otherwise let me know how can i provide more info to help fix this issue. Thank you.

6 years, 11 months

How to make OutBound calls with kamailio

by sharad tyagi

Hi I am novice to kamailio , I have installed kamailio-4.2.0 and SIREMIS. I have add and registered two IP phones with kamailio these phone able to call each other. How can i make outbound call with that I am using a asterisk server as PSTN Gateway. i am not famalier with kamailio script. Regards Sharad Tyagi SparkTG info Pvt Ltd

6 years, 11 months

Parallel Forking with Different Call-Id

by SamyGo

Hi, I've a very strange scenario to work on which requires me to parallel fork the call to the same Destination provider. The only problem here is that they think that the second INVITE with different branch tag is a re-transmission and hence only take one call forward. I do not have to modify any R-URI or any headers, hence just 'append_branch() before t_relay() is in the code. ... $ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port); append_branch(); route(RELAY); ... *Question:* Is there anyway possible I can change the CallID of the forked INVITEs ? I have tried using Topoh module, but it still puts the same CallID before sending out. Different from the A-leg but the Sent out INVITEs have same Call-ID value. In other weird scenario, I've also tried branching, and looping call within Kamailio before sending out to carrier hoping that Kamailio would treat the two different calls and Topoh would change the Call-ID on both INVITEs before sending out.. ... if(is_present_hf("X-FORKED")) { $ru = "sip:" + $rU + "@" + $avp(carrier_ip) + ":" + $avp(carrier_port); route(RELAY); }else { append_hf("X-FORKED: 1\r\n"); append_branch(); route(RELAY); } ... Still I get same Call-ID on outgoing branched call. I could branch out one INVITE to a MediaServer, say FreeSWITCH/Asterisk but again I don't want to have that component bottleneck the throughput. That could be my very last option. Looking for some ideas. Regards, Sammy

7 years, 1 month

Cannot hear voice with symmetric NAT and STUN

by Khoa Pham

Hi, I have Kamailio as SIP server and RTP server. Client is PJSIP. I read that STUN is for non-symmetric NAT, and RTP server is for symmetric NAT. Supposed A calls B. If A, B both use symmetric NAT and STUN, they cannot hear each other If A or B use non-symmetric NAT and NOT using STUN, they cannot hear each other. Why is that? I read http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt for Prediction Failure, is that related to this problem ? -- Khoa Pham HCMC University of Science Faculty of Information Technology

7 years, 2 months

(no subject)

by jay binks

Hi Guys, Im using a keepalived solution between 2 kamailio boxes, with net.ipv4.ip_nonlocal_bind =1 . On the "non master" I pretty much constantly get these logs in syslog. What Im looking for is a way to suppress these because they are expected in my configuration. is there any way to tell kamailio to not log this... ( or at least, not at CRIT and ERROR ) *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: ERROR: tm [../../forward.h:208]: msg_send(): udp_send failed* *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: ERROR: <core> [udp_server.c:576]: udp_send(): sendto(sock,0x7fc0732d5ab0,380,0,xxx.xxx.xxx.xxx:5060,16): Invalid argument(22)* *Jun 25 10:32:53 lb2 /usr/sbin/kamailio[24869]: CRITICAL: <core> [udp_server.c:581]: udp_send(): invalid sendtoparameters#012one possible reason is the server is bound to localhost and#012attempts to send to the net* -- Sincerely Jay

7 years, 3 months

Using the auth_ephemeral module

by Hemanshu Vadehra

I'm involved in setting up a Kamailio instance and was hoping to make use of the auth_ephemeral module for authentication. But the module documentation doesn't quite make clear how exactly the module is to be employed or the web service set up. Does anyone have a working example? Regards, Hemanshu Vadehra hemanshu.v(a)directi.com

7 years, 3 months

Siremis installation with postgresql.

by José Seabra

Hi there, I'm facing some issues trying to install siremis with postgresql. The file Config.xml has the correct configuration for postgresql driver but It seems that during installation phase siremis can't create database structure for postgresql. Anyone have installed siremis with postgresql, if yes can you share the steps needed for this installation. -- Cumprimentos José Seabra

7 years, 4 months

Send SIP Info within a dialog using $uac_req(method)="INFO"

by Jonathan Hunter

Hi Guys, Is it still the case that when using uac_req_send, you cant send withing a specific dialog?I can modify call-id, but I presume tags may be more of a problem?See old post below from 2015; > I am familiar with uac_req_send. but how do I send it with in a > specific dialog and with data in the INFO req ? sending a new request inside a dialog is not possible with uac_req_send(). It is not easy over all because you change the sequence order (CSeq value). Practically, you need to track how many requests you sent from the middle to update (and restore in reply) when caller or callee sends a new request. dialog module can track changes in CSeq for requests sent to callee, being used now for authentication of INVITE to another provider, when Kamailio adds the credentials. But for more you would need to extend the dialog module. I just need to send a SIP info within an established dialog to stop some function up stream, so wondered if this is still a blocker? Many thanks Jon

7 years, 4 months

usrloc module expires column issues

by Grant Bagdasarian

Hello, When saving in the location table, the expires and last_modified columns contain the value 000-00-00 00:00:00 which causes issues when Kamailio is restarted and the preload modparam is set to load the location table from db in memory at startup. I've already upgraded Kamailio to 4.4.3, and used the dbtables script from version 4.4 to recreate the location table, but without success. Anyone else having this issue? Any resolution for it? Regards, Grant Bagdasarian CM

7 years, 5 months

Contacts replacing each other when registering

by Sebastian Damm

Hi, we are running a Registrar server with 4.4.3, the registrar module is configured with the following parameters: modparam("registrar", "max_contacts", 50) modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 0) modparam("registrar", "path_use_received", 1) modparam("registrar", "received_avp", "$(avp(i:801))") modparam("registrar", "default_expires", 600) modparam("registrar", "min_expires", 60) modparam("registrar", "max_expires", 600) modparam("registrar", "gruu_enabled", 0) A customer has configured 4 phones with the same username. Normally, all 4 phones would be visible in the location database, and incoming calls would fork out to all 4 phones. However, only one of the devices is always online, the others always replace each other on each registration. Client details: * All phones are snom 715 devices with the same firmware version. * All phones sit behind the same router. Registrations: client 1: * Via: SIP/2.0/UDP 192.168.208.91:35812;branch=z9hG4bK-4q0mmxgu6gm7;rport * Contact: <sip:1794388e3@192.168.208.91:35812;line=gicode6v>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 2: * Via: SIP/2.0/UDP 192.168.208.90:41331;branch=z9hG4bK-3cbxdvbmk0di;rport * Contact: <sip:1794388e3@192.168.208.90:41331;line=0j6veso8>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 3: * Via: SIP/2.0/UDP 192.168.208.92:5360;branch=z9hG4bK-4drsogakez94;rport * Contact: <sip:1794388e3@192.168.208.92:5360;line=0n7jfzih>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>" client 4: * Via: SIP/2.0/UDP 192.168.208.93:5260;branch=z9hG4bK-1ci0qia3yxyl;rport * Contact: <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;reg-id=1;q=1.0 Only client 4 is reachable all the time. The other 3 clients replace other registrations. So after client 1 registers, the contacts returned in the 200 OK looks like this: Contact: <sip:1794388e3@192.168.208.91:35812;line=gicode6v>;q=1;expires=600;received="sip:1.2.3.4:6411";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1, <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=303;received="sip:1.2.3.4:8923" And after client 2 registers, the contacts returned in the 200 OK looks like this: Contact: <sip:1794388e3@192.168.208.90:41331;line=0j6veso8>;q=1;expires=600;received="sip:1.2.3.4:49061";+sip.instance="<urn:uuid:0a14174a-77be-424c-864e-0004137F1C9D>";reg-id=1, <sip:1794388e3@192.168.208.93:5260;line=mh9sgxa1>;q=1;expires=301;received="sip:1.2.3.4:8923" So you see, one contact stays the same, the other one gets replaced. Does anybody know what could cause this kind of behavior? I think, it could be GRUU. I see that those three clients all send the same GRUU parameter. From my understanding, this UUID should be different from client to client. I don't know whether this is a bug in the snom firmware always sending the same GRUU UUID or whether som "intelligent" SIP aware router is putting this in the Contact header. However, since we have disabled gruu for the registrar module (see above), I think, Kamailio should ignore it. Ideas? Thanks in advance. Best Regards, Sebastian

7 years, 5 months

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