sr-dev June 2012

sr-dev@lists.kamailio.org

31 participants
250 discussions

by Jason Penton

Hi All, I was wondering if there was an existing pattern is Kamailio to deal with long-running code being executed on a callback. If we take, for example, usrloc. Lets say the domains are synced every 60 seconds. Assume there are going to be 200 expired contacts at the next fire. Now imagine the callback for each expired contact having to do some long IO (viz talking to DB, in IMS case doing diameter, etc). Under load, some of these task can be in excess of 100ms. In this specific case your timer (albeit most likely a slow timer in this case) will be "stuck" running the callbacks for a good (100ms x 200) = 20 seconds :-/ I can only think of using some form of async model to get around this. I know there would be the pain of most likely having to use reference counting, for example in usrloc on urecords and ucontacts. Does anyone have any ideas around this? Is there a gap to look at some core functionality for handling async callbacks? does it already exist and I have missed it? ideas/comments welcome. cheers jason

11 years, 11 months

[tracker] Task closed: is_gruu() test fails

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#235 - is_gruu() test fails User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Fixed Additional comments about closing: Committed in master branch as GIT#1e5b711a88eb2c4a5d656d4e8f24729e04924518 More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=235 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

11 years, 11 months

[tracker] User took ownership: is_gruu() test fails

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Daniel-Constantin Mierla has taken ownership of the following task: FS#235 - is_gruu() test fails More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=235 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

11 years, 11 months

git:master: siputils: fix for is_gruu()

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 1e5b711a88eb2c4a5d656d4e8f24729e04924518 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1e5b711… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue Jun 5 23:40:53 2012 +0200 siputils: fix for is_gruu() - improper return code check resulted in wrong gruu detection when there was no uri parameter - reported by Juha Heinanen, closes FS#235 --- modules_k/siputils/sipops.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/modules_k/siputils/sipops.c b/modules_k/siputils/sipops.c index c235aa6..3ee7566 100644 --- a/modules_k/siputils/sipops.c +++ b/modules_k/siputils/sipops.c @@ -102,7 +102,7 @@ int w_is_gruu(sip_msg_t *msg, char *uri1, char *p2) return -1; puri = &turi; } else { - if(parse_sip_msg_uri(msg)) + if(parse_sip_msg_uri(msg)<0) return -1; puri = &msg->parsed_uri; }

11 years, 11 months

git:master: pkd/deb Remove lua and Add redis to wheezy build

by Jon Bonilla

Module: sip-router Branch: master Commit: f5a60cb91ecb701681b7ef0a29d5f1b0bb503908 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f5a60cb… Author: Jon Bonilla <manwe(a)aholab.ehu.es> Committer: Jon Bonilla <manwe(a)aholab.ehu.es> Date: Wed May 30 01:44:50 2012 +0200 pkd/deb Remove lua and Add redis to wheezy build --- pkg/kamailio/deb/wheezy/control | 40 +++++++++++++++++++------------------- pkg/kamailio/deb/wheezy/rules | 2 +- 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/pkg/kamailio/deb/wheezy/control b/pkg/kamailio/deb/wheezy/control index a3a894b..8ae44e0 100644 --- a/pkg/kamailio/deb/wheezy/control +++ b/pkg/kamailio/deb/wheezy/control @@ -2,7 +2,7 @@ Source: kamailio Section: net Priority: optional Maintainer: Jon Bonilla <manwe(a)aholab.ehu.es> -Build-Depends: debhelper (>= 5), dpatch, libmysqlclient-dev, libexpat1-dev, libxml2-dev, libpq-dev, libradiusclient-ng-dev, flex, bison, zlib1g-dev, unixodbc-dev, libxmlrpc-c3-dev, libperl-dev, libsnmp-dev, dpkg-dev (>= 1.13.19), libdb-dev (>= 4.6.19), xsltproc, libconfuse-dev, libldap2-dev, libssl-dev, libcurl3-openssl-dev, python, libpcre3-dev, docbook-xml, libmemcache-dev, libreadline-dev, liblua5.1-0-dev, python-dev, libsasl2-dev, libgeoip-dev (>= 1.4.5), libsqlite3-dev, libjson0-dev, libevent-dev, libncurses5-dev +Build-Depends: debhelper (>= 5), dpatch, libmysqlclient-dev, libexpat1-dev, libxml2-dev, libpq-dev, libradiusclient-ng-dev, flex, bison, zlib1g-dev, unixodbc-dev, libxmlrpc-c3-dev, libperl-dev, libsnmp-dev, dpkg-dev (>= 1.13.19), libdb-dev (>= 4.6.19), xsltproc, libconfuse-dev, libldap2-dev, libssl-dev, libcurl3-openssl-dev, python, libpcre3-dev, docbook-xml, libmemcache-dev, libreadline-dev, python-dev, libsasl2-dev, libgeoip-dev (>= 1.4.5), libsqlite3-dev, libjson0-dev, libevent-dev, libncurses5-dev, libhiredis-dev (>= 0.10.0) Standards-Version: 3.8.0 Homepage: http://www.kamailio.org/ @@ -235,16 +235,16 @@ Description: contains the TLS kamailio transport module This has been split out of the main kamailio package, so that kamailio will not depend on openssl. This module will enable you to use the TLS transport. -Package: kamailio-lua-modules -Architecture: any -Depends: ${shlibs:Depends}, kamailio (= ${Source-Version}) -Description: contains the app_lua module - Kamailio is a very fast and flexible SIP (RFC3261) - proxy server. Written entirely in C, Kamailio can handle thousands calls - per second even on low-budget hardware. - . - This package provides the app_lua module, an extension allowing to - execute embedded Lua applications within configuration file. +#Package: kamailio-lua-modules +#Architecture: any +#Depends: ${shlibs:Depends}, kamailio (= ${Source-Version}) +#Description: contains the app_lua module +# Kamailio is a very fast and flexible SIP (RFC3261) +# proxy server. Written entirely in C, Kamailio can handle thousands calls +# per second even on low-budget hardware. +# . +# This package provides the app_lua module, an extension allowing to +# execute embedded Lua applications within configuration file. Package: kamailio-python-modules Architecture: any @@ -268,15 +268,15 @@ Description: contains the geoip module This package provides the geoip module, an extension allowing to use GeoIP API within configuration file. -#Package: kamailio-redis-modules -#Architecture: any -#Depends: ${shlibs:Depends}, kamailio (= ${binary:Version}), libhiredis0.10 -#Description: Redis database connectivity module for Kamailio -# Kamailio is a very fast and flexible SIP (RFC3261) -# proxy server. Written entirely in C, Kamailio can handle thousands calls -# per second even on low-budget hardware. -# . -# This package provides the Redis NOSQL database driver for Kamailio. +Package: kamailio-redis-modules +Architecture: any +Depends: ${shlibs:Depends}, kamailio (= ${binary:Version}), libhiredis0.10 +Description: Redis database connectivity module for Kamailio + Kamailio is a very fast and flexible SIP (RFC3261) + proxy server. Written entirely in C, Kamailio can handle thousands calls + per second even on low-budget hardware. + . + This package provides the Redis NOSQL database driver for Kamailio. Package: kamailio-sqlite-modules Architecture: any diff --git a/pkg/kamailio/deb/wheezy/rules b/pkg/kamailio/deb/wheezy/rules index 723e344..2e1a9eb 100755 --- a/pkg/kamailio/deb/wheezy/rules +++ b/pkg/kamailio/deb/wheezy/rules @@ -42,7 +42,7 @@ MODULES_SP= # on which other depend first) PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \ ldap xml perl utils memcached tls \ - snmpstats carrierroute xmpp cpl lua python geoip\ + snmpstats carrierroute xmpp cpl redis python geoip\ sqlite json # name of libdir in the path for libraries (e.g., lib for 32b, lib64 for 64b)

11 years, 11 months

[tracker] Task opened: is_gruu() test fails

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Juha Heinanen (jh) Attached to Project - sip-router Summary - is_gruu() test fails Task Type - Bug Report Category - Module Status - New Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - as i indicated on the mailing list, is_gruu() test is not working. this piece of config code if (!is_gruu()) { xlog("L_INFO", "Request URI $ru is NOT gruu\n"); }; if (is_gruu($ru)) { xlog("L_INFO", "Request URI $ru IS gruu\n"); }; produces this to syslog: Jun 5 22:30:03 siika /usr/sbin/sip-proxy[16681]: INFO: Request URI sip:test@test.fi;gr=urn:uuid:447ff092-6236-47d9-bc0a-a3c6856aacf2 is NOT gruu Jun 5 22:30:03 siika /usr/sbin/sip-proxy[16681]: INFO: Request URI sip:test@test.fi;gr=urn:uuid:447ff092-6236-47d9-bc0a-a3c6856aacf2 IS gruu More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=235 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

11 years, 11 months

git:master: parser: Also support single-quoted URI params.

by Andreas Granig

Module: sip-router Branch: master Commit: 1a5b6cd11af4ec65148bc06617c33d689dbb5189 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1a5b6cd… Author: Andreas Granig <agranig(a)sipwise.com> Committer: Andreas Granig <agranig(a)sipwise.com> Date: Tue Jun 5 14:29:13 2012 +0200 parser: Also support single-quoted URI params. RFC3261 only allows single-quoted params (no double-quoted ones), however better support both. --- parser/parse_param.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/parser/parse_param.c b/parser/parse_param.c index 986b873..845292a 100644 --- a/parser/parse_param.c +++ b/parser/parse_param.c @@ -266,6 +266,7 @@ static inline void parse_uri_class(param_hooks_t* _h, param_t* _p) static inline int parse_quoted_param(str* _s, str* _r) { char* end_quote; + char quote; /* The string must have at least * surrounding quotes @@ -274,13 +275,18 @@ static inline int parse_quoted_param(str* _s, str* _r) return -1; } + /* Store the kind of quoting (single or double) + * which we're handling with + */ + quote = (_s->s)[0]; + /* Skip opening quote */ _s->s++; _s->len--; /* Find closing quote */ - end_quote = q_memchr(_s->s, '\"', _s->len); + end_quote = q_memchr(_s->s, quote, _s->len); /* Not found, return error */ if (!end_quote) { @@ -415,7 +421,7 @@ static inline void parse_param_name(str* _s, pclass_t _c, param_hooks_t* _h, par */ static inline int parse_param_body(str* _s, param_t* _c) { - if (_s->s[0] == '\"') { + if (_s->s[0] == '\"' || _s->s[0] == '\'') { if (parse_quoted_param(_s, &(_c->body)) < 0) { LOG(L_ERR, "parse_param_body(): Error while parsing quoted string\n"); return -2;

11 years, 11 months

git:master: modules_k/path: Use single-quotes around received

by Andreas Granig

Module: sip-router Branch: master Commit: a5b181bca6bf37b4a18ef502717b50d06e53d5e4 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a5b181b… Author: Andreas Granig <agranig(a)sipwise.com> Committer: Andreas Granig <agranig(a)sipwise.com> Date: Tue Jun 5 14:31:04 2012 +0200 modules_k/path: Use single-quotes around received For full RFC3261 compliance, use single-quoted "received" param instead of double-quoted one. --- modules_k/path/path.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/modules_k/path/path.c b/modules_k/path/path.c index 57c413a..b8eb0c8 100644 --- a/modules_k/path/path.c +++ b/modules_k/path/path.c @@ -122,23 +122,23 @@ static int prepend_path(struct sip_msg* _m, str *user, int recv) if (recv) { /* TODO: agranig: optimize this one! */ src_ip = ip_addr2a(&_m->rcv.src_ip); - rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 22); /* "sip:<ip>:<port>;transport=sctp"\0 */ + rcv_addr.s = pkg_malloc(6 + IP_ADDR_MAX_STR_SIZE + 22); /* 'sip:<ip>:<port>;transport=sctp'\0 */ if(!rcv_addr.s) { LM_ERR("no pkg memory left for receive-address\n"); goto out3; } switch (_m->rcv.proto) { case PROTO_UDP: - rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 6, "\"sip:%s:%u\"", src_ip, _m->rcv.src_port); + rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 6, "'sip:%s:%u'", src_ip, _m->rcv.src_port); break; case PROTO_TCP: - rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "\"sip:%s:%u;transport=tcp\"", src_ip, _m->rcv.src_port); + rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tcp'", src_ip, _m->rcv.src_port); break; case PROTO_TLS: - rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "\"sip:%s:%u;transport=tls\"", src_ip, _m->rcv.src_port); + rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 20, "'sip:%s:%u;transport=tls'", src_ip, _m->rcv.src_port); break; case PROTO_SCTP: - rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "\"sip:%s:%u;transport=sctp\"", src_ip, _m->rcv.src_port); + rcv_addr.len = snprintf(rcv_addr.s, 6 + IP_ADDR_MAX_STR_SIZE + 21, "'sip:%s:%u;transport=sctp'", src_ip, _m->rcv.src_port); break; }

11 years, 11 months

Redesign of rtpproxy control protocol

by Andreas Granig

Hi guys, I've had a discussion with Daniel Mierla at Linuxtag last week, and we were talking about the future of rtpproxy and its control protocol. The current state of affairs is that it has a number of mandatory parameters and a couple of trailing optional ones. Since the protocol relies on the position of the parameters, it's really difficult to add new ones because you somehow need to fill up the optional positions in between, which would cause quite some headache. For example, one thing we did for upcoming 3.3 was adding via branch to the call-id separated by a semi-colon and let the rtpproxy daemon parse it if it's capable to do so, which is a pretty hackish approach. Another thing we'd like to get into 3.4 is to let rtpproxy pass back media statistics in the response of a delete-command. My proposal is to change the control protocol to some kind of key/value style format, which would allow to easily add such additions. A good way in my opinion would be to use an esablished format like JSON, so an rtpproxy request like this: 20477_10 USII mycallid;myviabranch 192.168.51.1 5016 myfromtag;1 would become something like this: { cookie:"20477_10", method:"update", flags:"SII", callid:"mycallid", viabranch:"myviabranch", ipv4addr:"192.168.51.1", port:"5016", fromtag:"myfromtag", streamnum:1} The "flags" option could also be split up, and adding more parameters is straight-forward, so we're pretty flexible here. From a reply perspective, it's also easier to pass back errors instead of the "0" port approach. Any comments on that approach? Andreas

11 years, 11 months

Single-quoted vs double-quoted params in Path/Route

by Andreas Granig

Hi guys, When I implemented the Path module 6 years ago, I chose to enclose the received-URI in double-quotes, like this: Path: <sip:1.2.3.4:5060;received="sip:1.2.3.5:1234;transport=tcp"> This Path value is stored in usrloc by registrar module, and is converted to a Route in a subsequent request. This worked fine so far, because there's the logic in parser/parse_param.c to handle double-quoted parameters. Now while doing some interop tests with another platform, it turned out that double-quotes are not allowed in URI params (see https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-May/019335.ht…, and in the grammar the allowed chars in the "unreserved" definition are "alphanum" and "mark", where "mark" is only "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" ). Anyways, to fully comply with RFC3261, I'd like to push a bugfix to path module to use single-quotes instead, however it also needs a change in the parser to use parse_quoted_param() also in case of single-quoted params (which hasn't been handled at all until now). My question now is if there are any concerns on your side with handling single-quoted URI params the way we handle double-quoted ones? If we were strict, we'd actually need to remove the handling for double-quoted ones, but for backwards-compatibility I'd rather keep it there. Comments? Andreas

11 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2012