[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