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
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#37 - tm clone msg / free_faked_req bug
User who did this - Klaus Darilion (klaus3000)
----------
Hi Andrei!
Thanks, no crashes anymore.
Probably you will update master too.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=37#comment29
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.