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.
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.
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.
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
---
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
---
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.
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
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
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