[Freeswitch-users] FreeSwitch setup as a "Dumb" SBC
rod
kawarod at laposte.net
Tue Feb 3 23:09:52 PST 2009
One more thing,
I worked on a setup like yours:
- Kamailio as a registrar that do the routing decision
- FS as a SBC
What you have to do is just append an header with Kamailio and send the
invite to your FS server using something like that (use of pseudo
variables in Kamailio):
#-------------------------------------------
# PREPARE ROUTING USING REWRITING OF DOMAIN
#-------------------------------------------
if (is_method("INVITE") && from_uri==myself && src_ip!=10.10.10.254){
if(!cr_route("default", "0", "$rU", "$rU", "call_id")){
xlog("$ci CALLEE ROUTING FAILED: no route found");
sl_send_reply("604", "Unable to route this call");
exit;
} else {
xlog("$ci Route found for $rU via $rd");
}
}
# -----------------------------------------------------------------
# Route to FREESWITCH using domain rewriting applied above for LCR
# -----------------------------------------------------------------
xlog("$ci ROUTE: $rd");
append_hf("X-ROUTE: $rd\r\n");
rewritehostport("10.10.10.254:5062"); # there you have to distribute the
invite to your FS servers, take a look at the dispatcher module
Using that, the FS server receiving the Invite, just need to parse the
X-ROUTE header and route the call, without having to resend the call to
a Kamailio server.
I think you can adapt this scenario to your perl script using variable
exportation and append_hf function.
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
>
>
>
More information about the FreeSWITCH-users
mailing list