sr-users April 2011

sr-users@lists.kamailio.org

64 participants
105 discussions

meeting in thailand bangkoke
by Meftah Tayeb 03 Apr '11

03 Apr '11

hi guys i'm in thailand right now this week i'm staying in bangkoke anyone want to meet please drop me an email thank you -- Meftah Tayeb inum: +883510001288000 phone: +13477595883

1 0

Setting Global Variables
by Nathaniel L Keeling 02 Apr '11

02 Apr '11

Hello, I am trying to use global variables within my configuration script. I am using Kamailio v3.0.0 and I am following the syntax example written in the sample config file but I keep getting syntax errors. Here is a copy of my syntax and I am using cfg_get.voicemailserver.bindip to get the value. #!ifdef WITH_VOICEMAIL voicemailserver.bindip = "10.0.0.1" desc "Voicemail Server IP Address" voicemailserver.bindport = "5060" desc "Voicemail Server Port" #!endif Here is the error that I am receiving: 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: syntax error 0(1875) : <core> [cfg.y:3333]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 17: unknown config variable 0(1875) : <core> [cfg.y:3330]: parse error in config file /usr/local/kamailio-3.0.0/etc/kamailio/kamailio.cfg, line 156, column 19-28: ERROR: bad config file (3 errors) 0(1875) DEBUG: <core> [mem/shm_mem.c:236]: shm_mem_destroy Thanks Nathaniel

1 0

Avpops problem - bad avp flags.
by Ricardo Martinez 01 Apr '11

01 Apr '11

Hello. I’m having a problems using the avpops with the kamailio version 3.1.2 I have the next configuration: modparam("avpops", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("avpops", "avp_table", "usr_preferences") ----- route[REQINIT] { if( !(avp_db_load("pike", "s:ip_origen") && avp_check("s:ip_origen", "eq/$src_ip/gi")) ) { … } mysql> select * from usr_preferences; +----+------+----------+--------+-----------+------+---------------+---------------------+ | id | uuid | username | domain | attribute | type | value | last_modified | +----+------+----------+--------+-----------+------+---------------+---------------------+ | 1 | pike | 0 | | ip_origen | 0 | 100.20.100.20 | 1900-01-01 00:00:01 | +----+------+----------+--------+-----------+------+---------------+---------------------+ 1 row in set (0.00 sec) When I try to start kamailio I’m getting the next error : Apr 1 10:36:08 kamailio[15418]: ERROR: avpops [avpops_parse.c:129]: error - bad avp flags Apr 1 10:36:08 kamailio[15418]: ERROR: avpops [avpops.c:299]: parse failed Apr 1 10:36:08 kamailio[15418]: ERROR: <core> [route.c:1161]: fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:238 Apr 1 10:36:08 kamailio[15418]: ERROR: <core> [route.c:1161]: fixing failed (code=-1) at cfg:/usr/local/etc/kamailio/kamailio.cfg:263 I can’t find the problem. Can someone help me? Regards. Ricardo.-

2 1

The SIP protocol v2 - we're giving up.
by Olle E. Johansson 01 Apr '11

01 Apr '11

Friends, After having spent many years working with the Asterisk SIP channel driver, Kamailio and the SIPv2 protocol, I have finally realized that this is a dead end. It's getting nowhere and it's way too complicated to set up, run and support in working code. After realizing this, I started a new standardization project together with my friends in Canada, Simon and Marc, to develop a working solution based on the combination of IPv6 and SIP. We have gotten great feedback and now the IETF, the ITU and the IPv6 forum jointly launches the new standard, SIP-six. From the press release: "”We realize that 99% of the SIP users use SIP for PSTN phone calls. The original SIP standards was written with other applications in mind, a vision that never came true.” said Bob Plug, area director in the IETF. ”That’s why we sat down and said to ourselves that this should be way more simple.” The SIP-six standard totally removes the dependency of domains and URI syntax. There’s no point in using this, since everyone seems to think that IP addressing is more than enough. The new standard use part of the vast IPv6 address space to incorporate the E.164 phone numbers as addresses. This is the reverse of the reverse phone number usage in the enum standard, which is no longer needed in SIP-six. By using IPv6 mobile IP, phone users register their phones and get access to their phone number. Users that need security can easily integrate IPsec into their setup. Media and signalling uses the same addressing scheme and is mixed so that both SIP-six, RTP and RTCP only uses one port address - but in this case a port address with 32 bit subaddress identifying the media stream. This finally solves a lot of the firewall traversal issues that SIP v2.0 had. With the combination of mobile IP and use of public IPv6 addresses NAT traversal won’t be an issue. The testbed for SIP-six has been running for a year at six choosen large SIP carriers, with the assistance of Edvina AB in Sweden and ViaGenius in Montreal, Canada. In an International effort, the testbed is today put in production and Roboid phones all over the world is automatically connected to this worldwide network." You will be able to find out more about it here: http://bit.ly/sipsix SIP-six is implemented as a channel driver in Asterisk 2.0, as a replacement for SIP2.0 in Kamailio 4.0 and a channel module in FreeSwitch - all releases to be released later today. Softphones for testing will shortly be available from Blink and Zoiper. Looking forward to continue this project with the rest of the Kamailio/SIP-router community! Special thanks to Daniel for the reference implementation in Kamailio 4.0! Have a nice weekend! /Olle

7 7

valgrind errors from 3.1-stable (git 2fe4d633e4ac)
by Timo Teräs 01 Apr '11

01 Apr '11

Hi all, I'm running 3.1-branch git head currently under valgrind. And I've seen several invalid reads and writes (apparently most are off by one). ==22274== Invalid read of size 1 ==22274== at 0x6DA2C0A: pv_set_ruri_user (pv_core.c:1755) ==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357) ==22274== by 0x13BF0F: lval_assign (lvalue.c:405) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x13A86F: run_actions_safe (action.c:1607) ==22274== by 0x1E2666: rval_get_int (rvalue.c:904) ==22274== by 0x1E5252: rval_expr_eval_int (rvalue.c:1866) ==22274== by 0x131B8A: do_action (action.c:1071) ==22274== by 0x13A6F1: run_actions (action.c:1555) Is fairly obvious. modules_k/pv/pv_core.c has several places which take backup of "val->rs.s[val->rs.len]" and replaces it with zero for string termination. It's than later on set back to the original value. However, it would appear that the value passed does not always point to a memory area which is large enough. This results in multiple invalid reads and writes of one. The remaining reads are not so clear to me. ==22274== Invalid read of size 1 ==22274== at 0x4811A69: strncpy (mc_replace_strmem.c:339) ==22274== by 0x6DA77FF: set_var_value (pv_svar.c:122) ==22274== by 0x6DA1EDB: pv_set_scriptvar (pv_core.c:1636) ==22274== by 0x13BA15: lval_pvar_assign (lvalue.c:357) ==22274== by 0x13BF0F: lval_assign (lvalue.c:405) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x131E05: do_action (action.c:1086) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x131E05: do_action (action.c:1086) ==22274== Invalid read of size 2 ==22274== at 0x4811E1F: memcpy (mc_replace_strmem.c:523) ==22274== by 0x1E134D: rval_new_str (rvalue.c:269) ==22274== by 0x1E394E: rval_convert (rvalue.c:1301) ==22274== by 0x1E4780: rval_str_add2 (rvalue.c:1610) ==22274== by 0x1E8681: rval_expr_eval (rvalue.c:2399) ==22274== by 0x13BBD9: lval_assign (lvalue.c:389) ==22274== by 0x139E4D: do_action (action.c:1472) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x12FDEB: do_action (action.c:711) ==22274== by 0x13A6F1: run_actions (action.c:1555) ==22274== by 0x139229: do_action (action.c:1342) ==22274== by 0x13A6F1: run_actions (action.c:1555) Any ideas how to fix these? Or any instructions what to provide more in the bug report? Cheers, Timo

3 7

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 April 2011