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
--
Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello all,
I’m trying to configure my Kamailio environment with multiple Presentation
Server in active/active mode. This should be needed in order to manage the
scalability problem.
So, I have already installed two PS/Registrar Servers but we have a problem
when a message is delivered from the SERVER (such as Notify event) to a
client who have not an active connection with the same server: I mean, the
server isn’t able to deliver the message Notify to the destination client
(values of ip, port, protocol di PC client are in the active_watchers table)
when this client doesn’t already have an active connection with the same
Server.
We encountered a similar problem using the TLS: it was solved using the NAT
Traversal module and the right configuration (as also you suggested us) but
we were using only one server and all the connection were opened from all
client to the same server.
Working with more than one PS/Registrar Server, each Server doesn’t have the
connections opened from all the client because they are distributed to one
or to the other one Server.
The Registrar seems to be ok because it’s involved in the client
authentication steps, so it saves the the sip client location in the DB and
that’s it.
We seem that the problem is to deliver the messages (NOTIFY/MESSAGE/INVITE)
from the server to the destination client if the destination client doesn’t
have an open connection with the same server (information are in the
location table) which is managing those messages.
Please, consider that we are also using the TLS and the NAT Traversal. And
the version of Kamailio is the 3.1.3 on Redhat5.6_x64.
Could you please help us to understand how configure Kamailio Servers in the
described scenario?
Thanks in advance.
laura
Hi, by inspecting the code it seems there is no problem if "grp" field
in table "address" becomes "mediumint" rather than "smallint" (as
now).
In my case I use diferent intervals within "grp" value to determine
the nature of the source IP of a request (requests from clients, from
trusted nodes, from PSTN gateways...) so I need to change it to
"mediumint" (and works well).
Could it be changed in the database schema so no manual change would
be required?
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hello Klaus,
thanks a lot for your answer.
Please, see my comment (BOB:>) below .
Message: 8
Date: Mon, 23 May 2011 09:47:23 +0200
From: Klaus Darilion <klaus.mailinglists(a)pernau.at>
Subject: Re: [sr-dev] kamailio 3.1.3 Presence + XCAP problem, is it a
bug?
To: sr-dev(a)lists.sip-router.org
Message-ID: <4DDA110B.2020907(a)pernau.at>
Content-Type: text/plain; charset=windows-1252
Am 20.05.2011 17:00, schrieb laura testi:
> Hello,
>
>
>
> I?m wring you again about the Presence = xcap Problem on Kamailio
> related with the deleting of a contact.
>
> Here a detailed description we have observed:
> User Case:
> ------------------
> - user A is a contact of B and viceversa.
> - then user A removes B from PC client
>
>
> 1) A sends SUBSCRIBE B to Kamail Presence Server (PS) with even type:
> presence and Expire:0 without body
> a) PS removes A as wacther of B from the active_watchers table
> b) PS sends NOTIFY to B (from B to B) with event type:
> presence.winfo and Subscription State:active,expire=570
> c) PS sends NOTIFY to A (from B to A) with event type: Presence and
> Subscription State: terminated,reason=timeout
>
> 2) A sends XCAP PUT to PS with updated pres-rules without B in
> presence_allow rule
> a) PS update xcap table the pres-rules record of A (without B)
>
>
> 3) A sends XCAP PUT to PS with updated resource-lists without B
> a) PS update xcap table the resource-lists record of A(without B)
>
> 4) the script kamailio.cfg calls pres_update_watchers
> a) PS updates watcher table by setting the status = 2(pending) for
> the record of B is watcher of A (presentity), while the status remains
> active (1) for the record of A is watcher of B
> b) PS sends NOTIFY to B(from A to B) with event type: presence and
> subscription state: pending
>
> 5) the script kamailio.cfg calls pres_refresh_watchers
> a) PS sends NOTIFY to B(from A to B) with event type: presence and
> content type:application:pdif+xml (open, online, pdif entity:A,...)
> b) the PC client of B shows a popup by saying 5has authorized the B
> adds A as contact request
>
>
> Test environments:
> --------------------------
> - server: kamailio 3.1.3 with presence, xcap and mysql in Redhat5.6_x64
> - transport: tcp
> - db: mysql
> - client: jitsi (ex SIP communicator)
> - kamailio.cfg: please see the attached file kamailio.zip
>
> Questions:
> -----------------
> 1) is it correct the first SUBSCRIBE from the PC client of A?
Strictly said: subscribing someones presence and allowing someone to
subscribe its own presence are 2 different things. But, usually they
come together.
Thus, by removing someone from the buddy list Jitsi does:
- unsubscribe the presentity
- remove the presentity from the allowed watchers
IMO this is fine.
> 2) are the over all call flows correct (see the attached wireshark trace)
> 3) are the steps 2 and 3 correct?
IMO yes.
> 4) the steps 4 and 5 are very strange, is it the bug of xcap module
> or/and presence module?
I think 4 is OK. But step 5 seems buggy as.
BOB:>
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.
What do you think would be the correct behavior?
BOB:>
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,
laura
regards
klaus
Module: sip-router
Branch: 3.1
Commit: 4ffe22ae5215f48873438e788fa541d82c5ba3ad
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=4ffe22a…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Mon May 23 13:06:49 2011 +0200
htable: spelling fix in htable table definition docs
(cherry picked from commit 938b50beab952645438743720833070a484c07ab)
---
lib/srdb1/schema/htable.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/srdb1/schema/htable.xml b/lib/srdb1/schema/htable.xml
index 0344c7d..8de8ac3 100644
--- a/lib/srdb1/schema/htable.xml
+++ b/lib/srdb1/schema/htable.xml
@@ -12,7 +12,7 @@
<version>1</version>
<type db="mysql">&MYSQL_TABLE_TYPE;</type>
<description>
- <db:para>This table us used by the htabke module to load values in the hash table at start up. More information about the avpops module can be found at: &KAMAILIO_MOD_DOC;htable.html
+ <db:para>This table us used by the htable module to load values in the hash table at start up. More information about the htable module can be found at: &KAMAILIO_MOD_DOC;htable.html
</db:para>
</description>