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

Rod. kawarod at laposte.net
Tue May 4 01:12:45 PDT 2010


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
> To: 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
> 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/20100504/a6e4aa98/attachment-0001.html 


More information about the FreeSWITCH-users mailing list