[Freeswitch-users] Scale UP Freeswitch

David Ponzone david.ponzone at ipeva.fr
Mon Dec 13 16:36:15 MSK 2010 

Well OpenSIPS is a proxy and FreeSWITCH is a B2BUA.
If you just need to load-balance calls to your main FS boxes (which are used as B2BUA), to use another B2BUA for that task is not really useful.
A SIP Proxy is generally more efficient for this, as they are dedicated to handle lots of REGISTER & INVITE, but if you want to avoid the trouble to deal with OpenSIPS config, which I find far less intuitive than FreeSWITCH, you may use FreeSWITCH in bypass-media as proposed in this thread.

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 13/12/2010 à 14:26, Avi Marcus a écrit :

> Can someone explain what the difference is between using FS with bypass media and opensips? I've heard that opensips can handle a much higher CPS.
> -Avi
> 
> On Mon, Dec 13, 2010 at 11:41 AM, Steven Ayre <steveayre at gmail.com> wrote:
> You can use X-Auth-IP with a FS-FS call too:
> 
> Customer --> FS1 --> FS2
> FS1 = front FS
> FS2 = media server
> 
> 1. Create a proxy ACL on FS2
> 2. Add the IP of FS1 to that ACL
> 3. On FS1 do this in the dialplan:
> 
> <extension ...>
>  <condition ...>
>    <action application="set" data="sip_h_X-Auth-IP=${network_addr}" />
>    <action application="bridge" data="sofia/gateway/fs2/..." />
>  </condition>
> </extension>
> 
> FS2 will then be able to use the customer's IP in ACLs, user directory, etc.
> 
> Remember to either set inbound_bypass_media=true on the sip profile,
> or <action application="set" data="bypass_media=true" /> in dialplan
> before the bridge.
> 
> -Steve
> 
> 
> 
> On 12 December 2010 21:32, Saeed Ahmed <saeedahmad1981 at gmail.com> wrote:
> > hmmm... so doing that will also require X-Auth-IP, right or something more
> > tricky can be done?
> > On Sun, Dec 12, 2010 at 9:51 PM, Steven Ayre <steveayre at gmail.com> wrote:
> >>
> >> It is, but it relies on the caller supporting 3xx. They might not
> >> handle the redirect.
> >>
> >> A lot won't because you could redirect them to anywhere, so lots of
> >> implementations will ignore the 3xx. FreeSWITCH for instance can
> >> either ignore a 3xx or will send the call back into the dialplan.
> >>
> >> I think you'll have more success having a FS server in front of the
> >> others and bridging the call through to each server. If you set
> >> inbound_bypass_media=true on the SIP profile, the RTP media will
> >> bypass that server and go directly between the caller and the other FS
> >> box. That means that the call won't be using any CPU since it'll only
> >> wake up when a SIP packet is being sent/received. You'll still be
> >> creating a session through so it'll still be allocating memory to the
> >> call, a SIP proxy would use fewer resources.
> >>
> >> -Steve
> >>
> >>
> >> On 12 December 2010 19:28, Saeed Ahmed <saeedahmad1981 at gmail.com> wrote:
> >> > Thanks Steve for suggestion, i'll check X-Auth-IP, its new for me.
> >> > Since we are talking about HA options... Is it practically doable use
> >> > it:
> >> >
> >> > http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_redirect#Example_2
> >> > The idea is to run one FS box (Redirect-FS) in front of several FS boxes
> >> > which redirect the call to active/available FS. If we make some script
> >> > on
> >> > redirect FS to count the active calls on media FSes and rearrange the
> >> > order
> >> > of redirect then loadbalacing can also be done.
> >> > ...possible?
> >> >
> >> > On Sun, Dec 12, 2010 at 12:23 PM, Steven Ayre <steveayre at gmail.com>
> >> > wrote:
> >> >>
> >> >> > 1. i am thinking to use kamailo in front of FS boxes, is there any
> >> >> > difference between kamailo and opensips?
> >> >>
> >> >> They're both forks of OpenSER so for the most part there's little
> >> >> difference.
> >> >>
> >> >> There are some small differences though since the fork. For example,
> >> >> opensips has a load_balancer module which kamalio does not (kamalio
> >> >> can still do load balancing but has a different interface to do so).
> >> >>
> >> >> > 2. if kamailo or opensips is running in front of FS, then will it
> >> >> > send
> >> >> > call
> >> >> > to FS with original customer ip? so i can do billing etc on FS box
> >> >> > -> actually i do IP based authentication and also ip based billing on
> >> >> > FS
> >> >> > box, so in case, i recieve kamailo ip on FS box then i'll loose the
> >> >> > original
> >> >> > customer overview.
> >> >>
> >> >> It will appear coming from the proxy IP. But there is a workaround.
> >> >> Configure a proxy ACL on the SIP profile and add your proxy IP to it.
> >> >> Then adjust your proxy routing rules so that it adds a X-Auth-IP
> >> >> header that contains the original IP.
> >> >> Anything coming from anything in the proxy ACL is trusted and FS will
> >> >> use the value from X-Auth-IP (if it exists).
> >> >>
> >> >> -Steve
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On 11 December 2010 14:00, Saeed Ahmed <saeedahmad1981 at gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > 1. i am thinking to use kamailo in front of FS boxes, is there any
> >> >> > difference between kamailo and opensips?
> >> >> >
> >> >> > 2. if kamailo or opensips is running in front of FS, then will it
> >> >> > send
> >> >> > call
> >> >> > to FS with original customer ip? so i can do billing etc on FS box
> >> >> > -> actually i do IP based authentication and also ip based billing on
> >> >> > FS
> >> >> > box, so in case, i recieve kamailo ip on FS box then i'll loose the
> >> >> > original
> >> >> > customer overview.
> >> >> >
> >> >> > thanks
> >> >> > On Tue, Dec 7, 2010 at 2:31 PM, Steven Ayre <steveayre at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> There are a few performance tweaking tips at
> >> >> >>
> >> >> >> http://wiki.freeswitch.org/wiki/Performance_testing_and_configurations.
> >> >> >>
> >> >> >> Yes a Sangoma card will reduce your CPU load since transcoding won't
> >> >> >> be done on the CPU any longer, that will then mean there's more CPU
> >> >> >> available so you'll be able to handle more calls.
> >> >> >>
> >> >> >> However, if you're looking to increase your number of calls then you
> >> >> >> probably want a cluster of servers as Juan pointed out.
> >> >> >>
> >> >> >> It'll mean you can increase the capacity by adding extra servers, so
> >> >> >> there'd no longer be a limit to the number of calls you could handle
> >> >> >> (just add another server).
> >> >> >>
> >> >> >> It'll also make maintenance easier, as you'll be able to pull a
> >> >> >> server
> >> >> >> from service for updates etc while traffic continues to run on the
> >> >> >> other servers. Maintenance won't mean a service outage.
> >> >> >>
> >> >> >> If you're handling that many calls then additional servers would
> >> >> >> make
> >> >> >> your service more reliable. If a server crashes you'll still have
> >> >> >> the
> >> >> >> calls running on the other servers while you're fixing the problem
> >> >> >> so
> >> >> >> you won't have a complete outage. If FS is behind a load balancer
> >> >> >> then
> >> >> >> your customers might not even notice anything apart from a few
> >> >> >> dropped
> >> >> >> calls.
> >> >> >>
> >> >> >> There's http://wiki.freeswitch.org/wiki/Freeswitch_HA which will
> >> >> >> attempt to continue calls if FS crashes and restarts, but I think
> >> >> >> that's only for SIP-SIP not SIP-ISDN.
> >> >> >>
> >> >> >> -Steve
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On 7 December 2010 12:26, Stephen Wilde <wstephen80 at gmail.com>
> >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> > I have one server running Freeswitch with some ISDN connections
> >> >> >> > (via
> >> >> >> > FreeTDM+Sangoma boards) and some SIP connections with service
> >> >> >> > providers
> >> >> >> > and
> >> >> >> > customer.
> >> >> >> > The usage of Freeswitch is as switching so it "bridge" each
> >> >> >> > incoming
> >> >> >> > call to
> >> >> >> > a new outgoing call.
> >> >> >> > SIP calls use G.729 and ISDN calls use ALaw for voice encoding.
> >> >> >> > Now the number of call is grow up and also the CPU load is a
> >> >> >> > little
> >> >> >> > high
> >> >> >> > so
> >> >> >> > I have the necessity to scale UP my Freeswitch to handle more
> >> >> >> > calls:
> >> >> >> > what is
> >> >> >> > the best way to do that?
> >> >> >> > My first idea is to use a Sangoma D500 board to reduce the CPU
> >> >> >> > load.
> >> >> >> > Can
> >> >> >> > be
> >> >> >> > this a solution?
> >> >> >> > There are different way to scale UP?
> >> >> >> > Thanks in advance,
> >> >> >> > Stephen
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > 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 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 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 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 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 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 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 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 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/20101213/ee8e8c65/attachment-0001.html

More information about the FreeSWITCH-users mailing list