sr-users March 2009

sr-users@lists.kamailio.org

92 participants
149 discussions

Start a nNew thread

Re: [Kamailio-Users] Siremis 0.9.2 with Kamailio 1.5 on Debian 5.0
by mike＠agcusa.com 23 Mar '09

23 Mar '09

2 1

[Kamailio-Users] [LCR] About ping
by Iñaki Baz Castillo 22 Mar '09

22 Mar '09

Hi, some questions about LCR module ping mechanism: - How to know which gws are down? The only I see is a NOTICE log: --------- NOTICE:lcr:gw_set_state: trunk "99.99.99.99:5060" from group: <2> is OFFLINE --------- Is not possible a MI command to list the down gateways? - Why ping_interval cannot be less than 180 seconds? - In case of failure_route and "next_gw()", is the used gw (failing gw) automatically marked as down? (it would be useful so we don't need to wait "fr_timer" seconds for each request during "ping_interval"). Thanks. -- Iñaki Baz Castillo

4 17

[Kamailio-Users] ACK when using NAT
by michel freiha 20 Mar '09

20 Mar '09

Dear All, Hi all, i'm trying to send FAX to an endpoint behind a NAT...The FAX is failing because the ACK message is sent to Private endpoint IP instead of PUBLIC IP....Can you please let me know what's wrong?Please find below my ACK method that i define in loose route methode f ( is_method("ACK") ) { if ( t_check_trans() ) { xlog("AAAAKKKCCCCCCCNNNNNN"); force_rport(); t_relay(); exit; } Regards

3 7

[Serusers] (no subject)
by Bill McNamara 20 Mar '09

20 Mar '09

We are having something of an issue with lookup_user() and lookup_contacts(). Our UA's are added to the proxy using "ser_ctl user add 1234567890(a)ourdomain.com -p password" which works great And the UA's register just fine. When a call comes in from a carrier, the invite is for 1234567890(a)12.34.56.78 where 12.34.56.78 is the IP address of our proxy. When we do a lookup to see if the call is destined for a local user via lookup_user("$tu.uid","@ruri") it fails because the registration is done using the URL and not the IP address. If I add the same user for the IP address domain, "ser_ctl user add 1234567890(a)12.34.56.78 -p password", the lookup_user() works, but the lookup_contacts(0 never does. I have tried adding aliases in the ser.cfg file: alias=12.34.56.78 alias=proxy.ourdomain.com but it does not work. I'm new to SER and the documentation I have been able to locate does not really address this issue, if, in fact, it really is an issue. If anyone could point me to something that will help me work through this problem, I'd greatly appreciate it. Thanks, Bill Bill McNamara billmc(a)connectmevoice.com ConnectMeVoice LLC 800-743-1208 x104

2 1

[Kamailio-Users] [LCR] Can "prefix" be "empty" (any)?
by Iñaki Baz Castillo 20 Mar '09

20 Mar '09

Hi, I read in LCR doc: --------- each gateway group is associated with one or more <prefix, from pattern, priority> tuples. A gateway matches a request if user part of Request URI matches a prefix and caller's URI matches a from pattern in a tuple that belongs to the group of the gateway. ---------- Can "prefix" be empty (or NULL?) so any RURI matches it? Thanks. -- Iñaki Baz Castillo

2 4

[Kamailio-Users] [LCR] Can I use a hostname in "ip_addr" field of "gw" table?
by Iñaki Baz Castillo 20 Mar '09

20 Mar '09

Hi, instead of an IP, can I use a hostname in "ip_addr" field of "gw" table? The hostname would have no DNS record (it would appear just in local /etc/hosts). Is it possible? or perhaps a real IP is required? Thanks. -- Iñaki Baz Castillo

2 2

[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?
by Frank Durda IV 20 Mar '09

20 Mar '09

I'm running into a problem with rtpproxy on this point, quoting from the README: - - - - - - - - - - - - after the session has been created, the proxy listens on the port it has allocated for that session and waits for receiving at least one UDP packet from each of two parties participating in the call. Once such packet is received, the proxy fills one of two ip:port structures associated with each call with source ip:port of that packet. When both structures are filled in, the proxy starts relaying UDP packets between parties; - - - - - - - - - - - However, a number of clients frequently fail to emit any audio when originating a call until they hear something from the TDM gateway, such as ring-back or the called party answering. So although rtpproxy is receiving a stream of audio, such as a voice mail menu robot, the calling party can't hear any of it unless they happen to make some noise or randomly and blindly press a DTMF key. This seems to be made worse on links with silence suppression, so there is no background noise to trigger two-way audio. This is being encountered between Class 4 carriers, so we don't have the option to get someone to adjust their phone/PBX settings or have them breathe heavier. Is there a setting adjustment to get rtpproxy to just pass the RTP packets from directed calling and called sources even if one party hasn't happened to make noise yet? I personally don't understand why this requirement for seeing audio from both sides before starting the flow in either direction if audio starts coming in even exists. It seems to have no benefit but is bound to cause this deadly embrace problem in many situations that may be beyond the control of the owners of the equipment passing traffic along to the site where rtpproxy is in use. Suggestions? Fix? I have looked at the latest snapshot of rtpproxy and the README is unchanged since 1.1 so apparently this behavior is still the same. Thanks in advance!

4 15

Re: [Kamailio-Users] Problem starting Kamailio
by Sara EL KABIRI 20 Mar '09

20 Mar '09

On Thu, Mar 19, 2009 at 12:18 PM, Henning Westerholt < henning.westerholt(a)1und1.de> wrote: > > Hi Sara, > > ok, take a look to the plain output from strace, without the grep command. > Does it shows any errors from a file open, or a stat? Probably stupid > question, but do you've the strace command installed? > > Cheers, > > Henning Hello Henning, I do have strace :-) Yesterday i tried it with and without the grep part, and there was no error. So i did some IMS presence service tests... And Kamailio couldn't process a "SIP PUBLISH" because of an error "*ERROR 600 : Busy everywhere - Forwarding to S-CSCF failed*". For your information, i'm using the Fokus OpenIms Core as an ims server, and Kamailio as a presence server. An IFC (Initial Filter Criteria) is set up in OpenIms to route properly the presence messages to Kamailio. And by the way, i saw some lines in the logs about /tmp/kamailio_fifo opening successfully... Today, i launch the strace command and gess what... i'm getting the /tmp/kamailio_fifo opening error. Still a new kamailio_fifo is created indeed in my /tmp directory. And well, i am encountering the "busy everywhere" error again... Have anyone ever noticed the error 600? And what about the mi_fifo error that appears half the time? PS: Here you are some parts of the logs, and you can have a look at the attached file for the entire trace. ====LOG PARTS==== 1/ Error 600 : busy everywhere (in kamailio start) *Mar 19 10:46:28 [11850] DBG:core:parse_msg: SIP Request: Mar 19 10:46:28 [11850] DBG:core:parse_msg: method: <PUBLISH> Mar 19 10:46:28 [11850] DBG:core:parse_msg: uri: <sip:bob@test.ims.com<sip%3Abob(a)test.ims.com> > Mar 19 10:46:28 [11850] DBG:core:parse_msg: version: <SIP/2.0> Mar 19 10:46:28 [11850] DBG:core:parse_headers: flags=2 Mar 19 10:46:28 [11850] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKa813.b002d4e4.0>; state=16 Mar 19 10:46:28 [11850] DBG:core:parse_via: end of header reached, state=5 Mar 19 10:46:28 [11850] DBG:core:parse_headers: via found, flags=2 Mar 19 10:46:28 [11850] DBG:core:parse_headers: this is the first via Mar 19 10:46:28 [11850] DBG:core:receive_msg: After parse_msg... Mar 19 10:46:28 [11850] DBG:core:receive_msg: preparing to run routing scripts... Mar 19 10:46:28 [11850] DBG:core:parse_headers: flags=100 Mar 19 10:46:28 [11850] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKa813.41769183.0>; state=16 Mar 19 10:46:28 [11850] DBG:core:parse_via: end of header reached, state=5 Mar 19 10:46:28 [11850] DBG:core:parse_headers: via found, flags=100 Mar 19 10:46:28 [11850] DBG:core:parse_headers: parse_headers: this is the second via Mar 19 10:46:28 [11850] DBG:core:parse_via_param: found param type 235, <rport> = <5060>; state=6 Mar 19 10:46:28 [11850] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bK315224847>; state=16 Mar 19 10:46:28 [11850] DBG:core:parse_via: end of header reached, state=5 Mar 19 10:46:28 [11850] DBG:core:parse_headers: via found, flags=100 Mar 19 10:46:28 [11850] DBG:core:parse_to: end of header reached, state=10 Mar 19 10:46:28 [11850] DBG:core:parse_to: display={}, ruri={ sip:bob@test.ims.com <sip%3Abob(a)test.ims.com>} Mar 19 10:46:28 [11850] DBG:core:get_hdr_field: <To> [25]; uri=[** sip:bob@test.ims.com <sip%3Abob(a)test.ims.com>**] Mar 19 10:46:28 [11850] DBG:core:get_hdr_field: to body [<** sip:bob@test.ims.com <sip%3Abob(a)test.ims.com>**> ] Mar 19 10:46:28 [11850] DBG:core:get_hdr_field: cseq <CSeq>: <20> <PUBLISH> Mar 19 10:46:28 [11850] DBG:maxfwd:is_maxfwd_present: value = 15 Mar 19 10:46:28 [11850] DBG:uri:has_totag: no totag Mar 19 10:46:28 [11850] DBG:core:parse_headers: flags=78 Mar 19 10:46:28 [11850] DBG:tm:t_lookup_request: start searching: hash=12682, isACK=0 Mar 19 10:46:28 [11850] DBG:tm:matching_3261: RFC3261 transaction matched, tid=a813.b002d4e4.0 Mar 19 10:46:28 [11850] DBG:tm:t_lookup_request: REF_UNSAFE: after is 1 Mar 19 10:46:28 [11850] DBG:tm:t_lookup_request: transaction found (T=0xb5a0d430) Mar 19 10:46:28 [11850] DBG:tm:t_retransmit_reply: nothing to retransmit Mar 19 10:46:28 [11850] DBG:tm:t_check_trans: UNREF_UNSAFE: after is 0 Mar 19 10:46:28 [11850] DBG:core:destroy_avp_list: destroying list (nil) Mar 19 10:46:28 [11850] DBG:core:receive_msg: cleaning up Mar 19 10:46:31 [11852] DBG:core:parse_msg: SIP Reply (status): Mar 19 10:46:31 [11852] DBG:core:parse_msg: version: <SIP/2.0> Mar 19 10:46:31 [11852] DBG:core:parse_msg: status: <600> Mar 19 10:46:31 [11852] DBG:core:parse_msg: reason: <Busy everywhere - Forwarding to S-CSCF failed> Mar 19 10:46:31 [11852] DBG:core:parse_headers: flags=2 Mar 19 10:46:31 [11852] DBG:core:parse_via_param: found param type 232, <branch> = <z9hG4bKa813.192cfef5.0>; state=16 Mar 19 10:46:31 [11852] DBG:core:parse_via: end of header reached, state=5* 2/ /tmp/kamailio_fifo opening error (with strace kamctl) *rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 stat64("/tmp/kamailio_fifo", {st_mode=S_IFIFO|0660, st_size=0, ...}) = 0 geteuid32() = 1000 getegid32() = 1000 getuid32() = 1000 getgid32() = 1000 access("/tmp/kamailio_fifo", W_OK) = -1 EACCES (Permission denied) rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(1, "\33[37;31m\33[1mERROR: Error opening"..., 72ERROR: Error opening Kamailio's FIFO /tmp/kamailio_fifo ) = 72 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 brk(0x9302000) = 0x9302000 write(1, "\33[37;31m\33[1mERROR: Make sure you"..., 123ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")' in your config ) = 123 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 write(1, "\33[37;31m\33[1mERROR: and also have"..., 64ERROR: and also have loaded the mi_fifo module. ) = 64 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 exit_group(2) = ? Process 12215 detached* ================== -- S.

6 7

Re: [Kamailio-Users] ERROR:error opening Openser's FIFO FIFO
by Henning Westerholt 20 Mar '09

20 Mar '09

On Friday 20 March 2009, Metshet Seleshi wrote: > Really > appreciate your replay, I am sorry, I wasn’t able to replay time sooner, > > Answers > to the questions > > I > am using OpensER-1.3.4-tls , > > Server > starts up fine, and register, > > And below is part of the config file, I hope it helps > [..] > loadmodule "mi_fifo.so" > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") Hi Metshet, the cfg looks good so far. Can you do a "ls -la /tmp/openser_fifo" and quote the output? With what user do you've tried to run the openserctl tool? Cheers, Henning

1 0

Re: [Kamailio-Users] server isnt writing to "acc" table - how to debug?
by Daniel-Constantin Mierla 20 Mar '09

20 Mar '09

please keep the mailing list in the recipient list, so the others facing same problem learn the right solutions. Thanks, Daniel On 03/19/2009 06:14 PM, Joao Gomes Pereira wrote: > That's it :) > Thanks for the help > Joao Pereira > > Daniel-Constantin Mierla wrote: >> Hello, >> >> have you set db_url for acc module? >> >> modparam("acc", "db_url", "mysql://dbusername:dbpass@localhost/openser") >> >> Cheers, >> Daniel >> >> >> On 03/19/2009 05:55 PM, Joao Gomes Pereira wrote: >>> Hello to all >>> I enabled the Kamailio acc modules but it isn't writing to "acc" or >>> "missed_calls" table. >>> How can I see in real time the SQL querys that Kamailio is sending >>> to Mysqld? >>> Here are some parts of my configuration file. >>> >>> >>> (...) >>> loadmodule "db_mysql.so" >>> loadmodule "acc.so" >>> >>> (...) >>> >>> # ----- acc params ----- >>> /* what sepcial events should be accounted ? */ >>> modparam("acc", "early_media", 1) >>> modparam("acc", "report_ack", 1) >>> modparam("acc", "report_cancels", 1) >>> modparam("acc", "detect_direction", 0) >>> /* account triggers (flags) */ >>> modparam("acc", "failed_transaction_flag", 3) >>> modparam("acc", "log_flag", 1) >>> modparam("acc", "log_level", 2) >>> modparam("acc", "log_missed_flag", 2) >>> modparam("acc", "log_extra", >>> "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") >>> >>> /* uncomment the following lines to enable DB accounting also */ >>> modparam("acc", "db_flag", 1) >>> modparam("acc", "db_missed_flag", 2) >>> modparam("domain", "db_url", >>> "mysql://dbusername:dbpass@localhost/openser") >>> modparam("acc", >>> "db_extra","src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd") >>> >>> >>> >>> Flags 1 and 2 are in the configuration (the same way as in the >>> sample that comes with Kamailio) >>> >>> (...) >>> >>> if (has_totag()) { >>> # sequential request withing a dialog should >>> # take the path determined by record-routing >>> if (loose_route()) { >>> if (is_method("BYE")) { >>> setflag(1); # do accounting ... >>> setflag(3); # ... even if the >>> transaction fails >>> } >>> route(1); >>> (...) >>> >>> # account only INVITEs >>> if (is_method("INVITE")) { >>> setflag(1); # do accounting >>> } >>> >>> So, if accounting is enabled and the flags in the right place... why >>> is the "acc" table still empty? >>> Thanks >>> Regards >>> Joao Pereira >>> >>> >> > > -- Daniel-Constantin Mierla SIP Router Masterclass - Kamailio (OpenSER) Training http://www.asipto.com/index.php/sip-router-masterclass/

2 2

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

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