sr-dev May 2013

sr-dev@lists.kamailio.org

29 participants
317 discussions

[tracker] User took ownership: modules/debugger: activate/deactivate via cfg framework
by sip-router 21 May '13

21 May '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Víctor Seva has taken ownership of the following task: FS#298 - modules/debugger: activate/deactivate via cfg framework More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=298 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

[tracker] Task opened: modules/debugger: activate/deactivate via cfg framework (Attachment added)
by sip-router 21 May '13

21 May '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Víctor Seva (linuxmaniac) Attached to Project - sip-router Summary - modules/debugger: activate/deactivate via cfg framework Task Type - Improvement Category - Module Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - with this patch it's possible to activate/deactivate as: cfg.set_now_int dbg level_mode 1 dbg.mod_level tm 4 dbg.mod_level core 2 cfg.set_now_int dbg level_mode 0 One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=298 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

git:4.0: modules/auth_db: detailed documentation of URI checking in auth_check function
by Klaus Darilion 21 May '13

21 May '13

Module: sip-router Branch: 4.0 Commit: 721b0adc4addad2ed2da1579af21fc9b66915ddc URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=721b0ad… Author: Klaus Darilion <klaus.mailinglists(a)pernau.at> Committer: Klaus Darilion <klaus.mailinglists(a)pernau.at> Date: Tue May 21 12:39:15 2013 +0000 modules/auth_db: detailed documentation of URI checking in auth_check function --- modules/auth_db/README | 61 ++++++++++++++++++-------------- modules/auth_db/doc/auth_db_admin.xml | 12 +++++-- 2 files changed, 43 insertions(+), 30 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=721…

1 0

git:master: modules/auth_db: detailed documentation of URI checking in auth_check function
by Klaus Darilion 21 May '13

21 May '13

Module: sip-router Branch: master Commit: 31880a46d7f634b568cc192bec6db3d969e738ef URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=31880a4… Author: Klaus Darilion <klaus.mailinglists(a)pernau.at> Committer: Klaus Darilion <klaus.mailinglists(a)pernau.at> Date: Tue May 21 12:39:15 2013 +0000 modules/auth_db: detailed documentation of URI checking in auth_check function --- modules/auth_db/README | 15 +++++++++++---- modules/auth_db/doc/auth_db_admin.xml | 12 +++++++++--- 2 files changed, 20 insertions(+), 7 deletions(-) diff --git a/modules/auth_db/README b/modules/auth_db/README index 55de782..7bcc6f4 100644 --- a/modules/auth_db/README +++ b/modules/auth_db/README @@ -154,7 +154,7 @@ Chapter 1. Admin Guide For dbtext module (which stores data in plaintext files) it is directory in which the database resides. - Default value is “mysql://openserro:openserro@localhost/openser”. + Default value is “mysql://kamailioro:kamailioro@localhost/kamailio”. Example 1.1. db_url parameter usage ... @@ -399,7 +399,8 @@ if (!proxy_authorize("$fd", "subscriber)) { REGISTER, the second for the rest. In addition, a matter of flags parameter value, the function checks if - authentication username matches From/To header username. + authentication username matches From/To header username, and + Request-URI in case of PUBLISH. Meaning of the parameters is as follows: * realm - Realm is a opaque string that the user agent should present @@ -413,8 +414,14 @@ if (!proxy_authorize("$fd", "subscriber)) { The string may contain pseudo variables. * flags - set of flags to control the behaviour of the function. If it is 1, then the function will check to see if the authentication - username matches either To or From header username, a matter of - whether it is for a REGISTER request or not.. + username matches either To or From header username. REGISTER + requests: From and To must match the authentication user. PUBLISH + requests: From, To and Request-URI must match the authentication + user. All other requests: From header must match the authentication + user. + Additionally all domains in the checked URIs and the realm in the + authentication header will be checked to match the provided realm + parameter. The string may contain pseudo variables. This function can be used from REQUEST_ROUTE. diff --git a/modules/auth_db/doc/auth_db_admin.xml b/modules/auth_db/doc/auth_db_admin.xml index eac0351..999c3cf 100644 --- a/modules/auth_db/doc/auth_db_admin.xml +++ b/modules/auth_db/doc/auth_db_admin.xml @@ -477,7 +477,7 @@ if (!proxy_authorize("$fd", "subscriber)) { <para> In addition, a matter of <emphasis>flags</emphasis> parameter value, the function checks if authentication username matches From/To header - username. + username, and Request-URI in case of PUBLISH. </para> <para>Meaning of the parameters is as follows:</para> <itemizedlist> @@ -508,8 +508,14 @@ if (!proxy_authorize("$fd", "subscriber)) { <para><emphasis>flags</emphasis> - set of flags to control the behaviour of the function. If it is 1, then the function will check to see if the authentication username matches either To or - From header username, a matter of whether it is for a REGISTER - request or not.. + From header username. REGISTER requests: From and To must match the + authentication user. PUBLISH requests: From, To and Request-URI must + match the authentication user. All other requests: From header must + match the authentication user. + </para> + <para> + Additionally all domains in the checked URIs and the realm in the + authentication header will be checked to match the provided realm parameter. </para> <para> The string may contain pseudo variables.

1 0

git:richard.good/diameter_rx_media: Merge branch 'master' into richard.good /diameter_rx_media
by Richard Good 21 May '13

21 May '13

Module: sip-router Branch: richard.good/diameter_rx_media Commit: 297f1bf10873b5a84e70036fae10d50684d92128 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=297f1bf… Author: Richard Good <richard.good(a)smilecoms.com> Committer: Richard Good <richard.good(a)smilecoms.com> Date: Tue May 21 14:06:39 2013 +0200 Merge branch 'master' into richard.good/diameter_rx_media ---

1 0

git:tmp/tm_async_reply_support: Merge branch 'master' into tmp/ tm_async_reply_support
by Richard Good 21 May '13

21 May '13

Module: sip-router Branch: tmp/tm_async_reply_support Commit: 10165e4ce452dbc8d72ed592e65a63c2de461a0c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=10165e4… Author: Richard Good <richard.good(a)smilecoms.com> Committer: Richard Good <richard.good(a)smilecoms.com> Date: Tue May 21 14:04:33 2013 +0200 Merge branch 'master' into tmp/tm_async_reply_support ---

1 0

[tracker] Comment added: UAC generates messages with a NULL body which failes in SANITY module check
by sip-router 20 May '13

20 May '13

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#295 - UAC generates messages with a NULL body which failes in SANITY module check User who did this - oren avraham (orenav) ---------- Here is my code $uac_req(method) = "REGISTER"; $uac_req(ruri) = $sht(websocket=>$si:$sp:ruri); $uac_req(furi) = $sht(websocket=>$si:$sp:furi); $uac_req(turi) = $sht(websocket=>$si:$sp:turi); $uac_req(hdrs) = $sht(websocket=>$si:$sp:hdrs); if (uac_req_send() < 0) xlog("L_ERROR","Failed sending unregister request"); and also a code for debug the sanity check: if (!sanity_check("2")) { xlog("SANITY: uri scheme\n"); exit; } if (!sanity_check("4")) { xlog("SANITY: no mininal set of required headers\n"); exit; } if (!sanity_check("64")) { xlog("SANITY: cseq value\n"); exit; } if (!sanity_check("32")) { xlog("SANITY: cseq method\n"); exit; } if (!sanity_check("128")) { xlog("SANITY: content length: cl=$cl rb= $rb bs=$bs mb=$mb\n"); exit; } if (!sanity_check("256")) { /* the register contains an invalid expires value and is replied with a 400 */ xlog("SANITY: invalid expires\n"); exit; } if (!sanity_check("1024","7")) { /* the register contains an invalid expires value and is replied with a 400 */ xlog("SANITY: bad uris\n"); exit; } if(!sanity_check("1511", "7")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } I generate the message from a saved register message, that i've altered its expired contact parameter to 0. When the generated message is run within main_route it gets to the sanity check and fails with check no.128 and its $rb is null. Hope it was helpfull.. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=295#comment882 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

1 0

pass fd to timer proc
by Matthew Williams 20 May '13

20 May '13

Hi, In the jsonrpc-c module, a pipe is used to send commands into the jsonrpc process. We've run into an issue where the timer process needs to send on that pipe, but it does not have access to the file descriptor. So far we have been unable to identify a method for passing the fd into the timer process. Any thoughts or suggestions on this would be appreciated. -- Matthew Williams Flowroute LLC

1 1

ACK sometimes routed incorrectly on latest git master
by Peter Dunkley 20 May '13

20 May '13

Hello, The configuration is: Jitsi #1 registered with sip2sip.info Jitsi #2 registered with my server(s) (Kamailio edge proxy and Kamailio registrar) on Amazon AWS running Kamailio from git master I make a call from Jitsi #1 to Jitsi #2 (there are SRV records for my domain in Amazon Route 53 so that sip2sip.info can find my servers). The flow of the call is: Jitsi #1 -> sip2sip.info -> Kamailio edge proxy -> Kamailio registrar -> Kamailio edge proxy -> Jitsi #2 The calls do not get established properly because the ACK is not correctly routed. Calls between two Jitsi instances registered on my servers works. Calls from Jitsi #2 to Jitsi #1 (my servers to sip2sip.info) also work. This problem occurs whatever the value of the "enable_double_rr" modparam. The 200 OK (INVITE) sent from my servers back to sip2sip.info looks OK and has a valid looking route-set: SIP/2.0 200 OK To: <sip:...callee...@...callee domain...>;tag=e5116094 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.0;i=0efbc,SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-23ca624fe9c119f229080992ed4fc143 Record-Route: <sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:e.f.g.h;r2=on;lr=on>,<sip:81.23.228.129;r2=on;lr;ftag=2d246de3;did=989.4a20eb73>,<sip:81.23.228.129:5061;transport=tls;r2=on;lr;ftag=2d246de3;did=989.4a20eb73> CSeq: 2 INVITE Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 From: "Caller" <sip:...caller...@sip2sip.info>;tag=2d246de3 Contact: "callee" <sip:...callee...@10.6.201.224:60847;transport=tls;registering_acc=...callee domain...> User-Agent: Jitsi2.3.4622.9647Linux Content-Type: application/sdp Content-Length: 838 ...lots of SDP... The ACK from sip2sip.info to my servers looks OK too: ACK sip:...callee...@174.129.184.181:5060;transport=tls;registering_acc=...callee domain... SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller" <sip:...caller...@sip2sip.info>;tag=2d246de3 To: "callee" <sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 69 Route: <sip:e.f.g.h;r2=on;lr=on>,<sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on> Contact: "Caller" <sip:...caller...@90.152.0.102:52379;transport=tls;registering_acc=sip2sip_info> User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0 But the ACK from from my edge proxy to my registrar looks very broken: ACK sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/TCP e.f.g.h:5060;branch=z9hG4bKdb93.444f42f24139f6dc512d70f61ca64be4.0 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller" <sip:...caller...@sip2sip.info>;tag=2d246de3 To: "callee" <sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 16 Route: <sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on> Contact: "Caller" <sip:...caller...@a.b.c.d:52379;transport=tls;registering_acc=sip2sip_info> User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0 With debug turned up on the edge proxy I see the output from lines 673 and 723 indicating that the loose.c:after_strict() is run. My edge proxy configuration is: request_route { route(REQINIT); route(OPTIONS); sip_trace(); setflag(F_SIPTRACE); if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } route(WITHINDLG); ... route[WITHINDLG] { if (has_totag()) { if (!loose_route()) { switch($rc) { case -2: send_reply("403", "Forbidden"); exit; default: if (is_method("ACK")) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } send_reply("404","Not Found"); } } else { if ($rc == 2) { setflag(F_OB_DRIVEN); } if (is_method("NOTIFY")) { record_route(); } route(RELAY); } exit; } } Have I done something fundamentally stupid here, or is there some obscure bug in the loose/strict routing code? Regards, Peter

2 1

unREGISTER not working on recent master (built Saturday evening) when usrloc db_mode = 3
by Peter Dunkley 20 May '13

20 May '13

This un-REGISTER: REGISTER sip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To: <sip:...user...@...domain...> From: <sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact: <sip:pufj2a59@18vku8fabcfq.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5>";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path: <sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Results in this 200 OK (with 0 bindings): SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To: <sip:...user...@...domain...>;tag=8ab1eb0246bb313f703b656487ebc696.9519 From: <sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path: <sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Supported: outbound Require: outbound Content-Length: 0 But with usrloc db_mode set to 3 the corresponding record remains in the database. When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table. It looks like some recent change to the way usrloc interacts with the database has broken something. Regards, Peter

3 12

← Newer
1
...
11
12
13
14
15
16
17
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2013