sr-users December 2010

sr-users@lists.kamailio.org

63 participants
114 discussions

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v3.1.1 is released. This is a maintenance release of latest stable branch, 3.1, that includes fixes since release of v3.1.0. There is no change to database or configuration file required to upgrade to 3.1.1 from 3.1.0 version. If you run v3.1.0 from tarball or packages, it is strongly recommended to upgrade to v3.1.1. For more details about version 3.1.1, visit: http://www.kamailio.org/w/2010/12/kamailio-v3-1-1-released/ Cheers, Daniel -- Daniel-Constantin Mierla Kamailio (OpenSER) Advanced Training Jan 24-26, 2011, Irvine, CA, USA http://www.asipto.com

13 years, 5 months

When too many calls, calls does not complete, too much delay when placing calls

by Vic Jolin

Hi all, Just want to ask if anybody here has come across this problem of mine, when single call proxy is ok, but when you send more traffic to it, calls somehow get stuck, trying to make a new call it takes a lot of time and so it times out. Does anybody know what could be the problem? Thanks!

13 years, 5 months

limit on fail-over in lcr?

by Anders

Hi there, Kamailio 1.5: I cannot find an answer to this in the documentation: Is there a limit to how many fail-overs Kamailio does? I have lcr setup for a destination where it is rejected with 403 on the first and second priority, but then it goes no further, even though I have a third priority defined. Is there a limit to fail-over on two levels? Thanks!! //Anders

13 years, 5 months

Re: [SR-Users] SIP between IPv4 and IPv6 agents

by Klaus Darilion

Am 02.12.2010 13:06, schrieb Komáromi Péter: > Hi! > > So if you say it is possible to solve the problem with the only > location table, the location_inet4 and location_inet6 is not > certainly necessary... do I _have to_ use the 4to6.cfg file from the > source of kamailio, or not? When you call force_rtp_proxy() then you have to provide the i/e flags to tell rtpproxy how it should bridge the call. Therefore you need to know for every call: - is the caller IPv4 or IPv6? - is the callee IPv4 or IPv6? Finding out the protocol version of the caller is rather easy: if (af == inet) { # caller ipv4 ... } else { # caller ipv6 ... } But finding out if the callee is v4 or v6 is difficult. Actually it may even be that the callee is registered with 2 clients at the same time - one using v4 and v6. As far as I know this multi-registration scenario can not be handled currently - only single-registrations or multi-registrations which use the same protocol version are supported. Anyway - there are several approaches how to detect the IP version of the callee. - fixed mapping: for example if you know that all usernames starting with 1 are IPv4 clients, and all usernames starting with 2 are IPv6 clients, then you can detect the callee's protocol version manually, e.g: if ( $(rU{s.substr,0,1}) == "1") { # callee ipv4 ... } else { # callee ipv6 ... } - check destination URI if it contains a IPv4 or IPv6 address, e.g. use http://www.kamailio.org/dokuwiki/doku.php/transformations:devel#resubst_exp… to test if $dd contains '.' which would indicate a ipv4 address. - use dedicated location tables > (Because it uses them, for instance here: if (method == "REGISTER") > { if (af == inet) { save("location-inet4"); } else if (af == inet6) > { save("location-inet6");...) > > If I do not have to use it, I do not need to merge it with my > kamailio.cfg file, the steps I have to do are: install rtpproxy, > start it with the appropriate parameters and set the forcing in the > kamailio.cfg file?! The more I think about it I prefer the approach with separated location tables. It should be rather easy to integrate the 2 location tables into your existing config. regards Klaus PS: please Cc the mailing list

13 years, 5 months

Parallel forking and recording with rtpproxy?

by Jeremya

Hi, I'm having some issues with recording in rtpproxy when I parallel fork an incoming call. The scenario is that I want to record incoming calls to a small number of operators, and the call is converted to an 'all-call' by the local kamailio instance - parallel forking. It appears - though I could be wrong - that only the call tag is used to differentiate calls in kamailio/rtpproxy. I am guessing that when the call is forked and presented to rtpproxy that it somehow creates/uses only one data structure. When the call is answered, the other calls are cancelled and this results in the data structure being deleted. Is this correct? If so, are there any easy ways to achieve recording in this scenario? Thanks Jeremy

13 years, 5 months

nathelper force_rtp_proxy etc flag "f"

by Jeremya

Is the flag "f" of any actual use in force_rtp_proxy, rtp_proxy_offer and rtpproxy_answer? With an upstream proxy the lack of "f" causes problems. Does some problem occur when it is used without an upstream proxy? Thanks Jeremy

13 years, 5 months

Releasing Kamailio 3.1.1

by Daniel-Constantin Mierla

Hello, there are almost 2 months since release of Kamailio 3.1.0, so it is time for 3.1.1 as there were several important fixes done. I propose Thursday, next week, by that time we should sort out most of the issues reported lately. Other opinions? Cheers, Daniel -- Daniel-Constantin Mierla Kamailio (OpenSER) Advanced Training Jan 24-26, 2011, Irvine, CA, USA http://www.asipto.com

13 years, 5 months

"invalid version 1 for table trusted found, expected 5" while trying to load permissions and drouting modules togheter

by Pierpaolo Culurciello

Hello to everybody, I'm facing the following problem while trying to load and use Permissions and Drouting modules togheter: here you are the detailed starting debug of my Kamailio 3.1.0: 0(2456) DEBUG: db_postgres [km_pg_con.c:72]: opening connection: postgres://xxxx:xxxx@192.168.190.150:5432/kamailio 0(2456) DEBUG: db_postgres [km_pg_con.c:80]: PQsetdbLogin(0x93ec520) 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): permissions 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): ldap 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): alias_db 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): domain 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): presence 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): presence_xml 0(2456) DEBUG: presence_xml [presence_xml.c:300]: [-127] pid [2456] 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): nathelper 0(2456) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (-127): mediaproxy 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): mi_fifo 1(2457) DEBUG: <core> [sr_module.c:791]: DEBUG: init_mod_child (1): tm 1(2457) DEBUG: tm [callid.c:131]: DEBUG: callid: '65df7ef6-2457(a)192.168.190.185' 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): avpops 1(2457) DEBUG: <core> [db.c:294]: connection 0x82a7358 found in pool 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): usrloc 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): registrar 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): uri_db 1(2457) DEBUG: <core> [db.c:294]: connection 0x82a7408 found in pool 1(2457) DEBUG: <core> [sr_module.c:791]: DEBUG: init_mod_child (1): ctl 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): acc 1(2457) DEBUG: <core> [db.c:294]: connection 0x82bc668 found in pool 1(2457) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (1): drouting 1(2457) DEBUG: <core> [db.c:294]: connection 0x82bc910 found in pool 1(2457) DEBUG: db_postgres [km_dbase.c:149]: 0x82bc8f8 PQsendQuery(select gwid,address,strip,pri_prefix,type,attrs from dr_gateways ) 1(2457) DEBUG: <core> [db_res.c:116]: allocate 28 bytes for result set at 0x82a74e8 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): mi_fifo 2(2458) DEBUG: <core> [sr_module.c:791]: DEBUG: init_mod_child (2): tm 2(2458) DEBUG: tm [callid.c:131]: DEBUG: callid: '65df7ef6-2458(a)192.168.190.185' 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): avpops 2(2458) DEBUG: <core> [db.c:294]: connection 0x82a7358 found in pool 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): usrloc 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): registrar 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): uri_db 2(2458) DEBUG: <core> [db.c:294]: connection 0x82a7408 found in pool 2(2458) DEBUG: <core> [sr_module.c:791]: DEBUG: init_mod_child (2): ctl 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): acc 2(2458) DEBUG: <core> [db.c:294]: connection 0x82bc668 found in pool 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): drouting 2(2458) DEBUG: <core> [db.c:294]: connection 0x82bc910 found in pool 2(2458) DEBUG: <core> [sr_module.c:807]: DEBUG: init_mod_child (2): permissions 2(2458) DEBUG: <core> [db.c:294]: connection 0x82a7500 found in pool 2(2458) DEBUG: db_postgres [km_val.c:158]: PQescapeStringConn: in: 7 chars, out: 7 chars 2(2458) DEBUG: db_postgres [km_dbase.c:149]: 0x82a74e8 PQsendQuery(select table_version from version where table_name='trusted') 2(2458) DEBUG: <core> [db_res.c:116]: allocate 28 bytes for result set at 0x82a7598 LOG: statement: select gwid,address,strip,pri_prefix,type,attrs from dr_gateways 2(2458) DEBUG: db_postgres [km_dbase.c:403]: 0x82a74e8 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x93f6010) 2(2458) DEBUG: db_postgres [km_res.c:108]: 6 columns returned from the query 2(2458) DEBUG: <core> [db_res.c:153]: allocate 24 bytes for result names at 0x82a75c0 2(2458) DEBUG: <core> [db_res.c:163]: allocate 24 bytes for result types at 0x82a75e0 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[0] at 0x82a7600 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7600)[0]=[gwid] 2(2458) DEBUG: db_postgres [km_res.c:140]: use DB1_INT result type 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[1] at 0x82a7610 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7610)[1]=[address] 2(2458) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[2] at 0x82a7620 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7620)[2]=[strip] 2(2458) DEBUG: db_postgres [km_res.c:140]: use DB1_INT result type 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[3] at 0x82a7630 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7630)[3]=[pri_prefix] 2(2458) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[4] at 0x82a7640 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7640)[4]=[type] 2(2458) DEBUG: db_postgres [km_res.c:140]: use DB1_INT result type 2(2458) DEBUG: db_postgres [km_res.c:126]: allocate 8 bytes for RES_NAMES[5] at 0x82a7650 2(2458) DEBUG: db_postgres [km_res.c:133]: RES_NAMES(0x82a7650)[5]=[attrs] 2(2458) DEBUG: db_postgres [km_res.c:166]: use DB1_STRING result type 2(2458) DEBUG: db_postgres [km_res.c:222]: allocate for 6 columns 24 bytes in row buffer at 0x82a7660 2(2458) DEBUG: <core> [db_res.c:182]: allocate 8 bytes for rows at 0x82a7680 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,0)=[1] 2(2458) DEBUG: db_postgres [km_res.c:251]: [0][0] Column[gwid]=[1] 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,1)=[192.168.190.150] 2(2458) DEBUG: db_postgres [km_res.c:251]: [0][1] Column[address]=[192.168.190.150] 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,2)=[2] 2(2458) DEBUG: db_postgres [km_res.c:251]: [0][2] Column[strip]=[2] 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,3)=[88] 2(2458) DEBUG: db_postgres [km_res.c:251]: [0][3] Column[pri_prefix]=[88] 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,4)=[0] 2(2458) DEBUG: db_postgres [km_res.c:251]: [0][4] Column[type]=[0] 2(2458) DEBUG: db_postgres [km_res.c:242]: PQgetvalue(0x82a74e8,0,5)=[] 2(2458) DEBUG: <core> [db_row.c:119]: allocate 120 bytes for row values at 0x82c17f8 2(2458) DEBUG: <core> [db_val.c:73]: converting INT [1] 2(2458) DEBUG: <core> [db_val.c:117]: converting STRING [192.168.190.150] 2(2458) DEBUG: <core> [db_val.c:127]: allocate 16 bytes memory for STRING at 0x82a7690 2(2458) DEBUG: <core> [db_val.c:73]: converting INT [2] 2(2458) DEBUG: <core> [db_val.c:117]: converting STRING [88] 2(2458) DEBUG: <core> [db_val.c:127]: allocate 3 bytes memory for STRING at 0x82c1878 2(2458) DEBUG: <core> [db_val.c:73]: converting INT [0] 2(2458) DEBUG: <core> [db_val.c:56]: converting NULL value 2(2458) DEBUG: db_postgres [km_res.c:266]: freeing row buffer at 0x82a7660 2(2458) DEBUG: db_postgres [km_dbase.c:302]: PQclear(0x93f6010) result set 2(2458) DEBUG: <core> [db_res.c:79]: freeing 6 columns 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[0] at 0x82a7600 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[1] at 0x82a7610 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[2] at 0x82a7620 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[3] at 0x82a7630 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[4] at 0x82a7640 2(2458) DEBUG: <core> [db_res.c:83]: freeing RES_NAMES[5] at 0x82a7650 2(2458) DEBUG: <core> [db_res.c:92]: freeing result names at 0x82a75c0 2(2458) DEBUG: <core> [db_res.c:97]: freeing result types at 0x82a75e0 2(2458) DEBUG: <core> [db_res.c:52]: freeing 1 rows 2(2458) DEBUG: <core> [db_row.c:68]: free VAL_STRING[1] '192.168.190.150' at 0x82a7690 2(2458) DEBUG: <core> [db_row.c:68]: free VAL_STRING[3] '88' at 0x82c1878 2(2458) DEBUG: <core> [db_row.c:97]: freeing row values at 0x82c17f8 2(2458) DEBUG: <core> [db_res.c:60]: freeing rows at 0x82a7680 2(2458) DEBUG: <core> [db_res.c:134]: freeing result set at 0x82a7598 2(2458) ERROR: <core> [db.c:408]: invalid version 1 for table trusted found, expected 5 (check table structure and table "version") 2(2458) ERROR: permissions [trusted.c:249]: error during table version check. 2(2458) DEBUG: <core> [db_pool.c:97]: connection still kept in the pool 2(2458) ERROR: <core> [sr_module.c:811]: init_mod_child(): Error while initializing module permissions 2(2458) ERROR: <core> [pt.c:332]: ERROR: fork_process(): init_child failed for process 2, pid 2458, "" 2(2458) : <core> [main.c:1439]: main_loop: Cannot fork As you can see expecially from the extract reported below, the problem seems to occur when multiple threads run at the same time and placing queries almost at the same time and it happens that the results of those queries are returned back to the other thread. 2(2458) DEBUG: db_postgres [km_val.c:158]: PQescapeStringConn: in: 7 chars, out: 7 chars 2(2458) DEBUG: db_postgres [km_dbase.c:149]: 0x82a74e8 PQsendQuery(select table_version from version where table_name='trusted') 2(2458) DEBUG: <core> [db_res.c:116]: allocate 28 bytes for result set at 0x82a7598 LOG: statement: select gwid,address,strip,pri_prefix,type,attrs from dr_gateways 2(2458) DEBUG: db_postgres [km_dbase.c:403]: 0x82a74e8 PQresultStatus(PGRES_TUPLES_OK) PQgetResult(0x93f6010) 2(2458) DEBUG: db_postgres [km_res.c:108]: 6 columns returned from the query Here thread number 2 executes the query "select table_version from version where table_name='trusted'" but then the same thread doesn't evaluate its result but the one of the previous query, "select gwid,address,strip,pri_prefix,type,attrs from dr_gateways"; as a matter of fact you can see in the LOG statement "6 columns returned from the query". The strange thing is that this problem occurs only when I try to load Permissions and Drouting modules at the same time: whenever I load anyone of that two modules alone Kamailio starts whitout complaining about anything. Obviously I have already checked the value of "table_version" in version table and it's the correct one (5). Moreover I have also tried to apply the patch suggested in the following thread for a similar problem, (http://www.mail-archive.com/sr-dev@lists.sip-router.org/msg07551.html) but without any success. Please let me know if you have some advice for my problem, I really need to use these two modules at the same time! Greetings, Pierpaolo Culurciello

13 years, 5 months

CANCEL with Totag

by Iñaki Baz Castillo

Hi, Samsung PBX's generate a wrong CANCEL: - It contains To tag !!! - It contains "application/sdp" mirroring the SDP of the 183 received !!! Really ugly. Actually those CANCEL's are being rejected by my kamailio (403) as they contain Totag but no Route header. So, as a workaround, I will move the section of CANCEL before the loose-routing section. I expect it will work, but I would like to be sure that Kamailio (1.5) will not react due to the Totag of the CANCEL (it shouldn't IMHO as the Totag has no relationship with the INVITE transaction being cancelled). Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

13 years, 5 months

Kamailio 3.1 doesn't start with siptrace module

by vonlouda

Hi, I've installed a new instance of Kamailio 3.1 without prb and it works fine. However, in order to activate siptrace, I've added the following lines in the config file, loadmodule "siptrace.so" modparam("siptrace","db_url", DBURL) modparam("siptrace","table","sip_trace") modparam("siptrace","trace_on",1) modparam("siptrace","trace_flag",13) I had the following message in kamailio logs: Dec 1 17:17:55 km36133 /usr/sbin/kamailio[5522]: INFO: usrloc [hslot.c:53]: locks array size 512 Dec 1 17:17:55 km36133 kernel: [10765022.447713] kamailio[5522]: segfault at 0 ip 0 sp 7fffffffc748 error 4 in kamailio[400000+1f7000] Dec 1 17:17:55 km36133 kamailio: ERROR: <core> [daemonize.c:269]: Main process exited before writing to pipe Is it a known issue? Do you have an idea how to fix that, or at least how to activate siptrace module without craching Kamailio. Regards.

13 years, 5 months

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 December 2010