Module: sip-router
Branch: master
Commit: 04f55d6c20fbb7628b3c672a5df5a0a1e2c67114
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=04f55d6…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Fri Feb 19 16:37:51 2010 +0100
Merge remote branch 'origin/andrei/blst_send_flags'
Support for blacklist ignore flags, both global and on a per
message basis.
E.g.:
per message:
if (method=~"MESSAGE")
blst_set_ignore(6);
global:
sercmd cfg.set_now_int core dst_blacklist_tcp_imask 16
* origin/andrei/blst_send_flags:
NEWS: minor blacklist flag number correction
tm: blacklist on 503 reply fixed for send flags
NEWS: mentioned blacklist ignore masks
core: cfg script support for blacklist ignore masks
blst: global config variables for ignoring blacklist events
blst: docs for blst_{set,clear}_ignore script functions
blst: functions for ignoring blacklist events
blst: use dst_blacklist_force_add
tm: simplified blacklist add code
blacklist: ignore mask support
tm: updated to the new snd_flags_t structure
core: send_flags preliminary blacklist support
Conflicts:
NEWS
cfg.lex
cfg.y
dst_blacklist.h
---
Module: sip-router
Branch: andrei/blst_send_flags
Commit: 0f2375f9216fd7f431e91d02f4ccc5dc9e4e5730
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0f2375f…
Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org>
Date: Fri Feb 19 15:35:57 2010 +0100
tm: blacklist on 503 reply fixed for send flags
Blacklisting the source of a 503 reply now obeys also the
blacklist ignore masks (both global and per message).
The ignore 503 blacklist flag can be set (and it will be obeyed)
in any route (be it main route, on branch, on send or the on_reply
route). E.g.: using blst_set_ignore(32) in the onsend_route for a
specific destination would cause the ignore 503 flag to be
inherited by the 503 reply (this is the only blacklist flag that
it's inherited this way).
---
modules/tm/t_reply.c | 25 ++++++++++++++-----------
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c
index 0b16fae..4e53584 100644
--- a/modules/tm/t_reply.c
+++ b/modules/tm/t_reply.c
@@ -1844,7 +1844,6 @@ int reply_received( struct sip_msg *p_msg )
#endif
#ifdef USE_DST_BLACKLIST
int blst_503_timeout;
- struct dest_info src;
struct hdr_field* hf;
#endif
#ifdef TMCB_ONSEND
@@ -1972,6 +1971,10 @@ int reply_received( struct sip_msg *p_msg )
switch_rb_retr_to_t2(&uac->request);
}
}
+ /* pre-set the ignore BLST_503 flag in the message, if the
+ corresponding branch had it set on send */
+ p_msg->fwd_send_flags.blst_imask|=
+ uac->request.dst.send_flags.blst_imask & BLST_503;
/* processing of on_reply block */
if (t->on_reply) {
set_route_type(ONREPLY_ROUTE);
@@ -2008,10 +2011,13 @@ int reply_received( struct sip_msg *p_msg )
}
#ifdef USE_DST_BLACKLIST
/* add temporary to the blacklist the source of a 503 reply */
- if (cfg_get(tm, tm_cfg, tm_blst_503)
- && cfg_get(core, core_cfg, use_dst_blacklist)
- && (msg_status==503)
- ){
+ if ( (msg_status==503) &&
+ cfg_get(tm, tm_cfg, tm_blst_503) &&
+ /* check if the request sent on the branch had the the
+ blst 503 ignore flags set or it was set in the onreply_r*/
+ should_blacklist_su(BLST_503, &p_msg->fwd_send_flags,
+ p_msg->rcv.proto, &p_msg->rcv.src_su)
+ ){
blst_503_timeout=cfg_get(tm, tm_cfg, tm_blst_503_default);
if ((parse_headers(p_msg, HDR_RETRY_AFTER_F, 0)==0) &&
(p_msg->parsed_flag & HDR_RETRY_AFTER_F)){
@@ -2027,12 +2033,9 @@ int reply_received( struct sip_msg *p_msg )
}
}
if (blst_503_timeout){
- src.send_sock=0;
- src.to=p_msg->rcv.src_su;
- src.id=p_msg->rcv.proto_reserved1;
- src.proto=p_msg->rcv.proto;
- dst_blacklist_add_to(BLST_503, &src, p_msg,
- S_TO_TICKS(blst_503_timeout));
+ dst_blacklist_force_su_to(BLST_503, p_msg->rcv.proto,
+ &p_msg->rcv.src_su, p_msg,
+ S_TO_TICKS(blst_503_timeout));
}
}
#endif /* USE_DST_BLACKLIST */
Revision: 5989
http://openser.svn.sourceforge.net/openser/?rev=5989&view=rev
Author: mariuszbihlei
Date: 2010-02-19 15:09:39 +0000 (Fri, 19 Feb 2010)
Log Message:
-----------
modules:acc Fixed a bug that caused global log_facility (the one in kamailio) to be overwritten by acc's log_facility if the module was loaded.
This caused log messages to be printed in the acc's log facility (really annoying if the )
In kamailio executable log_facility in the initialized Data segment (global variables) and elf's .dynsym section
, the dynamic symbol table, which contains all of the file's imported and exported symbols
08131cec D log_facility
Also the same can be said for acc's log facility
00007234 D log_facility
This caused that when dlopen() was called on acc.so, the .dynsym section to the concatenated, and caused the main's log_facility
to resolve to wrong symbol.
Patch by Timo Reimann(timo.reimann AT 1und1.de)
Modified Paths:
--------------
branches/1.5/modules/acc/acc.c
branches/1.5/modules/acc/acc_mod.c
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Hi, I'm dealing with presence right now. I've read full OMA and RCS
specifications/proposals/guidelines for presence and XCAP but I don't feel
comfortable with some parts of them.
So let me to explain the question (it involves the sr/kamailio presence module
behavior for a future re-design in which I want to participate):
In presence/XCAP/XDM there are three ways bob can deny alice to see his
presence status (by modifying the XCAP documents according):
1) Ignore alice's request. This is, bob doesn't "allow" neither "blocks"
alice, so alice just gets the first NOTIFY from the server with:
Subscription-Status: pending
After some long time the server will send:
Subscription-Status: terminated ; reason=expired
2) Block alice by invoking a "block" action. This means that alice receives a
NOTIFY from the server with:
Subscription-Status: terminated; reason=rejected
This is: alice *knows* that she has been explicitely blocked by bob.
3) Polite-block alice by invoking "polite-block" action. In this way the
presence server generates a spoofed NOTIFY for alice containing "offline"
information but the header:
Subscription-Status: active
This is: alice *things* she has been allowed by bob and bob it's offline right
now (not true).
Well, in real IM/presence world (MSN, Skype, XMPP, Yahoo...) option 2 doesn't
exist, am I right? This is, if you block an user he doesn't know that you have
blocked him. Instead just options 1 or 3 are used (and in some networks just
option 1).
Do you see any advantage in point 2? Personally I don't see it and it just
introduces too much complexity for presence/XCAP/XDM client developers.
I would appreciate your opinnions about it.
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#37 - tm clone msg / free_faked_req bug
User who did this - Andrei Pelinescu-Onciul (andrei)
Reason for closing: Fixed
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=37
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!
I have a client wich registers via IPv6 - that works. Now, if this
client is called, t_relay generates errors and no message is sent:
INFO: <script>: main branch in branch_route[1]:
INFO: <script>:
$ru=sip:klaus.darilion@[2A02:850:2:2:8C4:955A:C892:A15A]:1066;transport=UDP
INFO: <script>: $du=sip:[2A02:850:2:2:8C4:955A:C892:A15A]:1066
INFO: <script>: $bF=00000040
ERROR: <core> [resolve.c:1502]: ERROR: sip_hostport2su: could not
resolve hostname: "[2A02:850:2:2:8C4:955A:C892:A15A]"
ERROR: tm [ut.h:318]: failed to resolve "[2A02:850:2:2:8C4:955A:C892:A15A]"
regards
Klaus