[Freeswitch-users] Unable to successfully bridge calls to an "external" user
anthony.minessale at gmail.com
Tue May 19 05:56:36 PDT 2009
edit your sip profile and comment out every line that contains the string
nat to disable all the nat auto-detection.
for dmz, you need to set the rtp-ext-ip and sip-ext-ip to be the live ip and
sip-ip and rtp-ip to be the lan ip (the real one)
On Mon, May 18, 2009 at 8:02 PM, David Robinson <pawzlion at gmail.com> wrote:
> > My suspicion is that the RTP traffic isn't traversing the NAT
> > properly. You
> > may have to configure the routers at both ends to forward the RTP
> > packets to
> > the correct destinations. There is a good discussion of NAT on the
> > wiki.
> Situation: FS (10.0.0.12) -> DMZ (18.104.22.168) -> Internet -> NAT
> (22.214.171.124) -> Softphone (10.0.0.2)
> The problem is there's so much discussion of NAT that I'm not sure
> where to start. OK the problem is that I can't control the "external"
> user's router so I need a solution that works by only fixing the FS
> end. I've put my FS in the DMZ, but of course it's still got a local
> LAN IP address. Is there something I can configure to make FS realise
> that it _doesn't_ need to use NAT ? Whenever my softphones register to
> FS they register as UDP-NAT. Can I prevent that and make them register
> as regular UDP ? It would seem like they don't need to be in NAT mode
> since FS is in a DMZ, or do they ?
> I tried setting inbound-late-negotiation in my external (is this
> right ?) SIP profile and added proxy_media to my extension
> configurations in the dialplans, but this made no difference. It's
> possible that I haven't done this in the right spot or something.
> The other thing that looks promising is on
> which gives an example of a softphone registering to a NAT'd FS from
> outside on the internet (Switch with External Softphone example) which
> suggests I create a new external profile on a different port. I've
> done this and the user's softphone can register fine, but when he
> makes calls we still get no audio, presumably from lack of RTP data. I
> then tried adding in values for rtp-ip, sip-ip, ext-rtp-ip and ext-sip-
> ip on the new external profile to see if that made any difference but
> it didn't. Step 6 of the example says "reference the caller from your
> FreeSWITCH system as: sofia/external5090/<caller extension>@x.x.x.x:
> 5090". I'm not sure what that means. Do I have to change something
> else to make it "reference" the caller by that external profile ? I
> figured it must be at least using that external profile because the
> phone is successfully registering on port 5090, but I'm not sure if I
> have to do something different to route incoming calls from the main
> external profile to the new 5090 one.
> I'm just not sure which NAT-related solution I'm supposed to be using.
> The External_profile wiki page example for the external softphone
> seems to fit my situation but didn't solve anything. The proxy_media
> solution seemed promising but had no real effect. It seems to me that
> the solution has something to do with having FS know that it's in a
> DMZ and that it doesn't need to do any NAT traversal, thereby making
> it think it's got a live internet IP and therefore only the external
> user would be using NAT traversal.
> I hope someone can give me some insight into which particular NAT-
> related solution I need because there seems to be dozens of ways to
> deal with this problem and I can't figure out which applies.
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
Anthony Minessale II
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FreeSWITCH-users