Created new profile for double-natted phones, calling these fails with USER_NOT_REGISTERED
Hi all, I have set up a new profile for phones behind NAT connecting to an FS box behind NAT. Calls in from a NAT'ed phone works fine, however calls out to one fail with USER_NOT_REGISTERED. All the phones are set up in /opt/freeswitch/conf/directory/default/<sip id>. I have added the following in the new profile config hoping it would resolve the issue but it does not: <param name="challenge-realm" value="$${domain}"/> <param name="force-subscription-domain" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <param name="force-register-db-domain" value="$${domain}"/> Any clues? Thanks Alex
Alex, Does FS *have* to be behind a NAT? Are you doing a straight 1:1 from public to private (FS side)? What kind of router/firewall are you using on the FS side and endpoint sides? You'll will probably want to lower the endpoint registration times from the normal default of 1 hour to 180 seconds (3 minutes) or even lower depending on router/firewall. You may also want to turn on keep-alive packets to keep the data flowing in/out. What you are running into is either one or both sides are closing off 5060/udp early, FS is marking the registration as dead. Best thing to do is to place FS in a DMZ or install a public facing SBC to take the registrations and forward them on to FS internally. Anthony On Dec 5, 2011, at 7:09 AM, Alex Crow wrote:
Hi all,
I have set up a new profile for phones behind NAT connecting to an FS box behind NAT. Calls in from a NAT'ed phone works fine, however calls out to one fail with USER_NOT_REGISTERED. All the phones are set up in /opt/freeswitch/conf/directory/default/<sip id>.
I have added the following in the new profile config hoping it would resolve the issue but it does not:
<param name="challenge-realm" value="$${domain}"/> <param name="force-subscription-domain" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <param name="force-register-db-domain" value="$${domain}"/>
Any clues?
Thanks
Alex
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
On 05/12/11 13:04, Anthony Cosgrove wrote:
Alex,
Does FS *have* to be behind a NAT? Are you doing a straight 1:1 from public to private (FS side)? What kind of router/firewall are you using on the FS side and endpoint sides? You'll will probably want to lower the endpoint registration times from the normal default of 1 hour to 180 seconds (3 minutes) or even lower depending on router/firewall. You may also want to turn on keep-alive packets to keep the data flowing in/out. What you are running into is either one or both sides are closing off 5060/udp early, FS is marking the registration as dead.
Anthony, No, it's definitely not that - the registration is alive and well. The issue is that FS sees that the user is not registered on the internal sip profile and doesn't check the doublenat profile. The router/firewall is iptables (shorewall) and I'm doing a DNAT of the relevant ports to the FS box. What I have found is that I can specify the dialstring for the external users in the directory entries, eg: <param name="dial-string" value="{sip_invite_domain=${domain_name},presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(doublenat/${dialed_user}@${dialed_domain})}"/>
Best thing to do is to place FS in a DMZ or install a public facing SBC to take the registrations and forward them on to FS internally.
Yes, it would probably be better that way, but this is really mostly for internal use. Cheers Alex
Anthony
On Dec 5, 2011, at 7:09 AM, Alex Crow wrote:
Hi all,
I have set up a new profile for phones behind NAT connecting to an FS box behind NAT. Calls in from a NAT'ed phone works fine, however calls out to one fail with USER_NOT_REGISTERED. All the phones are set up in /opt/freeswitch/conf/directory/default/<sip id>.
I have added the following in the new profile config hoping it would resolve the issue but it does not:
<param name="challenge-realm" value="$${domain}"/> <param name="force-subscription-domain" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <param name="force-register-db-domain" value="$${domain}"/>
Any clues?
Thanks
Alex
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
-- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 5300 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856)
Alex - Check out the presense settings. Make sure both profiles are using the same DB: On Monday 05 December 2011 08:19:33 Alex Crow wrote:
On 05/12/11 13:04, Anthony Cosgrove wrote:
Alex,
Does FS *have* to be behind a NAT? Are you doing a straight 1:1 from public to private (FS side)? What kind of router/firewall are you using on the FS side and endpoint sides? You'll will probably want to lower the endpoint registration times from the normal default of 1 hour to 180 seconds (3 minutes) or even lower depending on router/firewall. You may also want to turn on keep-alive packets to keep the data flowing in/out. What you are running into is either one or both sides are closing off 5060/udp early, FS is marking the registration as dead.
Anthony,
No, it's definitely not that - the registration is alive and well. The issue is that FS sees that the user is not registered on the internal sip profile and doesn't check the doublenat profile.
The router/firewall is iptables (shorewall) and I'm doing a DNAT of the relevant ports to the FS box.
What I have found is that I can specify the dialstring for the external users in the directory entries, eg:
<param name="dial-string" value="{sip_invite_domain=${domain_name},presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(doublenat/${dialed_user}@${dialed_domain})}"/>
Best thing to do is to place FS in a DMZ or install a public facing SBC to take the registrations and forward them on to FS internally.
Yes, it would probably be better that way, but this is really mostly for internal use.
Cheers
Alex
Anthony
On Dec 5, 2011, at 7:09 AM, Alex Crow wrote:
Hi all,
I have set up a new profile for phones behind NAT connecting to an FS box behind NAT. Calls in from a NAT'ed phone works fine, however calls out to one fail with USER_NOT_REGISTERED. All the phones are set up in /opt/freeswitch/conf/directory/default/<sip id>.
I have added the following in the new profile config hoping it would resolve the issue but it does not:
<param name="challenge-realm" value="$${domain}"/> <param name="force-subscription-domain" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <param name="force-register-db-domain" value="$${domain}"/>
Any clues?
Thanks
Alex
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#Presence On Monday 05 December 2011 12:55:32 Rob Hutton wrote:
Alex -
Check out the presense settings. Make sure both profiles are using the same DB:
On Monday 05 December 2011 08:19:33 Alex Crow wrote:
On 05/12/11 13:04, Anthony Cosgrove wrote:
Alex,
Does FS *have* to be behind a NAT? Are you doing a straight 1:1 from public to private (FS side)? What kind of router/firewall are you using on the FS side and endpoint sides? You'll will probably want to lower the endpoint registration times from the normal default of 1 hour to 180 seconds (3 minutes) or even lower depending on router/firewall. You may also want to turn on keep-alive packets to keep the data flowing in/out. What you are running into is either one or both sides are closing off 5060/udp early, FS is marking the registration as dead.
Anthony,
No, it's definitely not that - the registration is alive and well. The issue is that FS sees that the user is not registered on the internal sip profile and doesn't check the doublenat profile.
The router/firewall is iptables (shorewall) and I'm doing a DNAT of the relevant ports to the FS box.
What I have found is that I can specify the dialstring for the external users in the directory entries, eg:
<param name="dial-string" value="{sip_invite_domain=${domain_name},presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(doublenat/${dialed_user}@${dialed_domain})}"/>
Best thing to do is to place FS in a DMZ or install a public facing SBC to take the registrations and forward them on to FS internally.
Yes, it would probably be better that way, but this is really mostly for internal use.
Cheers
Alex
Anthony
On Dec 5, 2011, at 7:09 AM, Alex Crow wrote:
Hi all,
I have set up a new profile for phones behind NAT connecting to an FS box behind NAT. Calls in from a NAT'ed phone works fine, however calls out to one fail with USER_NOT_REGISTERED. All the phones are set up in /opt/freeswitch/conf/directory/default/<sip id>.
I have added the following in the new profile config hoping it would resolve the issue but it does not:
<param name="challenge-realm" value="$${domain}"/> <param name="force-subscription-domain" value="$${domain}"/> <param name="force-register-domain" value="$${domain}"/> <param name="force-register-db-domain" value="$${domain}"/>
Any clues?
Thanks
Alex
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org 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
On 05/12/11 17:56, Rob Hutton wrote:
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#Presence
Rob, Indeed, that seems to have done the trick. Many thanks for that! Alex -- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 5300 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856)
Rob, Thanks. Ah, OK. I thought presence was just for things like BLF and the like, but I will give it a go. Probably should be added to the wiki if this fixes it (which I'm sure it will). I'd rather not have to add special entries in my directory for external phones. Cheers Alex On 05/12/11 17:55, Rob Hutton wrote:
Alex -
Check out the presense settings. Make sure both profiles are using the same DB:
On Monday 05 December 2011 08:19:33 Alex Crow wrote:
On 05/12/11 13:04, Anthony Cosgrove wrote:
Alex,
Does FS *have* to be behind a NAT? Are you doing a straight 1:1 from public to private (FS side)? What kind of router/firewall are you using on the FS side and endpoint sides? You'll will probably want to lower the endpoint registration times from the normal default of 1 hour to 180 seconds (3 minutes) or even lower depending on router/firewall. You may also want to turn on keep-alive packets to keep the data flowing in/out. What you are running into is either one or both sides are closing off 5060/udp early, FS is marking the registration as dead.
Anthony,
No, it's definitely not that - the registration is alive and well. The
issue is that FS sees that the user is not registered on the internal
sip profile and doesn't check the doublenat profile.
The router/firewall is iptables (shorewall) and I'm doing a DNAT of the
relevant ports to the FS box.
What I have found is that I can specify the dialstring for the external
users in the directory entries, eg:
<param name="dial-string"
value="{sip_invite_domain=${domain_name},presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(doublenat/${dialed_user}@${dialed_domain})}"/>
Best thing to do is to place FS in a DMZ or install a public facing SBC to take the registrations and forward them on to FS internally.
Yes, it would probably be better that way, but this is really mostly for
internal use.
Cheers
Alex
Anthony
On Dec 5, 2011, at 7:09 AM, Alex Crow wrote:
Hi all,
I have set up a new profile for phones behind NAT connecting to an FS
box behind NAT. Calls in from a NAT'ed phone works fine, however calls
out to one fail with USER_NOT_REGISTERED. All the phones are set up in
/opt/freeswitch/conf/directory/default/<sip id>.
I have added the following in the new profile config hoping it would
resolve the issue but it does not:
<param name="challenge-realm" value="$${domain}"/>
<param name="force-subscription-domain" value="$${domain}"/>
<param name="force-register-domain" value="$${domain}"/>
<param name="force-register-db-domain" value="$${domain}"/>
Any clues?
Thanks
Alex
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
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
-- This message has been scanned for viruses and dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is believed to be clean.
-- This message is intended only for the addressee and may contain confidential information. Unless you are that person, you may not disclose its contents or use it in any way and are requested to delete the message along with any attachments and notify us immediately. "Transact" is operated by Integrated Financial Arrangements plc Domain House, 5-7 Singer Street, London EC2A 4BQ Tel: (020) 7608 4900 Fax: (020) 7608 5300 (Registered office: as above; Registered in England and Wales under number: 3727592) Authorised and regulated by the Financial Services Authority (entered on the FSA Register; number: 190856)
participants (3)
-
Alex Crow
-
Anthony Cosgrove
-
Rob Hutton