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-boun...@lists.freeswitch.org > [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of rod > Sent: Tuesday, February 03, 2009 1:33 AM > To: freeswitch-users@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_us...@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org