The FS in front that doesn't handle the media is a good solution for me!<div>The incoming SIP call can be bridged with a simple round robin rule to "FS media server" and a called prefix number can be added by front FS (and removed by FS media server) to propagate the "source IP address".</div>
<div>Thank you for this info: I'll do some test on this solution.</div><div><br></div><div>Stephen<br><br><div class="gmail_quote">On Sun, Dec 12, 2010 at 9:51 PM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">It is, but it relies on the caller supporting 3xx. They might not<br>
handle the redirect.<br>
<br>
A lot won't because you could redirect them to anywhere, so lots of<br>
implementations will ignore the 3xx. FreeSWITCH for instance can<br>
either ignore a 3xx or will send the call back into the dialplan.<br>
<br>
I think you'll have more success having a FS server in front of the<br>
others and bridging the call through to each server. If you set<br>
inbound_bypass_media=true on the SIP profile, the RTP media will<br>
bypass that server and go directly between the caller and the other FS<br>
box. That means that the call won't be using any CPU since it'll only<br>
wake up when a SIP packet is being sent/received. You'll still be<br>
creating a session through so it'll still be allocating memory to the<br>
call, a SIP proxy would use fewer resources.<br>
<br>
-Steve<br>
<div><div></div><div class="h5"><br>
<br>
On 12 December 2010 19:28, Saeed Ahmed <<a href="mailto:saeedahmad1981@gmail.com">saeedahmad1981@gmail.com</a>> wrote:<br>
> Thanks Steve for suggestion, i'll check X-Auth-IP, its new for me.<br>
> Since we are talking about HA options... Is it practically doable use it:<br>
><br>
> <a href="http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_redirect#Example_2" target="_blank">http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_redirect#Example_2</a><br>
> The idea is to run one FS box (Redirect-FS) in front of several FS boxes<br>
> which redirect the call to active/available FS. If we make some script on<br>
> redirect FS to count the active calls on media FSes and rearrange the order<br>
> of redirect then loadbalacing can also be done.<br>
> ...possible?<br>
><br>
> On Sun, Dec 12, 2010 at 12:23 PM, Steven Ayre <<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>> wrote:<br>
>><br>
>> > 1. i am thinking to use kamailo in front of FS boxes, is there any<br>
>> > difference between kamailo and opensips?<br>
>><br>
>> They're both forks of OpenSER so for the most part there's little<br>
>> difference.<br>
>><br>
>> There are some small differences though since the fork. For example,<br>
>> opensips has a load_balancer module which kamalio does not (kamalio<br>
>> can still do load balancing but has a different interface to do so).<br>
>><br>
>> > 2. if kamailo or opensips is running in front of FS, then will it send<br>
>> > call<br>
>> > to FS with original customer ip? so i can do billing etc on FS box<br>
>> > -> actually i do IP based authentication and also ip based billing on FS<br>
>> > box, so in case, i recieve kamailo ip on FS box then i'll loose the<br>
>> > original<br>
>> > customer overview.<br>
>><br>
>> It will appear coming from the proxy IP. But there is a workaround.<br>
>> Configure a proxy ACL on the SIP profile and add your proxy IP to it.<br>
>> Then adjust your proxy routing rules so that it adds a X-Auth-IP<br>
>> header that contains the original IP.<br>
>> Anything coming from anything in the proxy ACL is trusted and FS will<br>
>> use the value from X-Auth-IP (if it exists).<br>
>><br>
>> -Steve<br>
>><br>
>><br>
>><br>
>><br>
>> On 11 December 2010 14:00, Saeed Ahmed <<a href="mailto:saeedahmad1981@gmail.com">saeedahmad1981@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > 1. i am thinking to use kamailo in front of FS boxes, is there any<br>
>> > difference between kamailo and opensips?<br>
>> ><br>
>> > 2. if kamailo or opensips is running in front of FS, then will it send<br>
>> > call<br>
>> > to FS with original customer ip? so i can do billing etc on FS box<br>
>> > -> actually i do IP based authentication and also ip based billing on FS<br>
>> > box, so in case, i recieve kamailo ip on FS box then i'll loose the<br>
>> > original<br>
>> > customer overview.<br>
>> ><br>
>> > thanks<br>
>> > On Tue, Dec 7, 2010 at 2:31 PM, Steven Ayre <<a href="mailto:steveayre@gmail.com">steveayre@gmail.com</a>> wrote:<br>
>> >><br>
>> >> There are a few performance tweaking tips at<br>
>> >> <a href="http://wiki.freeswitch.org/wiki/Performance_testing_and_configurations" target="_blank">http://wiki.freeswitch.org/wiki/Performance_testing_and_configurations</a>.<br>
>> >><br>
>> >> Yes a Sangoma card will reduce your CPU load since transcoding won't<br>
>> >> be done on the CPU any longer, that will then mean there's more CPU<br>
>> >> available so you'll be able to handle more calls.<br>
>> >><br>
>> >> However, if you're looking to increase your number of calls then you<br>
>> >> probably want a cluster of servers as Juan pointed out.<br>
>> >><br>
>> >> It'll mean you can increase the capacity by adding extra servers, so<br>
>> >> there'd no longer be a limit to the number of calls you could handle<br>
>> >> (just add another server).<br>
>> >><br>
>> >> It'll also make maintenance easier, as you'll be able to pull a server<br>
>> >> from service for updates etc while traffic continues to run on the<br>
>> >> other servers. Maintenance won't mean a service outage.<br>
>> >><br>
>> >> If you're handling that many calls then additional servers would make<br>
>> >> your service more reliable. If a server crashes you'll still have the<br>
>> >> calls running on the other servers while you're fixing the problem so<br>
>> >> you won't have a complete outage. If FS is behind a load balancer then<br>
>> >> your customers might not even notice anything apart from a few dropped<br>
>> >> calls.<br>
>> >><br>
>> >> There's <a href="http://wiki.freeswitch.org/wiki/Freeswitch_HA" target="_blank">http://wiki.freeswitch.org/wiki/Freeswitch_HA</a> which will<br>
>> >> attempt to continue calls if FS crashes and restarts, but I think<br>
>> >> that's only for SIP-SIP not SIP-ISDN.<br>
>> >><br>
>> >> -Steve<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> On 7 December 2010 12:26, Stephen Wilde <<a href="mailto:wstephen80@gmail.com">wstephen80@gmail.com</a>> wrote:<br>
>> >> > Hi,<br>
>> >> > I have one server running Freeswitch with some ISDN connections (via<br>
>> >> > FreeTDM+Sangoma boards) and some SIP connections with service<br>
>> >> > providers<br>
>> >> > and<br>
>> >> > customer.<br>
>> >> > The usage of Freeswitch is as switching so it "bridge" each incoming<br>
>> >> > call to<br>
>> >> > a new outgoing call.<br>
>> >> > SIP calls use G.729 and ISDN calls use ALaw for voice encoding.<br>
>> >> > Now the number of call is grow up and also the CPU load is a little<br>
>> >> > high<br>
>> >> > so<br>
>> >> > I have the necessity to scale UP my Freeswitch to handle more calls:<br>
>> >> > what is<br>
>> >> > the best way to do that?<br>
>> >> > My first idea is to use a Sangoma D500 board to reduce the CPU load.<br>
>> >> > Can<br>
>> >> > be<br>
>> >> > this a solution?<br>
>> >> > There are different way to scale UP?<br>
>> >> > Thanks in advance,<br>
>> >> > Stephen<br>
>> >> ><br>
>> >> > _______________________________________________<br>
>> >> > FreeSWITCH-users mailing list<br>
>> >> > <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> >> > <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> >> ><br>
>> >> > UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> >> > <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> >> ><br>
>> >> ><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> FreeSWITCH-users mailing list<br>
>> >> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> >> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> >><br>
>> >> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> >> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > FreeSWITCH-users mailing list<br>
>> > <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> > <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> > UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> > <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>> ><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> FreeSWITCH-users mailing list<br>
>> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
> _______________________________________________<br>
> FreeSWITCH-users mailing list<br>
> <a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
<br>
_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br></div>