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

[Atlanticnynex]

Thanks Alex, for the quick and detailed response. I really appreciate it.
Well, that's pretty much what I've been getting from my reading.
I'm curious as to what areas (specifically, modules/features) of OpenSER I
should look into to accomplish this.
Essentially I don't want any endpoint to endpoint traffic or visibility
(both endpoints only see the 'backend platform' as their endpoint) for SIP
and RTP.
I understand the most common OpenSER configuration is that it acts only as a
'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? Also, just
to clarify,  I do not plan to transcode anything- or any other molestation
of the media stream.
I'm sure there must be some way to do this all, as I hear a great number of
VoIP carriers have employed (Open)SER and other open source software to run
their networks.

So in short I this is what I'm looking to do:


(SIP Users)----------------------[
                        ]  /--------- (Upstream SIP Provider)
(SIP Users)----------------------[              My Switch/ Backend
Platform          ] 0 --------------(Upstream SIP Provider)
(SIP Users)----------------------[   (LCR trunk selection, CDR, outbound
auth.) ]  \--------------(Upstream SIP Provider)

My SIP users can't know who the Upstream Providers are, so all traffic must
be 'relayed' through my server, including media.
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? and 2) how do can
OpenSER authenticate to my Upstream Providers? I've been pointed to the
'UAC' module, but how can I integrate that with the LCR  module (each
'gateway' / provider has different authentication info. and the LCR module
mentions nothing about outbound authentication)? It is very important that
the SIP Users are not relayed the outbound authentication info for security
purposes.

Thanks,

kn0x


On 5/12/07, Alex Balashov <abalashov at evaristesys.com> wrote:
>
>
> Greetings,
>
>    It is my impression that Asterisk cannot safely handle more than about
> 100-200 calls in parallel, but it may be possible to increase the yield by
> removing any transcoding and offloading some of the channel functionality
> to hardware DSP boards.  I do not know much about this, and specifically
> do
> not know how much help they would be if there is no transcoding to be
> performed per se.
>
>    Some of the stuff you're wanting to do - authenticating via RADIUS,
> perform an LCR lookup, select trunks - is best done by a proxy that sits
> behind Asterisk.  OpenSER can certainly interface with this kind of call
> logic, and what's more, it can act as a registrar.  It certainly does have
> a bit of an abstruse learning curve, but I can say it's not impossible to
> figure out by any stretch of the imagination, having been through that
> multiple times for inbound call processing / distribution tasks.
>
>    I am not sure that what you are attempting to describe really fits the
> definition of a session border controller, however.  An SBC really only
> holds the SIP URI reachability information (contacts) for end-users and
> not much else.  In most other respects it behaves rather like a proxy;
> authentication is done by handoff to a backend registrar/proxy, any kind
> of call routing is also typically farmed out to backend proxies.  The
> SBC more or less does exactly what its name suggests;  it provides a
> "border," a logical horizon of call control.  Otherwise, it's a pretty
> dumb device, whereas what you appear to be alluding to sounds more like
> a rather intelligent processing endpoint.
>
>    Sometimes the SBC stays in the media path, and sometimes it
> doesn't.  It
> depends on the implementation.  And some SBCs can provide primitive native
> registrars, but this isn't typically thought scalable or desirable from a
> systems integration standpoint.
>
>    So, in the grand scheme of things, the situation usually resembles:
>
>                                               +----------+
>                                               | Backend  |
>      Client <--/- Internet -/----> SBC <----> | Platform |
>                                               | -------- |
>                                               +----------+
>
>    A "backend platform" can be an array of specialised proxies and
> registrars, which may or may not be one and the same, that ultimately
> direct the call to other endpoints within or outside of the service
> provider's network.  Or it can be a softswitch that has a built-in
> call agent / registrar / proxy / media gateway rolled in, or any number
> of other curious configuration possibilities.
>
> -- 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/3caefdd9/attachment.htm