sr-users March 2009

sr-users@lists.kamailio.org

92 participants
149 discussions

Re: [Kamailio-Users] handling of DNS-SRV in kamailio-1.4.3 & 1.5.0

by Klaus Feichtinger

Hello Daniel, I've done several test with different scenarios: 1) including 4 hosts in the answer of the SRV reply message; the 1st and 2nd host are unreachable, the third an fourth are reachable - the SIP message never reached the target (= host 3) 2) including 4 hosts in the answer of the SRV reply message; the SIP service is not running on the first and second host; the third and fourth have the service activated - the SIP message is transmitted to the second host after the fr_timeout of the TM module, but is not forwarded to the target (= host 3); it is retransmitted to host 2 until SIP timeout The conclusion is: when only on master and slave are in the answer of the SRV reply message it works fine. But starting with the third host the service hangs on the second host and does not try reaching an alternative target (as listed in the SRV response). In the syslog I can only see entries like this (but no ERROR message): Mar 9 15:36:21 lennysrv /usr/local/sbin/kamailio[25041]: DBG:core:mk_proxy: doing DNS lookup... Mar 9 15:36:21 lennysrv /usr/local/sbin/kamailio[25041]: DBG:core:a2dns_node: storing kamailio2.test.loc:5080 Mar 9 15:36:21 lennysrv /usr/local/sbin/kamailio[25041]: DBG:core:a2dns_node: storing kamailio3.test.loc:5060 Mar 9 15:36:26 lennysrv /usr/local/sbin/kamailio[25043]: DBG:core:mk_proxy: doing DNS lookup... Mar 9 15:36:28 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:is_3263_failure: dns-failover test: branch=0, last_recv=408, flags=1 Mar 9 15:36:28 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:t_should_relay_response: trying DNS-based failover Mar 9 15:36:28 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:do_dns_failover: new destination available Mar 9 15:36:31 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:is_3263_failure: dns-failover test: branch=1, last_recv=408, flags=1 Mar 9 15:36:31 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:t_should_relay_response: trying DNS-based failover Mar 9 15:36:31 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:do_dns_failover: new destination available Mar 9 15:36:34 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:is_3263_failure: dns-failover test: branch=2, last_recv=408, flags=1 Mar 9 15:36:34 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:t_should_relay_response: trying DNS-based failover Mar 9 15:36:34 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:do_dns_failover: new destination available Mar 9 15:36:37 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:is_3263_failure: dns-failover test: branch=3, last_recv=408, flags=1 Mar 9 15:36:37 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:t_should_relay_response: trying DNS-based failover Mar 9 15:36:37 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:do_dns_failover: new destination available Mar 9 15:36:40 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:is_3263_failure: dns-failover test: branch=4, last_recv=408, flags=1 Mar 9 15:36:40 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:t_should_relay_response: trying DNS-based failover Mar 9 15:36:40 lennysrv /usr/local/sbin/kamailio[25047]: DBG:tm:do_dns_failover: new destination available Mar 9 15:36:43 lennysrv /usr/local/sbin/kamailio[25045]: DBG:tm:is_3263_failure: dns-failover test: branch=5, last_recv=487, flags=1 The syslog output seems to be okay, because kamailio theoretically makes a dns_failover. But practically it is only sent to the first and second target. Do you have any other idea what could be wrong? I haven't found any specific parameters that could influence this behaviour of kamailio.... regards, Klaus F. -------- Original-Nachricht -------- > Datum: Fri, 06 Mar 2009 10:59:28 +0200 > Von: Daniel-Constantin Mierla <miconda(a)gmail.com> > An: Klaus Feichtinger <klaus.feichtinger(a)gmx.net> > CC: users(a)lists.kamailio.org > Betreff: Re: [Kamailio-Users] handling of DNS-SRV in kamailio-1.4.3 & 1.5.0 > Hello, > > On 03/05/2009 02:51 PM, Klaus Feichtinger wrote: > > Hello, > > > > I have to relay SIP requests to a special "redundant" destination (= > FQDN - e.g. "test.kamailio.loc") that consists of 3 hosts with different > priorities. > > > > After startup Kamailio creates a DNS-SRV request to the DNS server and > receives a response with following answer (e.g.): > > _sip._udp.test.kamailio.loc: type SRV, class IN, priority 10, weight > 100, port 5060, target host1.test.kamailio.loc > > _sip._udp.test.kamailio.loc: type SRV, class IN, priority 20, weight > 90, port 5060, target host2.test.kamailio.loc > > _sip._udp.test.kamailio.loc: type SRV, class IN, priority 30, weight > 80, port 5060, target host3.test.kamailio.loc > > > > In worst case - if the prime and secondary host (host1 and host2) are > unavailable - I expect that kamailio tries relaying the request to the third > host in the list. But it doesn't. It makes retransmission of the original > invite to the second host and does not try reaching the third host. > > > > For tuning the switchover to the alternative target(2) I have set the > module parameter "fr_timer" for TM to 3 seconds (modparam("tm", "fr_timer", > 3)). > > > > > > Is this behaviour of Kamailio-1.4.3 and Kamailio-1.5.0 (I've tested it > with both versions) as expected (= limited to support only two answers in a > DNS SRV reply)? Does anybody have experience with this scenario? Can > anybody give me a hint? > > > should be no such limitation. If you try with 4 hosts what happens? Do > you get any errors in the syslog? > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

15 years, 8 months

[Kamailio-Users] t_relay with result code -6 creates transaction

by jh＠tutpro.com

i was playing with t_relay and tcp and noticed that when forwarding to a tcp contact fails, transaction is still created although README says: * 0x02 - do not internally send a negative reply in case of forward failure (due internal error, bad RURI, bad message, etc). When a forward failure occurs, no SIP request is relayed and therefore no negative reply or timeout will show up on the failure_route (if one is set). It applies only when the transaction is created. By default one negative reply is sent. Useful if you want to implement a serial forking in case of failure. and In case of error, the function returns the following codes: ... * -6 - generic send failed while testing this i had two contacts with different q values: Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_load_contacts: loaded contact <sip:test@192.98.101.10:5074#012#012#012udp:192.98.101.10:5060#0120#012d> with q_flag <0> Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_load_contacts: loaded contact <sip:jh@192.98.101.10:5555;transport=tcp#012#012#012#01216#0124> with q_flag <4> i then called next_contacts() followed by t_relay("0x03") and tested the result: while (1) { xlog("L_INFO", "INFO: Routing initial $rm to <$ru> and <$bR>\n"); t_relay("0x03"); switch ($retcode) { case 1: xlog("L_INFO", "INFO: retcode is <1>\n"); exit; case -1: case -2: case -3: sl_reply_error(); exit; case -4: xlog("L_INFO", "INFO: retcode is <-4>\n"); case -5: xlog("L_INFO", "INFO: retcode is <-5>\n"); case -6: xlog("L_INFO", "INFO: retcode is <-6>\n"); if (!t_next_contacts()) { send_reply("480", "Temporarily Unavailable"); exit; }; }; }; i got to syslog: Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_next_contacts: entering next_contacts WITHOUT transaction Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_next_contacts: R-URI contact is <sip:jh@192.98.101.10:5555;transport=tcp#012#012#012#01216#0124> Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: INFO: Routing initial INVITE to <sip:jh@192.98.101.10:5555;transport=tcp> and <<null>> Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:core:tcp_blocking_connect: poll error: flags 18 Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:core:tcp_blocking_connect: failed to retrieve SO_ERROR (111) Connection refused Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:core:tcpconn_connect: tcp_blocking_connect failed Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:core:tcp_send: connect failed Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:tm:msg_send: tcp_send failed Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: ERROR:tm:t_forward_nonack: sending request failed Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: INFO: retcode is <-6> the first debug line above is a new one that i added to the beginning of next_contacts(): t = get_t(); if (!t || (t == T_UNDEFINED)) { LM_DBG("entering next_contacts WITHOUT transaction\n"); } else { LM_DBG("entering next_contacts WITH transaction\n"); } then the script goes on and calls t_next_contacts()/t_relay("0x03") again and now i get: Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_next_contacts: entering next_contacts WITH transaction Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: DBG:tm:t_next_contacts: next branch contact is <sip:test@192.98.101.10:5074#012#012#012udp:192.98.101.10:5060#0120#012d> Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: INFO: Routing initial INVITE to <sip:jh@192.98.101.10:5555;transport=tcp> and <<sip:test@192.98.101.10:5074>;q=0> Mar 10 06:50:07 taimen /usr/sbin/kamailio[18101]: INFO: retcode is <1> how is it possible that the transaction was created even when the first t_relay failed with result code -6? this example should prove that scripting tm like this NOT user friendly and prone to errors. -- juha ps. i think we agreed earlier that failing forward to a tcp contact is NOT an error and should not be printed to syslog as an error.

15 years, 8 months

[Kamailio-Users] bug in subscribe when contact uses tcp transport?

by jh＠tutpro.com

> The modules from 1.5 should work out of the box with 1.4. My plan is to > test them a while in 1.5 and backport before next minor release > 1.4.x. daniel, unfortunately the above does not seem to be true. when i copy presence module from 1.5 and try to make it, i get make[1]: Entering directory `/usr/src/4.1-src/openxg-kamailio/modules/presence' publish.c:46:26: error: ../../cmpapi.h: No such file or directory Compiling bind_presence.c ... Compiling notify.c gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls -DMOD_NAME='"presence"' -DNAME='"kamailio"' -DVERSION='"1.4.3-tls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:5638M"' -DUSE_TLS -DUSE_SCTP -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/local/ssl/include -I/usr/local/include -I/usr/include/openssl -I/usr/include/libxml2 -I/usr/local/include/libxml2 -I/usr/local/include -c notify.c -o notify.o notify.c: In function ??get_p_notify_body??: notify.c:728: error: ??EVENT_DIALOG_SLA?? undeclared (first use in this function) notify.c:728: error: (Each undeclared identifier is reported only once notify.c:728: error: for each function it appears in.) -- juha

15 years, 8 months

[Kamailio-Users] bug in subscribe when contact uses tcp transport?

by jh＠tutpro.com

if user subscribes using tcp transport, kamailio presence server replies with 200 ok where contact specifies udp transport. this looks like a bug to me, because re-subscribe to contact uri then uses udp transport, which may not even be enabled by firewall between ua and kamailio. do others agree that this is a bug? if so, any volunteers to fix it? -- juha +++ 6-3-2009 10:27:39.692364 INFO SIP ::send_sip_tcp Send to: tcp:192.98.101.10:5060 SUBSCRIBE sip:test@test.fi SIP/2.0 Via: SIP/2.0/TCP 192.98.101.10:5074;rport;branch=z9hG4bKrzmiknas Max-Forwards: 70 To: <sip:test@test.fi> From: "Juha Heinanen" <sip:jh@test.fi>;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Contact: <sip:jh@192.98.101.10:5074;transport=tcp> Accept: application/pidf+xml Event: presence Expires: 3600 User-Agent: Twinkle/1.4.1 Content-Length: 0 +++ 6-3-2009 10:27:39.707261 INFO SIP ::process_sip_msg Received from: tcp:192.98.101.10:5060 SIP/2.0 202 OK Record-Route: <sip:192.98.101.10;r2=on;lr> Record-Route: <sip:192.98.101.10;transport=tcp;r2=on;lr> Via: SIP/2.0/TCP 192.98.101.10:5074;received=192.98.101.10;rport=54705;branch=z9hG4bKrzmiknas To: <sip:test@test.fi>;tag=3d2810ff0e005fca9b24aee8694a9a3d-a5a3 From: "Juha Heinanen" <sip:jh@test.fi>;tag=gonhy Call-ID: ljkaayblocflyyu@taimen CSeq: 62 SUBSCRIBE Expires: 3600 Contact: <sip:192.98.101.10:5082> Server: OpenXg Kamailio (1.5.0-pre2-tls (i386/linux)) Content-Length: 0

15 years, 8 months

[Kamailio-Users] Forget about my first mail..

by Sara EL KABIRI

The mysql database problem is solved, but i have now another problem... I'm sending a second mail... Sorry for the spam.

15 years, 8 months

[Kamailio-Users] Problem starting Kamailio

by Sara EL KABIRI

Hello, I've installed kamailio 1.4.3 (without tls) on ubuntu by following the provided INSTALL guide. I want to use it as a presence server but i've got some problems creating the MySQL database: I got this error : *ERROR* *1105* (HY000): *MyISAM* *table* ‘version′ *is* *in* *use* (*most* * likely* *by* *a* *MERGE* *table*). *Try* *FLUSH* *TABLES*… Could anyone help please? -- Sara

15 years, 8 months

[Kamailio-Users] lcr-module, ping and load_gws_from_grp (kamailio 1.5)

by Stefan Prelle

Hi, I just noticed something weird when working with the lcr module. My setup has 5 gateways - 4 in group 1, one in group 2. The lcr-table has an entry for each group, both reacting on the same prefix. I am using load_gws_from_grp("1") to get a gateway for a target. This usually works fine. If now all 4 gateways in group 1 ar disabled because the alive check failed, load_gws_from_grp("1") returns the gateway from group 2 (or other groups where the prefix from the lcr-table matches. I would consider this a bug, since I explicitly requested gateways from a specific group. Regards, Stefan

15 years, 8 months

[Kamailio-Users] Send a status from reply route

by Kévin L'heveder

Hi, I work with Kamailio as Proxy and a call manager. From a MI_datagram script I manage kamailio. My script check the current data rate on different links. So if the max data rate is reached my script must cancel the call. That works good because I can use t_reply or sl_send_reply from request route and send cancel or status error. But in one case I need to cancel the call after receiving the trying (after INIVTE) from the call manager (because the call manager could preempt a call to free some space one the link) My trouble is that i can't use t_reply or sl_send _reply from REPLY_ROUTE and to cancel the call properly i need to send a status error, so i can't use t_uac_dlg from my management interface (because this function sends request only). I didn't find out a solution to do this, so is someone have one ...? Thanks, Koon _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

15 years, 8 months

[Kamailio-Users] AUTO: Miodrag Radulovic is out of the office (returning 16-03-2009)

by Miodrag Radulovic

I am out of the office until 16-03-2009. Privremeno nedostupan - Out-of-Office Message. Poruka koju ste poslali je prispela i bice sacuvana, napominjem da je za vreme mog puta pristup elektronskoj posti veoma ogranicen. The message that you have sent will be saved in my inbox, but please note that I will be out of the country and my access to my email will be very limited. Miodrag Radulovic General Manager COMUTEL Note: This is an automated response to your message "Users Digest, Vol 46, Issue 27" sent on 9.3.2009 4:07:38. This is the only notification you will receive while this person is away.

15 years, 8 months

[Kamailio-Users] reseting of t_on_branch, t_on_reply and t_on_failure

by jh＠tutpro.com

i have noticed that i need to call again t_on_branch, t_on_reply and t_on_failure in failure route before calling again t_relay, i.e., successful call of t_relay resets these settings and they need to be re-armed. how about if t_relay fails and transaction is not created? are the t_on_X calls still in effect or do they need to be re-armed again? i haven't found in tm/README any discussion about when the t_on_X calls get reset. -- juha

15 years, 8 months

← Newer
1
...
8
9
10
11
12
13
14
15
Older →

Jump to page:

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 2009