sr-users

sr-users@lists.kamailio.org

18 participants
37470 discussions

[Kamailio-Users] sl README does not know send_reply()
by jh＠tutpro.com 11 Mar '09

11 Mar '09

the new send_reply() function is not documented in sl/README. another related thing: would it be logical to also have corresponding reply_error() function especially when t_relay seems to create transaction even in case of some internal errors. -- juha

2 2

[Kamailio-Users] Problem starting Kamailio
by Sara EL KABIRI 11 Mar '09

11 Mar '09

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 starting it. "kamctl start" returns nothing. and "kamctl moni" returns "Error opening kamailio's FIFO /tmp/kamailio_fifo" I've checked in my .cfg file and the 'loadmodule' and 'modparam' lines related to mi-fifo module are uncommented. I've checked also the mi-fifo module was installed indeed (mi_fifo.so appears in /usr/local/lib/kamailio/modules directory). Could anyone help please? -- Sara

3 2

[Kamailio-Users] Force rtp proxy
by michel freiha 11 Mar '09

11 Mar '09

Hi all, I have a question regarding rtp proxy...I need to force rtp proxy in order that all rtp packets pass through...The issue now is the first INVITE does contains the PSTN GW IP instead of RTP Proxy IP...My config is as below: if (is_method("INVITE")) { # setflag(4); # do accounting fix_nated_sdp("1"); } if(!cr_route("default", "0", "$rU", "$rU", "call_id")){ sl_send_reply("403", "Not allowed"); } else { # In cas of failure, re-route the request t_on_failure("1"); t_on_reply("1"); force_rtp_proxy(); t_relay(); } onreply_route[1] { # if (t_check_status("2[0-9][0-9]") ) if((t_check_status("200|183|180") && search("Content_Type: application/sdp")) || search("Content-Type: application/sdp")) { force_rtp_proxy(); } exit; } Please let me know what's wrong here and how i can fix this issue Regards

2 1

[Kamailio-Users] Forgetting to call unforce_rtp_proxy
by mayamatakeshi 11 Mar '09

11 Mar '09

Hello, is there any risk of having resources leaking if I fail to call unforce_rtp_proxy? Like having rtpproxy not freeing ports? I'm mean, my cfg is becoming bigger and I may fail to call this function somewhere. Should I be extremely careful about this? regards, takeshi

2 1

[Kamailio-Users] LCR With 300,000 Routes
by Geoffrey Mina 10 Mar '09

10 Mar '09

I have spec'd out how my LCR table would look based my current PSTN gateway providers. Looks like I would need to load roughly 300,000 routes to properly represent everything. This server needs to be able to support spikes of 100 call setups per second. What is the general consensus on this? And, if it's a No-Go, what alternatives do I have? I have looked briefly at the CarrierRoute module, but haven't actually played with it. Thanks! Geoff

3 4

Re: [Kamailio-Users] handling of DNS-SRV in kamailio-1.4.3 & 1.5.0
by Klaus Feichtinger 10 Mar '09

10 Mar '09

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

2 1

[Kamailio-Users] t_relay with result code -6 creates transaction
by jh＠tutpro.com 10 Mar '09

10 Mar '09

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.

2 1

[Kamailio-Users] bug in subscribe when contact uses tcp transport?
by jh＠tutpro.com 10 Mar '09

10 Mar '09

> 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

1 0

[Kamailio-Users] bug in subscribe when contact uses tcp transport?
by jh＠tutpro.com 09 Mar '09

09 Mar '09

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

4 16

[Kamailio-Users] Forget about my first mail..
by Sara EL KABIRI 09 Mar '09

09 Mar '09

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

1 0

Jump to page:

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