sr-users May 2019

sr-users@lists.kamailio.org

84 participants
97 discussions

warning logs - DB_Redis and usrloc in mode 3

by José Seabra

Hello there, I'm testing the db_redis with usrloc module in mode 3 and i have been noticing that every time that kamailio checks if there is contacts expired then it logs the following warning messages: *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1099]: db_redis_perform_query(): performing full table scan on table 'location' while performing query* *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1102]: db_redis_perform_query(): scan key 0 is 'expires'* *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1102]: db_redis_perform_query(): scan key 1 is 'expires'* *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1274]: db_redis_perform_delete(): performing full table scan on table 'location' while performing delete* *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1277]: db_redis_perform_delete(): scan key 0 is 'expires'* *WARNING: PR_LOG: 5a14aea50d9d9b17-75(a)172.31.1.11 <5a14aea50d9d9b17-75(a)172.31.1.11>: db_redis [redis_dbase.c:1277]: db_redis_perform_delete(): scan key 1 is 'expires'* I'm not sure what is the rational behind of this, but having these logs being written when we have log level equal 2 in production is something unnecessary, so i'm asking if it shouldn't be better we have it as debug instead of warning? or do you forecast any performance issues using usrloc module in mode 3 with db_redis? Thank you for your support Cheers José -- Cumprimentos José Seabra

5 years, 1 month

Re: [SR-Users] Modern SIP Trunking, Route on To: or INVITE Headers?

by JR Richardson

Benoit, Alex, I appreciate the feedback, confirming my assumptions. Good news is the Vendor finally responded positively and agreed to add in configuration option to route on INVITE R-URI in next SDK release, expected later this year. In the meantime I added 'uac_replace_to' function to my proxy to re-write To: header with R-URI, so far so good. Thanks. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope > > The To header is a cosmetic, purely logical commentary on the intended ultimate destination of the call, and no routing should ever be done on it. The RURI of the INVITE is the appropriate vehicle for that. > > When dealing with proxies, however, one will encounter from time to time the grim reality that there are user agents which expect the To URI and the INVITE RURI to be in alignment. For that scenario, you can use ‘uac’ module’s stateful rewriting functionally (uac_replace_to()) to modify To with Kamailio in a way that displays fidelity and esteem for protocol formalities. > > — > Sent from mobile, with due apologies for brevity and errors. > > > On May 21, 2019, at 9:32 AM, JR Richardson <jmr.richardson(a)gmail.com> wrote: > > > > Hey Folks, > > > > I could use some feedback to see if my mind is right on this topic.I'm > > in a discussion with a software Vendor (respectfully unnamed) with > > terminal software routing on To: header info. It's my contention any > > modern SIP software should use INVITE header to retrieve DID info and > > route from there. > > > > My reasoning is due to the To: header should contain the original > > intended DID, Extension, Name, AoR or whatever else the original SIP > > transaction wanted to contact, but being in a multi-carrier, > > multi-hop, call forwarding environment, the INVITE header contains the > > hop-to-hop true intention of where the call should route at any given > > transaction. So in the case of terminal software the To: header could > > likely be irrelevant where as the INVITE header is accurate. > > > > My most recent response from the Vendor suggest I put a SIP Proxy in > > front of the terminal software and transform the To: header to > > whatever I need for this application. Although I can do this, I'm > > concerned with breaking RFC for CANCEL and BYE transaction sent back > > from the terminal software that may not be recognized by upstream > > origination carriers. > > > > Plus modifying To: header is widely frowned upon by most folks. > > > > Thanks. > > > > JR

5 years, 1 month

Kamailio v5.2.3 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v5.2.3 stable release is out. This is a maintenance release of the latest stable branch, 5.2, that includes fixes since the release of v5.2.2. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.2.x. Deployments running previous v5.2.x versions are strongly recommended to be upgraded to v5.2.3. For more details about version 5.2.3 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2019/05/kamailio-v5-2-3-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

5 years, 1 month

Kamailio IMS installation from pacakges

by Mohit Chawla

Hi, My name is Mohit Chawla working on LTE Network integration with Kamailio IMS server. We are facing issues in installation & Configuring of kamailio IMS on CentOS 7 due to no documentation is available on web (or at least I am not able to find one). Primarily I am interested in installing packages (not building from source code as of now) and use it for further testing. I can go with building the package from source if its more easier and quick. Can you guys help me share any document/wiki which is helpful for my cause ? I will be really grateful if someone can reply me by today. Thanks and Regards, Mohit -- _Disclaimer: This email and any files transmitted along with it may contain Azcom confidential and proprietary information. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action based on the contents of the information contained herein is strictly prohibited. If you are not an intended recipient of this transmission and you received it in error, please inform the sender by reply e-mail and destroy this and all other copies of this transmission to which you have access. The sender of this email or Azcom does not accept liability for any errors or omissions in the contents of this message that may occur as a result._

5 years, 1 month

Releasing Kamailio v5.2.3

by Daniel-Constantin Mierla

Hello, I am considering to release Kamailo v5.2.3 out of latest git branch 5.2 next week, likely on Wednesday, May 22. As usual, if you are aware of issues not reported to the github bug tracker, fill a report there as soon as possible to give a chance to be analyzed and fixed. Also, if there was a fix for an issue that you were reporting, check to see if it was backported to be sure it is not forgotten. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

5 years, 1 month

remove_hf inside of onreply_route

by Володимир Іванець

Hello! I was wondering if someone is using remove_hf in onreply_route and if yes on which Kamailio version? I'm using Kamailio v5.2.1 and as soon as I add remove_hf function to onreply_route Kamailio will fail to start with following error messages: ERROR: <core> [core/mem/q_malloc.c:291]: qm_find_free(): qm_find_free(0x7fc1dc044010, 27120); Free fragment not found! ERROR: <core> [core/mem/q_malloc.c:425]: qm_malloc(): qm_malloc(0x7fc1dc044010, 27120) called from core: core/io_wait.c: init_io_wait(524), module: core; Free fragment not found! Thank you for any suggestions!

5 years, 1 month

Modern SIP Trunking, Route on To: or INVITE Headers?

by JR Richardson

Hey Folks, I could use some feedback to see if my mind is right on this topic.I'm in a discussion with a software Vendor (respectfully unnamed) with terminal software routing on To: header info. It's my contention any modern SIP software should use INVITE header to retrieve DID info and route from there. My reasoning is due to the To: header should contain the original intended DID, Extension, Name, AoR or whatever else the original SIP transaction wanted to contact, but being in a multi-carrier, multi-hop, call forwarding environment, the INVITE header contains the hop-to-hop true intention of where the call should route at any given transaction. So in the case of terminal software the To: header could likely be irrelevant where as the INVITE header is accurate. My most recent response from the Vendor suggest I put a SIP Proxy in front of the terminal software and transform the To: header to whatever I need for this application. Although I can do this, I'm concerned with breaking RFC for CANCEL and BYE transaction sent back from the terminal software that may not be recognized by upstream origination carriers. Plus modifying To: header is widely frowned upon by most folks. Thanks. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope

5 years, 1 month

$snd(proto) mapping?

by Andrew Chen

Hey guys, Is there a numeric mapping for $snd(proto)? Thanks -- Andy Chen Sr. Telephony Lead Engineer achen@ <achen(a)thinkingphones.com>fuze.com -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

5 years, 1 month

How to get started (configuring an interconnection)

by Benoit Panizzon

Dear Kamailio Users I might need a bit help with starting. We are a TSP and at the moment we use a commercial carrier grade voice switch, which is very VERY inflexible and where bugs we find either don't get fixed, or only with a large delay. As everywhere else we embrace opensource and enjoy the possibility to quickly fix bugs ourselves (we have a software development department) we are evaluating Kamailio. Basically, if we have a centralized SIP routing engine, which can record CDRS for Billing and do some Number Translations (lookup on external service or database) for (location based emergency numbers, call forwarding services, ported numbers, call spam blacklisting) we could do way more than our actual $$$ carrier switch is capable of. Kamailio sounds like perfect for this task. First step: Get a machine up and running with Kamailio and Siremis, done, that was easy. Next: Connect his SIP wise via what I would call a 'SIP carrier interconnecton', ip based authenticated trunk between our carrier switch and Kamailio so we can route some number ranges from our carrier switch to Kamailio and then continue to test with subscribers, subscriber trunks and all else we need on Kamailio. I'm quite fluent in Asterisk (our Voicemail and Announcement Services are based on Asterisk) and SIP and have come across many different PBX, but after reading parts of the documentation, and trying myself to understand how Kamailio talks to other SIP endpoints I am a bit at a loss. I would have expected that I would configure our carrier switch as 'remote SIP gateway' or whatever it would be called. But I start fearing, Kamilio works completely differently. So I might need a bit of pointing the right direction to get started. I did try with the 'CarrierRoute Management' or 'Dispatcher' functions, but I only find very little documentation on this. So how do I get started? How do I, for starters, tell Kamailio what the Hostname or IP of my Carrier switch is and how do I set a 'default' call route to this? Kind regards -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

5 years, 1 month

Storing an integer value into AVP from REDIS string

by Stephen Bucklin

Hi, Any quick thoughts. I am using a REDIS "GET" to retrieve a JSON obj as a string from REDIS and then the JANSSON get value to extract a key value from the string and pop it into an AVP ($avp(val)) and wish to ensure the value is an integer in the AVP. New to this, be kind :-) Steve

5 years, 1 month

← Newer
1
2
3
4
5
6
7
8
9
10
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 May 2019