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@lists.freeswitch.org [mailto:freeswitch-users-bounces@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_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@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