sr-users December 2008

sr-users@lists.kamailio.org

73 participants
108 discussions

[Kamailio-Users] reply_route is not called though a response is received
by Aurelien Grimaud 05 Dec '08

05 Dec '08

Hi, I am running a rather old version of openser, but since in a production context, I cannot upgrade anytime I want to catch up with newer releases. I searched bugs and googled for my problem without any result. There it is. I have a module with functions beginning with mn_ mn_received handle any incoming request and prints it out. my module has a callback on response which prints out responses. My configuration file is something like // handle register mn_received() ; record_route() ; if ( method=="INVITE") { t_on_failure(ROUTE_INVITE) ; t_on_reply(ROUTE_INVITE) ; } Then the request is t_relayed to destination. The onreply_route[ROUTE_INVITE] prints some output, and fix_contact on 200, ... whatever. Then this happens : - An INVITE is received from A (I see it with mn_received) - INVITE is relayed to destination B - B replies 180, I see the response on my module output and I see my onreply_route[INVITE] statements. - B replies 200, I see the response on my module output, but, I *do not* see my reply_route statements. - A sends ACK for INVITE - ACK is relayed to B 2 minutes later (fr_inv_timer), the failure_route[INVITE] is triggered ! Since I use failure routes to manage serial forking, this means openser forward the initial INVITE to the other destination, though first call was established ! Moreover, first call, which seems ok is CANCELED by the openser (I can see a 200 answer to a cancel from B) Openser did not disarm the fr_inv_timer on "200" answer to INVITE ? Openser did not triggered my onreply_route... Has someone already experienced this ? Has someone a clue where it may come from ? - Sometimes it works ok - Sometimes, 180 is not "seen" and 200 is ok - Sometimes 180 is seen but not 200 - Sometimes neither 180, nor 200 are seen - Headers in 180 and 200 are the same except for content - I'm running openser-1.2.0 (ouch !) I'm stuck ! Could this be related to 2008-05-15 10:59 Bogdan-Andrei Iancu, <bogdan at voice-system dot ro> * [r4191] modules/tm/t_reply.c: backport from trunk (rev #4190): - fixed race condition that may lead to deadlock on the transaction lock. As the reply route (t_on_reply()) stored in transaction may be changed in reply route br the current process or any other process, to avoid race conditions, it is better to make a local copy of the reply route number to be sure it will not be changed. The deadlock can appear as the reply route number is used in several conditions to determine id locking is required. But as this value may be changed (by current or other process), it may lead to multiple lockings with no unlock -> deadlock. NOTE: this might happen only if onreply_avp_mode is turned on. Aurelien

2 2

Re: [Kamailio-Users] Failover from SRV lookups?
by Henning Westerholt 05 Dec '08

05 Dec '08

On Thursday 04 December 2008, Geir O. Jensen wrote: > [..] > However, this sounds like it will only solve the problem every other time, > so some calls will go through quicker than the others. I guess our GW > supplier should've used a better solution for their loadbalancing (for > instance anycast) but that is out of my hands. > > Thanks again for the tip, I'll keep it in mind if/when we upgrade... Hi Geir, one other thing would be to not use the SRV records for loadbalancing. I think the dispatcher module has functionality to query configured servers with an options ping, and disable balancing to failed ones. Or you can use the carrierroute module, which gives you complete control over the routing, you can disable then the failed GW with some external scripts. Cheers, Henning

2 1

[Kamailio-Users] callerid openser
by Ricky Gutierrez 04 Dec '08

04 Dec '08

Hi , is possible to negotiate the callerid for each extension with openser? regards rickygm

2 2

Re: [Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 04 Dec '08

04 Dec '08

Hello, I tried all the ways you told : I moved the SIP phone at home, which I don't have any firewall and it does not pass through the entreprise fw. so the SIP phone is directly connected to the proxy. it registers well, no pbm, but the problem stay. Impossible to make a call to the Thomson. INVITE from any SIP phone (hard or soft, I tried with a Linksys, then a SJ Phone) through Kamailio is not going to the Thomson. All the others SIP stuff are working (Linksys to SJ Phone, ...). I tried many configuration changes into the Thomson ST2030, unsuccessfully. I mean it's not a NAT problem ... Here you are the SIP messages in the kamailio debug from SJ Phone (0123451011) to the f***in' Thomson (0123451014) : Dec 1 20:49:36 kamailio[29592]: -> incoming SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 70 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 Dec 1 20:49:36 kamailio[29592]: -> outgoing SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 69 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 In the attached file, the full kamailio debug level 9. It seems that nothing is coming to the Thomson (I don't have any hub where I can sniff the frames). "The truth is out there" ... :/ .desperate house Sam. On Mon, Dec 1, 2008 at 1:44 PM, Samuel Muller <sml(a)720.fr> wrote: > many thanks Klaus, > > I'll check tonight at home, and will reply to you after. > > sincerely, thanks ! > > .Sam. > > > > > On Mon, Dec 1, 2008 at 1:28 PM, Klaus Darilion < > klaus.mailinglists(a)pernau.at> wrote: > >> Hi Samuel! >> >> The INVITE sent from Kamailio to Thomson phone does not trigger any >> response. There are various possible reasons: >> >> 1. INVITE is ignored by Thomson phone >> 2. INVITE does not make it thorugh to the Thomson phone >> 2.1 either sent to the wrong port >> 2.2 or the NAT binding time out, thus NAT does not forward correctly >> >> Thus, verify if the INVITE is received by the NAT device and forwarded to >> the Thomson phone (e.g. putting a hub between the NAT router and the phone). >> REGISTER with the Thomson phone and then immediately after call it >> (linksys->thomson) - this should work as the binding should be alive just >> after the registration. >> >> The problem could also be caused by a buggy NAT router or VPN client or >> firewall ALGs. >> >> To further debug this issue you could also try the Thomson phone with >> another VoIP service (e.g. iptel.org or ekiga.net) or try the Thomson >> phone from another access (e.g. try it at home bypassing your company >> FW/NAT). >> >> You could also try to avoid port 5060, e.g. Put the proxy on port 5678 and >> also use other ports locally for the SIP clients. SIP ALGs (application >> level gateways) usually are triggered by port 5060. >> >> regards >> klaus >> >> >> Samuel Muller schrieb: >> >>> >>> >>> On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion < >>> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> >>> wrote: >>> >>> >>> >>> Samuel Muller schrieb: >>> >>> Hey Klaus, >>> >>> first, some answers : >>> >>> -> when a thomson is the callee, there's no ringing even if >>> indicated into the SIP message. >>> -> when a thomson is the caller, no problem, there's a ring, and >>> the call is ok with audio. >>> >>> >>> Please be a bit more specific: What does "no ring" mean? >>> No "180 ringing" response from callee to caller? >>> "180 ringing" response but no "ring-back" at the caller's client? >>> >>> >>> oups, sorry, I mean : SIP messages are ok, there is all the sig process. >>> >>> the architecture is : >>> linksys + thomson -> cisco 827 -> SDSL -> our backbone which have a >>> firewall for VPN (so NAT and NAPT are applied here), then the kamailio with >>> a public ip. >>> >>> you have the 100 trying, 180 ringing in the SIP message, but there's no >>> ring-back tone for the callee. >>> >>> in the attached file : >>> linksys to linksys, where all the call process is ok (sip + rtp) >>> thomson to linksys, idem >>> linksys to thomson, sip ok but rtp apparently not. >>> I forgot the firewall for the vpn, rtp proxying is required, sorry - so >>> yes rtp proxy must be used. >>> >>> regards, >>> >>> .Sam. >>> >>>

2 2

Re: [Kamailio-Users] Kamailio 1.4.1 fails at startup
by Henning Westerholt 04 Dec '08

04 Dec '08

On Thursday 04 December 2008, Arturo Díaz Almagro wrote: > Hi Henning, > > Forget the last mail. This is the configuration and the output log. I got a > segmentation fault in the pdt module: > [..] > Dec 4 13:28:37 mediaGW kamailio[9082]: DBG:db_text:dbt_load_file: > column[0] is INT! > > This error is gotten with kamailio 1.4.1 and 1.4.2. If I comment out the > modparam lines configuring pdt module kamailio starts up correctly. Hi Arturo, do you get a core dump from the segmention fault? If not, please enable the core dumping (e.g. with ulimit -c unlimited), and send me the backtrace when you examine the dump with gdb. As alternative you could also send me the DB contents that leads to the crash with private mail. Cheers, Henning

1 0

Re: [Kamailio-Users] lost path
by Daniel-Constantin Mierla 04 Dec '08

04 Dec '08

Hello, please post such questions to users mailing lists (cc-ed). Cheers, Daniel On 12/04/08 01:18, Waseem Besada wrote: > Hi > > I highly appreciate your help to solve the error I get when I try to > create a database. It seems that path to standard-create.sql is not > set probably and I'm lost how this can be fixed. > > Thank you in advance, > /Waseem > > linux-0g00:/usr/local/sbin # ./kamdbctl create > MySQL password for root: > INFO: test server charset > INFO: creating database openser ... > /usr/local/lib64/kamailio/kamctl/kamdbctl.mysql: line 155: > ./mysql/standard-create.sql: No such file or directory > ERROR: Creating core tables failed! >

1 0

[Kamailio-Users] Kamailio 1.4.1 fails at startup
by Arturo Díaz Almagro 03 Dec '08

03 Dec '08

Hello all, I am defining a little script for Kamailio working as a simple forwarder (doing some simple tasks sometimes). I have to use an static database with few rows of PDT data so I decided to use a text database via db_text module. The scripts seems to ok because I do not get any error message from start up logging but kamailio processes are not there!! Moreover, I am not making use of the functions in the script, only initialization!! I am using kamailio-1.4.1-notls and these are the script lines defining the initialization of those modules. Thanks a lot. ####### Global Parameters ######### debug=3 log_stderror=no fork=yes children=7 #KAMAILIO_CHILDREN /* uncomment the next line to disable TCP (default on) */ disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:172.16.10.1:5060#KAMAILIO_PROTO:KAMAILIO_IP:KAMAILIO_PORT port=5060 #KAMAILIO_PORT /* domain alias for the host */ alias=domain1.com #KAMAILIO_DOMAIN # global domain alias=domain2.com ####### Modules Section ######## #set module path mpath="//lib/kamailio/modules/" loadmodule "db_text.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "path.so" loadmodule "pdt.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- modparam("pdt|avpops", "db_url", "text:///tmp/kamailio_db") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) #modparam("rr", "append_fromtag", 0) # ----- path params ----- modparam("path", "use_received", 0) # ----- dbtext ----- modparam("db_text", "db_mode", 0) # ----- pdt params ----- modparam("pdt", "db_table", "pdt") modparam("pdt", "sdomain_column", "sdomain") modparam("pdt", "prefix_column", "prefix") modparam("pdt", "domain_column", "domain") ####### Routing Logic ######## [..] -- Arturo Díaz

2 2

[Kamailio-Users] How are computed $Tf and $Ts?
by Iñaki Baz Castillo 03 Dec '08

03 Dec '08

Hi, it doesn't make sense: xlog("L_INFO","--- time pre http: $Tf - $Ts\n"); http_query("/test1.html", "r_uri=$(ru{s.escape.param})&f_uri=$(fu{s.escape.param})", "$var(result)"); xlog("L_INFO","--- time post http: $Tf - $Ts\n"); I always get: --- time pre http: Mon Nov 24 14:37:25 2008 - 1227533845 --- time post http: Mon Nov 24 14:37:25 2008 - 1227533845 Of course it's just impossible that the http query takes 0.000 seconds. I could use 'benchmark' module fot this stuf, but I wonder why $Tf returns the same value in any place of the script. Maybe it is just computed at the script start for each message? Thanks. -- Iñaki Baz Castillo

2 4

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?
by Frank Durda IV 03 Dec '08

03 Dec '08

Jeroen van Bemmel wrote: > Frank, > > RFC3261 specifically specifies that proxies should convert response code > 503 into 500: > > A proxy which receives a 503 (Service Unavailable) response > SHOULD NOT forward it upstream unless it can determine that any > subsequent requests it might proxy will also generate a 503. > In other words, forwarding a 503 means that the proxy knows it > cannot service any requests, not just the one for the Request- > URI in the request which generated the 503. If the only > response that was received is a 503, the proxy SHOULD generate > a 500 response and forward that upstream. > > So SER is behaving in accordance with the standard. There might be a > configuration option to turn this off? Well, yes and no. Thanks for pointing out this item in the RFC which I missed, but if the RFC action is honored, then SER should have emitted "500 Server Internal Error" which is in the RFC, and not the hybrid and made-up "500 Service Unavailable", which is not in the RFC. So, I think SER is wrong at least on that point. (Personally I think SIP desperately needs at least 20 additional defined Response Codes so we can all quit using the existing not-entirely-inappropriate values to cover real-life situations, but right now the book says that's all the codes that we've all got to work with. When you see a dozen SS7 release codes all map to the same SIP Response Codes, you don't have nearly enough SIP Response Codes, but I digress.) That said, our SER server knows the given condition sent from a paired PSTN switch is permanent, eg the SIP caller can't call this number via our network now, tomorrow or next week because of who you they or whom their provider is (or what they failed to buy), so in this situation returning 503 all the way out of our network is correct behavior (as stated in the RFC), and doing so allows the upstream entity to click over to the next preferred carrier that might reach that destination. We have found that many SIP providers simply blindly lob all calls at the cheapest carrier and if a given call bounces, repeat that action with the next-cheapest carrier, and the next until they finally resort to a Tandem that will take anything, but will also be the most expensive way to route the call. Nearly all require us to send them back a 503 (a few want us to send 502 back instead) to say back to them "not via here, try next door". Deplorable and this method certainly causes slow call set-up times, but that is what quite a few of these outfits are doing. So, our SER must send them back a 503 and not a 500 in this situation. If I explicitly state one in a reply rule, will that override this default behavior, or will some deeper part of SER veto even a sl_reply("503", "Service Unavailable"); added to the onreply_route? If so, where is this piece of source code, so that I may break this well-intended but undesired behavior?

5 8

[Kamailio-Users] important: pseudo-variables moved to pv module
by Daniel-Constantin Mierla 03 Dec '08

03 Dec '08

Hello, please note that pseudo-variables implemented in core for kamailio/openser versions <= 1.4.x are now moved in pv module. This is part of cleaning up the core, in order to keep it slimmer and less exposed to bugs. There are modules and use cases that need no PVs, therefore no need of keeping the implementation of about 100 PV in core. Now the core includes only an API that allows to: - register PVs from modules - parse PV names in config script, evaluate PVs, assign values to PVs $shv() - shared variables, and $time() - broken down time, were moved from cfgutils module to pv module ($shv() depends on $var()). To summarize, if you need $ru, $avp(...), $var(...), a.s.o. in your config file you have to load pv module from now on with devel version and upcoming stable releases. Two new pseudo-variables were introduced with this occasion, $TS and $TF, see more: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#string_form… http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#unix_time_s… Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

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