sr-users February 2018

sr-users@lists.kamailio.org

90 participants
109 discussions

by Jan Gaida

Hello juha, Sorry for getting back on this old topic. Can you confirm that with Kamailio v4.3 your problem was solved? Regards, Jan

6 years, 2 months

Create ISUP Body

by Duarte Rocha

Hey Everyone I'm setting up a load testing scenario for my Kamailio. In order to do that i've created another Kamailio to answer "200 OK" to an Invite in order to simulate a call being answered. One of the scenarios I need to test is reading values from the ISUP IAM or ACM body. Here's the code on the Kamailio that replies with 200 : $var(acm) = "06 02 04 01 2c 01 fb 0c 08 83 10 19 7c 82 12 15 00 36 01 19 40 01 00 39 06 2c c0 36 c0 40 c0 00"; set_reply_body("$var(acm)","application/isup;base=itu-t92+;version=etsi356"); if( is_method("INVITE") && !has_totag() ) { · xnotice("First Invite"); send_reply("200","OK"); } However, when i use this and i do a pcap i get a "Message Type: Overload", which doesn't support optional parameters. What am i doing wrong ? Are there other methods to setup a simple ISUP part without hex ? Thanks in advance

6 years, 2 months

Kamailio mod ALIAS_DB: multiple aliases

by Stefan Rüetschli

Hello Kamailio-Users I'm using kamailio 5.1 with Alias_DB module. My subscribers register with a username like 0000001, 0000002 etc... Every user has a list of multiple aliases which they can use on their SIP-Trunk. I want to avoid that the user can use any alias for outgoing calls, only the aliases which are boud to his username in the aliases-db. So, if the user uses an alias which does not belong to him, i want to overwrite it to the first alias for his username in the aliases-db. At the moment, the function alias_db_find returns me the last alias found in the db. Is there any way to do it? Or is there a way to extend the dbaliases with a new column marking the "primary" alias for an account?|||| This would be the perfect solution. Regards Stefan

6 years, 2 months

Info: Kamailio World 2018 - Preview With 15 Sessions

by Daniel-Constantin Mierla

Hello, less than 3 months till the start of the 6th edition of Kamailio World Conference, time if flying fast! About one week ago we published the details for a group of accepted speakers, today we made a selection of sessions at the Kamailio World 2018. We had more proposals than we could accommodate, we are trying hard to fit in as many as possible, taking also in consideration the feedback from the participants at the past editions. For now you can head to the Schedule page and see the details of 15 sessions, from both workshops and conference days: https://www.kamailioworld.com/k06/schedule/ A very divers range of topics, from using Kamailio for emergency services (112/911), scaling with Redis backend, deploying in a containerized environment with Docker and Kubernetes, how to migrate the SIP routing logic to rich KEMI languages such as Lua, Python or Javascript, unit testing for Kamailio and test driven deployments, to blockchains in telephony, using Kamailio and FreeSwitch together, or latest updates from Asterisk PBX. The IMS/VoLTE workshop is going to show what you can do with latest Kamailio in mobile networks. And, of course, we have the very popular two sessions that never missed a Kamailio World edition: Dangerous Demos with James Body and VUC Visions with Randy Resnick. The details for other speakers and sessions will be published in the near future, stay tuned! Do not miss Kamailio World Conference 2018, it is going to be another great edition! You can register now at: https://www.kamailioworld.com/k06/registration/ Looking forward to meeting many of you at the next Kamailio World Conference, during May 14-16, 2018, in Berlin, Germany! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

6 years, 2 months

IMS: maybe a bug in S-CSCF: should we create an issue?

by Valentin Christoph

Hi all, We are using kamailio 5.1.0 as S-CSCF as follows: We have two machines and two kamailio instances, one on each machine, both working on the same database (together they build one highly available S-CSCF). After registering a user via the first kamailio instance, then the first instance is stopped (simulating an outage), and the HSS sends an RTR to the second instance. However, the second instance does not find the registered user in its cache and it does not access the database --> the deregistration fails. Configuration: kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "enable_debug_file", 0) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "matching_mode", 0) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "db_url", DB_URL) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "db_mode", 2) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "timer_interval", 10) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "timer_procs", 4) Does anyone immediately "see" a mis-configuration, or should we create an issue? Details in the mail below. Thanks, Christoph From: Friedrich Peter Sent: Friday, February 16, 2018 6:38 PM To: Valentin Christoph <Christoph.Valentin(a)kapsch.net> Cc: Onic Roman <Roman.Onic(a)kapsch.net>; Habashizadeh Mahmoud <Mahmoud.Habashizadeh(a)kapsch.net> Subject: AW: Kein RTR Message nachdem SCSCF-1 outage Hello, following scenario at REGISTER of catt subscriber: start with empty db and empty usrloc cache node1(.23): MariaDB [scscf]> select * from impu; Empty set (0.00 sec) [root@vict-ims ~]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net [root@vict-ims ~]# [root@vict-ims2 etc]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net [root@vict-ims2 etc]# After catt REGISTER: catt_subscriber visible in DB and usrloc cache of .23 but missing in usrloc cache of .24 MariaDB [scscf]> select * from impu; +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ | id | impu | barring | reg_state | ccf1 | ccf2 | ecf1 | ecf2 | ims_subscription_data | +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ | 196 | sip:catt178@vict-ims.net | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | | 197 | sip:+4350255872178@vict-ims.net | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | | 198 | tel:+4350255872178 | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ 3 rows in set (0.00 sec) MariaDB [scscf]> [root@vict-ims ~]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net { impu: sip:catt178@vict-ims.net state: registered barring: 0 ccf1: ccf2: ecf1: ecf2: subscription: { impi: catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> service profiles: { 1: { impus: { 1: sip:catt178@vict-ims.net 2: sip:+4350255872178@vict-ims.net 3: tel:+4350255872178 } } } } contacts: { sip:catt178@193.154.113.40:5060;transport=UDP;rinstance=317-catt178: { expires: 3542 client: n/a } } } [root@vict-ims ~]# [root@vict-ims2 etc]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net [root@vict-ims2 etc]# After kamctl stop + kamctl start of .24 catt_subscriber is visible in usrloc cache of (.24): preload_data loads data from db at module init [root@vict-ims2 ~]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net { impu: sip:catt178@vict-ims.net state: registered barring: 0 ccf1: ccf2: ecf1: ecf2: subscription: { impi: catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> service profiles: { 1: { impus: { 1: sip:catt178@vict-ims.net 2: sip:+4350255872178@vict-ims.net 3: tel:+4350255872178 } } } } contacts: { sip:catt178@193.154.113.40:5060;transport=UDP;rinstance=317-catt178: { expires: 2949 client: n/a } } } [root@vict-ims2 ~]# Now deregister catt_subscriber from HSS1: catt_subscriber disappears from db and usrloc cache of (.23) but persists on (.24) as registered in usrloc cache HSS >hss.deregister_subscriber catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> 0 [root@vict-ims ~]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net [root@vict-ims ~]# MariaDB [scscf]> select * from impu; Empty set (0.00 sec) MariaDB [scscf]> [root@vict-ims2 ~]# kamctl kamcmd ulscscf.showimpu sip:catt178@vict-ims.net { impu: sip:catt178@vict-ims.net state: registered barring: 0 ccf1: ccf2: ecf1: ecf2: subscription: { impi: catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> service profiles: { 1: { impus: { 1: sip:catt178@vict-ims.net 2: sip:+4350255872178@vict-ims.net 3: tel:+4350255872178 } } } } contacts: { sip:catt178@193.154.113.40:5060;transport=UDP;rinstance=317-catt178: { expires: 2571 client: n/a } } } [root@vict-ims2 ~]# Scenario of RTR from HSS after REGISTER of catt_subscriber at (.23) and outage of (.23): subscr. visible in db but not visible in usrloc cache of .24 HSS sends diameter RTR message to (.24) and deregister callback in (.24) searches in usrloc cache and does not find catt_subscriber and fails. MariaDB [scscf]> select * from impu; +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ | id | impu | barring | reg_state | ccf1 | ccf2 | ecf1 | ecf2 | ims_subscription_data | +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ | 196 | sip:catt178@vict-ims.net | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | | 197 | sip:+4350255872178@vict-ims.net | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | | 198 | tel:+4350255872178 | 0 | 1 | NULL | NULL | NULL | NULL | catt178(a)vict-ims.net<mailto:catt178@vict-ims.net> sip:catt178@vict-ims.net sip:+4350255872178@vict-ims.net tel:+4350255872178 | +-----+---------------------------------+---------+-----------+------+------+------+------+----------------------------------------------------------------------------------------------------------------------+ 3 rows in set (0.00 sec) Cfg file of (.24): kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "enable_debug_file", 0) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "matching_mode", 0) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "db_url", "cluster://cluster1") kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "db_url", DB_URL) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "db_mode", 2) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "timer_interval", 10) kamailio-scscf/kamailio-scscf-modules.cfg:modparam("ims_usrloc_scscf", "timer_procs", 4) lg P The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately.

6 years, 2 months

issue with running kamailio

by justin barnes

I am installing from githum kamailio 5.0 on my ubuntu-16.04-x86_64 VPS. when I start the kamailio server I get this error : /# /etc/init.d/kamailio start [....] Starting kamailio (via systemctl): kamailio.serviceJob for kamailio.service failed because the control process exited with error code. See "systemctl status kamailio.service" and "journalctl -xe" for details. failed! Ilooking up the status, I get this kamailio.service - Kamailio (OpenSER) - the Open Source SIP Server Loaded: loaded (/etc/systemd/system/kamailio.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2018-02-19 15:23:41 EST; 4h 10min ago Process: 18969 ExecStart=/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f $CFGFILE -m $SHM_MEMORY -M $PKG_MEMORY -u $USER -g $GR Feb 19 15:23:41 khynepassion systemd[1]: Starting Kamailio (OpenSER) - the Open Source SIP Server... Feb 19 15:23:41 khynepassion systemd[18969]: kamailio.service: Failed at step EXEC spawning /usr/sbin/kamailio: No such file or directory Feb 19 15:23:41 khynepassion systemd[1]: kamailio.service: Control process exited, code=exited status=203 Feb 19 15:23:41 khynepassion systemd[1]: Failed to start Kamailio (OpenSER) - the Open Source SIP Server. Feb 19 15:23:41 khynepassion systemd[1]: kamailio.service: Unit entered failed state. Feb 19 15:23:41 khynepassion systemd[1]: kamailio.service: Failed with result 'exit-code'.

6 years, 2 months

LCR options as of 2018

by Francisco Valentin Vinagrero

Hello, I am configuring a Kamailio node that will interface with 3 carriers and will implement Least Cost Routing for around 900 destinations. I have already implemented a quick prototype with the LCR module and I have been reading the CarrierRoute doc and the CGrates site. I don't really need advanced functionality, just: - Re-routing to a backup carrier when the main one is not available. - Ping with OPTIONS to all carriers so I can detect if any of them is not available (à la Dispatcher) - Translate prices from a central DB to routing priorities. - Get some accounting post-call info about the routing decision (acc module) So far, while testing the LCR module I have had some issues with the rule IDs being integers that auto-increment, so the LCR rules need to be referenced from the rule_target table using this numeric ID. I can see some issues when scaling this to 900 lcr_rules and 2700 lcr_rule_targets with 3 priorities. In addition to that, I think the OPTIONS mechanism is just used by the lcr module when a gateway is marked as defunct, but the gateways are not actively monitored in the normal status. Is this correct? I have been considering CarrierRoute, which has a slightly simpler table structure, but I can't find any other advantage for my use case. Regarding CGrates, it looks great but it looks like it exceeds my current needs. For those who have implemented LCR in your kamailios, am I missing something regarding performance, scalability, etc? Are there any newer modules that can implement this, or maybe just a dispatcher-on-steroids setup will do the trick? Cheers, Francisco.

6 years, 2 months

User state

by Magnus Löfqvist

Hi, We are running for a customer a kamailio server for user registration and routing of calls. Also using Asterisk for queue management and IVR. Now we are in the progress of writing a web portal where the customers users should be able to see if there collueges are busy in phone or availible. In asterisk I would use hints and listing in events in AMI. But what way are the best in Kamailio? Best Regards Magnus Sent from Nine<http://www.9folders.com/>

6 years, 2 months

PR1447: first attempt at app_python3

by Anthony Alba

Hi Daniel and kamailio contributors, I have submitted a PR for app_python3 here: https://github.com/kamailio/kamailio/pull/1447. It is very rough, but would appreciate your feedback. Notes: 1. Almost a verbatim port of app_python; just changing obvious semantics. String->Unicode is practically the only large change. No change to symbol names and export functions so the two modules cannot coexist. (Don't loadmodule "app_python.so" and loadmodule "app_python3.so) 2. Module initialization semantics in Py3 have changed: add the top level modules to the inittab before calling Py_Initialize(). I have done this for KSR and Router. I.e. PyImport_AppendInittab() is called for Router and KSR *before* Py_Initialize() 3. Makefile looks for a python3 binary (PYTHON3 in the Makefile) to get include paths and link libraries. Here is an example compile line for IUS Python 3.6 on CentOS 7 (no native Python3 from RHEL) ## default: needs to find python3 and python3-config ## needs to find both python3.6 and python3.6-config make -C src/ PYTHON3=python3.6 SKIP_MODULES="${SKIP_MODULES}" quiet=verbose module_group_py="app_python3" group_include=py every-module 4. The semantics for GIL and thread management are too different for one-to-one replacements. I have therefore decided to comment out all threading calls. Fortunately, kamailio does not used threads at the moment. This is more complicated than it seems: even with Py2+thread management: there would be deadlocks if kamailio->python2 script->Cython extension with threads(e.g. grpcio). For an MVP it would be best to get it in without thread management. 5. It should backport to 5.1. 6. Tested locally, with a routing scripting making many python_exec() calls Thank you. Anthony Alba

6 years, 2 months

PUBLISH and ETag

by Cyrille Demaret

Hi, I'm using Kamailio with presence enabled and Asterisk PJSIP and outbound-publish. My problem is happening when I place 2 consecutive calls from Asterisk : When I make a first call Asterisk sent the following: PUBLISH sip:201@192.168.100.37 SIP/2.0 Via: SIP/2.0/UDP 192.168.100.37:5080;rport;branch=z9hG4bKPj4f9c19eb-26d8-4bb1-8f00-e69723a610 82 From: sip:201@mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf To: sip:201@mydomain.com Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183 CSeq: 10697 PUBLISH Event: dialog Expires: 180 Max-Forwards: 70 User-Agent: Asterisk PBX 14.6.0 Content-Type: application/dialog-info+xml Content-Length: 247 <?xml version="1.0" encoding="UTF-8"?> early.. Kamailio replies : SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.100.37:5080;rport=5080;branch=z9hG4bKPj4f9c19eb-26d8-4bb1-8f00-e6972 3a61082;received=192.168.100.37 From: sip:201@mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf To: sip:201@mydomain.com;tag=b596189c6de9c38f624fd84638f43be6-ff39 Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183 CSeq: 10697 PUBLISH Expires: 180 SIP-ETag: a.1518775074.19863.16.0 Server: kamailio (5.0.5 (x86_64/linux)) Content-Length: 0 When the call is done, Asterisk sent another PUBLISH telling that the call if terminated : PUBLISH sip:201@192.168.100.37 SIP/2.0 Via: SIP/2.0/UDP 192.168.100.37:5080;rport;branch=z9hG4bKPja93efb01-a518-445e-9e9b-f6f97ab8c7 52 From: sip:201@mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce To: sip:201@mydomain.com Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183 CSeq: 10698 PUBLISH Event: dialog SIP-If-Match: a.1518775074.19863.16.0 Expires: 180 Max-Forwards: 70 User-Agent: Asterisk PBX 14.6.0 Content-Type: application/dialog-info+xml Content-Length: 230 <?xml version="1.0" encoding="UTF-8"?> terminated.. And Kamailio replies : SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.100.37:5080;rport=5080;branch=z9hG4bKPja93efb01-a518-445e-9e9b-f6f97 ab8c752;received=192.168.100.37 From: sip:201@mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce To: sip:201@mydomain.com;tag=b596189c6de9c38f624fd84638f43be6-48b4 Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183 CSeq: 10698 PUBLISH Expires: 180 SIP-ETag: a.1518775074.19873.18.1 Server: kamailio (5.0.5 (x86_64/linux)) Content-Length: 0 Here, the SIP ETag is a.1518775074.19873.18.1. The problem is if I make a new call before the expiration of the previous SUBSCRIBE, Asterisk reuse this SIP ETag according to the RFC : PUBLISH sip:201@192.168.100.37 SIP/2.0 Via: SIP/2.0/UDP 192.168.100.37:5080;rport;branch=z9hG4bKPj9d13bb82-31d9-48db-9672-bd4b6b4f22 f0 From: sip:201@mydomain.com;tag=33e6b028-0444-4b3a-8bc2-4a987a291528 To: sip:201@mydomain.com Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183 CSeq: 10699 PUBLISH Event: dialog SIP-If-Match: a.1518775074.19873.18.1 Expires: 180 Max-Forwards: 70 User-Agent: Asterisk PBX 14.6.0 Content-Type: application/dialog-info+xml Content-Length: 247 <?xml version="1.0" encoding="UTF-8"?> early. Kamailio refuse it with this error : "Trying to update an already terminated state. Skipping update." because the call is considered as terminated. The RFC is stating : When updating previously published event state, PUBLISH requests MUST contain a single SIP-If-Match header field identifying the specific event state that the request is refreshing, modifying or removing. This header field MUST contain a single entity-tag that was returned by the ESC in the SIP-ETag header field of the response to a previous publication. Why Kamailio is acting like that? Best regards, Cyrille

6 years, 2 months

← Newer
1
2
3
4
5
6
7
8
9
10
11
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 February 2018