sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

[tracker] Task opened: inconsitent config.mak for different targets

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 - Ovidiu Sas (osas) Attached to Project - sip-router Summary - inconsitent config.mak for different targets Task Type - Bug Report Category - tools/scripts Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - I'm working on building an rpm spec file for kamailio 3.0.1. While building kamailio on CentOS I noticed that the default location for the config file is wrong (got /usr/etc/kamailio/ instead of /etc/kamailio/). The make cfg options that I was using on centos are similar with the ones used to build a debian package. I did an experiment by playing with the config options and the results are different based on 'cfg_prefix' and 'basedir' options. Here are the steps to reproduce the issue (on a debian box): # get the latest kamailio code: cd /usr/local/src rm -rf kamailio-3.0.1 git clone --depth 1 git://git.sip-router.org/sip-router kamailio-3.0.1 cd kamailio-3.0.1 git checkout -b kamailio_3.0 origin/kamailio_3.0 # configure kamailio in debian style: make cfg prefix=/usr cfg_prefix=/usr/local/src/kamailio-3.0.1/debian/kamailio cfg_target=/etc/kamailio/ basedir=/usr/local/src/kamailio-3.0.1/debian/kamailio # save the generated config.mak file: cp config.mak config.mak.deb #clean up the repo: rm -rf config.mak modules.lst # configure kamailio in centos style: make cfg prefix=/usr cfg_prefix=/var/tmp/kamailio-3.0.1-buildroot cfg-target=/etc/kamailio/ basedir=/var/tmp/kamailio-3.0.1-buildroot # save the generated config.mak file: cp config.mak config.mak.centos # run a diff between the two generated file: diff config.mak.centos config.mak.deb The output is quite different: 11c11 < C_DEFS= -DNAME='"kamailio"' -DVERSION='"3.0.1"' -DARCH='"i386"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386 -D__OS_linux -DSER_VER=3000001 -DCFG_DIR='"/usr/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DF_MALLOC -DUSE_TLS -DTLS_HOOKS -DSTATISTICS -DMALLOC_STATS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT --- > C_DEFS= -DNAME='"kamailio"' -DVERSION='"3.0.1"' -DARCH='"i386"' -DOS='linux_' -DOS_QUOTED='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386 -D__OS_linux -DSER_VER=3000001 -DCFG_DIR='"/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DUSE_DNS_CACHE -DUSE_DNS_FAILOVER -DUSE_DST_BLACKLIST -DUSE_NAPTR -DF_MALLOC -DUSE_TLS -DTLS_HOOKS -DSTATISTICS -DMALLOC_STATS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DCC_GCC_LIKE_ASM -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_SCHED_SETSCHEDULER -DHAVE_EPOLL -DHAVE_SIGIO_RT -DSIGINFO64_WORKARROUND -DUSE_FUTEX -DHAVE_SELECT 53c53 < basedir= /var/tmp/kamailio-3.0.1-buildroot --- > basedir= /usr/local/src/kamailio-3.0.1/debian/kamailio 57c57 < cfg_prefix= /var/tmp/kamailio-3.0.1-buildroot --- > cfg_prefix= /usr/local/src/kamailio-3.0.1/debian/kamailio 75c75 < cfg_target= $(prefix)/$(cfg_dir) --- > cfg_target= /etc/kamailio/ The cfg_target is not identical for the two config files and therefore when kamailio is built on CentOS, the default kamailio config file location is /usr/etc/kamailio/ instead of being /etc/kamailio/. I would expect the cfg_target to be identical in both cases. Regards, Ovidiu Sas More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=50 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.

14 years, 9 months

[tracker] Task opened: per module debug level

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 - Ovidiu Sas (osas) Attached to Project - sip-router Summary - per module debug level Task Type - Feature Request Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - One feature that I'm missing is a per module debug level. Sometimes, having all the modules at the same debug level may be heavy. Having only one or a few module with a higher debug level then the others may help in debugging issues that are happening in realtime traffic. If work is scheduled for FS#48 - per transaction debug level, then it might be a good time to combine the work for this two feature requests. Regards, Ovidiu Sas More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=49 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.

14 years, 9 months

[tracker] Assignee added: per module debug level

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#49 - per module debug level User who did this - Ovidiu Sas (osas) http://sip-router.org/tracker/index.php?do=details&task_id=49 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.

14 years, 9 months

[tracker] Task opened: per transaction debug level

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 - per transaction debug level Task Type - Feature Request Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - allow overriding debug level per transaction. for example, that would allow logging OPTIONS requests at lower debug level than what default debug level is. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=48 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.

14 years, 9 months

[tracker] Assignee added: per transaction debug level

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#48 - per transaction debug level User who did this - Juha Heinanen (jh) http://sip-router.org/tracker/index.php?do=details&task_id=48 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.

14 years, 9 months

[tracker] Task opened: allow choosing of avp syntax

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 - allow choosing of avp syntax Task Type - Feature Request Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - in order to better detect script writing typos, allow script writer to choose, which avp syntax is in use, i.e., $name or $avp(name). More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=47 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.

14 years, 9 months

[tracker] Assignee added: allow choosing of avp syntax

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#47 - allow choosing of avp syntax User who did this - Juha Heinanen (jh) http://sip-router.org/tracker/index.php?do=details&task_id=47 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.

14 years, 9 months

[tracker] Task opened: return does not work when called inside while statement

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 - return does not work when called inside while statement Task Type - Bug Report Category - Core Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - High Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - looks like return statement does not work when called inside while statement. route [TEST] { while (1) { if (1) { xlog("Trying to get out!\n"); return; }; }; } route(TEST); outputs to syslog Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! Mar 25 07:53:27 localhost /usr/sbin/sip-proxy[19413]: ERROR: Trying to get out! .... More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=46 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.

14 years, 9 months

[tracker] Assignee added: return does not work when called inside while statement

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#46 - return does not work when called inside while statement User who did this - Juha Heinanen (jh) http://sip-router.org/tracker/index.php?do=details&task_id=46 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.

14 years, 9 months

Modifications to Kamailio/rtpproxy to support high capacity encryption and transcoding

by Vikram Ragukumar

Hello, This post is fairly long, and we expect that some of the subsequent posts will also be long, so we are creating and maintaining a document on our ftp site with the same information as in the posts. This document can be accessed at ftp://ftp.signalogic.com/mailing_lists/sr-dev_post_24Mar10.pdf Current Work ------------ Below I have tried to summarize modifications made to nathelper, Rtpproxy and Kamailio.cfg to support encryption/decryption below 1) Nathelper Nathelper defines a new function force_rtp_proxy_ex(). This function is an extension of the existing force_rtp_proxy(). force_rtp_proxy_ex() has the following additional features when compared to force_rtp_proxy() (a) force_rtp_proxy_ex() takes an additional flag '_' as input. The presence of this flag indicates that rtp streams being setup by associated SIP messages are encrypted using a custom encryption algorithm. The '_' flag is in place only because SDP contains no information regarding encryption. (b) Number of elements in struct iovec array, has been increased to include more information to rtpproxy while passing commands. Additional information that is passed to rtpproxy includes common SRTP parameters like (i) Encryption type (ii) Encryption key scheme (iii) Encryption authorization type (iv) Salt size (v) Encryption mode (vi) Encryption key length (c) Duplicated functions force_rtp_proxy0_f(), force_rtp_proxy1_f(), force_rtp_proxy2_f()for use with force_rtp_proxy_ex() 2) Rtpproxy Rtpproxy now includes a sub-structure in the rtpp_session structure. Implementation details are given below (a) rtpp_session.h defines a new sub-structure 'struct DS_Encryption_attributes' under the rtpp_session structure. The DS_Encryption_Attributes structure is detailed below. All relevant enum types have also been defined in rtpp_session.h struct DS_Encryption_Attributes{ DS_ENCRYPTION_TYPE EncryptionType; char *EncryptionKey; short KeyLengthU8; short SaltSizeU8; DS_ENCRYPTION_MODE EncryptionMode; DS_ENCRYPTION_KEY_SCHEME KeyScheme; DS_ENCRYPTION_AUTH_TYPE AuthType; }; (b) rtpp_command.c modified to understand the '_' flag in nathelper's new command. Upon receiving the '_' command from nathelper, rtpproxy now populates the DS_Encryption_Attributes structure associated with the appropriate rtp session. (c) main.c modified to decrypt/encrypt rtp packets soon after reception or just before sending respectively, if valid parameters have been defined in the sessions encryption attributes. main.c defines a new include file, that contains the actual encryption/decryption algorithm. 3)Kamailo.cfg Kamailio's configuration file now takes a new function call force_rtp_proxy_ex(). It accepts all the same flags and parameters as force_rtp_proxy() excepting for an additional '_' flag followed by an encryption key. This key is then passed onto rtpproxy through nathelper where rtpproxy populates the EncryptionKey field of the appropriate rtp session's DS_Encryption_Attributes structure using the string that appears after the '_' flag. 4)Encryption module The encryption module is a C implementation of the encryption/decryption algorithm and is included as #include "crypt.h" within main.c of rtpproxy. The API used while making calls to the encryption/decryption function is given below void crypt(unsigned char *rtp_payload,unsigned int pkt_length, struct DS_Encryption_Attributes enc_attr); The encryption/decryption is just a first step. For now these are simple, packet based APIs. However in order to support high capacity server acceleration cards that have their own GbE interface, we are also adding call-based APIs, which can be used to establish a sequence of processing operations and data flow, including GbE termination with fully formed IP/UDP/RTP packets. Hopefully the above summary is useful. After some discussion here, we feel this type of "start simple" sequence allows us to (i) get a good understanding of how Kamailio and rtpproxy work at a basic level, such that our changes hold up over the long term, and (ii) have a good chance to get feedback and constructive criticism from the group Long-Term Concerns ------------------ Our efforts so far have primarily been customer driven. But as you know we’re worried about correct implementation that meets with approval of the developers’ group, and holds up over the long term. Some of our larger concerns include: (a) Transcoding. What would be the best way to handle scenarios such as (i) Two endpoints that do not have a codec in common, but still want to communicate through a proxy server capable of transcoding. How do we “spoof” one or both endpoints? Or does the proxy somehow “advertise” its capabilities? (ii) Encode only to satisfy need to record at lower bitrate to conserve disk space (iii) Decode only to satisfy lawful interception or other “third party” requirement (b) Incorporating Kamailio / SIP proxy level support for SRTP. Our main area of worry is key management protocol and distribution. Here are a couple of scenarios: (i) A proxy needs to know the encryption keys (one example lawful interception) (ii) One or both endpoints of a call cannot handle SRTP so the proxy must implement encryption/decryption for one or both endpoints Any comments/suggestions on the above will be appreciated. Thanks and Regards, Vikram.

14 years, 9 months

← Newer
1
...
8
9
10
11
12
13
14
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010