sr-users August 2019

sr-users@lists.kamailio.org

65 participants
96 discussions

by Maryam Baghdadi

hello, I need to know wildcarde_IMPU feature support in kamailio or not? I use kamailio as scscf and need to have support of wildcarded_impu in my scscf. is there any implementation of AVP_Wildcarded_IMPU in kamailio ? thanks

5 years, 3 months

Uac_replace for header's parameters

by Duarte Rocha

Greetings, I'm using uac_replace_to() and uac_replace_from() to do some number manipulations. It allows me to modify and automatically restore Display Number and URI. This works nicely, however it only allows to manipulate URI's parameter. Is there any method to the same and include the Header's parameters too? Best regards, Duarte Rocha

5 years, 3 months

Question regarding Dispatcher + ds_default_socket() modparam + Call-ID generation

by Joel Serrano

Hello, Simple doubt regarding dispatcher module when you have the ds_default_socket() modparam set: Say you have 2 kamailio boxes, active + passive, one shared IP via keepalived.... On the actrive node, you have dispatcher.send_ping to 1, and the passive has it set to 0. So far OK, only the active box is sending out probing OPTIONS requests, and it's using as outbound socket the virtual IP out of all the available ones (as defined with ds_default_socket() modparam) I have seen in a capture that the outbound OPTIONS look like: OPTIONS sip:190.14.203.219:5060 SIP/2.0 Via: SIP/2.0/UDP A.B.C.180 ;branch=z9hG4bK7abb.6fbaccc1000000000000000000000000.0 To: <sip:190.14.203.219:5060> From: <sip:dspinger@my.domain>;tag=e2bdd495733c59fd91487a137fccad4e-8a73 CSeq: 10 OPTIONS Call-ID: 2019f8491329c382-31419(a)A.B.C.181 Max-Forwards: 70 Content-Length: 0 A.B.C.180 -> VRRP A.B.C.181 -> Physical IP of the box My doubt is, shouldn't ds_default_socket also update the IP used to generate the Call-ID used in the OPTIONS request? Currently, I believe it's using the first defined listen= IP from config script as I switched the order the listen= are defined and I get the desired result: OPTIONS sip:186.188.220.174:5060 SIP/2.0 Via: SIP/2.0/UDP A.B.C.180 ;branch=z9hG4bKc97e.a8d9e1c2000000000000000000000000.0 To: <sip:186.188.220.174:5060> From: <sip:dspinger@my.domain>;tag=5e2e1773f812f6a7e4085c5d036e29d8-d323 CSeq: 10 OPTIONS Call-ID: 7d9a92c218fc1ba0-32111(a)A.B.C.180 Max-Forwards: 70 Content-Length: 0 Is this expected? Cheers, Joel.

5 years, 3 months

Kamailio/Freeswitch auth user and UserID

by Petarr Jones

Hi I am new to Kamailio and would like some guidance on linking up with Freeswitch. I have an exiting hosted Asterisk PBX that uses a combination of extension and pbx username (eg 1001-126252581276) and I want to move it over to Kamailio/Freeswitch without re-configuring the SIP phones. I have tried Freeswitch "number-alias" but it does not seem like a good fit due to things like BLF not working and the added overhead etc. Is there a way to configure Kamailio to authenticate a user based on the above username and then send an extension to Freeswitch as the UserID instead, thereby separating the Kamailio authentication from the Freeswitch UserID? As I don't yet have a full understanding of the Kamailio/Freeswitch interaction, I don't know whether this will cause other issues? Thanks in advance Petarr

5 years, 3 months

Re: [SR-Users] Dispatcher round-robin problems in 5.2

by JR Richardson

Hey Alex, After I recently upgraded, I had to include more response codes, 5.2 by default only 200 OK is accepted. I had some upstream carriers sending 405 and were taken off-line as a result until I added that code in modparm: modparam("dispatcher", "ds_ping_reply_codes", "class=2;code=405") Not sure if this applies to what you are doing, but my dispatcher round robin distribution acts as it did prior to upgrade to 5.2, pretty even, no anomalies with any nodes getting more calls than any other. JR JR Richardson Engineering for the Masses Chasing the Azeotrope Hi, I've got a proxy that does very basic round-robin distribution of calls to an elastic pool of servers, defined in a simple SQLite database with equal priorities. Nothing too complicated, just a vanilla `ds_select_domain("1", "4")`. The only complication is that seldom are most of the gateways enabled. Probing stuff was turned on, but didn't do quite what was desired, so it was replaced with a system that manages activation and deactivation of the gateways externally. Nevertheless, these are the left-over probing settings: modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_from", "sip:pinger@domain") modparam("dispatcher", "ds_ping_interval", 15) modparam("dispatcher", "ds_probing_threshold", 256) modparam("dispatcher", "ds_inactive_threshold", 1) modparam("dispatcher", "ds_probing_mode", 0) After an upgrade from 5.1 to 5.2.3 (009f62), the round-robin has become extremely "sticky" and tendentious. That is to say, it directs _almost_ all calls to a single gateway -- the first gateway in the table -- though not 100%. There is also a marked tendency to send lots of consecutive calls to the same gateway, even if it's not the first one, though most of the time it is. Has anyone experienced similar upon upgrading to 5.2? Thanks much! -- Alex

5 years, 3 months

Wrong Record-Route and Via header fields when TCP is used

by Leonid Fainshtein

Hi, Kamailio server has two legs that are connected to different networks. I'm using Kamailio v.5.2.3 and the "enable_double_rr" is implicitly set to "1". The leg "A" IP address is 10.159.65.1 The leg "B" IP address is 192.168.0.31 The call is initiated from 10.159.65.18 According to the "rr" module documentation, function record_route() should insert two "Record_Route" header fields when a request is accepted on one leg is should go out via the second leg. This works as expected in case of UDP protocol: INVITE sip:2000@192.168.6.106:5460;transport=UDP SIP/2.0 Record-Route: <sip:192.168.0.31;r2=on;lr;did=e2c.a191> Record-Route: <sip:10.159.65.1;r2=on;lr;did=e2c.a191> Via: SIP/2.0/UDP 192.168.0.31;branch=z9hG4bKcfa5.d64ecbd87d5315b5993c4ccf16f86537.0 Via: SIP/2.0/UDP 10.159.65.18:5060;rport=5060;branch=z9hG4bK3a9e9a4d But when the TCP protocol is used then the outbound message looks like this: INVITE sip:2005@192.168.0.178:35058;transport=tcp SIP/2.0 Record-Route: <sip:10.159.65.1;transport=tcp;lr;did=bb6.7dc1> Via: SIP/2.0/TCP 10.159.65.1;branch=z9hG4bKc85a.14afc3867dd3220826f9b9940f78168f.0;i=3 Via: SIP/2.0/TCP 10.159.65.18:5060;rport=58616;branch=z9hG4bK1469331f There are two problems there: a) only one Record-Route with leg is inserted b) the added "Via" header field contains the leg "A" IP address instead of expected leg "B" IP address (192.168.0.31). In the LAN trace I see that in reality the message was sent from leg "B". Is it a bug? Best regards, Leonid Fainshtein

5 years, 3 months

Kamailio v5.2.4 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v5.2.4 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.3. 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.4. For more details about version 5.2.4 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2019/08/kamailio-v5-2-4-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, 3 months

Planning the release of Kamailio v5.2.4

by Daniel-Constantin Mierla

Hello, I am considering to do soon a new release out of branch 5.2, respectively v5.2.4. I am aiming for August 12 or August 14, a matter of how backporting is finished, given that next week some devs travel to ClueCon. As usual, if you are aware of issues not reported yet on bug tracker or fixes not yet backported to branch 5.2, act during the next days to have enough time to approach them. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

5 years, 3 months

Strange behavior for unregister() function. Wrong docs? Bug?

by Joel Serrano

Hello, I'm playing around with the unregister() function from the registrar module: https://www.kamailio.org/docs/modules/devel/modules/registrar.html#registra… Docs say that that it can be used in REQUEST_ROUTE or FAILURE_ROUTE. I needed it in REPLY_ROUTE, and before reading the docs I tried it and got this error: Aug 12 15:52:44 csbc01 kamailio: CRITICAL: <core> [core/cfg.y:3526]: yyerror_at(): parse error in config file /etc/kamailio/csbc/reply_routes.cfg, line 27, column 71: Command cannot be used in the block#012 Aug 12 15:52:44 csbc01 kamailio[12737]: ERROR: bad config file (1 errors) But, I have this working on another setup, I compared, and my difference is that I'm running unregister() inside a route, and calling that route from reply_route, and that works (and by works, I mean it also does what it is supposed to do, which is unregister the AoR). So this doesn't work: ... onreply_route[MANAGE_REG_REPLY] { if(status=~"2[0-9][0-9]") { if(($sel(contact.expires)==0) || ($hdr(Expires)==0)){ if (unregister("location", "$sht(sipserver=>$fU::contact)")) { xlog("L_NOTICE", "[usrloc] removed user location\n"); } route(DEL_SIPSERVER); } ... But this works: ... onreply_route[MANAGE_REG_REPLY] { if(status=~"2[0-9][0-9]") { if(($sel(contact.expires)==0) || ($hdr(Expires)==0)){ route(UNREG_CUSTOMER); route(DEL_SIPSERVER); } ... ... route[UNREG_CUSTOMER] { if (unregister("location", "$sht(sipserver=>$fU::contact)")) { xlog("L_NOTICE", "[usrloc] removed user location\n"); } } ... So I'm in no-mans-land right now, docs say it's not allowed in REPLY_ROUTE, and if I try it it will fail, but if I try it inside a route, it woks (hack?). What is the correct approach here? Should unregister() be valid in reply_route (like other similar functions, for example: save()) and therefor docs should be updated and the error in the logs should also be updated, or if it's really not supported, shouldn't Kamailio not let me use it anywhere that a ends up being called from reply_route? I hope I have explained myself correctly. As always, please let me know if this should be a GH issue instead and I'll happily create it. Thanks, Joel.

5 years, 3 months

Dispatcher round-robin problems in 5.2

by Alex Balashov

Hi, I've got a proxy that does very basic round-robin distribution of calls to an elastic pool of servers, defined in a simple SQLite database with equal priorities. Nothing too complicated, just a vanilla `ds_select_domain("1", "4")`. The only complication is that seldom are most of the gateways enabled. Probing stuff was turned on, but didn't do quite what was desired, so it was replaced with a system that manages activation and deactivation of the gateways externally. Nevertheless, these are the left-over probing settings: modparam("dispatcher", "ds_ping_method", "OPTIONS") modparam("dispatcher", "ds_ping_from", "sip:pinger@domain") modparam("dispatcher", "ds_ping_interval", 15) modparam("dispatcher", "ds_probing_threshold", 256) modparam("dispatcher", "ds_inactive_threshold", 1) modparam("dispatcher", "ds_probing_mode", 0) After an upgrade from 5.1 to 5.2.3 (009f62), the round-robin has become extremely "sticky" and tendentious. That is to say, it directs _almost_ all calls to a single gateway -- the first gateway in the table -- though not 100%. There is also a marked tendency to send lots of consecutive calls to the same gateway, even if it's not the first one, though most of the time it is. Has anyone experienced similar upon upgrading to 5.2? Thanks much! -- 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/

5 years, 3 months

← 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 August 2019