sr-users November 2013

sr-users@lists.kamailio.org

100 participants
160 discussions

by phillman25

Dear List I am trying to interconnect with a Cisco Call manager express, i am sending the INVITE message with the below format: INVITE sip:22775019@81.21.39.153 SIP/2.0 Record-Route: <sip:81.21.38.33;lr=on;ftag=685329680;did=671.51a2> Via: SIP/2.0/UDP 81.21.38.33;branch=z9hG4bKda1d.291eab1622fb619ec7df3ca647581a19.0 Via: SIP/2.0/UDP 81.21.35.22:5060;branch=z9hG4bKterm-4a32-99665015-6855A22775019-37284 From: 99665015 <sip:99665015@81.21.35.22;user=phone>;tag=685329680 To: 6855A22775019 <sip:6855A22775019@81.21.38.33;user=phone> Call-ID: 6fea2437-2d338fcf-4efc6b90-2d08(a)81.21.35.22 CSeq: 1 INVITE Supported: timer Session-Expires: 1800 Min-SE: 1800 Contact: <sip:99665015@81.21.35.22:5060> Allow: INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE Max-Forwards: 69 Content-Type: application/sdp Content-Length: 528 P-hint: outbound v=0 o=- 3099173 0 IN IP4 81.21.35.44 s=Cisco SDP 0 c=IN IP4 81.21.35.44 t=0 0 m=audio 52168 RTP/AVP 0 8 18 99 102 103 104 4 105 3 106 107 108 125 101 100 a=rtpmap:99 G.726-16/8000 a=rtpmap:102 G.726-24/8000 a=rtpmap:103 G.726-32/8000 a=rtpmap:104 G.723.1-H/8000 a=rtpmap:105 G.723.1-L/8000 a=rtpmap:106 G.729b/8000 a=rtpmap:107 G.723.1a-H/8000 a=rtpmap:108 G.723.1a-L/8000 a=rtpmap:125 G.nX64/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=nortpproxy:yes The Cisco Manager Express replies by sending the TRYING message in the below format with 1 via header: SIP/2.0 100 Trying Via: SIP/2.0/UDP 81.21.38.33;branch=z9hG4bKda1d.291eab1622fb619ec7df3ca647581a19.0,SIP/2.0/UDP 81.21.35.22:5060 ;branch=z9hG4bKterm-4a32-99665015-6855A22775019-37284 From: 99665015 <sip:99665015@81.21.35.22;user=phone>;tag=685329680 To: 6855A22775019 <sip:6855A22775019@81.21.38.33;user=phone> Date: Tue, 05 Nov 2013 18:24:17 GMT Call-ID: 6fea2437-2d338fcf-4efc6b90-2d08(a)81.21.35.22 CSeq: 1 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Seems like Kamailio is not accepting this, is the Trying message from the client correct? Is it correct that he is sending 1 via header with 2 IP's as opposed to 2 via headers with 1 IP in each via header? Otherwise is there a solution for this? Thanks in advance Phillip

10 years, 5 months

Where do I place the logic for modifying auth and call requests?

by erik＠valerius.se

Hello everyone. Some of my confusion probably comes from me coming from the web development world and not software dev, but I would greatly appreciate any response to the following question: I use the MySQL auth for my subscribers which is working great. However, let's say that I add the column "valid_until" in the subscriber table and want to check if today's date is less than the caller's valid_until value. I can set up the sqlops module without a problem and get the actual value, but I have no idea where I place the logic to compare it to a date and then pass on the OK message to Kamailio to continue the request. Is this done with embedded scripts? Or right there in the config file? Where can I find a list of what parts of the call request are exposed for customization from Kamailio? I'd greatly prefer to do things in Python or JavaScript, if that matters. Many thanks in advance! Erik Eklund

10 years, 5 months

RTPproxy support in Wireshark

by Peter Lemenkov

Hello All! First of all I'm sorry for the crossposting. For those who unaware of what's going inside Wireshark project - I'm working on a "classic" RTPproxy protocol dissector. Most of the patches already accepted, and Wireshark's RTPproxy parser is already usable. Few more patches should land in trunk quite soon. As for rtpproxy-ng - I plan to add support for its protocol as well (right after I finish with this one). If you're using Fedora Linux, then Wireshark from the repository already compiled with RTPproxy protocol dissection support. -- With best regards, Peter Lemenkov.

10 years, 5 months

Mitigation of unavailable rtpproxy

by Alex Balashov

Hello, (Sorry for cross-posting to -users and -dev; not really sure where this post belongs most.) A few days ago, I ran into an issue with a Kamailio server being somewhat unresponsive, during moderate call volume, on account of a down rtpproxy--the only rtpproxy in the set. This is rtpproxy classic, not ngcp-mediaproxy-ng. Rtpproxy was not actually engaged on any of the initial INVITEs going through the server; the server is configured to invoke it conditionally based on a setting, and the setting was not set for any endpoints. rtpproxy_manage() was never called. However, I call unforce_rtp_proxy() unconditionally in my config when handling CANCELs, reasoning that it can't do any harm if rtpproxy_manage() was not called before[1]. Nevertheless, it seemed to be the case that this situation was clogging up SIP worker threads, because some SIP messages were definitely dropped. Periodic log messages about inability to reach the rtpproxy were echoed as well. This problem cleared up almost immediately when the rtpproxy instance was restored into service. This raised some questions in my mind about the relationship between rtpproxy management and SIP worker thread utilisation. I assume it was my indiscriminate unforce_rtp_proxy() calls that were actually clogging up the worker threads, right? If so, why? I figured that in the unforce_rtp_proxy() case, the rtpproxy module simply sends fire-and-forget UDP messages down the UDP control socket without any sort of blocking for acknowledgement, since in this case the call must be released on the rtpproxy side without doing any rewriting of SDP on the Kamailio side (unlike in the case where rtpproxy is engaged). Thus, there should be no need to wait for ports to substitute into the message. Or is the same response-wait mechanism used regardless, even in the unforce_rtp_proxy() case, for programmatic reasons? More broadly, is there any way that this scenario can be prevented? In other words, is there a way to work around an outage of all rtpproxies in the set without tying up workers, or at least tying them up less severely? Thanks! -- Alex [1] Is this a reasonable assumption? The reason I do this is that I don't see a way to find out if rtpproxy was engaged from the body of a CANCEL message. I do check for a ;proxy_media RR parameter when handling BYEs, but since a CANCEL is not an in-dialog request, I'm not sure what to do except to call unforce_rtp_proxy()/rtpproxy_manage() indiscriminately, without resorting to storing state in htable or other complications I don't want. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

10 years, 5 months

Kamctl ping works as my unix user, not in root nor kamailio user

by Benjamin Henrion

Hi, I am trying to find out why kamctl ping sip:1.2.3.4:5060 works with my unix user (got a 200 OK), while it does not with kamailio nor root user (I got a 408 timeout). Any idea? The permissions of the socket in /tmp are like this: ======================================= srw------- 1 root root 0 Oct 31 01:01 kamailio_ctl prw-rw---- 1 kamailio kamailio 0 Nov 7 13:55 kamailio_fifo srw-rw-rw- 1 kamailio kamailio 0 Oct 31 01:01 kamailio_socket ======================================= Best, -- Benjamin Henrion <bhenrion at ffii.org> FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators."

10 years, 5 months

SIP registration

by Mudasser

Hello I am devloping the chat/call application like viber,whatsapp etc in Android using sip. I want to know how i can register the sip account with ur sevrer. what's code which i need to write in my application.suppose if i want to chat or call between other person how i can get register without telling user that i am going for sip registration means there i cam not going to display sip registration form etc. where i can save user message and how i can maintain user info like dispaly name , display pic etc.is there any serverside databse involvement to save messages,pic etc or sip sever maintain automatically. Kindly describe in details as i am new in Android Thank you Best Regards Mudasser Tufail Senior Software Engineer

10 years, 5 months

Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route

by Klaus Feichtinger

Hello Daniel, I´ve patched the code and found that the return value of the 'sleep' command is - as expected - differing in the scenarios. For scenario 1 (no provisional response), the return value is '0' and for scenario 2, the return value is '2' (see log output): scenario 1: Nov 7 12:40:51 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s Nov 7 12:40:51 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds Nov 7 12:40:53 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 0 Nov 7 12:40:53 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s scenario 2: Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 2 Nov 7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s This means that the sleep command is interrupted (in scenario 2) by a signal, as the return value is representing the "number of seconds left to sleep, if the call was interrupted by a signal handler.". Which signal is interrupting "sleep" in this scenario (only) :-( ? Klaus > Daniel-Constantin Mierla <miconda(a)gmail.com> hat am 7. November 2013 um 10:36 > geschrieben: > > Hello, > > can you try to see if sleep_us() works? > > It is rather strange because sleep() from cfgutils just uses sleep() from > system library, nothing special internally... sleep is interrupted by signals > as well. Can you patch the function in kamailio to log the return code from > sleep()? > > Cheers, > Daniel > > On 11/7/13 8:40 AM, klaus.lists#inode.at wrote: > > > > Hello, > > > > I have an update: > > > > today I´ve tested with kamailio version 4.0.4, but the behaviour is > > still the same: it is working fine only when no response has been received; > > as soon as a provisional response is received, the failure route is ignoring > > the "sleep" function. > > > > Klaus > > > > > > > Hello list, > > > > > > I have troubles using the function "usleep(x)" or "sleep(x)" (the > > > behaviour is the same) of the "cfgutils" module > > > (<http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968> > > > ) in the failure_route. According documentation, this function could be > > > used in any route, including the failure_route, too. However, when I call > > > this function, it does not show any reaction, if a transaction was already > > > answered with a provisional response. It is still working fine, when a > > > transaction is timing out, as no target socket is reachable. This is > > > confusing me! > > > > > > Please find below some xlog messages from my configuration file in > > > two scenarios (function "t_set_fr(20000, 10000);" is identic in both > > > scenarios): > > > (1) scenario 1 is including a primary target, looked up in the > > > registrar DB, which is unreachable; after transaction timeout I have > > > inserted the function "sleep()" in the failure_route for forcing a delay > > > => here it is working fine (see timestamp) > > > > > > (2) scenario 2 is including a primary target which is responding, > > > but not establishing the session; after transaction timeout the procedure > > > is still the same as in scenario (1) > > > => here is no delay visible in the log and practically detectable > > > > > > From my point of view, this is a malfuntion! Does anybody see it > > > different? I´ve tested these scenarios with kamailio-3.2.x and > > > kamailio-3.3.x - no difference. > > > > > > Thanks for any hints! > > > > > > Klaus > > > > > > ################# SCENARIO (1) ORIG TARGET IS UNREACHABLE > > > ########################## > > > Nov 6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: > > > -<|XLOG|>-: <RELAY> is reached for RU:<sip:117002@10.16.48.226:5678> , > > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 1107651805(a)10.16.48.71 <mailto:1107651805@10.16.48.71> > > > > > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: > > > -<|XLOG|>-: <FAILRELAY> is reached with Code: 408 > > > From:<sip:1101015555@10.16.48.71> To:<sip:115300@10.16.48.44> > > > > > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: > > > -<|XLOG|>-: failure_route <FAILRELAY> is reached because of a > > > BRANCH_TIMEOUT of RU:<sip:117002@10.16.48.226:5678> > > > > > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: > > > -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s > > > > > > Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: > > > -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s > > > > > > Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: > > > -<|XLOG|>-: <RELAYFB> is reached for RU:<sip:117003@10.16.48.226:7001> , > > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 1107651805(a)10.16.48.71 <mailto:1107651805@10.16.48.71> > > > > > > ################# SCENARIO (2) ORIG TARGET IS REACHABLE > > > ########################## > > > > > > Nov 6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: > > > -<|XLOG|>-: <RELAY> is reached for RU:<sip:117002@10.16.48.226:5678> , > > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > > > INVITE, Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> > > > > > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: > > > -<|XLOG|>-: <FAILRELAY> is reached with Code: 408 > > > From:<sip:5555@10.16.48.71> To:<sip:4000@10.16.48.44> > > > > > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: > > > -<|XLOG|>-: failure_route <FAILRELAY> is reached because of a > > > BRANCH_TIMEOUT of RU:<sip:117002@10.16.48.44> > > > > > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: > > > -<|XLOG|>-: <FAILRELAY> s l e e p 2000ms / 2s > > > > > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: > > > -<|XLOG|>-: <FAILRELAY> s l e p t 2000ms / 2s > > > > > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: > > > -<|XLOG|>-: <RELAYFB> is reached for RU:<sip:117003@10.16.48.44> , > > > From:<sip:5555@10.16.48.71> , To:<sip:4000@10.16.48.44> , Method: INVITE, > > > Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> > > > > > > > > > > > > > > > > > > _______________________________________________ > > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > > sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> > > <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users> > > > > > > -- > Daniel-Constantin Mierla - <http://www.asipto.com> > <http://twitter.com/#!/miconda> - <http://www.linkedin.com/in/miconda> > Kamailio Advanced Trainings - Berlin, Nov 25-28 > - more details about Kamailio trainings at <http://www.asipto.com> - >

10 years, 5 months

IM Broadcasting

by sipatse＠in.gr

10 years, 5 months

Function to test DB connection from route[]?

by Allen Zhang

Hi all, Is there a function I can use to test database connection from the routing script in the cfg file? My dispatcher uses OPTIONS probing. When the destination receives the OPTIONS request, I'd like to detect the health status of the database connection before sending a 200 back. Note the OPTIONS request doesn't have a user part in the RURI. Hence, is_subscriber() and alias_db_lookup() don't work. Any suggestion? Regards, Allen Zhang

10 years, 5 months

Re: [SR-Users] #cfgutils: sleep(x) does not work in failure_route

by klaus.lists#inode.at

Hello, I have an update: today I´ve tested with kamailio version 4.0.4, but the behaviour is still the same: it is working fine only when no response has been received; as soon as a provisional response is received, the failure route is ignoring the "sleep" function. Klaus > Hello list, > > I have troubles using the function "usleep(x)" or "sleep(x)" (the behaviour > is the same) of the "cfgutils" module > (<http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968> ) > in the failure_route. According documentation, this function could be used in > any route, including the failure_route, too. However, when I call this > function, it does not show any reaction, if a transaction was already answered > with a provisional response. It is still working fine, when a transaction is > timing out, as no target socket is reachable. This is confusing me! > > Please find below some xlog messages from my configuration file in two > scenarios (function "t_set_fr(20000, 10000);" is identic in both scenarios): > (1) scenario 1 is including a primary target, looked up in the registrar DB, > which is unreachable; after transaction timeout I have inserted the function > "sleep()" in the failure_route for forcing a delay > => here it is working fine (see timestamp) > > (2) scenario 2 is including a primary target which is responding, but not > establishing the session; after transaction timeout the procedure is still the > same as in scenario (1) > => here is no delay visible in the log and practically detectable > > From my point of view, this is a malfuntion! Does anybody see it different? > I´ve tested these scenarios with kamailio-3.2.x and kamailio-3.3.x - no > difference. > > Thanks for any hints! > > Klaus > > ################# SCENARIO (1) ORIG TARGET IS UNREACHABLE > ########################## > Nov 6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -<|XLOG|>-: > <RELAY> is reached for RU:<sip:117002@10.16.48.226:5678> , > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 1107651805(a)10.16.48.71 <mailto:1107651805@10.16.48.71> > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: > <FAILRELAY> is reached with Code: 408 From:<sip:1101015555@10.16.48.71> > To:<sip:115300@10.16.48.44> > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: > failure_route <FAILRELAY> is reached because of a BRANCH_TIMEOUT of > RU:<sip:117002@10.16.48.226:5678> > > Nov 6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: > <FAILRELAY> s l e e p 2000ms / 2s > > Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-: > <FAILRELAY> s l e p t 2000ms / 2s > > Nov 6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -<|XLOG|>-: > <RELAYFB> is reached for RU:<sip:117003@10.16.48.226:7001> , > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 1107651805(a)10.16.48.71 <mailto:1107651805@10.16.48.71> > > ################# SCENARIO (2) ORIG TARGET IS REACHABLE > ########################## > > Nov 6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: -<|XLOG|>-: > <RELAY> is reached for RU:<sip:117002@10.16.48.226:5678> , > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method: > INVITE, Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: > <FAILRELAY> is reached with Code: 408 From:<sip:5555@10.16.48.71> > To:<sip:4000@10.16.48.44> > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: > failure_route <FAILRELAY> is reached because of a BRANCH_TIMEOUT of > RU:<sip:117002@10.16.48.44> > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: > <FAILRELAY> s l e e p 2000ms / 2s > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: > <FAILRELAY> s l e p t 2000ms / 2s > > Nov 6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-: > <RELAYFB> is reached for RU:<sip:117003@10.16.48.44> , > From:<sip:5555@10.16.48.71> , To:<sip:4000@10.16.48.44> , Method: INVITE, > Call-ID: 553330101(a)10.16.48.71 <mailto:553330101@10.16.48.71> >

10 years, 5 months

Jump to page:

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 November 2013