[Freeswitch-users] FreeSwitch setup as a "Dumb" SBC

Tue Feb 3 22:59:48 PST 2009

Hi Adam,

I detailed a bit more my previous mail on this page:
http://wiki.freeswitch.org/wiki/SBC_Setup

Round robin is managed by the carrierroute module. Carrierroute will 
reply based on the probability you defined for a route, so if you define 
0.3 and 0.7 for the same prefix, your traffic will point to 2 different 
gateways with a probability of 30% for one and 70% for the others (If I 
understood well the behaviour of carrierroute).

For forking, what I do is that carrierroute replies with a code and not 
an IP address.
This code, is then used as a condition in FS and the dialplan matched 
could then propose serial or parallel forking (in the wiki, I detailed 
serial forking).

The idea is that you could define many combination of GWs, eg:
- code01: try IP_A then IP_B (serial)
- code02: try IP_B then IP_A (serial)
- code03: try IP_A and IP_C (parallel)

this setup is working for me as I do not have 1000 of GWs but I need a 
big routing table (approx 160000). I'm sure it could be possible to use 
the failure route functionnality of carrierroute to define a new route 
when the first one failed without having to define code.
The drawback of this method is that you can't define metrics/properties 
for a route (quality, cost, fax compliance...) in realtime, and this is 
where using/enhancing the native FS module mod_lcr could be better (I 
have no idea on how mod_lcr performs, I will give it a try).

rod

Adam Long wrote:
> Hi Rod,
>
> Great info, Thanks!
> Glad to see others are interested in the same concept.
> My reasons for SER as routing core and implementation is slightly different
> yet similar.
>
> I like your Redirect model, with that you are truly using your Kamailio as
> route server only. I would imagine very scalable.
> 	- Are you able to do any round robin, serial or parallel forking
> with this?
> 	- I wonder if multiple Contacts in the 302 response maybe with some
> logic in FreeSwitch dialplan?
> If so I think your design is a bit more efficient than mine as it keeps SER
> out of the call path.
>
> My design is little different.. it is more of a "Stateful" setup.  With SER
> staying in call path and FreeSwitch at Edge.
> I do this to enable Serial Forking to a series of SBCs (FreeSwitch) geo
> distributed, when one of the branches is congested it
> forks to the next SBC (route).
>
> The FreeSwitch guys are probably right tho... with mod_easyroute and mod_lcr
> we could probably implement all of this in FreeSwitch without SER.
> I would be curious to know if anyone is doing something similar at high
> volumes and what sort of concurrency and cps they
> are able to achieve.
>
> I am a Perl and C# guy, I thought about implementing a mod_manged_lcr with
> memcached support.
> Memcache support would prob boost the scalability by a factor of 10 at
> least.
>
> I will let you know if I end up developing a high performance FreeSwitch
> route module.
> Right now I use memcache in a OpenSIPS perl script for my route caching and
> its incredibly fast
> and clusters well.
>
> It actually might be easier to add memcached support to mod_lcr and
> mod_easyroute but im not real strong in C/C++
>
> I'll jump on IRC later and chat with some of the experts on this as I know
> memcache has been discussed before.
> I'd be curious to know if any progress has been made there already. 
>
>
> Regards,
> -Adam
>
> -----Original Message-----
> From: freeswitch-users-bounces at lists.freeswitch.org
> [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of rod
> Sent: Tuesday, February 03, 2009 1:33 AM
> To: freeswitch-users at lists.freeswitch.org
> Subject: Re: [Freeswitch-users] FreeSwitch setup as a "Dumb" SBC
>
> Hi Adam,
>
> I'm in the process of using FS as a SBC. For the route lookup, I do it 
> using OpenSER carrierroute, without having to flow through 
> SBC---Openser---SBC. I'm using carrierroute at this time cause I need 
> more than 200 000 routing entries and carrierroute has been tested with 
> twice this number.
>
> Here is the setup:
>
> - install openser and carrierroute and make openser listening on 
> 127.0.0.1:5062 (for example) on your SBC
> - populate carrierroute table
>
> What I do to use carrierroute module from FS is to use a specific 
> X-header (X-LOOKUP).
>
> In the dialplan, in the default context, I have something like this:
> <extension name="LOOKUP_ROUTE">
> <condition field="destination_number" expression="(\d+)$">
> <action application="set" data="hangup_after_bridge=true"/>
> <action application="set" data="continue_on_fail=true"/>
> <action application="export" data="sip_h_X-ROUTE=LOOKUP"/>
> <action application="bridge" 
> data="sofia/internal/${sip_req_user}@127.0.0.1:5062"/>
> <action application="export" 
> data="sip_h_X-ROUTE=${sip_redirect_contact_host_0}"/>
> <action application="transfer" data="${destination_number} XML ROUTING"/>
> </condition>
> </extension>
>
> The process is simple:
> the export "sip_h_X-ROUTE=LOOKUP" had a sip header X-ROUTE=LOOKUP
> then I bridge the call to 127.0.0.1:5062 (openser process)
>
> In openser I have a route block that checks the presence of header 
> LOOKUP and openser sends a "604: unable to route call" if the prefix is 
> not found, or a "302: with the IP of the gateway found"
>
> In FS, you can get the IP using the variable 
> "${sip_redirect_contact_host_0}". Then I transfer this to the context 
> ROUTING, where the check condition is based on the LOOKUP header that 
> has been rewritten with this variable.
>
> I will document all this setup (installation of openser/carrierroute and 
> config file of FS and openser) on a wiki page I start writing yesterday, 
> so please be indulgent and patient.
> The next step is to test the scalability of this.
>
> I'm a very bad programmer, so that's the only way for me to contribute 
> to FS, and as I see many people interested for an SBC setup, I think it 
> could be great if we share our work/knowlegde.
>
> The wiki page is there:
> http://wiki.freeswitch.org/wiki/SBC_Setup
>
> regards,
> rod.
>
>
>
>
>
> Adam Long wrote:
>   
>> Hi Guys,
>>
>> I've been working at setting up a couple of FreeSwitch nodes as a 
>> topology hiding SBCs that handles both ingress traffic from my
>>
>> providers/peers and pass traffic up to an openser router that then 
>> routes call across the cluster of SBCs through which they reach the 
>> destination.
>>
>> I have OpenSIPS/SER setup doing DB route lookups and ENUM with 
>> LCR/Serial forking etc.
>>
>> My question is what would be the best way to send a call out to a 
>> destination choosen by the OpenSER router?
>>
>> For example:
>>
>> SIP Provider -- > SBC --- > OpenSER ---- ( route lookup returns 
>> 123.123.123.4 as dest ) -- > SBC --- > 123.123.123.4
>>
>> I was thinking something along the lines of adding a "X-Route-To: 
>> +1NXXNXXXXXX@ <mailto:+1NXXNXXXXXX@>123.123.123.4" with openser
>>
>> and then something like this in the SBC.
>>
>> <context name="from-sipcore">
>>
>> <extension name="outboundroute">
>>
>> <action application="bridge" data="sofia/external/${sip_h_X-Route-To}" />
>>
>> </extension>
>>
>> </context>
>>
>> Is this a wise approach, is there anything I could do to do this better?
>>
>> I'd like to keep the logic in the SBCs as simple as possible.
>>
>> I am pretty familiar with SIP but my knowledge fades when it gets into 
>> the nitty gritty of routing. ie the Contact: and Via: headers
>>
>> and all that good stuff.
>>
>> I should also state I have two profiles defined one for the 
>> internal/private "core" network and one for the outside "external" 
>> network.
>>
>> Any thoughts on this at all would be greatly appreciated.
>>
>> Am I missing something in the SIP spec that would allow for this is a 
>> standardized way?
>>
>> Regards,
>>
>> -Adam
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>
>   