sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Fwd: Weird issue with kamailio relaying messages to itself
by George Diamantopoulos 26 Aug '17

26 Aug '17

Stupid gmail replying to sender only... ---------- Forwarded message ---------- From: George Diamantopoulos <georgediam(a)gmail.com> Date: 27 August 2017 at 02:29 Subject: Re: [SR-Users] Weird issue with kamailio relaying messages to itself To: Daniel-Constantin Mierla <miconda(a)gmail.com> Hello all, I've figured out what was going on, so I'm sharing here in case anyone else runs into this. I guess it should be a fairly common situation under certain circumstances when using the dispatcher module... The problem was that no destinations in the dispatcher set used were available for these requests. So $du was not set by ds_select_next. Which meant that when t_relay() was called later in the script, it would route based on R-URI, and the RURI's uri was kamailio itself. As to the reason why I was left with no dispatcher destinations available, well, I would mark destinations offline for 500 "server error" responses coming from them, and asterisk (which is the receiving application for all of dispatcher's destination sets) will send out a 500 to the B-leg when it receives a 480 to an A-leg. Getting a single 480 to one of the asterisk boxes would cause this to happen across all destinations, as kamailio would retry the next destination after a 500 failure and would receive a 500 from all of them in the end (because all of them would get the 480 in such small time frame). BR, George On 31 July 2017 at 21:52, George Diamantopoulos <georgediam(a)gmail.com> wrote: > Hello Daniel, > > Thanks for the reply. That is correct, looping was not my intention, I'm > trying to figure out what's causing it... > > BR, > George > > On 31 July 2017 at 17:29, Daniel-Constantin Mierla <miconda(a)gmail.com> > wrote: > >> Hello, >> >> usually you should not loop requests locally, unless a very special case >> -- do you do the loop routing because of a need or just happens but you >> don't know why? >> >> Cheers, >> Daniel >> >> On 31.07.17 13:46, George Diamantopoulos wrote: >> >> Hello all, >> >> I have been toying with kamailio lately, and I thought I had gotten to >> the point where I had a mostly working (tm) prototype. I gave it a test >> drive with some real calls, however, and an issue manifested at least once, >> where homer received packets originating from the kamailio host, and whose >> destination was also the kamailio host. >> >> The dialog this manifested in is a generally problematic one, with many >> retransmissions occurring because of slow database access (I haven't >> implemented htable caching yet). No packet capture over the network is >> actually taking place, I'm copying everything to homer with "trace_mode"set >> to 1. >> >> Homer shows these messages like in the screenshot: >> https://imagebin.ca/v/3VGJAmovRBmo. Here's an example of a packet: >> >> >> 2017-07-28 14:32:29 +0300 : 2.3.4.5:5060 -> 2.3.4.5:5060 >> INVITE sip:1234567890@kamailio-server.org SIP/2.0 >> Record-Route: <sip:2.3.4.5;lr;ftag=as491cec82> >> Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bK0cf.0779 >> 9e3eb71f33a9ef91178ac760ebd2.0 >> Via: SIP/2.0/UDP 2.3.4.5;branch=z9hG4bKsr-BnCVy >> rWoUladI14pU7Pry-Pzy-ONy-VSQ74NU7HzeYazq2nFU2Oc5FIWiGIKq-HXe >> x1oONpam-C6IrIXkr4FQxZRh7sM >> Max-Forwards: 69 >> From: <sip:subscriber@5.4.3.2:5061>;tag=as491cec82 >> To: <sip:1234567890@kamailio-server.org> >> Contact: <sip:2.3.4.5;line=sr-eNC05xhKefQnON1EglFrOkF0OfpzV2s9UzM9UXM >> NQXMn5-B0Q-s*> >> Call-ID: 4e5d22c3369704b97d866c8d0f3798f8@192.168.201.2:5061 >> CSeq: 103 INVITE >> User-Agent: Asterisk PBX 11.13.1~dfsg-2~bpo70+1 >> Date: Fri, 28 Jul 2017 11:32:24 GMT >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, >> PUBLISH, MESSAGE >> Supported: replaces, timer >> Remote-Party-ID: "9876543210" <sip:9876543210@192.168.201.2> >> ;party=calling;privacy=off;screen=yes >> Content-Type: application/sdp >> Content-Length: 500 >> >> v=0 >> o=root 242468242 242468243 IN IP4 172.17.130.13 >> s=Asterisk PBX 11.13.1~dfsg-2~bpo70+1 >> c=IN IP4 172.17.130.13 >> t=0 0 >> m=audio 59426 RTP/AVP 18 101 >> a=rtpmap:18 G729/8000 >> a=fmtp:18 annexb=no >> a=rtpmap:101 telephone-event/8000 >> a=fmtp:101 0-16 >> a=ptime:50 >> a=sendrecv >> a=rtcp:59427 >> a=ice-ufrag:hffIoy6x >> a=ice-pwd:nXB8ip7Qz8ZG5yyZRr97kGJbej >> a=candidate:igct4zWHEzhGCjWc 1 UDP 2130706431 <21%203070%206431> >> 172.17.130.13 59426 typ host >> a=candidate:igct4zWHEzhGCjWc 2 UDP 2130706430 <21%203070%206430> >> 172.17.130.13 59427 typ host >> >> Can something like this be triggered by misconfiguration in the routing >> scripts? Should it worry me and should I dig into it more? Could it be a >> bug of the siptrace module and nothing bad actually took place? I'm not >> sure where to start with this, so any input would be greatly appreciated. >> Thanks! >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Daniel-Constantin Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda >> Kamailio Advanced Training - www.asipto.com >> Kamailio World Conference - www.kamailioworld.com >> >> >

2 1

Kamailio fails to process ACK to 487 from Cisco-SIPGateway/IOS-12.x?
by George Diamantopoulos 26 Aug '17

26 Aug '17

Hello all, I'm having a weird issue with Kamailio failing to properly process an ACK received to a 487 it sent, resulting in retransmissions of the 487. I assume it's because it can't match the ACK to the transaction, but I could be wrong. I'm using a modified version of the default configuration, so ACKs should be handled correctly. I haven't editted the WITHINDLG route in any way that would affect this (or at least I think). In addition, ACKs to 487 from other UAs are processed correctly, and these transactions are handled by the same routes in kamailio configuration as the problematic one, so I'm inclined to believe it's UA-specific? Here's an example transaction of the failed kind (results in kamailio retransmitting the 487): myself:5060 -> peer:5060 ------------------------- SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP peer:5060 From: <sip:user@peer>;tag=116B5368-24D8 To: <sip:tel@myself>;tag=as655f6372 Call-ID: 84DC69F2-873811E7-8A639B5A-3D9194E8@peer CSeq: 101 INVITE Server: modCOM v2 SIP Server Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 peer:49590 -> myself:5060 ------------------------- ACK sip:tel@myself:5060 SIP/2.0 Via: SIP/2.0/UDP peer:5060 From: <sip:user@peer>;tag=116B5368-24D8 To: <sip:tel@myself>;tag=as655f6372 Date: Wed, 23 Aug 2017 12:50:47 GMT Call-ID: 84DC69F2-873811E7-8A639B5A-3D9194E8@peer Max-Forwards: 10 Content-Length: 0 CSeq: 101 ACK And here's another similar transaction which is successful (no retransmissions): myself:5060 -> peer:5060 ------------------------ SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP peer:5060;branch=z9hG4bKjbmvq4009gthskk0a6s1.1 From: <sip:user@anonymous.invalid;user=phone>;tag=599D7495-9ACE9E3-0A324A05 To: <sip:tel@anonymous.invalid:5060;user=phone>;tag=as65375e5d Call-ID: 599D7495-007A5832@fath3pcu238 CSeq: 1 INVITE Server: modCOM v2 SIP Server Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Length: 0 peer:5060 -> myself:5060 ------------------------ ACK sip:tel@myself:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP peer:5060;branch=z9hG4bKjbmvq4009gthskk0a6s1.1 From: <sip:user@anonymous.invalid;user=phone>;tag=599D7495-9ACE9E3-0A324A05 To: <sip:tel@anonymous.invalid:5060;user=phone>;tag=as65375e5d Call-ID: 599D7495-007A5832@fath3pcu238 Max-Forwards: 69 Content-Length: 0 CSeq: 1 ACK I can't pinpoint anything wrong with the first exchange, other than the fact that for some reason, the "less than" (<) sign in the from and to URIs is escaped as &lt in homer's GUI (which also breaks CSS rendering in Firefox, I had to clear this code out). However, these escaping characters are not visible with sngrep when capturing traffic normally, and neither when doing a select in homer's database directly, so I guess it's a rendering bug in homer-ui and can be ignored (unless someone has reason to believe otherwise). Now the relevant portion of the debug log is: Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) exec: *** cfgtrace:request_route=[WITHINDLG] c=[/etc/kamailio/kamailio.cfg] l=223 a=24 n=t_check_trans Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:1001]: t_check_msg(): msg id=104 global id=103 T start=(nil) Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:459]: t_lookup_request(): start searching: hash=54992, isACK=1 Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:494]: t_lookup_request(): proceeding to pre-RFC3261 transaction matching Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:641]: t_lookup_request(): no transaction found Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) DEBUG: tm [t_lookup.c:1070]: t_check_msg(): msg id=104 global id=104 T end=(nil) Aug 23 16:47:12 modcom-sbc-1 kamailio[9750]: {1 101 ACK 64AA4E6C-874011E7-9A729B5A-3D9194E8@peer} 7(9760) exec: *** cfgtrace:request_route=[WITHINDLG] c=[/etc/kamailio/kamailio.cfg] l=231 a=2 n=exit It explicitly states that no transaction is found, after initiating pre-RFC3261 (why?) transaction matching. However, even pre-3261 matching should work, as the from and to headers as well as call-id in request and repy are the same. Any input would be greatly appreciated, thanks! George

2 3

One Kamailio and many RTPENGINEs
by Denys Pozniak 25 Aug '17

25 Aug '17

Hello! I want to build distributed topology with one KAMAILIO and 5x RTPENGINEs for each region. I will have dedicated links between these sites, so I can garantee somehow voice quality. If one customer from region1 calls customer region2, RTP should go: Customer1->RTEPNGINE1->RTPENGINE2->Customer2 So the main question: Can one Kamailio build "call" between two RTPENGINEs ? BR, Denys

4 4

Handeling Proxy Cancel event
by Abdul Basit 25 Aug '17

25 Aug '17

Hi, I am trying to capture and distinguish two types of cancels generated by kamailio. 1- Cancel when Invite timeout 408 2- Cancel generated when call lands on multiple devices and any one of them answer the call. This type of cancel comes with (rfc3326) Reason: SIP;cause=200;text="Call completed elsewhere" How can I capture and isolate these proxy generated CANCEL events? -- regards, abdul basit

3 5

Diaplan module
by Nelson Migliaro 24 Aug '17

24 Aug '17

Hello, I am trying to use the dialplan module but I am having this problem: First of all, I pull the "dpid" value from the two first digits of the dnis: $var(dialplan_vendor) = $(rU{s.substr,0,2}); Then if(!dp_translate("$var(dialplan_vendor)","$dlg_var(servicio)/$var(ani_dialplan)")) { xlog("L_NOTICE","Error al seleccionar el dialplan\n"); sl_send_reply("403", "Not allowed"); drop; } But when I test everything I get: ERROR: dialplan [dialplan.c:233]: dp_get_ivalue(): no AVP, XAVP or SCRIPTVAR found (error in scripts) I think the problem is related to variable $var(dialplan_vendor). It is set up as string due to the transformation and dialplan need a integer. If I set up the variable this way for testing: $var(dialplan_vendor) = 18, it works correctly. Question, how can I transform the sting into a integer? Thank you Nelson.

1 1

Consistency: -1 sometimes true, sometimes false
by Sebastian Damm 24 Aug '17

24 Aug '17

Hi, we recently stumbled upon the following problem: We had something like this in our route: $var(ret) = allow_address("2"); if ($var(ret)) { do_something; } Turns out, this always evaluates to true, no matter whether the IP address really is in address group 2 or not. The values in $var(ret) are 1 or -1, depending on the outcome of allow_address(). However, if we write it this way if (allow_address("2")) { do_something; } the code inside is only executed if the IP address is in address group 2. Is this some kind of inconsistency? Should negative values in variables evaluate to true or false? Best Regards, Sebastian

3 5

Feature request: USRLOC jsonrpc ul.add - set all entry fields
by Dmitry Sytchev 23 Aug '17

23 Aug '17

Hi Daniel! Looking into code it seems RPC functions of USRLOC don't allow setting all fields for USRLOC entry, for example, Received and Socket. It would be great if we can set these, because we need to have ability to transfer contacts from other server to Kamailio. I think at present this can be done sending specially crafted fake REGISTER packets or calling special route from HTTP with some tricks for saving contact and received, but as for me it would be great to set it from RPC because we already have ul.add method. It also would be cool if we can use named parameters in JSONRPC params: {} section with names corresponding to usrloc fields, like 'table', 'AOR', 'received' and so on. Maybe on specual key not to mix with current 'params'. Thanks for your great work! -- Best regards, Dmitry Sytchev, IT Engineer

2 1

Feature request: USRLOC jsonrpc ul.add - set all entry fields
by Dmitry Sytchev 23 Aug '17

23 Aug '17

1 0

Kamailio APP_LUA
by santosh gupta 23 Aug '17

23 Aug '17

Hi Robert, Hope you are doing good. You have helped me in the past. I need to set LCR via app_lua, getting rates and destination from mysql. Link which i am following is https://www.kamailio.org/wiki/embeddedapi/4.0.x/lua The issue is I am not able to get connect via sr commands for example sr.sqlops.query("connection", "query", "result") What should be exactly is "connection", "query", "result" Error I am getting in syslog is /usr/local/kamailio/etc/kamailio/kamailio.lua:1: attempt to index field 'sqlops' (a nil value) I am using kamailio 5.0.2 A little bit of headsup will help me. Thanks a lot again. -- Regards Santosh Gupta +91 9323043570 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 2

Query in Dialplan module
by Logeshwaran G 23 Aug '17

23 Aug '17

Hi, I have one query in Dialplan module, my scenario is If I call 22291+++++++++ the first three digit should remove and the call place to 91+++++++. But i dont get the exact result, the first three digits are not removing. I have used the below rules: Lcr_rule table: ============ id: 5 lcr_id: 2 Prefix:22291 Request uri: NULL Stopper: 1 Enabled: 1 LCR_rule_target: ================== id:3 lcr_id:2 rule_id:5 gw:id:2 priority:1 weight:1 Dialplan table: ============= id:3 dpid:2 pr:1 match_op:1 match_exp: ^222[0-9]+$ subst_exp: ^222[0-9]+$ repl_exp:\1 Is it correct or not, Please guide me. Thanks & Kind Regards, Logeshwaran G

2 3

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