VoIP Mailing List Archives

[ajlong at worldlink.net]

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@ ([email]+1NXXNXXXXXX@[/email])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

[krice at freeswitch.org]

Yes you can do that, but there is nothing that says you cant have FreeSWITCH just do those lookups and ENUM (FS Supports ENUM out of the box) and do the exact same thing so it would work like Provider -> ingress SBC -> egress SBC/Registration Server -> customer

Loosing a whole hop in the process

From: Adam Long <ajlong@worldlink.net>
Reply-To: <freeswitch-users@lists.freeswitch.org>
Date: Mon, 2 Feb 2009 22:05:17 -0500
To: <freeswitch-users@lists.freeswitch.org>
Subject: [Freeswitch-users] FreeSwitch setup as a "Dumb" SBC

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@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

[kawarod at laposte.net]

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:

[ajlong at worldlink.net]

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:

[krice at freeswitch.org]

Actually I currently deploy FreeSWITCH for high volume usage using
FreeSWITCH + mod_easyroute (I'm the author) and an advanced LCR module that
does things like load balancing across multiple media gateways, auto route
advance, and a few other nifty things... (this LCR module uses a proprietary
algorithm so its not open source but it is licensable)

With these things we do run OpenSER but only as a proxy to aggregate traffic
heading upstream toward certain carriers (like L3 who make any IP changes a
royal pain)

Now to get down to some hard numbers that we have experience

Equipment:

DB Servers: Dell 2650 RAID 3+1 or 0+1 depending on number of Spindles, Dual
3GHz XEON (single code old slow FSB ones), 4G RAM, running Centos 5.2 and
PostgreSQL 8.3

SIP Servers: Dell 1950 Dual Quad Core 2Ghz (E5335 part), 4 to 8G of RAM,
GIG-E ethernet, whatever hard drive was cheap at time of order. Nothing
really lives on these boxes but FreeSWITCH with mod_easyroute, mod_lcr_adv,
and some CDR processing stuff

DB servers feed all the route information... (yes we do the route lookups
from the DB in real-time, the problem with most LCRs in doing this is an
algorithm

Call Rates Sustained, 500 avg cps, > 2000 calls (that's 2 legs not 1), avg
invite delay 115ms (INVITE in to INVITE out measured with 'ngrep -q -t
INVITE' - Note this is not a true picture of PDD as a number of other
factors affect that, this is a picture of how much time we are adding on box
in delaying an INVITE message)

On Registrations we have experienced Registration/second rates exceeding 150
registrations per second using mod_xml_curl to feed the users directory. I
suspect, this number can be greatly increased if we were to feed directory
with something that cut out the apache and php over head

K

[kokoska.rokoska at pos...]

Ken Rice napsal(a):
...

[anthony.minessale at g...]

What does it look like if you serve the directory from the static xml file out of curiosity.


On Tue, Feb 3, 2009 at 4:11 PM, kokoska.rokoska <kokoska.rokoska@post.cz (kokoska.rokoska@post.cz)> wrote:

[kokoska.rokoska at pos...]

Anthony Minessale napsal(a):

[krice at freeswitch.org]

Never tried hah...


From: Anthony Minessale <anthony.minessale@gmail.com>
Reply-To: <freeswitch-users@lists.freeswitch.org>
Date: Tue, 3 Feb 2009 16:34:38 -0600
To: <freeswitch-users@lists.freeswitch.org>
Subject: Re: [Freeswitch-users] FreeSwitch setup as a "Dumb" SBC

What does it look like if you serve the directory from the static xml file out of curiosity.


On Tue, Feb 3, 2009 at 4:11 PM, kokoska.rokoska <kokoska.rokoska@post.cz> wrote:

[kawarod at laposte.net]

I did the test when I start looking at FS.
With 10 000 files in conf/directory/default mounted as a ramdisk (if not
in Ramdisk, the IO are too high) and an intel quad core q9550 (2.83Ghz)
with 4GB RAM and the db also in Ramdisk, I was stuck at approx 150cps
with a very high CPU usage. The version I used was 1.0.1, but not sure.


Anthony Minessale wrote:

[kawarod at laposte.net]

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:

[kawarod at laposte.net]

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:

[kokoska.rokoska at pos...]

Anthony Minessale napsal(a):

[kawarod at laposte.net]

Hi,

how many static xml files did you create for your test ?

rod.

kokoska rokoska wrote:

[kokoska.rokoska at pos...]

rod napsal(a):