Thanks Alex, for the quick and detailed response. I really appreciate it.<br>Well, that's pretty much what I've been getting from my reading. <br>I'm curious as to what areas (specifically, modules/features) of OpenSER I should look into to accomplish this.
<br>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.<br>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.
<br>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.<br><br>So in short I this is what I'm looking to do:
<br><br><br>(SIP Users)----------------------[ ] /--------- (Upstream SIP Provider)<br>(SIP Users)----------------------[ My Switch/ Backend Platform ] 0 --------------(Upstream SIP Provider)
<br>(SIP Users)----------------------[ (LCR trunk selection, CDR, outbound auth.) ] \--------------(Upstream SIP Provider)<br><br>My SIP users can't know who the Upstream Providers are, so all traffic must be 'relayed' through my server, including media.
<br>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.
<br><br>Thanks,<br><br>kn0x<br><br><br><div><span class="gmail_quote">On 5/12/07, <b class="gmail_sendername">Alex Balashov</b> <<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Greetings,<br><br> It is my impression that Asterisk cannot safely handle more than about
<br>100-200 calls in parallel, but it may be possible to increase the yield by<br>removing any transcoding and offloading some of the channel functionality<br>to hardware DSP boards. I do not know much about this, and specifically do
<br>not know how much help they would be if there is no transcoding to be<br>performed per se.<br><br> Some of the stuff you're wanting to do - authenticating via RADIUS,<br>perform an LCR lookup, select trunks - is best done by a proxy that sits
<br>behind Asterisk. OpenSER can certainly interface with this kind of call<br>logic, and what's more, it can act as a registrar. It certainly does have<br>a bit of an abstruse learning curve, but I can say it's not impossible to
<br>figure out by any stretch of the imagination, having been through that<br>multiple times for inbound call processing / distribution tasks.<br><br> I am not sure that what you are attempting to describe really fits the
<br>definition of a session border controller, however. An SBC really only<br>holds the SIP URI reachability information (contacts) for end-users and<br>not much else. In most other respects it behaves rather like a proxy;
<br>authentication is done by handoff to a backend registrar/proxy, any kind<br>of call routing is also typically farmed out to backend proxies. The<br>SBC more or less does exactly what its name suggests; it provides a
<br>"border," a logical horizon of call control. Otherwise, it's a pretty<br>dumb device, whereas what you appear to be alluding to sounds more like<br>a rather intelligent processing endpoint.<br><br> Sometimes the SBC stays in the media path, and sometimes it doesn't. It
<br>depends on the implementation. And some SBCs can provide primitive native<br>registrars, but this isn't typically thought scalable or desirable from a<br>systems integration standpoint.<br><br> So, in the grand scheme of things, the situation usually resembles:
<br><br> +----------+<br> | Backend |<br> Client <--/- Internet -/----> SBC <----> | Platform |<br> | -------- |
<br> +----------+<br><br> A "backend platform" can be an array of specialised proxies and<br>registrars, which may or may not be one and the same, that ultimately<br>
direct the call to other endpoints within or outside of the service<br>provider's network. Or it can be a softswitch that has a built-in<br>call agent / registrar / proxy / media gateway rolled in, or any number<br>of other curious configuration possibilities.
<br><br>-- Alex<br><br><br>--<br>Alex Balashov <<a href="mailto:sasha@presidium.org">sasha@presidium.org</a>><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">
Easynews.com</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br></blockquote></div><br>