[asterisk-users] Fwd: SER as a Session Border Controller

[Alex Balashov]

On Sat, 12 May 2007, Atlanticnynex said something to this effect:

> 'SIP Redirect Proxy', which I'm understanding to just redirect the SIP 
> requests to the appropriate destination based on the routing logic- and 
> OpenSER is no longer involved in the call process (meaning that 
> accounting can no longer be handled); but I hear their are many different 
> ways for OpenSER to behave, can this include my described configuration?

   I gather that OpenSER can be combined with rtpproxy to stay in the media 
path as well, if desired.  And really, OpenSER can behave however you want;
it allows you full read/write modification of pretty much any SIP header.

   In terms of what module to use for this, I had a very hard time with this 
too since, believe it or not, for such a ubiquitous open-source package,
it did not offer a straightforward way of making SQL database dips without
relying on the particular schema of some module or another.

   Ultimately, I found that the 'avp' module has a little function called
avp_db_query() which can extract query results and stick them in individual
AVP values.  This function may have just been put there for kicks, since
what AVP "really" implements is some transparent way of storing key/value
pairs.

   So, what I really end up doing for most of my intelligent routing is 
something like:

---

           avp_db_query("SELECT ip_addr, port FROM customer_proxies WHERE 
customer_id = $avp(S:customer_id) AND active = true",
"$avp(S:proxy_ip);$avp(S:proxy_port)");

         if(!is_avp_set("$avp(S:proxy_ip)") ||
            !is_avp_set("$avp(S:proxy_port)")) {
                 xlog("L_INFO", "target-das - [$ci] - Active proxy not 
found.\n")
;
                 sl_send_reply("404", "Not Found");
                 exit;
         }

         xlog("L_INFO", "target-das - [$ci] - Resolved proxy 
$avp(S:proxy_ip):$avp(S:proxy_port)\n");

         avp_pushto("$ru/domain", "$avp(S:proxy_ip):$avp(S:proxy_port)");

         xlog("L_INFO", "target-das - [$ci] - Attempting handoff to $ru\n");

         avp_delete("$avp(S:customer_id)");
         avp_delete("$avp(S:proxy_ip)");
         avp_delete("$avp(S:proxy_port)");

---

   Seems like the simplest approach to me.

> My SIP users can't know who the Upstream Providers are, so all traffic must
> be 'relayed' through my server, including media.

   In that case, use Asterisk as an SBC and keep it in the media path 
perhaps, or tack on an RTP proxy to OpenSER, although unfortunately I can 
tell you absolutely nothing about how to go about this.

> I've confirmed that my SIP users can authenticate to OpenSER via the 
> RADIUS module, but 1) how do I keep track of the call detail records 
> {minutes used, user info, dest. info} and report it back to RADIUS?

   A decent RADIUS module will have the capability log the accounting 
information into a RADIUS accounting backend as well, since accounting is a 
key component of RADIUS.  If not, you can use something akin to what I 
described above to keep the CDRs yourself.

> how do can OpenSER authenticate to my Upstream Providers?

   I am not sure if it can.  There may have to be a B2BUA somewhere further 
upstream within your "backend platform," as is not infrequently done.

   In other implementations I've seen, all connections to providers are done 
on a hard-coded port/IP-mapped "peer" basis so that proxies can hand calls
off straight to them.  But another way is to put another SBC-type unit at
the egress to the provider(s) to take care of that.  Just beware that this
comes with the full implications of a B2BUA--distinct logical call legs.

Best of luck,

-- Alex

--
Alex Balashov   <sasha at presidium.org>