sr-users November 2012

sr-users@lists.kamailio.org

85 participants
125 discussions

Dialog module not decrementing profile size

by Grant Bagdasarian

Hello Community, I've recently started to use the Dialog module to manage the amount of incoming calls from our SIP provider allowed to pass through by using profiles_with_values and setting the size of these profiles to a certain amount. Most of the time this works as it should, but sometimes the 'slots' available for a profile aren't cleared even though a dialog has finished. This seems to happen when an high amount of regular traffic is hitting kamailio. Has anyone else experienced this? Are there perhaps any other ways to control the slots available for certain incoming SIP traffic? Below parts of my configuration file. Perhaps I'm doing something wrong which causes this to happen. In my route[WITHINDLG] -> loose_route -> is_method("BYE") I'm not calling dlg_manage(), could this be the problem? Other comments are welcome too, as I'm fairly new to Kamailio. modparam("dialog", "enable_stats", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "hash_size", 4096) modparam("dialog", "profiles_with_value", "318005004"); modparam("dialog", "default_timeout", 43200) modparam("dialog", "dlg_match_mode",2) modparam("dialog", "detect_spirals", 1) request_route { # per request initial checks route(REQINIT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE")) { xlog("L_INFO", "Incoming request for $rU from $fU"); if ($rU == "318005004") { route(DIALOG); } } # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations route(DISPATCH); route(RELAY); } route[DIALOG] { dlg_manage(); record_route(); $var(SIZE) = 0; sql_query("vf", "exec dbo.SelectAvailableSlots '00$rU'", "ra"); $avp(s:limit) = $dbr(ra=>[0,7]); xlog("L_INFO", "Maximum simultaneous calls is configured at $avp(s:limit) ...."); sql_result_free("ra"); if ($rU == "318005004") { get_profile_size("318005004", "$rU", "$var(SIZE)"); } xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, excluding the current call"); if($var(SIZE) >= $avp(s:limit)) { xlog("L_INFO", "Simultaneous calls limit of $avp(s:limit) reached for $rU: $var(SIZE)\n"); sl_send_reply("603", "Simultaneous calls limit reached"); exit; } if ($rU == "318005004") { set_dlg_profile("318005004", "$rU"); } if ($rU == "318005004") { if(get_profile_size("318005004", "$var(SIZE)")) { xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, including the current call"); } } } route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { #Used for call transfer if($fU == "318005004") { if (is_method("UPDATE")) { sl_send_reply("405","Method not allowed"); xlog("L_INFO", "Dropping UPDATE message...\n"); exit; } if (is_method("INVITE")) { record_route(); } if (is_method("BYE")) { dlg_manage(); } } if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; # must be ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard. exit; } } sl_send_reply("404","Not here"); } exit; } } Regards, Grant

11 years, 11 months

Kamailio <-> Asterisk MWI

by Daniel Tryba

I'm trying to get the MWI indicator on endpoints to work by redirecting the SUBSCRIBE to the voicemail server (asterisk) using usc_replace_(to|from). This works fine for the initial request but the next subscribe will fail since the to/from don't get rewritten, which is indicated by the error: ERROR: uac [replace.c:250]: decline FROM replacing in sequential request in auto mode (has TO tag) This occurs when the modparam "uac","restore_mode" is manual or auto. When set to none the redirect will be correct but all responses have to be rewritten manually (I'm a beginner and I don't want to do this just yet). And since uac has knowledge about this having being rewritten, sending the original from/to looks like like a bug to me (more probable a misconfiguration/omission of something crucial withing dialog responses :) Changes to the (default debian package) config, in route route[PRESENCE] in if(is_method("SUBSCRIBE")) if( is_method("SUBSCRIBE")) { if(search_hf("Event", "message-summary", "a")) { if (!www_authenticate("$fd", "subscriber")) { www_challenge("$fd", "1"); exit; } if(avp_db_query("SELECT value FROM usr_preferences WHERE username='$au' and attribute='voicemail' ORDER BY value limit 1")) { $avp(voicemail)=$avp(i:1); $avp(subscrfrom)=$fu; avp_subst("$avp(subscrfrom)", "/sip:.*@/sip:$avp(voicemail)@/"); uac_replace_from("$avp(subscrfrom)"); uac_replace_to("","sip:$avp(voicemail)@$sel(cfg_get.voicemail.srv_ip): $sel(cfg_get.voicemail.srv_port)"); remove_hf("Authorization"); $ru = "sip:" + $avp(voicemail) + "@" + $sel(cfg_get.voicemail.srv_ip) + ":" + $sel(cfg_get.voicemail.srv_port); route(RELAY); } } else { handle_subscribe(); t_release(); } } exit; 192.168.34.226 is the sip device, 192.168.32.40 kamailio, 192.168.32.41 the voicemailserver. Initial request: U 192.168.34.226:5852 -> 192.168.32.40:5060 SUBSCRIBE sip:grandstream@sip.local SIP/2.0. From: "Daniel" <sip:grandstream@sip.local>;tag=67d8f67065827fe2. To: <sip:grandstream@sip.local>. Gets rewritten to: U 192.168.32.40:5060 -> 192.168.32.41:5060 SUBSCRIBE sip:0880100782@192.168.32.41:5060 SIP/2.0. From: "Daniel" <sip:0880100782@sip.local>;tag=67d8f67065827fe2. To: <sip:0880100782@192.168.32.41:5060>. The response gets relayed to the endpoint and MWI will light up since there is a message. But next subscribe update from the endpoint triggers the "decline FROM replacing in sequential request" error and thus the subscribe send to voicemail is the original to/from: U 192.168.32.40:5060 -> 192.168.32.41:5060 SUBSCRIBE sip:0880100782@192.168.32.41:5060 SIP/2.0. From: "Daniel" <sip:grandstream@sip.local>;tag=67d8f67065827fe2. To: <sip:grandstream@sip.local>;tag=as324de8f3. Resulting in a 404 since the to/from are not the real peername on the voicemail server. How do I force Kamailio to rewrite the from/to without doing this manually for a requests/responses (restore_mode none)? The easy way out of this problem would be to have a 1 to 1 relation for the Kamailio subscribers and voicemail peers. But uac_replace should work (somehow). Attached is a full capture of the subscribe/notify. Running 3.3.2+squeeze from http://deb.kamailio.org/kamailio/. Machine is also running topoh module (192.168.0.1). -- POCOS B.V. - Croy 9c - 5653 LC Eindhoven Telefoon: 040 293 8661 - Fax: 040 293 8658 http://www.pocos.nl/ - http://www.sipo.nl/ K.v.K. Eindhoven 17097024

11 years, 11 months

Syntax of xavp

by Andreas Granig

Hi, I'm playing around with xavp, but there are some things I can't wrap my head around. What basically works is this: $xavp(a=>foo) = 'foo'; $xavp(a[0]=>bar) = 'bar'; Getting the value like this: xlog("L_INFO", "a-foo='$xavp(a=>foo)' and a-bar='$xavp(a=>bar)'"); as well as xlog("L_INFO", "a-foo='$xavp(a[0]=>foo)' and a-bar='$xavp(a[0]=>bar)'"); ... works, because when omitting the index, it assumes [0]. I really like to avoid such implicit assumptions though, to make the config really clear, so I prefer the second approach. What doesn't work for me then is explicit assignment of the very first value, like this: $xavp(a[0]=>foo) = 'foo'; $xavp(a[0]=>bar) = 'bar'; If I do this, the "a" xavp is never created. Wouldn't it be good practice to create the xavp on first assignment? That way, I don't have to take care in the config file whether the xavp is used for the first time, where I have to omit the index. What I'm also wondering is whether it's possible to directly access nested xavps, like this: $xavp(a=>foo) = 'afoo'; $xavp(b=>foo) = 'bfoo'; $xavp(c=>a) = $xavp(a); $xavp(c=>b) = $xavp(b); xlog("L_INFO", "a-foo='$xavp(c=>a[0]=>foo)'"); or xlog("L_INFO", "a-foo='$xavp(c=>a=>foo)'"); Both ways give me "a-foo='<<xavp:0x7f0d387fe178>>'". Is this even intended? Would be really cool if that's possible! Thanks, Andreas

11 years, 11 months

NAPTR, SRV and sips vs. transport=tls

by Andreas Granig

Hi, Hope to get some guidance here over the usage of "sips" and "sip plus transport=tls" when following RFC3263. The RFC3263 says that a NATPR record could return something like this for a query like "host -t NAPTR example.com": ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.com IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.com. This means that the client should use sips if possible when contacting example.com. Concluding from that, I suppose it should perform an SRV lookup "host -t SRV _sips._tcp.example.com", and the result would be: ;; Priority Weight Port Target IN SRV 0 1 5061 server1.example.com IN SRV 0 2 5061 server2.example.com What I'm curious about is how requests towards one of these servers should look like, and how they are being handled by kamailio. A lot of clients and servers are sending "sip:user@example.com;transport=tls" in request URIs and Contact headers and Record-Route headers, and you can check with uri_param("transport","tls") which transport socket to use. This is pretty useful as you can determine hop-by-hop whether or not to use TLS. This approach has been obsoleted by RFC3261 though, and there doesn't seem to be a mechanism in RFC3263 to indicate "use schema sip, but use transport=tls". On encounter of a NAPTR record like the one above, how does kamailio act? Does it set a "sips" schema for the next hop? And what's the general take on this "sips" schema? As far as I understand RFC3261, it means that if a client sends a request to a sips-URI, the request is sent to the domain via TLS, and from there "the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee." (RFC3261, Chapter 4). What does this really mean in practice? Are you allowed to rewrite the schema to "sip" and pass it on for example via UDP to the callee if the callee didn't indicate transport=tls (deprecated anyways) or "sips:" in the Contact of the registration? Or should you keep "sips" as schema, but still send it via UDP, because you know based on local policy or based on client registration that the next hop is not supporting TLS? How would widespread clients react when getting a call to a "sips" URI, especially if they receive it via UDP? Looking forward hearing your input on that, Andreas

11 years, 11 months

Kamailio 3.X.X + BLF configuration trouble

by Hemanshu Patel

Hello everyone, Till now we were working with asterisk to handle BLF. But then we decided to move everything to kamailio and hence i started working on BLF with kamailio. I have already configured kamailio for Call handling and presence information. >From different pages on Internet, I have found some information about configuration of kamailio+blf. And i did so, but somehow things are not working as they should. I have done following changes to kamailio.cfg file loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "presence_dialoginfo.so" loadmodule "presence_mwi.so" loadmodule "dialog.so" loadmodule "pua.so" loadmodule "pua_dialoginfo.so" modparam("presence", "fallback2db", 1) modparam("dialog", "dlg_flag", 4) modparam("dialog", "db_url", "mysql://xxxxxxxxx:xxxxxxxxxxxxxx@localhost/openser") modparam("dialog", "db_mode", 1) modparam("pua", "db_url", "mysql://xxxxxxxxx:xxxxxxxxxxxxxx@localhost/openser") Now when my phone(yealink VP530), sends subscribe request it looks as below: SUBSCRIBE sip:1001@172.16.27.66 SIP/2.0 Via: SIP/2.0/UDP 172.16.27.61:5063;branch=z9hG4bK10464096 From: "1000" <sip:1000@172.16.27.66>;tag=393923564 To: <sip:1001@172.16.27.66> Call-ID: 1572901975(a)172.16.27.61 CSeq: 1 SUBSCRIBE Contact: <sip:1000@172.16.27.61:5063> Accept: application/dialog-info+xml Max-Forwards: 70 User-Agent: VP530P 23.70.0.40 Expires: 120 Event: dialog Content-Length: 0 In response to this message, Kamailio returns 202 with following information SIP/2.0 202 OK Via: SIP/2.0/UDP 172.16.27.61:5063;branch=z9hG4bK245273058 From: "1000" <sip:1000@172.16.27.66>;tag=393923564 To: <sip:1001@172.16.27.66>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8ee2 Call-ID: 1572901975(a)172.16.27.61 CSeq: 2 SUBSCRIBE Expires: 120 Contact: <sip:172.16.27.66:5060> Server: kamailio (3.0.0 (i386/linux)) Content-Length: 0 Followed by a NOTIFY NOTIFY sip:1000@172.16.27.61:5063 SIP/2.0 Via: SIP/2.0/UDP 172.16.27.66;branch=z9hG4bK3ccd.adfbc416.0 To: sip:1000@172.16.27.66;tag=2058189864 From: sip:1001@172.16.27.66;tag=a6a1c5f60faecf035a1ae5b6e96e979a-6cd8 CSeq: 1 NOTIFY Call-ID: 2040123403(a)172.16.27.61 Content-Length: 0 User-Agent: kamailio (3.0.0 (i386/linux)) Max-Forwards: 70 Event: dialog Contact: <sip:172.16.27.66:5060> Subscription-State: active;expires=170 During subscribe message asked for XML based reply, yet NOTIFY doesnt send any XML. and hence there is no impact of this message on device. Nothing is changed.Also there's nothing when i call from this device to another, ideally i should get some NOTIFY messages So, i think i am doing something wrong in Configuration. Can anyone please help me in it. If you need any other info, i'll provide you. -- Regards, Hemanshu Patel Senior Software Engg P Help the environment – please don't print this email unless you really need to!

11 years, 11 months

dns resolver issue (RFC3263)

by MÉSZÁROS Mihály

Hi All, I am experiencing an issue when i try to contact xy(a)cisco.com. I found that kamailio/sip-router can't resolve by default resolving way a TCP + SRV records from domain cisco.com. e.g. cisco.com misi@alma:~$ host -t NAPTR cisco.com cisco.com has no NAPTR record misi@alma:~$ host -t SRV _sip._udp.cisco.com Host _sip._udp.cisco.com not found: 3(NXDOMAIN) misi@alma:~$ host -t SRV _sip._tcp.cisco.com _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com. misi@alma:~$ host -t SRV _sips._tcp.cisco.com _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com. I can't call xy(a)cisco.com because it does not exists an NAPTR record in domain cisco.com, and furthermore no SRV with udp. But it exists sip+tcp record and also exists an secure sip SRV, so sips+tcp record! I read rfc3263 I find kamailio dns resolver is not working as it should according RFC3263. http://tools.ietf.org/html/rfc3263 _If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each._ So kamailio should query all (udp, tcp, tls, sctp whatever) protocols. Can anyone help/guide me to create a fix to this issue? My plan is to create a patch to kamailio resolver, to correct and behave according RFC3263. Any help or guidance appreciated! Thanks, Misi

11 years, 11 months

[Kamailio-Users] BYE message not relayed to caller

by Vikram Ragukumar

Hello, My setup includes a cellphone that uses Wi-Fi to hookup to the internet with IP 192.168.1.101. Cellphone app, tries to register with VOIPSwitch through an outbound proxy server(Kamailio + rtpproxy), which rewrites SDP to force rtp through an rtpproxy. I can make a call from the cellphone to a PSTN number. When the PSTN endpoint hangs up, VOIPSwitch relays a BYE message to the proxy that looks like : No. Time Source Destination Protocol Info 27 18.383929 IPaddr_VoipSwitch IPaddr_proxy SIP Request: BYE sip:1234@IPaddr_VoipSwitch Frame 27 (420 bytes on wire, 420 bytes captured) Ethernet II, Src: Unispher_40:b5:39 (00:90:1a:40:b5:39), Dst: Supermic_bd:b9:bc (00:30:48:bd:b9:bc) Internet Protocol, Src: IPaddr_VoipSwitch , Dst: IPaddr_proxy User Datagram Protocol, Src Port: sip (5060), Dst Port: 7160 (7160) Session Initiation Protocol Request-Line: BYE sip:1234@IPaddr_VoipSwitch SIP/2.0 Method: BYE [Resent Packet: False] Message Header Route: <sip:IPaddr_proxy:7160;lr=on;nat=yes> CSeq: 1 BYE Via: SIP/2.0/UDP IPaddr_VoipSwitch:5060; branch=z9hG4bk180242100434182912333954 From: sip:5678@IPaddr_VoipSwitch;tag=18024210041929123187506289 Call-ID: LUOyIDm-ecy36NcUfj5G3v1lM6g5snkM To: "1234" <sip:1234@IPaddr_VoipSwitch>;tag=9XHJmiuf58vTrF7.vwflEK-G63JVPQSi Content-Length: 0 The request URI in the above message is the IP address of VOIPSwitch itself, which causes the proxy to forward the BYE message back to VOIPSwitch. The cellphone never receives the BYE message and consequently never hangs up. Any suggestions on how i can get around this problem ? Thanks and Regards, Vikram.

11 years, 11 months

Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

by SIP Mailing-list

Hi guys, I wonder if someone could sanity check something for me. I currently have a simple load balancer set up using algorithm 10 (call load distribution) from the dispatcher module. I'm using Record-Routing so that I can clear down the call load record at the end of the call. Everything looked like it was working okay until I just spotted a problem that I think might be a bug. It's to do with ACKs to non-200 responses. In a normal call, the flow goes: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 200 OK --- ds_load_update() 4 <-- 200 OK 5 ACK --> 6 ACK --> Now between step 3 and 4 the proxy runs ds_load_update which according to the documentation "set internal state to confirmed for the call load" entry in the internal call state store. This means the proxy knows where to send the ACK at step 5 because it is safely in the call state store so you can use ds_select_dst again on the ACK to get it to the right place. Works fine! Now consider the non-200 case: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 603 Decline --- ds_load_unset() 4 <-- 603 Decline 5 ACK --> 6 ACK --> ??? Between step 3 and 4 the proxy is supposed to run ds_load_unset() which unconditionally removes the call from the call state store. Now when the ACK comes in at step 5, the proxy has no record of the call and so doesn't know where to send the ACK. This results in retried Declines and ACKs. Broken :-( If the proxy doesn't run ds_load_unset() on the 603 response, is there some kind of timer that will cause the call to be removed from the call state store on unconfirmed calls? I don't think I can run ds_load_unset on the ACK because there's nothing in the ACK that tells me it is because of a 603, rather than a 200. Edit: actually there is! The Route header is present on the 200 ACK, but * not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any thoughts would be appreciated! Cheers, Richard

11 years, 11 months

Kamailio v3.3.2 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v3.3.2 stable release is out. This is a maintenance release of the latest stable branch, 3.3, that includes fixes since release of v3.3.1. There is no change to database schema or configuration language structure that you have to do on installations of v3.3.0 or v3.3.1. Deployments running previous v3.x.x versions are strongly recommended to be upgraded to v3.3.2. For more details about version 3.3.2 (including links and hints to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2012/10/kamailio-v3-3-2-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu

11 years, 11 months

LCR Failover

by Daniel W. Graham

I am having issues with LCR failure route. I have two gateways specified in LCR table, if I change the address of the gateway with highest priority to a bogus IP, the failure route never seems to takes place and call is never routed to second gateway. Also, I have tested successful calls to both gateways by switching the priorities around. Here is what I receive after the first gateway times out: U kamailio:5060 -> asterisk:5060 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP asterisk:5060;branch=z9hG4bK633b44d8;rport=5060. From: "user" <sip:user@asterisk>;tag=as67c0037f. To: <sip:dialednumber@domain>;tag=d7177f97ed67076dddc3163c85ab0656-f2e5. Call-ID: 248d69ed6495d0a65315458e2ba6c528@asterisk:5060. CSeq: 102 INVITE. Server: SIP Proxy. Content-Length: 0. Config: modparam("tm", "fr_timer", 10000) modparam("tm", "fr_inv_timer", 120000) modparam("lcr", "db_url", DBURL) modparam("lcr", "gw_uri_avp", "$avp(i:709)") modparam("lcr", "ruri_user_avp", "$avp(i:500)") modparam("lcr", "flags_avp", "$avp(i:712)") modparam("lcr", "lcr_id_avp", "$avp(s:lcr_id_avp)") route[LCR] { if (!load_gws(1)) { sl_send_reply("503", "Internal Server Error, Unable to load gateways"); exit; } else { if (next_gw()) { t_on_failure("LCR_FAIL"); route(RELAY); } else { sl_send_reply("503", "Service Unavailable, No available gateways"); exit; }; }; exit; } failure_route[LCR_FAIL] { if (next_gw()) { t_on_failure("LCR_FAIL"); route(RELAY); } else { t_reply("503", "Service Unavailable, No gateways"); exit; }; exit; }

11 years, 11 months

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