sr-users

sr-users@lists.kamailio.org

42 participants
37518 discussions

Planning the next major release - v5.3.0
by Daniel-Constantin Mierla 04 Sep '19

04 Sep '19

Hello, it's about the time to set the milestones to the next major release - v5.3.0. There are 6 new modules and many other enhancements to existing components in git master branch, also during the last irc devel meeting it was proposed to freeze after summer holidays. At this moment I would propose Wednesday, September 4, 2019 to freeze the development. Then the release should be about one month later, after testing interval. In case there are people willing a bit more time for development, we can freeze one week later, September 11, or another date -- your suggestions here. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

3 5

Using Kamailio IMS for making a call
by supreeth herle 04 Sep '19

04 Sep '19

Hello Everyone, I have successfully setup a VM in OpenStack with Kamailio IMS, rtpengine and FoHSS using the instructions mentioned in the guide which i wrote (attached to this mail), all running in the machine. I am using the existing alice and bob IMPUs created in FoHSS. But, when I try to call each other the call doesnt go through and I observe in the wireshark traces that S-CSCF is replying to I-CSCF that "403, Forbidden - Domain not served". Can somebody please tell me do I need any additional components to make a call or am i missing some configuration? It would be great if someone can help me troubleshooting this issue. I have attached the pcap file for your reference. Many thanks in advance. Regards, Supreeth

1 0

Kamailio stops processing requests over UDP
by Juha Heinanen 04 Sep '19

04 Sep '19

I'm returning to an old issue, where Kamailio stops processing incoming requests. Now it turned out that only requests over UDP are not processed. Requests over TCP work fine. Debug log doesn't show anything about the requests over UDP, but wireshark sees them coming. core.ps shows that main process - attendant and all udp receiver processes are alive. Any ideas what could cause Kamailio (5.2 version) to stop processing requests over UDP? What additional info should I try to get? -- Juha

4 21

Hello Group - I have a "challenge"
by Kevin Greene 04 Sep '19

04 Sep '19

I recently did the upgrade from v4.4 to 5.2 (via Yum). When starting Kamailio, I get these three errors. Not sure if they are related or not but I do not think so. Have spent a lot of time searching on Google for the answer and have not found the solution. [root@ids kamailio]# kamctl restart INFO: Stopping Kamailio : INFO: stopped INFO: Starting Kamailio : INFO: started (pid: 44608) [root@ids kamailio]# tail -f /var/log/sipserver.log Sep 4 00:39:06 ids /usr/sbin/kamailio[44608]: ERROR: <core> [core/pvapi.c:1119]: pv_parse_spec2(): wrong char [t/116] in [$mt] at [2 (0)] Sep 4 00:39:06 ids /usr/sbin/kamailio[44608]: ERROR: <core> [core/dprint.c:451]: log_prefix_init(): wrong format[{$mt $hdr(CSeq) $ci} ] Sep 4 00:39:06 ids /usr/sbin/kamailio[44626]: ERROR: <core> [core/receive.c:319]: receive_msg(): no request_route {...} and no other config routing engine registered The last error is repeated many times (each time a remote user tries to connect I think). I can send any additional files if needed. Thanks. I am burning out on this upgrade. Kevin

2 1

Unexpected BYEs from dialog module
by Alex Balashov 03 Sep '19

03 Sep '19

Hi, I am running 4.3.5:1b0c0a, which I am aware is an EOL'd release train, and have a problem with the dialog module I am baffled by. On many calls - I can't find any correlation to particular kinds of endpoints - I see spoofed BYEs come out of Kamailio after a minute and a half, as if the call had hit a dialog timeout or the dialog module's dead peer detection (OPTIONS pinging) kicked it out. The thing is, neither of those explanations seem to be borne out by the parameters of the calls under investigation. The dialog timeout on these calls is set to 7200, and the dialog keepalives aren't enabled in either direction. If they were, it'd be logged. Calls that are terminated in this manner also see the following log message: WARNING: dialog [dlg_req_within.c:214]: bye_reply_cb(): inconsitent dlg timer data on dlg 0x7f9997317e48 [3390:9644] with clid '1996679936_133218050(a)x.x.x.x' and tags '2bb17663-co4006-INS001' 'as7925780d' But I don't think this is unusual for a dialog-spoofed BYE; presumably this is due to a 200 OK for the BYE from both ends. So anyway, I am trying to track down anything else that could inadvertently cause dialog to hang up calls relatively quickly in that release, or inadvertently set the dialog timeout parameter to something lower than is apparent from the logging and the config. If anyone has any pointers, that would not go unappreciated! Many thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 6

crash/mem leaks on low memory
by Gaurav Bmotra 03 Sep '19

03 Sep '19

hi i m using kamailio 5.1 on Ubuntu 18.04 i m geting this error in logs and it stop registration form soft-phone plz help me -------------------------------------------------------------------------------------------------------- WARNING: tls [tls_init.c:778]: init_tls_h(): openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory th -------------------------------------------------------------------------------------------------------- kamailio.service - LSB: Start the Kamailio SIP proxy server Loaded: loaded (/etc/init.d/kamailio; generated) Active: active (exited) since Tue 2019-09-03 12:09:19 UTC; 26min ago Docs: man:systemd-sysv-generator(8) Process: 27237 ExecStart=/etc/init.d/kamailio start (code=exited, status=0/SUCCESS) Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: INFO: <core> [core/cfg/cfg_ctx.c:595]: cfg_set_now(): tls.low_mem_threshold2 has been changed to 7077888 Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: INFO: <core> [main.c:2636]: main(): processes (at least): 27 - shm size: 536870912 - pkg size: 8388608 Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: ERROR: dispatcher [dispatcher.c:813]: ds_warn_fixup(): failover functions used, but required AVP parameters are NULL -- feature disabled Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: ERROR: <core> [core/tcp_main.c:2850]: tcp_init(): bind(c, 0x7f0b41b001f4, 16) on 172.31.35.49:5091 : Address already in use Sep 03 12:09:18 talk /usr/local/sbin/kamailio[27270]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized -- thank you *Regards:* Gaurav Kumar

3 3

evapi mismatch version
by bill＠novatrope.us 02 Sep '19

02 Sep '19

Hi All Installed Kam 5.2.4, but now getting version mismatch on evapi. ERROR: <core> [core/sr_module.c:348]: version_control(): module version mismatch for /usr/lib64/kamailio/modules/evapi.so; core: kamailio 5.2.4 (x86_64/linux); module: kamailio 5.1.6 (x86_64/linux) Anybody know how to get the correct evapi version. I am running centos 7 Bill

3 2

Issue with uac_replace
by David Costa 01 Sep '19

01 Sep '19

Greetings, I have a Kamailio proxy with uac_replace for To and From Headers. So far everything has worked correctly. However, I now have a client who encodes my Calling Number too and I'm getting some issues in the restore mechanics. I have the restore setup as "auto" and it's info is stored in "vsf" and "vst" parameters of Record-Route. On replies sent by my client I have the following Record-Route and From Header (Note : My Kamailio has two IPs which makes it insert two RR headers ): Record-Route: <sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_ o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2> Record-Route: <sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_ o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2> From: "+351411110097" <sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4 In this case the restore is done correctly When the client sends me a BYE request I have the following Route Header and To Header Route : <sip:xxx.xxx.xxx.xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_ o=128_11_Y;vsf=AAAAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMH DQgJDQECA3RyAwMcHwIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2>,<sip:xxx.xxx.xxx. xxx;r2=on;lr;ftag=99A730303736313103579CC4;tbk_i=1_2_Y;tbk_o=128_11_Y;vsf=AA AAABgGBAMDAAUBBQAJDndyAwMcHwIdHQsWHwUDNw--;vst=AAAAABgGBAMHDQgJDQECA3RyAwMcH wIdGgQeHAIFAnVzZXI9cGhvbmU-;did=f74.78e2> To : "+351411110097" <sip:I2116446I_500@xxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4 In this scenario, the To after restore is : To :"+351411110097" <sip:Q4525417L_<>Gxxx.xxx.xxx.xxx>;tag=99A730303736313103579CC4, which throws an internal error on Kamailio about bad URI and also makes our MediaGateway reply with a "Bad Request". Can this error be caused by the restore of the uac_replace mechanics? Both Record Route URIs are on different headers while the both Route URIs are on the same Route header. Can this be the reason? If you need more information please let me know. Best Regards David Costa

2 1

Re: [SR-Users] controlling presence with new module `pua_json`
by Henning Westerholt 30 Aug '19

30 Aug '19

Hello Bill, (please keep the list in CC) yes, this seems to be the case. Just looked briefly to the code, it does an assignment in some cases. E.g. if no Presentity* data is given it will just use the From* information. And then it should later output an error from pua_json_update_presentity(..) if there is not the necessary data. Do you see any error message like this? Another idea - does it works if you add more "missing" data in the curl requests? Cheers, Henning Am 28.08.19 um 21:16 schrieb bill(a)novatrope.us: > Henning: Good point. > > I do see a number of errors in the log. It looks like the json routine > is looking for data that is not in the http query as specified by the > author. > > > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Event-Name: [update] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Event-Package: [dialog] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [Presentity] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Presentity: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [Presentity-User] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Presentity-User: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [Presentity-Realm] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Presentity-Realm: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): From: > [sip:1020101@<IP of phone>] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > From-User: [1020101] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > From-Realm: [<IP of phone>] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [From-URI] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > From-URI: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To: > [sip:1020108@<IP of server>:50060] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > To-User: [1020108] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [To-URI] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To-URI: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Call-ID: [1020101@<IP of phone>] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [From-Tag] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > From-Tag: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [To-Tag] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): To-Tag: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): Json-c > error - failed to extract field [Direction] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): > Direction: [] > 17(125579) DEBUG: json [json_mod.c:70]: _json_extract_field(): State: > [Confirmed] > 17(125579) DEBUG: presence [event_list.c:348]: search_event(): start > event= [dialog/5] > > On 8/28/19 12:00 PM, Henning Westerholt wrote: >> Hello Bill, >> >> just giving some generic debug pointers here: >> >> - do you see any errors in the kamailio log file? >> >> - do you see any SIP traffic (e.g. by observing with ngrep, wireshark >> etc..) to the phone after your curl command? >> >> Cheers, >> >> Henning >> >> Am 28.08.19 um 19:04 schrieb bill(a)novatrope.us: >>> Hi all: >>> >>> I am trying to use the procedure for setting BLF lights described in >>> https://blog.voipxswitch.com/2018/02/22/kamailio-controlling-presence-with-… >>> >>> >>> WIthout success. >>> >>> My configuration is 1 Grandstream GXP2130 phone behind a NAT on a >>> public IP. (IPP in example below) >>> >>> Kamailio is running on public IP (IPK in example) listening on port >>> 50060 >>> >>> The command I am sending: >>> >>> curl -d >>> '{"Call-ID":"1020101@<IPP>","Event-Category":"presence","Event-Name":"update","Event-Package":"dialog","Expires":"3600","To":"sip:1020108@<IPK>:50060","To-User":"1020108","To-Realm":"<IPK>:50060","From":"sip:1020101@<IPP>","From-User":"1020101","From-Realm":"<IPP>","State":"Confirmed"}' >>> >>> http://localhost:8080/presence/ >>> {"Call-ID":"1020101@<IPP>","Event-Category":"presence","Event-Name":"update","Event-Package":"dialog","Expires":"3600","To":"sip:1020108@<IPK>:50060","To-User":"1020108","To-Realm":"<IPK>:50060","From":"sip:1020101@<IPP>","From-User":"1020101","From-Realm":"<IPP>","State":"Confirmed"} >>> >>> >>> >>> >>> Kamailio appears to be processing the command OK, so I think I am just >>> not setting it up properly> >>> >>> Anybody having any luck with this procedure, let me know how you are >>> getting it to work. >>> >>> >>> Bill >>> >>> >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services

2 1

Info: Upgrading kamcli to work with Python3
by Daniel-Constantin Mierla 30 Aug '19

30 Aug '19

Hello, with the perspective that Python2 is going to be removed from the major Linux distributes starting with the beginning of next year, the work to upgrade kamcli to run with Python3 has been started. >From now on, master branch of kamcli is expected to work only with Python3: * https://github.com/kamailio/kamcli There is still work to be done to upgrade all the code, but any use of it should be done with Python3 and eventual issues to be filed on bug tracker. Of course, pull requests are welcome as always! Who wants to use the version for Python2 has to use the code from git branch v1.2-python2. That branch is probably not going to receive any new feature, it will be kept for use with older systems (as well as a running option during the upgrade period to Python3). Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

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