[Freeswitch-users] Registration ODBC feeded by another registrar proxy

Rod. kawarod at laposte.net
Fri May 7 01:25:54 PDT 2010


Thanks Philipp,

for the 40 000 users, I'm just playing with FS at the moment. I know 
that clustering is the way to go, but at the moment I'm just trying FS 
as a big PBX.

rod.

Le 06/05/2010 17:00, Phillip Jones a écrit :
> Ron,
>
> I don't know - but I suspect that expires is a actual time. That would 
> make sense to me - something like:
>
> expires = epochNow + timeout;
>
> As for the 40,000 users - are you really planning doing this on one 
> box? Registrations + there traffic? Surely doing a FS cluster as 
> discussed or having OpenSIPS handle registration would be the way to 
> go here.
>
>
>
> On Thu, May 6, 2010 at 5:13 AM, Rod. <kawarod at laposte.net 
> <mailto:kawarod at laposte.net>> wrote:
>
>     Hi,
>
>     At the moment, I'm registering 40000 users in FS using ODBC with
>     no more than 16 registration/sec.
>     When I do a select in the sip_registrations table, I see that
>     every sip_user have an expires value equal to something like
>     "1273141208" even if I'm using an expire value of 3600 in my sip
>     register request.
>
>     +-----------------------+----------+--------------+----------------+-----------------------------------+-----------------+---------+------------+------------+-------------+---------------+--------------+----------+------------+--------------+--------------+--------------+----------+--------------+------------------+---------------+
>     | call_id               | sip_user | sip_host     | presence_hosts
>     | contact                           | status          | rpid    |
>     expires    | user_agent | server_user | server_host   |
>     profile_name | hostname | network_ip | network_port | sip_username
>     | sip_realm    | mwi_user | mwi_host     | orig_server_host |
>     orig_hostname |
>     +-----------------------+----------+--------------+----------------+-----------------------------------+-----------------+---------+------------+------------+-------------+---------------+--------------+----------+------------+--------------+--------------+--------------+----------+--------------+------------------+---------------+
>     | 83755-2574 at 10.10.55.1 <mailto:83755-2574 at 10.10.55.1> | 3755    
>     | 10.10.55.254 | 10.10.55.254   | "user"
>     <sip:3755 at 10.10.55.1:5060> <mailto:sip:3755 at 10.10.55.1:5060> |
>     Registered(UDP) | unknown | 1273141208 | SIPp/Linux | 3755       
>     | 172.30.30.129 | internal     | voip     | 10.10.55.1 |
>     5060         | 3755         | 10.10.55.254 | 3755     |
>     10.10.55.254 | 172.30.30.129    | voip          |
>     +-----------------------+----------+--------------+----------------+-----------------------------------+-----------------+---------+------------+------------+-------------+---------------+--------------+----------+------------+--------------+--------------+--------------+----------+--------------+------------------+---------------+
>
>     When I look in the sofia status profile, it seems that the correct
>     expires value is set. Any idea why the expires is not set
>     accordingly to the SIP REGISTER.
>
>     Moreover, when doing a "sofia status profile internal" with such a
>     huge subscribers list, the CPU is at 100% and processing no more
>     SIP messages.
>     Is there a way to prevent this, by setting for example a lower
>     priority to CLI request. I already mounted the SQLlite DB in RAM
>     to avoid IO bottlenecks.
>
>     regards,
>     rod
>
>
>     Le 04/05/2010 12:12, Rod. a écrit :
>>     Hi,
>>
>>     I already thought about that, as I'm using static IP it could be
>>     even easier.
>>     But how to check network connectivity issue and reroute call to
>>     voicemail asap: call progress timeout ??
>>
>>     rod
>>
>>
>>
>>     Le 03/05/2010 21:42, Jan Berger a écrit :
>>>     May a suggest a change filter developed if this really is needed?
>>>
>>>     Re-loading everything just in case something has changes is a
>>>     huge waste of bandwidth and CPU - if you install an intelligent
>>>     change filter you would be down to a few entries changing.
>>>
>>>     Jan
>>>
>>>     ------------------------------------------------------------------------
>>>     Date: Mon, 3 May 2010 21:06:54 +0400
>>>     From: kawarod at laposte.net <mailto:kawarod at laposte.net>
>>>     To: freeswitch-users at lists.freeswitch.org
>>>     <mailto:freeswitch-users at lists.freeswitch.org>
>>>     Subject: Re: [Freeswitch-users] Registration ODBC feeded by
>>>     another registrar proxy
>>>
>>>     Hi,
>>>
>>>     thanks for your answer and just some details to describe what
>>>     I'm looking for.
>>>     I have to register 25 000 subscribers, no NAT is involved, each
>>>     equipment has its own IP address.
>>>     These equipments are registering every 60 seconds on our current
>>>     platform, but I can change this parameter if needed.
>>>     Equipments are ADSL CPE (router), that's why I'm using 60sec
>>>     cause flapping could happen very often with ADSL if the copper
>>>     line is crappy. ADSL could be very unpredictable sometimes.
>>>     As I don't want to delay too much forwarding to voicemail if a
>>>     user is unavailable (network issue), 60 sec was chosen (bandwith
>>>     is not an issue). But as I told before, I'm open to your
>>>     suggestions.
>>>
>>>     To Philip, using a single SIP proxy (opensips/ser...) in front
>>>     of a FS cluster could be a single point of failure too.
>>>     I think that maybe a solution using DNS SRV to distribute the
>>>     load across a cluster could do the trick or some kind of LVS
>>>     (virtual IP shared across many servers)
>>>     XML curl is a good idea too.
>>>     To be honest, clustering is a must to avoid a single point of
>>>     failure, but FS performance as a SBC are really great even on
>>>     commodity hardware, more than 100 CallPerSecond with no
>>>     transcoding. That's why I think that a mix with a SIP registrar
>>>     and FS (and redundancy) could easily handle my 25 000
>>>     subscribers. I did some lab (one or 2 years ago) with Kamailio
>>>     registering 90 000 users every 60sec (1500 Registration per
>>>     second) without any issues.
>>>     In my network, 25 000 users are not pushing more than 10 CPS and
>>>     500 simultaneous call. I'm not doing VoIP termination.
>>>
>>>     At the moment, I'm just collecting data/feedback on what could
>>>     be done as I have some time to work on this project, and if
>>>     going further I will share the configuration as I did before:
>>>     http://wiki.freeswitch.org/wiki/SBC_Setup (not the best setup,
>>>     but hope it helps users to begin with FS)
>>>
>>>     regards,
>>>     rod.
>>>
>>>
>>>
>>>
>>>     Le 03/05/2010 19:54, David Ponzone a écrit :
>>>
>>>         Rod,
>>>
>>>         Registering every 60 seconds is a bad idea, and this should
>>>         not be justified.
>>>         You should register every 1800 seconds and send a NAT
>>>         keepalive every X seconds.
>>>         X should be slightly lower than the NAT UDP timeout of the
>>>         router in front of the phones, if the phones are behind NAT.
>>>         If the phones are not behind NAT, NAT keepalive is not
>>>         necessary.
>>>
>>>         David Ponzone Direction Technique
>>>         email: david.ponzone at ipeva.fr <mailto:david.ponzone at ipeva.fr>
>>>         tel:      01 74 03 18 97
>>>         gsm:   06 66 98 76 34
>>>
>>>         Service Client IPeva
>>>         tel:      0811 46 26 26
>>>         www.ipeva.fr  - www.ipeva-studio.com
>>>
>>>         /Ce message et toutes les pièces jointes sont confidentiels
>>>         et établis à l'intention exclusive de ses destinataires.
>>>         Toute utilisation ou diffusion non autorisée est interdite.
>>>         Tout message électronique est susceptible d'altération.
>>>         /*/IPeva/*/ décline toute responsabilité au titre de ce
>>>         message s'il a été altéré, déformé ou falsifié. Si vous
>>>         n'êtes pas destinataire de ce message, merci de le détruire
>>>         immédiatement et d'avertir l'expéditeur./
>>>         /
>>>         /
>>>
>>>
>>>
>>>         Le 03/05/2010 à 15:39, Rod. a écrit :
>>>
>>>             Hi list,
>>>
>>>             was playing with FS 1.0.6 and trying to test the
>>>             registration
>>>             performance of FS. (Yes I know FS is more suited as a
>>>             B2BUA, but please
>>>             read further :p)
>>>
>>>             So I did the following:
>>>                 - generate one xml file with 20 000 user account
>>>             like this:
>>>             <include>
>>>             <user id="1">
>>>             <params>
>>>             <param name="password" value="1234"/>
>>>             </params>
>>>             </user>
>>>             <user id="2">
>>>             <params>
>>>             <param name="password" value="1234"/>
>>>             </params>
>>>                         ...
>>>
>>>             Then I used Sipp to test how many registration per
>>>             second could be fired
>>>             to the server (quad core 2.83Ghz).
>>>             I setup ulimit variables, and disable nat.
>>>
>>>             I got this:
>>>                 - using SQL Lite: unable to get higher than 80
>>>             registrations per
>>>             second (in fact it's less than this number but didn't
>>>             test too much this
>>>             setup), I see a lot of retransmission in Sipp
>>>                 - using SQL Lite in ramdisk (tmpfs): OK with 80
>>>             registrations per
>>>             second but not much
>>>                 - using ODBC and mysql: 130 reg/sec is OK
>>>
>>>             With ODBC, above 150 reg/sec I see that FS is stalled to
>>>             100-110% CPU, I
>>>             think it's because I'm using only one SIP profile and
>>>             that SOFIA is
>>>             monothreaded for this SIP profile.
>>>             If I'd like to register every 60sec, the server has to
>>>             support at least
>>>             more than 300 registration per second.
>>>
>>>             So I'm wondering if I could setup something like this:
>>>                 - use another SIP Proxy as a registrar and feed the
>>>             ODBC
>>>             "sip_registration database" of FS
>>>                 - FS will be able to use this database to setup a call
>>>                 - use FS as the outbound proxy for call routing
>>>
>>>             But what about the user params that have been setup in
>>>             the xml file
>>>             above. I think that FS loads the user params each time a
>>>             user is registered.
>>>
>>>             Comments and advices are welcome.
>>>
>>>             regards,
>>>             rod.
>>>
>>>
>>>
>>>             _______________________________________________
>>>             FreeSWITCH-users mailing list
>>>             FreeSWITCH-users at lists.freeswitch.org
>>>             <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>>             http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>             UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>             http://www.freeswitch.org <http://www.freeswitch.org/>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         FreeSWITCH-users mailing list
>>>         FreeSWITCH-users at lists.freeswitch.org  <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>>         http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>         UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>         http://www.freeswitch.org  <http://www.freeswitch.org/>
>>>            
>>>
>>>
>>>
>>>     ------------------------------------------------------------------------
>>>     Hotmail: Free, trusted and rich email service. Get it now.
>>>     <https://signup.live.com/signup.aspx?id=60969>
>>>
>>>
>>>     _______________________________________________
>>>     FreeSWITCH-users mailing list
>>>     FreeSWITCH-users at lists.freeswitch.org  <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>>     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>>     UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>>     http://www.freeswitch.org
>>>        
>>
>>
>>     _______________________________________________
>>     FreeSWITCH-users mailing list
>>     FreeSWITCH-users at lists.freeswitch.org  <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>     UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>     http://www.freeswitch.org
>>        
>
>
>     _______________________________________________
>     FreeSWITCH-users mailing list
>     FreeSWITCH-users at lists.freeswitch.org
>     <mailto:FreeSWITCH-users at lists.freeswitch.org>
>     http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>     UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>     http://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100507/5f481a4a/attachment-0001.html 


More information about the FreeSWITCH-users mailing list