sr-users March 2011

sr-users@lists.kamailio.org

83 participants
123 discussions

#!define and #!subst problem
by Klaus Darilion 09 Mar '11

09 Mar '11

Hi! I tried #!subst "/IPADDRESS_VIRTUAL/83.136.32.161/" listen=udp:IPADDRESS_VIRTUAL:5060 and #!define IPADDRESS_VIRTUAL 83.136.32.161 listen=udp:IPADDRESS_VIRTUAL:5060 Both do not work - am I doing something wrong or is this a known limitation with "listen" statements? Thanks Klaus

2 2

dispatcher confusion
by Klaus Darilion 07 Mar '11

07 Mar '11

Hi! Every time I use the dispatcher(k) module I am confused again. Sometimes it seems that "probing" is a dedicated state, sometimes it seems that "probing" is done also in "active" state, but never in "inactive" state. IMO "probing" should only be a flag which indicates if OPTIONS should sent or not. If probing is successful, then the state should be "active". If probing is unsuccessful, then the state should be "inactive". Current behavior is very strange (ds_probing_mode(0)): --> startup state: A --> no probing kamctl fifo ds_set_state i 1 sip:.... --> state: I --> no probing kamctl fifo ds_set_state a 1 sip:.... --> state: A --> no probing calling 3 times ds_mark_dst("p") --> state: P --> probing (and dst is still loaded as last value into the dst_avp, why?) kamctl fifo ds_set_state i 1 sip:.... --> state: I --> still probing kamctl fifo ds_set_state a 1 sip:.... --> state: P (???) --> probing Thus, "ds_set_state a ..." does not set active, but probing if it was probing before. Strange. And as "inactive" does not stop probing when dst was in probing mode, the destination becomes automatically "active" if the probing succeeds. And why is a destination in probing mode loaded into the dst_avp? Very weird. Is there a reason for this behavior? Thanks Klaus

3 4

Kamailio 3.0.4: dispatcher module request
by Klaus Feichtinger 07 Mar '11

07 Mar '11

Hello list, I have a question to the dispatcher module in Kamailio version 3.0.4. In my integration I use this module for distributing calls to a set of gateways (with the round robin algorithm). Sometimes a gateway does not react or send back a negative response. In that case I use the function 'ds_mark_dst("p")' in the failure_route and mark the current destination with the flag 'probing'. I have set the threshhold value for probing mode to '10'. This means that a gateway is effectively set to probing mode only when it was marked with the flag 'probing' for 10 times. However, sometimes a gateway is sending back a negative response for e.g. 5 times and is afterwards working fine - without any problems. A few hours later (e.g.) it is sending a negative reply again for one time. This means: the counter for the probing_flags is increasing every time when the function ds_mark_dst("p") is executed (in case that the process was not restarted in the meantime!). So the problem is, that the counter is reaching the threshhold value at any time and at that moment the gateway is set to probing mode. Even if the gateway has sent a negative reply for only one time (at that moment) - but according the history the proging_flag was set several times. What I miss in this module is a function to _reset_ that flag counter from a REPLY_ROUTE. Note: I have to reset the counter, because the gateway does not yet SIP OPTIONS requests and therefore it is set to 'probing' all time until it is manually set back to active via MI command or after a process restart. According the README file (and practical experience) the function ds_mark_dst() is executable only within the failure_route. However, when I want to set the flag ("a") for the current destination I will do it within a reply_route, but not in the failure_route (because I have received a positive response and not a negative one). From my point of view it does not make sense setting the 'active' flag for a destination from within a FAILURE route. Does anybody have an idea, how the 'flag-counter' could be reset (from within the script)? I do not want to use a MI command..... configuration excerpt: [...] modparam("dispatcher", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "dst_avp", "$avp(AVP_DST)") modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)") modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)") modparam("dispatcher", "ds_ping_from", "sip:proxy@192.168.37.87") modparam("dispatcher", "ds_probing_mode", 0) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "flags", 2) modparam("dispatcher", "force_dst", 1) [...] if (!ds_select_dst("1", "4")) { sl_send_reply("404", "No destination (disp)"); exit; } t_on_failure("failureroute"); t_on_reply("replyroute"); [...] failure_route[failureroute] { [...] if (t_check_status("[45][08]0") || (t_branch_timeout() && !t_branch_replied())) { ds_mark_dst("p"); if (!ds_next_dst()) { t_reply("404", "No destination (disp)"); exit; } t_on_failure("failureroute"); t_on_reply("replyroute"); } [...] } onreply_route [replyroute] { if (t_check_status("180|200") { # nice to have...... # ds_mark_dst("a"); } } Thanks in advance! regards, Klaus

2 4

Siremis Installation - Hangs at Database Configuration Page
by Tim Nelson 07 Mar '11

07 Mar '11

Greetings- I'm attempting an installation of Siremis on a CentOS 5.5 64-bit system running Kamailio 3.1.0. Following the instructions on the wiki [1], I find that I cannot pass step 3 for the database configuration. I've triple checked all of my details are correct and verified the permissions are set appropriately on the Siremis source dir. Also, I've successfully run 'make apache-config' and 'make prepare'. After clicking 'next', I simply get the 'Loading... please wait awhile' graphic. On three different fresh installs, I've waited for 3 hours each. By now, I have to assume it shouldn't be taking this long and there is an error somewhere. The Apache logs don't indicate anything of interest other than a missing favicon. Do you have any ideas? Thank you! --Tim [1] http://kb.asipto.com/siremis:install20:main

1 0

Limit call duration
by Hans Goossens 07 Mar '11

07 Mar '11

Hi, I'm wondering if there is a easy way to limit the call duration in Kamailio ? I would like to automaticaly end the call when the max. duration (for example 12 hours) is reached. In the feature overview of Kamailio 1.5 I found: "option to send BYE when dialog expires" but i'm can't figure out how to get this working (if it's still implemented at all in the current version). Thanks in advance, Kind regards Hans

2 2

about syn_branch
by Juha Heinanen 07 Mar '11

07 Mar '11

we noticed that if sr 3.1 config does not contain syn_branch=0 then acks to 200 oks that are t_relayed by sr, contain branch=0 param in topmost via. in kamailio 1.5, via branch param has proper value even when tm param syn_branch is not set. a couple of questions: 1) according to core cookbook, syn_branch core param only affects stateless forwarding. in my config, all acks are t_relayed, i.e., syn_branch param should not have any effect, but is does. how is that possible? is there a bug in core cookbook? 2) should t_relaying of acks to 200 oks use proper (i.e.. non 0) via branch param even when syn_branch is not set to any value in config? if not why? if yes, will branch=0 be used only when ack to 200 ok does not match any invite transaction? -- juha

2 3

How to access additional xavp's
by Alex Hermann 07 Mar '11

07 Mar '11

Hello, I'm currently toying with xavp's and have some trouble accessing the values. I want to have access to the xavp that isn't the last added one. From the wiki page on http://sip-router.org/wiki/devel/xavp I got the impression that indices are supported, but that doesn't seem to work. In the following fragment i want access to the values 1A & 1B, how to do that? $xavp(test=>a) = "1A"; $xavp(test[0]=>b) = "1B"; $xavp(test=>a) = "2A"; $xavp(test[0]=>b) = "2B"; xlog("$xavp(test[0]=>a)"); xlog("$xavp(test[0]=>b)"); xlog("$xavp(test[1]=>a)"); xlog("$xavp(test[1]=>b)"); pv_xavp_print(); Which gives the following result: Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a38770 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a387c4> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a387c4 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a386c8> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a386c8 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list -- Greetings, Alex Hermann

2 4

Balancing Asterisk
by Andy Lippitt 07 Mar '11

07 Mar '11

Hello all, I've read as many of the asterisk balancing threads as I can find. Either my situation is unusual or I simply haven't understood anything I've read. In short, I'm building an web/phone mashup which uses Asterisk's AGI to get its work done. My only users are on the PSTN connected to Asterisk through a SIP trunk provider. So presently, in and out through the same trunk, apps live on the single Asterisk box. My goal is scaling and failover. I don't have any need for cross talk or transfers between the asterisk instances, and the algo's in dispatcher seem fine. It seems to me that I should be setting the sip-router up a replacement for the existing peer in Asterisk. What leaves me scratching my head is how I then register the sip-router with the upstream provider. Alternatively, if I use the sip-router as an outboundproxy from asterisk (which seems like it's going to take some hacking to make this work in 1.4), doesn't this now mean I have multiple UAC's trying to register for the same name? Can someone set me on the right track? Thanks, Andy Lippitt

2 1

Newly acquired SIP fails authorization from softphone
by Larry Baumbach 06 Mar '11

06 Mar '11

I am a newbie to the world of VIOP. I am attempting to set up an ATA with SIP. I created a SIP at account iptel.com and received an email confirmation stating "We are reserving the following SIP address for you: sip:larry.baumbach@iptel.org". I tried to testing this address in Xlite but got messages saying: "Account failed to enable. Account Iptel could not be enabled. Verify your user ID, password and authorization name. When I set up the SIP account in Xlite I used: UserID: larry.baumbach(a)iptel.org ( I also tried "larry.baumbach" & "sip:larry.baumbach@iptel.org") Domain: sip.iptel.org Password: my password Authorization name: (I left blank as I did not receive any) I can log into SERweb with the same UserID and Password and access my account. What am I doing wrong? Or is there some kind of wait time before my SIP address is activated? I have spent too much time trying to get this to work on my own. Thanks very much for any help you can provide. -- Larry Baumbach 920.358.8695 larry.baumbach(a)gmail.com

2 1

Re: [SR-Users] [sr-dev] planning release of v3.1.2
by Bernhard Suttner 06 Mar '11

06 Mar '11

Hi, whats about: http://sip-router.org/tracker/index.php?do=details&task_id=108 I think that some users are trying to register to an asterisk system. Or does somebody have a solution for that? A new release would be nice!!! Thanks in advance. Best regards, Bernhard ----- Original Message ----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] To: kamailio [mailto:sr-users@lists.sip-router.org], sr-dev [mailto:sr-dev@lists.sip-router.org] Sent: Fri, 28 Jan 2011 20:15:50 +0100 Subject: [sr-dev] planning release of v3.1.2 > Hello, > > I think it is time to release v3.1.2, first date that comes in my mind > is next Thursday if everyone feels it is enough time to take care of > backporting any fix he/she did and it is not yet there. That will > provide us a fresh release for the FOSDEM event. If not, then maybe the > other week, Tuesday, so the participants at the Kamailio Devel training > in Barcelona can practice on it. > > Soon after we should plan also a release for previous stable, branch 3.0. > > Anyone having other options? > > Thanks, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >

2 1

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