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