[Users] openser setup as a telephony gateway (to PSTN) for NAT'd clients

[Ovidiu Sas]

Hi Taylor,


see inline:

On 5/14/07, Taylor Carpenter <taylor at codecafe.com> wrote:
> Thanks for your reply Ovidiu.
>
> Is there any need to change any thing with the SIP request because of
> NAT?  Do I need to use rewritehost?  Before the NAT requirements I was
> doing ds_select_domain() for loadbalancing...  At some point I will want
> to do that again, but for the moment I am just wanting private lan
> traffic to be able to place outbound calls with the PSTN provider.

Yes, you can use rewritehost() to route your request.
lcr would work better here.

> On that note some (though not all) of the providers require auth and I
> would like OpenSER to provide the credentials so that the SIP clients
> only have to know about OpenSER to dial out... I have been using the uac
> module for that.

You can use the uac for authentication, but there are some
restrictions (your provider must accept authenticated INVITEs with the
same CSeq number).

> So is there anything special (besides RTP traffic) to do with the rest
> of the SIP packets before doing a t_relay()?
>
> The examples I have seen using rtpproxy used FAEE, FAEI, FAIE, FAII,
> etc.. I assume that all of those are not needed if everything is coming from
> the private side out to the internet (and PSTN provider).  Is that
> correct?
>

You will need to proxy the RTP traffic between the two interfaces.

> Taylor
>
>
> On Mon, May 14, 2007 at 04:06:50PM -0400, Ovidiu Sas wrote:
> > Hi Taylor,
> >
> > From what you describe here, this should be an easy setup:
> > - configure all your SIP clients to talk to openser (on the private
> > interface)
> > - in the openser config, as soon as you get an INVITE, route the
> > INVITE to the appropriate PSTN GW (based on your rules).  You can
> > hardcode them or use lcr.
> > - use rtpproxy to bridge the media
> >
> >
> > Hope this helps,
> > Ovidiu Sas
> >
> > On 5/14/07, Taylor Carpenter <taylor at codecafe.com> wrote:
> > >I may be misunderstanding things (very probably so), but all the
> > >examples for both SER and OpenSER that I have seen either do not do
> > >NAT or NAT but are not the "end point" for a UAC to the PSTN.  From
> > >what I can tell they are just sending on the SIP request to the next
> > >destination as is.  The setup I am trying to accomplish is
> > >
> > >    * SIP clients are all on a private network with connectivity to
> > >OpenSER directly on one interface (on the same private network)
> > >    * OpenSER's other interface is on the external network (internet
> > >facing)
> > >    * SIP clients are only sending telephone numbers
> > >(sip:telephone_number@*... do not know about PSTN providers)
> > >    * OpenSER connects to the PSTN provider and send the number to
> > >dial that came from the SIP client
> > >    * OpenSER "proxies" the entire call (with the help of rtpproxy or
> > >mediaproxy for RTP of course)
> > >    * No incoming calls from the internet to OpenSER (no support for
> > >that is needed)
> > >    * Registration not required for sip clients (they are all on same
> > >private network and authorized)
> > >
> > >I have found several posts, example configs, documents that have
> > >pieces of what I need (from what I can tell).. and I have tried to
> > >put it together, but it does not quite work...
> > >
> > >So is there some example that fits this type of usage?  If not one
> > >then possibly several pieces from a few documents?  I have been
> > >thinking that OpenSER setup as a outbound proxy configured for
> > >multihome, but everything I have seen on that just routes the calls
> > >through to where ever the SIP client was requesting as a final
> > >destination and I need to send to one destination (the PSTN
> > >provider).  Any help is greatly appreciated.
> > >
> > >BTW, I was thinking the NAThelper or outbound proxy example from
> > >
> > >        http://www.voip-info.org/wiki-SER+tips+and+tricks
> > >
> > >Looked close to what is needed, but have a bunch of stuff (seemingly)
> > >unneeded for my scenario and have nothing about PSTN connectivity.
> > >
> > >Thanks for taking the time to read this long post (if you made it
> > >this far).
> > >
> > >Taylor
>