sr-users March 2012

sr-users@lists.kamailio.org

87 participants
162 discussions

by Andreas Granig

Hi, I'd like to implement a couple of helper functions for time handling, e.g. checking day of week, day of month etc. from within the kamailio config file. What would you prefer, a new module ("timeutils" maybe?) or adding it to cfgutils (there are already time-based functions there like sleep and usleep)? The idea is to implement time based call-forwards, and an approach could be to provision various time-related values in usr_preferences table, and then check it in the config. For example, when doing call-forwards from Monday to Friday only, I could put this into usr_preferences: attribute: cf_weekday value: [1, 2, 3, 4, 5] (each entry is a separate row in usr_preferences) And in kamailio config, I'd call this: avp_db_load(...); if(is_weekday("$avp(s:cf_weekday)")) { do CF } So is_weekday would iterate over the entries in the avp list and return true if the weekday at the time of routing matches an entry in the list. A module config param could control whether to use gmtime or localtime for matching. Does this make sense? Suggestions for other approaches? I'd rather prefer to do it directly in config instead of using some external interpreter like lua, python etc. Andreas

12 years, 3 months

Kamailio : Listening on multiple ports behind NAT

by Reda Aouad

Hello, I am trying to implement the following configuration : - Kamailio as a SIP proxy/registrar behind a one-to-one NAT (port number is not modified) listening on ports 5060 and 53 (and more ports in the future) - aliases correctly configured : alias= udp: public_ip:53 alias= udp: public_ip:5060 alias= udp: hostname:53 alias= udp: hostname:5060 - listen directive correctly on private ip address and both ports : listen=udp:private_ip:53 listen=udp:private_ip:5060 - advertised_address=public_ip - record_route_preset("public_ip") is used to announce the public IP address in the RR header - user A : registered on port 5060 - user B : registered on port 53 Suppose user A tries to call user B. The Record-Route header in the INVITE forwarded from Kamailio to user B should contain the port number on which user B is connected (53), to force user B to send future requests to that port number. But I have no method to know which port user B is connected to, and that problem is aggravated when user B has multiple registrations on different port numbers and parralel forking is done. Declaring advertised_port doesn't solve the problem. I cannot force port number 53 in record_route_preset("public_ip:53") since it wouldn't work when user B calls user A. Using the record_route( ) function, Kamailio doesn't use the advertised_address to construct the RR header. Another problem is that the record_route_preset function clears the DID cookie set by the dialog module, which makes Kamailio fallback to SIP elements to match the request to an existing dialog, thus dialog matching becomes slower, and performance is an issue for me. Any suggestions? I know that one solution would be to run Kamailio with a public IP address and no NAT, but unfortunately it's not possible. I suggest that the function record_route( ) takes a public IP address as a parameter, still doing what it does (correct record routing and cookie addition did=xxx and loose route lr=on), but only replacing the private IP address on which Kamailio listens with a public IP address. Or that the record_route( ) function uses the advertised_address to construct the RR header. Thank you RA

12 years, 4 months

Lua script calling rewriteuri

by Sharif Tanvir Rahman

Hello, We plan to use Kamailio as redirect server. Corresponding contact list is to be fetched by a Lua script from DB. The problem is about calling the required 'rewriteuri' function: 1. From lua script. both 'sr.rewriteuri()' and 'sr.modf("rewriteuri", ...)" fails to write the 'contact' field. 2. I tried an alternative way; pushing the value from lua (e.g. sr.pv.sets("contact", "sip:...")) and got the value in the Kamailio.cfg ($var(contact)). But can't call the rewriteuri function with this variable's value as argument. This seems to be a general problem of calling a function from .cfg with a variable's value as parameter. Any help much appreciated. -- Sharif

12 years, 5 months

lcr from_uri not matching

by Ben WIlliams

Has anyone experienced this problem where lcr only works when from_uri is null. When I change it to .* the match fails. Thanks Ben

12 years, 5 months

TLS performance testing

by Kristian Kielhofner

Hello everyone, I'm doing some TLS performance testing on Kamailio 3.2.1. Here's my setup: kamailio -V version: kamailio 3.2.1 (x86_64/linux) 31c991 flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, USE_STUN, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 31c991 compiled on 19:38:03 Dec 20 2011 with gcc 4.4.6 uname -a Linux null.null.com 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux CentOS 6.2 on a Dell PowerEdge R610 with 24 Intel X5650 Cores at 2.67GHz and 12GB of RAM (I could use more). Kamailio is the default config with a few changes: - WITH_TLS defined - TLS is using self-generated CAs/certs (essentially openvpn easy-rsa) with 1024 bit key size - TLS is *not* configured to verify client OR server certs by default - I'm using TLS v1 (SSL 3.1) - TLS cipher suites are set to any (although my simulated UAs only offer AES 256+SHA) - Various changes to Kamailio children (up to 256 at times) and memory sizes (up to 2048mb and even 4096mb at times) - One DNS based alias added - Maximum TCP connections increased to 65000 - Kamailio is configured to only listen on tested IP (UDP, TCP, TLS sockets active) - Syslog has been configured to log local0 (Kamailio) asynchronously My test rig/call generator is an Ixia Xcellon-Ultra NP load module with IXLoad. My call scenario does the following: - Registers two simulated user agents (100000, 200000) to Kamailio with TLS - Places call from 100000 to 200000 via Kamailio with TLS - Increments both user agents by 1 and continues as quickly (cps) as I like up to a channel limit (also configurable) - The Ixia generates a valid SDP but no RTP is generated (although that's certainly possible at these call levels) Two 1 gig ports on the Ixia are connected to the Broadcom NICs on the Dell R610 via a Cisco Catalyst 4948 switch. One port on the Ixia emulates the 100000 agents (A leg) and the other emulates the 200000 agents (B leg). Of course I can provide more information if needed. Here are some test numbers: With TLS at 20cps, 120 sec calls, up to a total of 2470 calls (4940 registrations) life is good. Very good - call setup time averages 23ms, the cps rate holds indefinitely, and not a single call or registration fails over long term tests. UDP and TCP numbers are excellent (bordering ridiculous) - usually around 500cps with practically no reasonable upper limit on simultaneous calls. This doesn't need any further discussion :). The TLS numbers start falling apart pretty quickly after 20cps, however. If I change the TLS test to 40cps, 120 sec calls, up to a total of 4940 calls (9,880 registrations) Kamailio starts to (seriously) struggle. The rate starts fluctuating all over the place, call setup time averages jump to 8000ms (or more) and things just generally get ugly. Interestingly enough all of the user agents are able to register, the logs look fine (to my eye at this log level) and the system (CPU, network, etc) doesn't appear to be under stress at all. I have a few questions: 1) Is there something obviously wrong or stupid I'm doing here? 2) Why are the TLS tests so much worse than TCP and UDP? Am I missing something here? Thanks (in advance) for any advice anyone might be able to offer! -- Kristian Kielhofner

12 years, 6 months

Consulting needed

by Pete Ashdown

I have been trying to accomplish a couple tasks with Kamailio over the past month with no luck. What I need is a bit of one-on-one training with someone who knows the lay of the land. If you do this kind of consulting and can use Skype with possibly a shared-screen terminal, please drop me an email with your rate.

12 years, 6 months

Re: [SR-Users] CallControl and MediaProxy

by Daniel-Constantin Mierla

Hello, I will patch and backport during next days -- I was mostly out of the office during past weeks. Cheers, Daniel On 3/12/12 11:30 AM, Reda Aouad wrote: > Hi Daniel, > > Any plans to backport this to 3.2 ? > I could still do the changes manually before compilation if you don't > have time to do it. > > Thank you again > Reda > > > > On Wed, Feb 29, 2012 at 10:19, Reda Aouad <reda.aouad(a)gmail.com > <mailto:reda.aouad@gmail.com>> wrote: > > Daniel, It works with flag 28. > Can you confirm that flag 28 isn't used by another module? > If so, can you patch it? When is the next release scheduled for? > > The following are the changes I made: > > modules_k/call_control.c: flag changed to 28 > ------------------------------------------- > #define FL_USE_CALL_CONTROL (1<<28) // use call control for > a dialog > > parser/msg_parser.h: warning added > ------------------------------------------- > /* WARNING: Value (1 << 28) is temporarily reserved for use in > kamailio call_control > * module (flag FL_USE_CALL_CONTROL )! */ > > > Thank you :) > Reda > > > > On Wed, Feb 29, 2012 at 09:58, Reda Aouad <reda.aouad(a)gmail.com > <mailto:reda.aouad@gmail.com>> wrote: > > A quick grep on flags FL_* in the sources shows the following : > Flag 29 is used by acc module, 31 by nat_traversal, 0 to 12 in > the parser. > Thus I assume that it is safe to test using flag 28. > I'll keep you posted on the test result. > > You'll also find below warnings in msg_parser.h for the used > flags. Since flag 30 is declared for mediaproxy in > msg_parser.h, I'll change the flag of callcontrol to 28. > > ----------------------------------------------------------------- > /* WARNING: Value (1 << 29) is temporarily reserved for use in > kamailio acc > * module (flag FL_REQ_UPSTREAM)! */ > > /* WARNING: Value (1 << 30) is temporarily reserved for use in > kamailio > * media proxy module (flag FL_USE_MEDIA_PROXY)! */ > > /* WARNING: Value (1 << 31) is temporarily reserved for use in > kamailio > * nat_traversal module (flag FL_DO_KEEPALIVE)! */ > ----------------------------------------------------------------- > > $ grep -R 'define FL.* (1' src/kamailio/kamailio-3.2.0 > > modules_k/call_control/call_control.c:#define > FL_USE_CALL_CONTROL (1<<30) // use call control for a dialog > modules_k/nat_traversal/nat_traversal.c:#define > FL_DO_KEEPALIVE (1<<31) > modules_k/acc/acc.h:#define FL_REQ_UPSTREAM (1<<29) > parser/msg_parser.h:#define FL_FORCE_RPORT (1 << 0) /*!< force > rport */ > parser/msg_parser.h:#define FL_FORCE_ACTIVE (1 << 1) /*!< > force active SDP */ > parser/msg_parser.h:#define FL_SDP_IP_AFS (1 << 2) /*!< SDP > IP rewritten */ > parser/msg_parser.h:#define FL_SDP_PORT_AFS (1 << 3) /*!< SDP > port rewritten */ > parser/msg_parser.h:#define FL_SHM_CLONE (1 << 4) /*!< msg > cloned in SHM as a single chunk */ > parser/msg_parser.h:#define FL_TIMEOUT (1 << 5) /*!< > message belongs to an "expired" branch > parser/msg_parser.h:#define FL_REPLIED (1 << 6) /*!< > message branch received at least one reply > parser/msg_parser.h:#define FL_HASH_INDEX (1 << 7) /*!< > msg->hash_index contains a valid value (tm use)*/ > parser/msg_parser.h:#define FL_MTU_TCP_FB (1 << 8) > parser/msg_parser.h:#define FL_MTU_TLS_FB (1 << 9) > parser/msg_parser.h:#define FL_MTU_SCTP_FB (1 << 10) > parser/msg_parser.h:#define FL_ADD_LOCAL_RPORT (1 << 11) /*!< > add 'rport' to local via hdr */ > parser/msg_parser.h:#define FL_SDP_BODY (1 << 12) /*!< > msg has SDP in body */ > modules/mediaproxy/mediaproxy.c:#define FL_USE_MEDIA_PROXY (1<<30) > > ----------------------------------------------------------------- > > > Reda > > > > On Wed, Feb 29, 2012 at 00:18, Daniel-Constantin Mierla > <miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: > > That should be. Try changing one of them to (1<<29) and > see if all works fine. > > On another hand, defining and using core msg flags in a > module is a risk, a different solution has to be done, a > simple one is to move the definition of these flags in the > core, so there will be no overlap in the future. > > Cheers, > Daniel > > > On 2/27/12 9:32 PM, Reda Aouad wrote: >> I looked into mediaproxy.c and found the following : >> >> ------------------------------------------------------- >> #define FL_USE_MEDIA_PROXY (1<<30) >> >> ... >> >> # dialog callback >> >> __dialog_created (...) { >> .... >> if ((request->msg_flags & FL_USE_MEDIA_PROXY) == 0) >> return; >> .... >> use_media_proxy (...); >> } >> ------------------------------------------------------- >> >> >> I also found this in call_control.c >> ------------------------------------------------------- >> #define FL_USE_CALL_CONTROL (1<<30) >> >> # Public API >> CallControl (...) { >> ... >> msg->msg_flags |= FL_USE_CALL_CONTROL; >> ... >> } >> ------------------------------------------------------- >> >> So I suspect that since the call_control module uses the >> same flag as the mediaproxy module, call_control function >> is used, flag 30 is set, and the following condition in >> the __dialog_created callback function above is never met >> >> (request->msg_flags & FL_USE_MEDIA_PROXY) == 0 >> >> so the callback function continues until executing its >> last line : use_media_proxy (...) >> which is called on every call to call_control ( ) function.. >> >> Reda >> >> >> >> On Mon, Feb 27, 2012 at 18:39, Reda Aouad >> <reda.aouad(a)gmail.com <mailto:reda.aouad@gmail.com>> wrote: >> >> Ok thanks Daniel. >> >> I'll do what you suggested and we'll see how to proceed. >> >> Thanks again >> Reda >> > > > -- > Daniel-Constantin Mierla --http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda > > > > -- Daniel-Constantin Mierla Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany http://www.asipto.com/index.php/kamailio-advanced-training/

12 years, 7 months

to tag not correctly inserted in rtpproxy command with kamailio 3.2.2

by Laurent Schweizer

Dear all, I see that in some scenario the To Tag is not passed in the command string to configure the rtpproxy. At least I see this scenario: I start a call -> all is ok I do a ReINVITE without any SDP in the INVITE , so I call the rtp_offer() for the 200 OK and the function rtpproxy_answer() for the ACK The problem is with the function rtpproxy_answer() only the from tag is passed so the stream cannot be found (lookup request failed) I do a test with the version 3.2.1 and they was no problem. Bellow rtpproxy log of both version. Regards Laurent With ver: 3.2.2 Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24732_28 Uc0,8,18,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 62.12.250.165 62968 pm04tutcvv;1 1332342221131;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 11416/18748, session timer restarted Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 62968 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 26495 Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24732_28 18748 50.10.21.8#012" Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "24679_17 Lc0,101 ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92 50.10.21.92 64078 pm04tutcvv;1" Mar 21 16:03:46 proxy3 rtpproxy[22197]: INFO:handle_command: lookup request failed: session ec1cdd343243785b663cc52b5af08cf0(a)50.10.21.92, tags pm04tutcvv;1/NONE not found Mar 21 16:03:46 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "24679_17 0 50.10.21.8#012" With ver: 3.2.1 Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10958_13 Uc0,8,18,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 62.12.250.165 56522 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: update from cmd requested Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: new IP : 62.12.250.165's address port 56522 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: old IP: 62.12.250.165 address port 29436 Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: RTCP IP are the same, we don't update them Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:doreply: sending reply "10958_13 16864 50.10.21.8#012" Mar 21 18:18:04 proxy3 rtpproxy[22197]: DBUG:handle_command: received command "10793_9 Lc0,101 4e21d3a85ce70fe0dfa28f517484cba1(a)50.10.21.92 50.10.21.92 63990 jddmr2qwrf;1 1332350278581;1" Mar 21 18:18:04 proxy3 rtpproxy[22197]: INFO:handle_command: lookup on ports 9974/16864, session timer restarted

12 years, 7 months

rtpproxy and CANCEL in serial forked scenarios

by Andreas Granig

Hi, I ran into a scenario with couple of serial forks where kamailio loops to itself and, due to the looping, the INVITE to a new branch happens before the CANCEL to an old branch. What I do at the moment is force rtpproxy in branch route, and stop rtpproxy in the failure route. The problem with this scenario is that in rtpproxy_offer and unforce_rtpproxy, the rtpproxy module only passes the call-id and from-tag to rtpproxy (because there is no to-tag yet), which then in unforce_rtpproxy for a CANCEL deletes all calls related to it (because it can only match on from-tag and call-id, obviously). This means that when I do a subsequent rtpproxy_answer for my new branch, rtpproxy doesn't find the session anymore, since it has been removed with the CANCEL. A fix I can think of is to also pass the branch of the top-most via to rtpproxy in order to perform a more fine-grained matching. Are there solutions to that out there somewhere, or is it something I should just introduce, eg. as a new param to offer/answer/unforce functions? Objections? Other approaches? Andreas

12 years, 7 months

LCR

by Jeff Russell

As a rule, I have managed to work my way through any issues however, I would really appreciate and help in getting the LCR module working (with postgres), what I really need is working examples of working config and database tables, Many thanks, Jeff

12 years, 7 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 March 2012