Re: [Freeswitch-users] Unable to successfully bridge calls to an "external" user
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 (124.254.81.250) -> Internet -> NAT (203.206.171.118) -> 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 http://wiki.freeswitch.org/wiki/External_profile 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.
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@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 (124.254.81.250) -> Internet -> NAT (203.206.171.118) -> 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 http://wiki.freeswitch.org/wiki/External_profile 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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
You will also need to modify the dial-string in conf/directory/ default.xml because it only looks on internal for registered users. /b On May 19, 2009, at 7:56 AM, Anthony Minessale wrote:
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)
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
Hey David, IMHO first you need to decide if you want to proxy the media traffic or not (look at bypass_media), as you are behind a NAT it suggests that you are perhaps using a cable or adsl connection to the internet and may not want to give up some of your bandwidth for VOIP calls to external connections. If you choose to bypass the media, you will then need to make sure the IP address reported in the 200 OK by the terminating user on answer is reported correctly to Faktortel your ITSP. You might find this mode will work as Faktortel will probably be able to determine the path to the terminating phone based on the IP and PORT it received the voice packets from. Alternatively if you want to proxy the media traffic, you will need to make sure that FS reports the correct External IP address in the INVITE message to the terminating user. These settings are mentioned by Anthony below. I use both NGREP and TCPDUMP heavily when trying new things on FS, because when you determine what comes out gets easier to findout what parms to change. Regards, Jim On Tue, May 19, 2009 at 11:24 PM, Brian West <brian@freeswitch.org> wrote:
You will also need to modify the dial-string in conf/directory/default.xml because it only looks on internal for registered users. /b On May 19, 2009, at 7:56 AM, Anthony Minessale wrote:
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)
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Anthony Minessale
-
Brian West
-
David Robinson
-
Jim Burke