sr-users May 2009

sr-users@lists.kamailio.org

59 participants
114 discussions

[Kamailio-Users] ACKed dialog remains in state 3 instead of 4

by catalina oancea

Hello, I was excited to find that I can now use dlg_manage instead of record_route so that I no longer need the record_route parameter but I now found a strange situation that maybe somebody can explain. I am sending an INVITE to kamailio, and kamailio sends it to a provider. It's like this: asterisk-----INVITE cseq 1-------> kamailio -----INVITE cseq 1-----------> provider asterisk<-----407 auth required---- kamailio <-----407 auth required------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When 407 reaches kamailio, kamailio changes dialog state to state 5. But the dialog is not deleted. Then the INVITE arrives again, authenticated, and a new dialog is created, but having the same callid and from-tag: asterisk-----INVITE cseq 2-------> kamailio -----INVITE cseq 2----------> provider asterisk<---- 200OK ----------------- kamailio <-----200OK--------------------- provider asterisk-----ACK----------------------> kamailio -----ACK------------------------> provider When this ACK arrives to kamailio, dlg_manage is called and kamailio searches for the dialog in the dialog list. It finds one but with state 5 (I printed a debug in the source), probably finds the first one, and thus it can no longer identify the ACK as being part of the second dialog. For this reason, the dialog created during the second invite remains with state 3. This causes sometimes the BYE not to be accepted correctly either, and some dialogs remain stuck in the database until they expire. Does anybody know why, when a dialog match is searched, when a match that is in state 5 in found, the search is interrupted? I was thinking of changing this so that the search can continue and the second INVITE dialog can be found, but I'm not sure that's safe. Thanks a lot, Catalina Oancea

14 years, 10 months

test e-mail... please ignore it

by Edson - Lists

14 years, 10 months

[Kamailio-Users] Pretty basic Presence question

by Mahesh Paolini-Subramanya

I'm trying to setup an extremely basic PRESENCE/BLF environment. However, when I call handle_subscribe(), the message gets sent to $si: 5060, *not* $si:$sp Any ideas? Should I be doing something with nat_traversal.co (don't see what, but worth asking...) The relevant portion of kamailio.cfg is if (!t_newtran()) { sl_reply_error(); return(-1); }; if (is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); }; Cheers, and thanx for any help --- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com

14 years, 10 months

[Kamailio-Users] rewritehostport

by Andrew Nowrot

Hi I am having the following problem. Can I use avp variable and rewritehostport function in this way: exec_avp("pool2domain.py $tU", "$avp(s:domainport)"); rewritehostport("$avp(s:domainport)"); Script called from exec_avp returns the string sample.sip.domain:port and it is written to avp variable. Can I use this variable in rewritehospport function because kamailio does not rewrite the host and the port number If I can not use it in this way is there any other solution. Cheers Andrew

14 years, 10 months

[Kamailio-Users] Question regarding kamailio transaction processing.

by Siddhardha Garige

Hi all, I have a question regarding kamailio transaction processing. Any help is greatly appreciated. We are load testing kamailio using SIPP tool. Kamailio is working in outbound proxy mode and routing SIP messages in-between SIPP servers. SIPP generates REGISTER requests and SIP calls. Registration load is 100 registrations per second. A steady stream of registration requests are generated throughout the test duration. Call load is 100 calls per second with average call duration of 3.5mins with a max load of 10,000 concurrent calls. SIPP starts with a call rate of 100 call/sec and makes 10,000 concurrent calls. Calls terminate at 3.5mins and SIPP will make new calls to maintain 10,000 concurrent call load. We monitored kamailio transactions using “kamctl moni” for current transaction in use. If kamailio has more than 1000 standing transaction in memory, we notice REGISTRATION retransmissions. Kamailio takes more than 300ms to process some registration requests. However requests related to call transactions are not affected. No INVITE or 200OK retransmissions were noticed in this process. By decreased call load to 10 call/second and registration retransmissions reduced considerably. Again by increased call load to 100 call/sec and we started noticing REGISTER retransmissions. Here is our question. If number of transactions in kamailio memory contributes to processing delay should not it affect both REGISTRATION and CALL transactions equally? Why only REGISTRATION are getting affected while calls are fine without any retransmissions. Is kamailio prioritizing processing call transactions over REGISTRATION transactions? Can someone throw some light on this please? -Sid

14 years, 10 months

[Kamailio-Users] How to refer to an AVP index?

by Edson - Lists

Hi, guys... On wiki page (http://www.kamailio.org/docs/avp_db_query.html) there is an example of the use of the 'avp_db_query' function, but it doesn't work on 1.5.1 SVN 5858. It fails on AVP index access... Kamailio complains on index syntax. Can anybody confirm the example error and point me to a page/link where the AVP index is described/exemplified (if still supported)? Edson.

14 years, 10 months

[Kamailio-Users] kamailio 3.0 config - routes with names

by Daniel-Constantin Mierla

Hello, to illustrate the new feature got by Kamailio to use names instead of integer index when defining/calling route blocks, I have updated the default config posted to the wiki: https://sip-router.org/wiki/migration/kamailio-3.0-config The workaround in the past was to use M4 or other text preprocessors, now can be done directly. It looks nicer and makes the config more human understandable. Happy testing, Daniel -- Daniel-Constantin Mierla http://www.asipto.com/

14 years, 10 months

[Kamailio-Users] snmpstats invalid condition in executeInterprocessBufferCmd

by mayamatakeshi

Hello, we have kamailio 1.4 (r. 5728) running in production. We compiled kamailio with 4 times the default pkg memory pool size (#define PKG_MEM_POOL_SIZE 4*1024*1024 ). We use snmpstats to monitor registration and number of calls using Nagios and PRTG. Some days ago, after almost 30 days of continuous operation without problems, in the shell we executed "snmpwalk -v2c -c public 192.168.88.22 .1.3.6.1.4.1.27483" as we routinely do for a quick check of SNMP in the command line and it failed. Then we checked kamailio logs and we found this: May 21 16:25:35 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:handle_openserSIPServiceStartTime: failed to read sysUpTime file at /tmp/openSER_SNMPAgent.txt I don't know what caused the above (maybe the file was mistakenly rm'd by someone. I failed to check it at that moment) but it was followed with this: May 21 16:25:35 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:executeInterprocessBufferCmd: Received a request for contact: [protected]@[protected] for user: sip:[protected]@[protected] who doesn't exists May 21 16:25:35 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:executeInterprocessBufferCmd: Received a request to delete contact: [protected]@[protected] for user: sip:[protected]@[protected] who doesn't exist ... then the same log "contact XXX who doesn't exist" happened several times per second till: May 21 16:36:30 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:createRegUserRow: failed to create a row for openserSIPRegUserTable May 21 16:36:30 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:updateUser: openserSIPRegUserTable ran out of memory. Not able to add user: [protected]@[protected] May 21 16:36:30 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:executeInterprocessBufferCmd: Received a request for contact: [protected]@[protected] for user: sip:[protected]@[protected] who doesn't exists May 21 16:36:30 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:insertContactRecord: no more pkg memory May 21 16:36:30 ipx022 /usr/local/sbin/kamailio[8781]: ERROR:snmpstats:executeInterprocessBufferCmd: openserSIPRegUserTable was unable to allocate memory for adding contact: [protected]@[protected] to user sip:[protected]@[protected]. During this time, snmpget queries issued by Nagios and PRTG were failing and the process spawned by module snmpstats was making heavy use of CPU. No other parts of kamailio were affected (calls and registration were OK), but snmpstats didn't normalize by itself so we decided to restart kamailio. I'm trying to recreate this in a lab machine but no luck so far. I am keeping the lab server busy with registration and calls while running snmpwalk in a loop. I've also ran "rm /tmp/openSER_SNMPAgent.txt" to check if could trigger the problem but the problem could not be recreated. If I push the lab server enough, I can see similar logs like this: May 27 20:16:54 ipx029 /usr/local/sbin/kamailio[14487]: ERROR:snmpstats:updateUser: openserSIPRegUserTable ran out of memory. Not able to add user: [protected]@[protected] May 27 20:16:54 ipx029 /usr/local/sbin/kamailio[14487]: ERROR:snmpstats:executeInterprocessBufferCmd: Received a request for contact: [protected]@[protected] for user: sip:[protected]@[protected] who doesn't exists May 27 20:17:05 ipx029 /usr/local/sbin/kamailio[14487]: ERROR:snmpstats:get_socket_list_from_proto: no more pkg memory May 27 20:17:05 ipx029 last message repeated 9 times May 27 20:17:59 ipx029 /usr/local/sbin/kamailio[14487]: ERROR:snmpstats:handle_openserSIPServiceStartTime: failed to read sysUpTime file at /tmp/openSER_SNMPAgent.txt May 27 20:40:25 ipx029 /usr/local/sbin/kamailio[14487]: ERROR:snmpstats:handle_openserSIPServiceStartTime: failed to read sysUpTime file at /tmp/openSER_SNMPAgent.txt But even with those messages, snmpget/snmpwalk doesn't stop to return responses. I was hoping someone could take a look at snmpstats code; the logs for snmpstats:executeInterprocessBufferCmd are marked with comments like : /* This should never happen. This is more of a sanity check. */ so probably my server hit some bug. regards, takeshi

14 years, 10 months

Re: [Kamailio-Users] ACKed dialog remains in state 3 instead of 4

by catalina oancea

---------- Forwarded message ---------- From: catalina oancea <catalina.oancea(a)gmail.com> Date: 2009/5/27 Subject: Re: [Kamailio-Users] ACKed dialog remains in state 3 instead of 4 To: Alex Balashov <abalashov(a)evaristesys.com> Hi Alex, thanks for answering >From what I know the record-route header is not compulsory, and dialog-matching can also be done using rfc dialog-matching instead of the did parameter in record-route (modparam("dialog", "dlg_match_mode", 2)). This is what I am trying to use, I don't want to use the record-route header at all. 2009/5/27 Alex Balashov <abalashov(a)evaristesys.com>: > Catalina, > > Unless I am missing something, dlg_manage() does not allow you to avoid > setting Record-Route; how else will the endpoints know to send sequential > messages through the proxy once the dialog is established? > > The purpose of dlg_manage() is to provide an alternative to setting a flag > for the purpose of indicating to Kamailio that the dialog the current INVITE > seeks to establish should be statefully tracked and exposed to additional > user-defined dialog module functionality (profiles, statistics, etc.) and > other module functionality relying on internal API callbacks from the dialog > module. > > modparam("dialog", "dlg_flag", 4) > > route { > ... > > # Process initial INVITE. > > if(is_method("INVITE")) { > ... > > setflag(4); # Track this dialog. > > } > > } > > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (678) 237-1775 >

14 years, 10 months

[Kamailio-Users] Dispatcher

by CSB

I wish to implement a kind of a failover situation, probably using the dispatcher module. We want to monitor our gateways by performing a range of tests (not just a ping or INFO but also waiting for a specific response to an INVITE). If the test fails then we want to mark a gateway as unavailable until the tests are successful again. Based on a bit of reading I think we could use the dispatcher module in database mode. We could run a script that performs the tests and marks the destination as inactive if the test fails. If that would work, can anyone advise how we mark a destination as inactive? It looks like the MI function ds_set_state does this but can I update the database directly? If so what field do I need to update? Thanks Cameron

14 years, 10 months

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

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