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")…
[View More]
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
---
[View Less]
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 …
[View More]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 */
[View Less]
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 …
[View More]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.
[View Less]
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, …
[View More]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>
[View Less]
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, …
[View More]you can change your notification settings at the URL shown above.
[View Less]
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: …
[View More]"[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
[View Less]