Hello,
do you have any news about this case?
About the described scenario:
I think the step 4a) may be a bug:
the subscription STATUS of B (watcher of A) to A should remain ACTIVE (1)
instead of PENDING(2). this state is very strange and that causes the
strange step 4b) after A having removed B. Because B does still subscribe
A’s presentity! And probably do this causes the incorrect behavior of step
5)?
Should the presence server also remove the record of the subscription from
A(watcher) to B(presentity) from both active_watchers and watchers tables
instead of only from active_wtachers table? Because if A remove B
(unsubscribe B), that mean A don’t want to see the presentity of B. Or maybe
it’s correct put A’s subscription status of B in TERMINATED(3) instead of
removing the record (actually remains in ACTIVE(1)).
When the presence server is doing pres_refresh_watchers in step 5), I think
it checks the xcap table and see A is watcher of B (A is in B’s
presence_allow rule) and is in B’s resource-list, and B is also
active_watcher of A in the active_watchers table, A’s subscription status of
B is ACTIVE(1) in watchers table, B’s subscription status of A is in
Pending(2), it send a NOTIFY to B. That’s really strange! Probabely the step
4) also causes this strange behavior.
I think in step 1, in addition to remove the record of A’s subscription of B
from active_watchers table, the PS should also remove the record of A’s
subscription of B from the watchers table or put the STATUS=TERMINATED.
That’s because A is not interested the B’s presentity anymore.
In step 4, the PS should not change watchers table, because B’s subscription
of A is still active (should not becomes pending), and should not send the
Pending notify too.
Same for step 5.
thanks in advance,
laura
On Wed, May 25, 2011 at 06:54, Jeremya <jeremy(a)electrosilk.net> wrote:
> These figures pale into insignificance compared to the power required
> for standard SIP devices - typically 5-8 watts per device multiplied by
> the number of devices.
>
> When you factor in Gigabit Ethernet the power ups significantly.
>
> Optimisation at the server level is not significant on any scale.
> Optimisation on communications power: i.e. end-devices, DSL & switches
> is where the power savings are important.
Sure, the total power consumption of the whole system is dominated by
the power consumption of end-point devices, there's no doubt about
that and the paper says that.
Nevertheless, as an ITSP you are typically paying for the energy
consumed by your servers and in that case knowing what you can expect
and how many servers you need is useful. Modern data-center servers
have significant base-line power consumption and a portion of that
needs to be attributed to the SIP service running on those servers.
-Jan
> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> Jan Janak conducted a very interesting research project regarding
>> energy efficiency of VoIP systems during 2010, a collaboration between
>> iptel.org and Columbia University.
>>
>> The team used the source code from sip-router.org GIT repository from
>> January 2010, which corresponds to Kamailio (former OpenSER) and SER
>> v3.0. The latest stable series v3.1 shares the same internal
>> architecture with v3.0.
>>
>> As part of the research work, Jan could also gather some figures about
>> capacity and performances of v3.0 with a quite complex configuration
>> file: etc/sip-router-oob.cfg (involving authentication and NAT
>> traversal as well).
>>
>> You can read the paper about energy efficiency at:
>>
>> - Green VoIP Article: http://asipto.com/u/2j
>>
>> The draft notes about capacity and performances of v3.0 are available at:
>>
>> - Performances and Capacity for v3.0 Wiki page: http://asipto.com/u/2k
>>
>> Some interesting results:
>>
>> - one instance of SIP server with 500 000 online users (mixed users –
>> behind and not NAT routers) – consumed energy 210W
>> - one instance of SIP server with 1 000 000 online users (no NAT
>> involved) – consumed energy 190W
>> - on a 32-bit machine with 4GB of memory and with 2.5GB reserved for
>> SIP server, the server could support 43 000 simultaneous TLS
>> connections – consumed energy 203W
>> - one SIP server instance with 80 000 permanent TCP connections, the
>> SIP server could still handle at least 1000 requests per second and a
>> connection arrival rate of 1000 new connections per second, done for
>> 20 000 new connections. CPU load generated by the SIP server was from
>> 6% to 8%.
>>
>> I added a new section to the draft notes to list the enhancements done
>> for the latest stable release (v3.1.x) that contribute to performance
>> improvements, like asynchronous TLS, fine tuning of memory for TLS
>> connections and raw UDP sockets.
>>
>> Cheers,
>> Daniel
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
Hi, "sip:alice@domain.org" is registered in Kamailio. If the proxy
receives a request for "sips:alice@domain.org" and invokes
"lookup(location)" the function doesn't retrieve the registration of
alice. But it should:
RFC 5630 section 3.3:
When used as the Request-URI of a request, the SIPS scheme
signifies that each hop over which the request is forwarded, until
the request reaches the SIP entity responsible for the domain
portion of the Request-URI, must be secured with TLS; once it
reaches the domain in question it is handled in accordance with
local security and routing policy, quite possibly using TLS for
any last hop to a UAS. When used by the originator of a request
(as would be the case if they employed a SIPS URI as the address-
of-record of the target), SIPS dictates that the entire request
path to the target domain be so secured.
Note the last phrase:
When used by the originator of a request
(as would be the case if they employed a SIPS URI as the address-
of-record of the target), SIPS dictates that the entire request
path to the target domain be so secured.
This is, the entire path *until* the proxy responsible for the domain
in the RURI must be secure (TLS) but it's not required (local policy)
that the destination proxy dellivers the request to the destination
user using TLS.
So IMHO lockup(location) should not inspect the registration schema. Am I wrong?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Dear All,
I'm using SER as a SIP proxy server for quite a long time. I'm not
been able to find its load bearing capacity. If you can help me get a
figure in terms of BHCA, that'll be quite helpful.
Thanks and Regards,
--Piyush Bansal
The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.