sr-users October 2009

sr-users@lists.kamailio.org

63 participants
105 discussions

by Anders

Hi, I have two issues, and I think they are connected. The number of Active Dialogs keeps growing - as if some of them are hung. Not all of them, but some of them. At the same time, I have seen that from a specific customer, there is no BYE in the 'acc' table in the accounting. So, my conclusion - no BYE means it's not finished means it's hung... - right? Any ideas where to look? Thanks!

14 years, 6 months

[Kamailio-Users] LCR problem with "id" column and match priorities

by jh＠tutpro.com

ricardo, in situation where you see higher priority valued gateway group selected first, do you know if the lower priority valued group would be used if none of the gateways in the higher priority valued gateway group can serve the request? if it is used, then both exist in the hash table. the list in the hash table is sorted by prefix length and priority. -- juha

14 years, 6 months

[Kamailio-Users] acc: accounting flag for CANCEL

by Alex Balashov

If I have acc set to log CANCEL'd calls, do I need to set the accounting flag on handling CANCEL request, since it is a new transaction relative to the initial INVITE, or will it get logged automatically? Thanks, -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671

14 years, 6 months

[Kamailio-Users] basic SIP forwarding with Asterisk

by Jeff Brower

All- Can we use Asterisk combined with Kamailio as follows: __________ ___________ | | | | SIP ___| |___ SIP ___| Kamailio |___ SIP | | | rtpproxy | | Asterisk | | | | | | | | | RTP ___| |___ RTP ___| DSP card |___ RTP (G711) |__________| (G711) |___________| (G729, G723, GSM-AMR, EVRC) We've already implemented an rtpproxy interface to the DSP card, which has its own GbE port. Our question is whether we can we perform some type of basic SIP forwarding or "SIP pass-thru", but still invoke rtpproxy for call setup and tear-down and/or when media attributes for the call change? We're getting a lot of requests from customers who -- for whatever reasons -- need to use or continue to use Asterisk, but need to also add transcoding, ec, encryption, and other compute-intensive requirements that Asterisk doesn't support (or at least doesn't support at higher capacity or without going unstable). Thanks. -Jeff

14 years, 6 months

[Kamailio-Users] Anybody using domainpolicy module?

by Klaus Darilion

Hi! The domainpolicy draft is obsolete and the module needs adaptions to work with sip-router. Thus, we plan to remove it, as I guess nobody uses it at all. So, if you use this module, please speek up NOW! regards klaus

14 years, 6 months

[Kamailio-Users] Search for text with a space in it

by CSB

OpenSER 1.3 When I try to match a phrase with a space in it I don't get a match. I'm looking for "User-Agent: My UA" None of the following seem to work: if (search("User-Agent:\sMy\sUA")) { if (search("User-Agent:[ ]My[ ]UA")) { if (search("User-Agent: My UA")) { Could anyone point out my obvious mistake? Thanks

14 years, 6 months

[Kamailio-Users] Kamailio ignores Via in replies?

by Alex Hermann

Hello, while debugging a problem today I encountered a rather strange issue. The client's UA/router was messing up the Via header, with as result that all the IP's in the Via's were replaced by the public IP of the DSL modem. Now the weird part: because of the mangled Via's, the expected result is that the reply would be routed back to the IP of the client. Instead, the replies were still following the "correct" return path through a series of OpenSER/Kamailio proxies. How is this possible? According to rfc3261, a proxy must forward the reply to the next Via in the received _response_. It seems Kamailio is incorrectly keeping the Via from the request and sends the reply to the stored address of the Via from the _request_. Btw, no 'received' parameter is involved. Can anyone with inside knowledge of Kamailio share his/her view on this issue? And possibly, how to fix it. I suspect I can use check_via=1 to drop incoming replies with incorrect via, although the behaviour of check_via is undocumented (what does it do when check fails?). And why is the default value 0 (as has every example config on the web)? There's also reply_to_via, but according to docs that's only for locally generated replies. Also, its use is beyond me, as the correct value is dependent on the src_ip of the request and thus can't possibly be a global option. Alex.

14 years, 6 months

[Kamailio-Users] SIP message

by Rajesh

Dear All, I am using a separate Location server.I would like to know which SIP message is used to call the location server.To be more clear, as INVITE messages are used to make calls, I would like to know the similar SIP message which is used to store the user details in the location table..Is that REGISTER message ?...Correct me if iam wrong.. -- Regards, Rajesh

14 years, 6 months

[Kamailio-Users] Kamailio v1.5.3 released

by Daniel-Constantin Mierla

A new release in 1.5 series is out. Kamailio 1.5.3 is based on the latest version of branch 1.5, including many fixes in code and documentation, therefore those running 1.5.0, 1.5.1 or 1.5.2 are advised to upgrade. Source tarballs are available at: http://www.kamailio.org/pub/kamailio/1.5.3/src/ Detailed changelog: http://www.kamailio.org/pub/kamailio/1.5.3/ChangeLog Download via SVN: svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 kamailio Tag for this release can be browsed at: http://openser.svn.sourceforge.net/viewvc/openser/tags/1.5.3/ Project site at SourceForge.net (still using old name): http://sourceforge.net/projects/openser/ Binaries and packages will be uploaded at: http://www.kamailio.org/pub/kamailio/1.5.3/ Modules' documentation: http://www.kamailio.org/docs/modules/1.5.x/ What is new in 1.5.x release series is summarized in the announcement of v1.5.0: http://www.kamailio.org/mos/view/Kamailio-OpenSER-v1.5.0-Release-Notes Enjoy and stay tunned -- new major release Kamailio 3.0.0 is going to be out very soon, Daniel

14 years, 6 months

[Kamailio-Users] LCR problem with "id" column and match priorities.

by Ricardo Martinez

Hello List. I'm having a weird behavior with the LCR module. I have a particular prefix routed as follows (according to the LCR tables) : mysql> select * from lcr where prefix=0251; +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 89 | 1351 | | 51 | 1 | | 127 | 1351 | | 43 | 2 | +-----+--------+----------+--------+----------+ The gw's group are as follows : mysql> select * from gw where grp_id=51; +-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+ | id | gw_name | grp_id | ip_addr | hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags | +-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+ | 100 | GW1.TERMN1 | 51 | XX.XXX.XXX.16 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 | | 101 | GW2.TERMN1 | 51 | XX.XXX.XXX.13 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 | | 102 | GW3.TERMN1 | 51 | XX.XXX.XXX.32 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 | | 103 | GW4.TERMN1 | 51 | XX.XXX.XXX.35 | | 5060 | 1 | 1 | 4 | 1351 | 25 | 1 | 0 | +-----+----------------+--------+---------------+----------+------+----- -------+-----------+-------+------+--------+------+-------+ 4 rows in set (0.00 sec) mysql> mysql> select * from gw where grp_id=43; +----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+ | id | gw_name | grp_id | ip_addr | hostname | port | uri_scheme | transport | strip | tag | weight | ping | flags | +----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+ | 76 | GW1.TERMN222 | 43 | XX.XXX.XXX.16 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 | | 77 | GW2.TERMN222 | 43 | XX.XXX.XXX.13 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 | | 78 | GW3.TERMN222 | 43 | XX.XXX.XXX.32 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 | | 79 | GW4.TERMN222 | 43 | XX.XXX.XXX.35 | | 5060 | 1 | 1 | 4 | 1343 | 25 | 1 | 0 | +----+------------------+--------+---------------+----------+------+---- --------+-----------+-------+------+--------+------+-------+ 4 rows in set (0.00 sec) So, when a call with prefix 1351 arrived at the proxy, the LCR module is changing the RURI for 1343 (matching the 2nd priority for that prefix). This keep happening even if change the priority value 2 for priority value 5. I even changed the priority 1 for priority 0 as follows : +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 89 | 1351 | | 51 | 0 | | 127 | 1351 | | 43 | 1 | +-----+--------+----------+--------+----------+ But the LCR module keep using the "second" priority. After doing some tests I've found two ways to use the "first" priority for the prefix. 1.- Removing the second priority 2.- Re-ordering the "id" column and using correlative values as indicated in the next table : mysql> select * from lcr where prefix=0251 order by id; +-----+--------+----------+--------+----------+ | id | prefix | from_uri | grp_id | priority | +-----+--------+----------+--------+----------+ | 127 | 1351 | | 51 | 1 | | 128 | 1351 | | 43 | 2 | +-----+--------+----------+--------+----------+ So, when the prefix are with "no correlatives" values in the "id" column seems to be a problem to match the first priority. But when the values are correlative there is no problem. Is this the correct behavior? Maybe I'm missing something? What happens for example if I need to add a third priority to a certain prefix after doing several changes in the LCR table? I need to re-order every time the "id" values to make them correlatives? I really hope that someone could give me a hand here. Ricardo Martinez.-

14 years, 6 months

← Newer
1
2
3
4
5
6
7
...
11
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 October 2009