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

[Atlanticnynex]

I've reposted to a new thread "Asterisk High Capacity Stability" as I don't
think the subject of this thread is appropriate anymore.

-kn0x

On 5/12/07, Alex Balashov <abalashov at evaristesys.com> wrote:
>
>
> 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>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070512/36e06f52/attachment.htm