sr-users

sr-users@lists.kamailio.org

17 participants
37528 discussions

Proposal to extend acc/dialog modules in order to log CDRs
by Timo Reimann 07 Feb '11

07 Feb '11

Hi all, I'd like to bring forward a proposal for creating CDRs (Call Data Records) from Kamailio by means of extending both acc and dialog modules. Feedback is very welcome. So far, CDR generation requires post-processing of log entries created by the (transaction-based) acc module or some other means. Looking at OpenSIPS (which is already capable of producing CDRs), my idea is to copy the basic notion of tracking dialogs for to-be-accounted calls and log a proper CDR on termination. Creating basic CDRs including start time, end time, and call duration can be accomplished quite easily this way. Apart from this very minimum CDR content, however, one can think of a number of CDR fields that cannot be filled easily. For instance, caller identity isn't always contained in the From header (think of CLIR calls) but need to be determined from other headers depending on the type of call, possibly even involving a database lookup. That's why I'd like to provide a way to pass additional, CDR-specific data from the configuration file to the dialog structure associated with the call. When the dialog is about to terminate, the extended acc module would make sure that the added CDR data associated to the dialog is included in the CDR. This way, users may define CDR fields to their personal needs from the configuration file in a flexible manner. In order to accomplish this, the dialog module would need to be extended such that dialog-specific data may be stored for the duration of a dialog (which is not possible to this day AFAICS). A new setter function attached to the dialog interface (struct dlg_binds) could accept a simple key/value pair for storage purposes. Exporting this function to the configuration file and accompanying it with a corresponding getter function will ensure that dialog-specific data may be written and read generically. Thus, improvements to the dialog module may be leveraged not just for CDR-accounting purposes. Regarding the acc module, a couple of new features need to be implemented: First, the introduction of another module parameter called something like "cdr_fields" that comprises the set of key names designated for CDR inclusion. Hence, a line like modparam("acc", "cdr_fields", "caller, callee, foo, bar") would require Kamailio configurators to store dialog-specific values for the keys "caller", "callee", "foo", and "bar", respectively, during call processing. The values will be fed to the dialog structure employing the new dialog store function explained above. Second, when the acc module is in CDR mode, dialogs shall be tracked from creation to termination using dialog callbacks. On termination of a dialog, values from keys referenced in the "cdr_fields" parameter will be fetched from the terminating dialog structure and associated with the new, fresh CDR. Third, the CDR is persisted to either log file, database, or both. Note that my approach would not touch the existing acc module functionality: CDR mode is supposed to be working in addition to transaction-based accounting as people will likely want to keep transaction logs for debugging or similar needs. A flag would enable and disable CDR generation at will. I have not fully investigated re-usability possibilities but believe that acc's persistence functions may be taken advantage of by the new CDR-producing parts as well. That's it with regards to the basic mode of operation. I am also thinking of having a few other features, such as using a switch to set the call start time to the moment the ACK or OK is seen instead of the INVITE (because users shouldn't be billed for call setup times). Looking forward to seeing your feedback on this proposal. Cheers, --Timo

3 6

topoh, angle brackets and Contact URI params interpretation
by Andrew Pogrebennyk 07 Feb '11

07 Feb '11

I'm having an issue with topoh module in Kamailio 3.1.0. When Contact header is formed like this: Contact: 0991 <sip:192.168.0.107;line=sr-N6IAzBysz.tyz.D4M.VLOBMfOBFuWxvfMxV4> The other party responds properly. But when there is no angle brackets in Contact: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy* Really, many parsers implement "prefer shift to reduce" principle, which means if something can be interpreted in more enclosed expression, it will be interpreted this way and no as part of less enclosed expression so ;line is interpreted as header parameter but not URI parameter. RFC 3261 section 20 suggests that any URI parameters be contained within angle brackets: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === I think the topoh module should force the angle brackets. BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1: other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" No .-* characters are allowed in the paramchar. But at least that's not causing me any problems. -- Sincerely, Andrew Pogrebennyk

3 6

Compiling Just One Module
by Amit Nepal 07 Feb '11

07 Feb '11

Could someone guide me how to compile and install just one module with flavor set to kamailio ? -- Thank You Amit Nepal Systems Administrator Phoenix Internet Phone: 602-385-0731 602-234-0917#112 http://www.phoenixinternet.net

3 4

authentication is not working
by Danny Dias 06 Feb '11

06 Feb '11

Hello my friends, I'm trying to configure authentication on my Kamailio and is not working at all :( I've added the following to the script to make it work: (but it doesn't) ... loadmodule "auth.so" loadmodule "auth_db.so" ... modparam("usrloc", "db_url", "mysql://kamailio:kamailiorw@localhost/kamailio") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "mysql://kamailio:kamailiorw@localhost/kamailio") modparam("auth_db", "load_credentials", "") ... if (!(method=="REGISTER") && from_uri==myself) /*no multidomain version*/ { if (!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); exit; } if (!db_check_from()) { sl_send_reply("403","Forbidden auth ID"); exit; } consume_credentials(); } ... if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; } ## if (!db_check_to()) { sl_send_reply("403","Forbidden auth ID"); exit; } if (!save("location")) sl_reply_error(); exit; } But is not working at all...take a look: # U 2011/02/03 09:31:04.402891 172.30.140.22:48752 -> 172.30.140.8:5060 REGISTER sip:172.30.140.8 SIP/2.0 Via: SIP/2.0/UDP 172.30.140.22:48752 ;branch=z9hG4bK-d87543-9a54af22967ae417-1--d87543-;rport Max-Forwards: 70 Contact: <sip:1000@172.30.140.22:48752;rinstance=fcade2df86ce0ab8> To: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>> From: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>>;tag=cd3e2323 Call-ID: MmU0YjM1NThiNTg0ZjhiNGM4ODA4ZmU1YWFiYjBmNTc. CSeq: 1 REGISTER Expires: 3600 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 # U 2011/02/03 09:31:04.404039 172.30.140.8:5060 -> 172.30.140.22:48752 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.140.22:48752 ;branch=z9hG4bK-d87543-9a54af22967ae417-1--d87543-;rport=48752 To: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8> >;tag=c97b4d1cb1f3d0da549e06a8d482ef63.34dc From: "1000"<sip:1000@172.30.140.8 <sip%3A1000(a)172.30.140.8>>;tag=cd3e2323 Call-ID: MmU0YjM1NThiNTg0ZjhiNGM4ODA4ZmU1YWFiYjBmNTc. CSeq: 1 REGISTER Contact: <sip:1000@172.30.140.22:48752 ;rinstance=fcade2df86ce0ab8>;expires=3600 Content-Length: 0 Am i missing something in my configuration? Thanks in advance!!!

5 12

503 Server error response for REGISTER request (Asterisk v1.6.0.5)
by Vikram Ragukumar 04 Feb '11

04 Feb '11

Hello, I had posted this question earlier on asterisk-users, but didn't receive any reply, so I'm posting on sr-users in the hope that someone can provide guidance on how to debug this problem. Our setup involves a Sip softphone registering with a fresh install of Asterisk v1.6.0.5 through an outbound proxy (Kamailio v3.1.1). We observe that about 80% of the time, immediately after startup of the softphone, when the softphone sends a REGISTER message, Asterisk replies with a "503 Server error". However, subsequent REGISTER messages are replied to appropriately (with a 401 Unauthorized). There are very few devices (under 5) registered with Asterisk, so this is not an overload issue. Please find attached a SIP trace for device registration. - What might cause this behavior in Asterisk ? - Are there any config file parameters that require to be changed ? - Would it help to see any other specific logs, if so which ones ? Thanks and Regards, Vikram.

2 3

SIP Router 3.03 topoh
by dotnetdub 04 Feb '11

04 Feb '11

Hi All, Kamailio had just started to get SIP attacked and it looked like they were sending a bad header and Kamailio died.. Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [R-MAIN =>] Request method OPTIONS is to our domain (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1] Received registration from sip:1368250498@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1] Received registration from sip:100@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3374]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.401446] kamailio[3374]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3373]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.636774] kamailio[3373]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3388]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.680305] kamailio[3388]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3390]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.710444] kamailio[3390]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1] Received registration from sip:2478223614@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3378]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.753334] kamailio[3378]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1] Received registration from sip:noauth@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3375]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.768137] kamailio[3375]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.775628] kamailio[3383]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3386]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.790925] kamailio[3386]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.798926] kamailio[3379]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3381]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.815493] kamailio[3381]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:54 sipproxy sip[3344]: INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD Nov 20 19:48:54 sipproxy sip[3399]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3396]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3400]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3392]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3401]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3394]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3402]: INFO: <core> [main.c:788]: INFO: signal 15 received Thanks Brian

4 20

dispatcher - ds_mark_dst("i"); is inactive only few seconds
by Thomas Baumann 04 Feb '11

04 Feb '11

Dear sr-users, I use this straight forward dispatcher config. In the failure route I am calling this function: ds_mark_dst("i"); Also this action is logged: Feb 2 17:20:31 node5 /openser/sbin/kamailio[15945]: INFO: : FAIL_ONE:time [Wed Feb 2 17:20:31 2011] destination sip:10.12.19.31:5060 marked as inactive The gateway is inactive: [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=I priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Few seconds later the gateway is active again (there is still now response to SIP-OPTIONS) [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=A priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Does anybody have a idea why ? regards, Thomas DB: mysql> select * from dispatcher -> ; +----+-------+----------------------+-------+----------+---------------------+-------------+ | id | setid | destination | flags | priority | attrs | description | +----+-------+----------------------+-------+----------+---------------------+-------------+ | 1 | 1 | sip:10.12.19.21:5060 | 0 | 0 | test1=123;test2=456 | AS 1 | | 2 | 1 | sip:10.12.19.31:5060 | 0 | 0 | test1=123;test2=456 | AS 2 | +----+-------+----------------------+-------+----------+---------------------+-------------+ CONFIG: #!KAMAILIO ####### Defined Values ######### #!define WITH_MYSQL #!define WITH_IPAUTH # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://openser:openserrw@10.12.18.51/openser" #!endif debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ alias="m-lab-ca805-sig.kd-lab.de:5060" alias="m-lab-ca805-sig.kd-lab.de" alias="10.12.19.51" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:10.12.19.51:5060 listen=tcp:10.12.19.51:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 ####### Modules Section ######## # set paths to location of modules mpath="/usr/local/kamailio-3.1/lib/kamailio/modules_k/:/usr/local/kamailio-3.1/lib/kamailio/modules/" # ------------------ module loading ---------------------------------- loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dialplan.so" loadmodule "avpops.so" loadmodule "dispatcher.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- dispatcher params ----- #modparam("dispatcher", "list_file", "/openser/etc/kamailio/dispatcher.list") modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1@m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); }; #!ifdef WITH_IPAUTH if (!allow_source_address()) { sl_send_reply("403", "Forbidden"); exit; } #!endif # Send to application servers for number evaluation if ($rU=~"^0[1-9][0-9]{5,20}$") { ds_select_dst("1","0"); if (method=="INVITE") { t_on_failure("FAIL_ONE"); } t_relay(); exit(); } sl_send_reply("403", "Forbidden"); exit; } # Sample failure route failure_route[FAIL_ONE] { if (t_check_status("408")) { xlog("L_INFO", "FAIL_ONE:time [$Tf] destination $avp(dsdst) marked as inactive \n"); ds_mark_dst("i"); } exit; } ___________________________________________________________ NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://produkte.web.de/go/webdefreephone

2 5

Reloading a module without restart
by Stagg Shelton 04 Feb '11

04 Feb '11

Is it possible to reload a module such as siptrace without requiring a full restart of kamailio. I have changed my db_url modparam for the siptrace module and would like to avoid restarting kamailio if possible. Thanks Stagg

3 3

Problem with ser
by Asuncion Merino Rodriguez 02 Feb '11

02 Feb '11

Hello, i have insalled a ser server sucessfully. To try it, we was registered by a softphone, but when i am calling to the another registered user, he hang the phone but we cant ear anything. Can somebody help me? Thanks

1 0

Redundancy between 2 Kamailio servers
by Danny Dias 02 Feb '11

02 Feb '11

Hello my friends, I wonder if someone has done this before? i would like to implement 2 Kamailio servers with redundancy, something like the following: SERVER_A is working as the primary sip proxy (virtual IP as the sip signaling), if it fails, the other server (sleeping) should UP the virtual IP and takes all the traffic....i guess there is many Linux implementations thah can do this, but i would like to know if there is someone that has done this before and hear some recomendations... I've read some difficulty in the synchronisation of registrations because Kamailio works best when it stores registrations in memory and registrations are constantly changing - they expire and are renewed, as well as new ones joining and old ones leaving. To make the failover solution function seamlessly, it is necessary to synchronise the in-memory registrations between the primary and the backup server . This can be done by forking a copy of the registration request to the backup server, but there are some practical problems in doing this, has anyone do something with this? Thanks in advance!

6 21

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