[Freeswitch-users] Registration ODBC feeded by another registrar proxy
Phillip Jones
pjintheusa at gmail.com
Thu May 6 06:00:25 PDT 2010
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> 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 | 3755 | 10.10.55.254 | 10.10.55.254 |
> "user" <sip:3755 at 10.10.55.1:5060> <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
> 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
> 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
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>
>
>
> ------------------------------
> Hotmail: Free, trusted and rich email service. Get it now.<https://signup.live.com/signup.aspx?id=60969>
>
>
> _______________________________________________
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing listFreeSWITCH-users at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://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/20100506/9cf48d95/attachment-0001.html
More information about the FreeSWITCH-users
mailing list