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