Best practices question about SIP registration
Please excuse me, I'm a VoIP newbie. I found the very helpful comment in conf/directory/default.xml. It says that the default domain is the IP address of the Freeswitch server. It seems to me that this could cause problems if the IP changed for some reason, or if the server has multiple NICs (which one does it choose in that case?) Is it better do just define a well known text string for the default domain, or even use a real DNS domain name? 2nd question is about SIP usernames. At least one phone I have found uses the MAC address as the default SIP user. Would it be better to avoid having a separate TFTP file for each phone, and just use the already unique MAC address as the user? -- Steve
Hi Steven, I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time. It also helps to manage things. If you set up SRV DNS records, many devices only need the user and domain, as the address and ports are looked up in the SRV record. This also allows for load share or failover right in the DNS record! For the second question, the MAC address probably doesn't make a lot of sense to me. The user part is supposed to be a user name, not a hardware address. What if you replace the phone? This is normally an extension number, a telephone number, or perhaps a username like the user part of an e-mail address. Any could be correct, but they should always be meaningful, and abstracted from the hardware. The user part is often presented as caller ID, so it should mean something if it comes up on someone else's display as the originating number. If you have a lot of phones, you should look into a better provisioning mechanism than individual TFTP files. It makes sense to have a master config file that contains common settings, but it in a larger system, some sort of automation is good. If you are running out of a database, you can use a server-side script to auto-generate the config as the phone asks for it. This requires the phone to be able to use HTTP to fetch config. Most phones can. Failing that, many other phones will let you include multiple files, so you can have a master config file, then a per-phone file that just has overrides. You may also be able to name the individual files based on the username, then create a symbolic link to the file named as the MAC address. If you want to re-assign a phone to a different user, just update the symlink. I recommend the HTTP script if you are up for it, as you can automate everything and save yourself a lot of time in the long run. Create one database that you manage your users in and have Freeswitch config (via XML Curl) as well as the phone config fetch the appropriate settings from it. That way, they will always match. -Tim Steven Schoch wrote:
Please excuse me, I'm a VoIP newbie.
I found the very helpful comment in conf/directory/default.xml. It says that the default domain is the IP address of the Freeswitch server. It seems to me that this could cause problems if the IP changed for some reason, or if the server has multiple NICs (which one does it choose in that case?)
Is it better do just define a well known text string for the default domain, or even use a real DNS domain name?
2nd question is about SIP usernames. At least one phone I have found uses the MAC address as the default SIP user. Would it be better to avoid having a separate TFTP file for each phone, and just use the already unique MAC address as the user?
-- Steve
------------------------------------------------------------------------
_________________________________________________________________________ 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 Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right? Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has: reg.1.auth.userId="1000" and reg.1.address="1000@fs.domain.local" How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it? -- Steve
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS. A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto:user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...) There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there). However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do. SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all. (RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :). all the best, Lawrence On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve _________________________________________________________________________ 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
Lawrence, Thanks for this explanation. It was very well written. I'm looking for a place to codify this on the wiki so that it gets preserved... :) -MC On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS.
A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto: user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there).
However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do.
SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all.
(RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :).
all the best, Lawrence
On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve _________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
I couldn't stand it, so I added Lawrence's info to this page: http://wiki.freeswitch.org/wiki/DNS#Explanation_of_DNS.2FSRV.2FNAPTR Cheers, MC On Tue, Jan 8, 2013 at 2:56 PM, Michael Collins <msc@freeswitch.org> wrote:
Lawrence,
Thanks for this explanation. It was very well written. I'm looking for a place to codify this on the wiki so that it gets preserved... :)
-MC
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS.
A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto: user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there).
However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do.
SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all.
(RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :).
all the best, Lawrence
On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve
_________________________________________________________________________
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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
From the wiki: "There IS a wrinkle to this special case: If you have a URL of the form <sip:user@example.com:5055> the client should NOT look for a NAPTR or SRV, but instead go straight to looking for an A or AAAA for the host example.com (i" This is an error in the RFC that we are trying to fix in the IPV6 wg of the SIP Forum. Software should NOT find A *OR* AAAA. It should look up both and then try them according to Happy Eyeballs - in parallell with a small advantage for IPv6. If we do serial forking here, we have in worst case a 32 second timeout in SIP over UDP, which is not acceptable. Every customer should require fixes and every developer should try to fix this... Some slides on these issues: * http://www.slideshare.net/oej/sipforum-sip-ipv6-discussion-slides * http://www.slideshare.net/oej/sip-ipv6-time-for-action I hope to see FreeSwitch at SIPit 30 in February so we can test this and other issues! /O 9 jan 2013 kl. 00:21 skrev Michael Collins <msc@freeswitch.org>:
I couldn't stand it, so I added Lawrence's info to this page: http://wiki.freeswitch.org/wiki/DNS#Explanation_of_DNS.2FSRV.2FNAPTR
Cheers, MC
On Tue, Jan 8, 2013 at 2:56 PM, Michael Collins <msc@freeswitch.org> wrote: Lawrence,
Thanks for this explanation. It was very well written. I'm looking for a place to codify this on the wiki so that it gets preserved... :)
-MC
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk> wrote: Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS.
A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto:user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there).
However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do.
SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all.
(RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :).
all the best, Lawrence
On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve _________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
Hi Michael, folks, if you're going to codify it, I did slightly simplify things: (full disclosure -- I disagreed with it at the time which is probably why I forgot to mention it -- honest). There IS a wrinkle to this special case: If you have a URL of the form <sip:user@example.com:5055> the client should NOT look for a NAPTR or SRV, but instead go straight to looking for an A or AAAA for the host example.com (i.e., there's a machine called example.com, and it is handling SIP traffic for that domainpart). Basically, if you see a colon in the domainpart, you're looking for a machine -- otherwise you're looking for a NAPTR (and/or a SRV at _sip._udp.<sipdomain>). I'd put that before the paragraph starting "However, relying on ..." Curiously enough, the old 2543-compliant servers did hunt the SRV rather than giving up and looking for an A, so this was a change. Such fun was had re-writing implementations (plural) and testing them yet again. Sigh. all the best, Lawrence On 8 Jan 2013, at 22:56, Michael Collins wrote:
Lawrence,
Thanks for this explanation. It was very well written. I'm looking for a place to codify this on the wiki so that it gets preserved... :)
-MC
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS.
A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto: user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there).
However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do.
SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all.
(RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :).
all the best, Lawrence
On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve _________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
Done! Thanks, MC On Tue, Jan 8, 2013 at 3:35 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi Michael, folks, if you're going to codify it, I did slightly simplify things: (full disclosure -- I disagreed with it at the time which is probably why I forgot to mention it -- honest).
There IS a wrinkle to this special case: If you have a URL of the form < sip:user@example.com:5055> the client should NOT look for a NAPTR or SRV, but instead go straight to looking for an A or AAAA for the host example.com (i.e., there's a machine called example.com, and it is handling SIP traffic for that domainpart). Basically, if you see a colon in the domainpart, you're looking for a machine -- otherwise you're looking for a NAPTR (and/or a SRV at _sip._udp.<sipdomain>).
I'd put that before the paragraph starting "However, relying on ..."
Curiously enough, the old 2543-compliant servers did hunt the SRV rather than giving up and looking for an A, so this was a change. Such fun was had re-writing implementations (plural) and testing them yet again. Sigh.
all the best, Lawrence
There IS a wrinkle to this special case: If you have a URL of the form <sip:user@example.com:5055> the client should NOT look for a NAPTR or SRV, but instead go straight to looking for an A or AAAA for the host
The reason being that a SRV record includes the port (note that means it's a very easy way to add/change additional ports as well as addresses without having to change customer configs). So obviously a host:port isn't compatible with a SRV, since it wouldn't make sense to override the port, so the assumption is that it's specifying an A/AAAA record instead and port on that IP instead. -Steve On 8 January 2013 23:35, Lawrence Conroy <lconroy@insensate.co.uk> wrote:
Hi Michael, folks, if you're going to codify it, I did slightly simplify things: (full disclosure -- I disagreed with it at the time which is probably why I forgot to mention it -- honest).
There IS a wrinkle to this special case: If you have a URL of the form <sip:user@example.com:5055> the client should NOT look for a NAPTR or SRV, but instead go straight to looking for an A or AAAA for the host example.com (i.e., there's a machine called example.com, and it is handling SIP traffic for that domainpart). Basically, if you see a colon in the domainpart, you're looking for a machine -- otherwise you're looking for a NAPTR (and/or a SRV at _sip._udp.<sipdomain>).
I'd put that before the paragraph starting "However, relying on ..."
Curiously enough, the old 2543-compliant servers did hunt the SRV rather than giving up and looking for an A, so this was a change. Such fun was had re-writing implementations (plural) and testing them yet again. Sigh.
all the best, Lawrence
On 8 Jan 2013, at 22:56, Michael Collins wrote:
Lawrence,
Thanks for this explanation. It was very well written. I'm looking for a place to codify this on the wiki so that it gets preserved... :)
-MC
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice. I have some sympathy, as the term domain is overloaded within fS.
A sip address consists of a userpart and a domain part -- e.g., <sip:user@sipdomain> The sip domain is similar to an email domain -- e.g., <mailto: user@maildomain> With email, you need to do a lookup of the MX record in DNS to find the FQDN of the machine that handles mail for the domain. With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening. (Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
There IS a "get out" clause in the SIP specs for RFC 2543 (AKA legacy) support that means most SIP clients will look for the SRV and, if it can't be found (or there's an IP address rather than a DNS -style domain, in which case the SIP client won't bother hunting the SRV), the client will guess that the domain has a machine (i.e. it will look for an A or AAAA record), and also guess it's listening on 5060 (the default port). Email is the same (mail to fred@example.com, and strictly the sender will do a check for a MX and then look for an A record for example.com, and try there).
However, relying on that default "get out" clause is definitely NOT what you should do for BCP. Using the hostname as the sip domain is a kludge -- the FQDN with A record usually works, but it's not what you want to do.
SO ... get yourself a domain, put a D2U NAPTR at that domain, put a SRV at _sip._udp.<domain>, and you're done. No need for an A record at that domain at all.
(RFC 3263 is not too hard to read, for a change -- it's certainly shorter than RFC 3261, and it even has an ASCII art diagram :).
all the best, Lawrence
On 8 Jan 2013, at 21:05, Steven Schoch wrote:
On Fri, Dec 28, 2012 at 8:47 PM, Tim St. Pierre < fs-list@communicatefreely.net> wrote:
Hi Steven,
I would recommend using a proper domain name as much as possible. For one, it looks nicer! A SIP URI is supposed to be user@domain like an e-mail address is, and I hope that one day URI dialing will be common place, so we might as well do it right the first time.
What you're saying is that "domain" should really be a fully-qualified host name that points via DNS to the actual host on which FreeSwitch is running. That is, the domain should be "pbx.example.com" instead of just " example.com", as the last example would most likely point to a web server, not the SIP server. Do I have that right?
Next, in the configuration for Polycom phones (for example), there are 2 fields that both have the userid. In the example in http://wiki.freeswitch.org/wiki/Polycom_configuration it has:
reg.1.auth.userId="1000"
and
reg.1.address="1000@fs.domain.local"
How is the "address" value used? Is that sent in the SIP registration message? If that's the case, what does Freeswitch do with it?
-- Steve _________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.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
_________________________________________________________________________ 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 Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice.
This party is open to all. I appreciate these answers, and as usual I have noticed that the fastest way to learn is to do it wrong, and then have somebody correct me! Thanks!
With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening.
For example, I did a lookup: $ dig SRV _sip._udp.sip.flowroute.com. This returns: _sip._udp.sip.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.sip.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com.
(Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
$ dig NAPTR sip.flowroute.com sip.flowroute.com. 42818 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.sip.flowroute.com. sip.flowroute.com. 42818 IN NAPTR 102 20 "s" "SIP+D2U" "" _sip._tcp.sip.flowroute.com. I found that _sip._tcp.sip.flowroute.com does not have a SRV record. I don't know what that means. The RFC says that you should use "SIP+D2T" for TCP. Now, as this relates to the Polycom phone example, there are these fields: reg.1.address="1000@fs.domain.local" reg.1.auth.userId="1000" reg.1.server.1.address="10.10.10.11" reg.1.server.1.port="5060" Since this is a VoIP phone that loads its configuration from the server, not VoIP software that is configured by the user, it really only needs the IP address, so the server address field is kind of moot. But the example domain here is "fs.domain.local". Why not just "domain.local"? Why didn't Flowroute use "flowroute.com" instead of " sip.flowroute.com"? And my other question was how is the address "1000@fs.domain.local" used? Does FreeSwitch use that or does it just use the auth.userId? -- Steve
Hi again Steven, with apologies for top-posting ... Re. flowroute.com Many of us have sup-domains for different classes of users -- looks like your sub-domain is sip.flowroute.com. However, flowroute.com does have a NAPTR (it has two): ;; ANSWER SECTION: flowroute.com. 21600 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.flowroute.com. flowroute.com. 21600 IN NAPTR 102 20 "s" "SIP+D2T" "" _sip._tcp.flowroute.com. Also, the _sip._udp.flowroute SRV shows: ;; ANSWER SECTION: _sip._udp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com. as does the _sip.tcp.flowroute.com SRV: ;; ANSWER SECTION: _sip._tcp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com. _sip._tcp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. so -- if a client is trying to call to sip:1000@flowroute.com, that client looks up the NAPTR set for flowroute.com (the sip domainpart), gets back the two entries, and chooses to look for a SRV under _sip._udp.flowroute.com (if it wants to call using UDP) or _sip.tcp.flowroute.com (if it wants to call using TCP or use sips:). flowroute would prefer that you contacted them by UDP (it has a lower preference -- 10 versus the D2T's 20). If you do contact them, they'd prefer that you used sip-nv1.flowroute.com. (as that has a better/lower preference than sip-cal). On to the polycoms -- I don't have any of these, so I'm guessing, but ... It looks strongly like the registration server is at fs.domain.local, which has an IP address of 10.10.10.11 for the DNS-challenged, and is listening on port 5060. The AuthID/UserID for this 'phone to use 1000, which is kinda apparent from the SIP address the phone has, which is sip:1000@fs.domain.local. I'd AssUMe that there's also a password field :). So ... if you had mydomain.com, and for your internal use you had a sub-domain of, say, internal.mydomain.com, and you had one fS handling your local 'phones, running on a machine called fs.internal.domain.com which had an IP address of 10.10.10.11, I'd put into the local view of DNS: internal.mydomain.com. IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.internal.mydomain.com. _sip._udp.internal.mydomain.com. IN SRV 10 10 5060 fs.internal.mydomain.com fs.internal.mydomain.com. IN A 10.10.10.11 Note that I'm assuming that you'd be using a split-view DNS (i.e., your local DNS server would only give these answers to its local machines) as it's kinda impolite to give private addresses like 10.10.10.11 to the outside world -- clients are sometimes too dumb to realise they can't contact that server using this address. [...which is why we have one way audio -- stupid implementers :]p Hope that helps, Lawrence On 8 Jan 2013, at 23:02, Steven Schoch wrote:
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice.
This party is open to all. I appreciate these answers, and as usual I have noticed that the fastest way to learn is to do it wrong, and then have somebody correct me! Thanks!
With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening.
For example, I did a lookup:
$ dig SRV _sip._udp.sip.flowroute.com.
This returns:
_sip._udp.sip.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.sip.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com.
(Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
$ dig NAPTR sip.flowroute.com
sip.flowroute.com. 42818 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.sip.flowroute.com. sip.flowroute.com. 42818 IN NAPTR 102 20 "s" "SIP+D2U" "" _sip._tcp.sip.flowroute.com.
I found that _sip._tcp.sip.flowroute.com does not have a SRV record. I don't know what that means. The RFC says that you should use "SIP+D2T" for TCP.
Now, as this relates to the Polycom phone example, there are these fields:
reg.1.address="1000@fs.domain.local" reg.1.auth.userId="1000" reg.1.server.1.address="10.10.10.11" reg.1.server.1.port="5060"
Since this is a VoIP phone that loads its configuration from the server, not VoIP software that is configured by the user, it really only needs the IP address, so the server address field is kind of moot.
But the example domain here is "fs.domain.local". Why not just "domain.local"? Why didn't Flowroute use "flowroute.com" instead of " sip.flowroute.com"?
And my other question was how is the address "1000@fs.domain.local" used? Does FreeSwitch use that or does it just use the auth.userId?
-- Steve _________________________________________________________________________ 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
Hi one last time Steven, folks, Oops -- you can't get the staff, 'nourdays ... For "fs.internal.domain.com", read "fs.internal.mydomain.com" :-§ -- time for bed. all the best, Lawrence (and the earlier sup-domains should have been sub-domains :-§ -- time for bed.) On 9 Jan 2013, at 00:04, Lawrence Conroy wrote:
called fs.internal.domain.com which had an IP address of 10.10.10.11, I'd put into the local view of DNS:
Great info Lawrence, especially the MX analogy. Thanks. I have to take this one more step and ask a question. We have FS configured for multitenant. Of course the "domains" for the tenants are FQDNs. I found it simple to setup and wonderful for setting up customers as their own virtual switches. Clearly this is a case where the sip address has to contain the FQDN. (It also gives me a chuckle every day when I see those a-holes' registration failures for "100@<ip address>" when a name is required!) My FS Domains are like "fs_A.xyz.com" and "FS_B.xyz.com" which I currently have as A records with the same IP address. If I add an SRV record for _sip._udp.xyz.com to that IP Address, are you saying I won't need the A records? Or do I need SRV records for each sub-domain? Of course this is assuming I set my hardware (Cisco SPA 5xx) to "Use SRV? Yes" Thanks for the information. Sean -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Lawrence Conroy Sent: Tuesday, January 08, 2013 7:05 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Best practices question about SIP registration Hi again Steven, with apologies for top-posting ... Re. flowroute.com Many of us have sup-domains for different classes of users -- looks like your sub-domain is sip.flowroute.com. However, flowroute.com does have a NAPTR (it has two): ;; ANSWER SECTION: flowroute.com. 21600 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.flowroute.com. flowroute.com. 21600 IN NAPTR 102 20 "s" "SIP+D2T" "" _sip._tcp.flowroute.com. Also, the _sip._udp.flowroute SRV shows: ;; ANSWER SECTION: _sip._udp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com. as does the _sip.tcp.flowroute.com SRV: ;; ANSWER SECTION: _sip._tcp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com. _sip._tcp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. so -- if a client is trying to call to sip:1000@flowroute.com, that client looks up the NAPTR set for flowroute.com (the sip domainpart), gets back the two entries, and chooses to look for a SRV under _sip._udp.flowroute.com (if it wants to call using UDP) or _sip.tcp.flowroute.com (if it wants to call using TCP or use sips:). flowroute would prefer that you contacted them by UDP (it has a lower preference -- 10 versus the D2T's 20). If you do contact them, they'd prefer that you used sip-nv1.flowroute.com. (as that has a better/lower preference than sip-cal). On to the polycoms -- I don't have any of these, so I'm guessing, but ... It looks strongly like the registration server is at fs.domain.local, which has an IP address of 10.10.10.11 for the DNS-challenged, and is listening on port 5060. The AuthID/UserID for this 'phone to use 1000, which is kinda apparent from the SIP address the phone has, which is sip:1000@fs.domain.local. I'd AssUMe that there's also a password field :). So ... if you had mydomain.com, and for your internal use you had a sub-domain of, say, internal.mydomain.com, and you had one fS handling your local 'phones, running on a machine called fs.internal.domain.com which had an IP address of 10.10.10.11, I'd put into the local view of DNS: internal.mydomain.com. IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.internal.mydomain.com. _sip._udp.internal.mydomain.com. IN SRV 10 10 5060 fs.internal.mydomain.com fs.internal.mydomain.com. IN A 10.10.10.11 Note that I'm assuming that you'd be using a split-view DNS (i.e., your local DNS server would only give these answers to its local machines) as it's kinda impolite to give private addresses like 10.10.10.11 to the outside world -- clients are sometimes too dumb to realise they can't contact that server using this address. [...which is why we have one way audio -- stupid implementers :]p Hope that helps, Lawrence On 8 Jan 2013, at 23:02, Steven Schoch wrote:
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice.
This party is open to all. I appreciate these answers, and as usual I have noticed that the fastest way to learn is to do it wrong, and then have somebody correct me! Thanks!
With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening.
For example, I did a lookup:
$ dig SRV _sip._udp.sip.flowroute.com.
This returns:
_sip._udp.sip.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.sip.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com.
(Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
$ dig NAPTR sip.flowroute.com
sip.flowroute.com. 42818 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.sip.flowroute.com. sip.flowroute.com. 42818 IN NAPTR 102 20 "s" "SIP+D2U" "" _sip._tcp.sip.flowroute.com.
I found that _sip._tcp.sip.flowroute.com does not have a SRV record. I don't know what that means. The RFC says that you should use "SIP+D2T" for TCP.
Now, as this relates to the Polycom phone example, there are these fields:
reg.1.address="1000@fs.domain.local" reg.1.auth.userId="1000" reg.1.server.1.address="10.10.10.11" reg.1.server.1.port="5060"
Since this is a VoIP phone that loads its configuration from the server, not VoIP software that is configured by the user, it really only needs the IP address, so the server address field is kind of moot.
But the example domain here is "fs.domain.local". Why not just "domain.local"? Why didn't Flowroute use "flowroute.com" instead of " sip.flowroute.com"?
And my other question was how is the address "1000@fs.domain.local" used? Does FreeSwitch use that or does it just use the auth.userId?
-- Steve ______________________________________________________________________ ___ 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-use rs 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
Hi Sean, folks, OK -- this is drifting away from the purely technical, but ... It depends on whether or not you trust your customers to have clue, and on whether or not your customers have sensible DNS providers. IMHO, most DNS providers are the sticking point -- they wouldn't know a NAPTR if it jumped up and bit them on the t*t, and have less desire to change their customer dashboard than pretty much anything; if it works for customer web sites, why would they need to do anything else? In theory, your customers could have their own domain, put a single NAPTR in that (pointing at a SRV you set up in your DNS domain), and you could then put your SIP servers at any FQDN you'd like, pointed to by those SRVs. Remember, the customer's domain can have a NAPTR but no A record and no SRV -- the NAPTR can quite easily point to a SRV in an entirely different domain, just as the SRV can point to a FQDN in yet another domain. There's a lot of flexibility there. In this ideal world, the customer gets to use <sip:myuser@customerdomain>, you keep your SRVs under your control in your domain and can tweak these at need without any change needed to customer domain's DNS records. Thus customers don't even need to know in advance what the IP address(es) of your servers are. It's all good. You (obviously) do need to know what sipdomains your customers are going to use and to configure fS accordingly to serve/auth these, but that's about it. BUT ... 1. Some old SIP implementations are crock, and don't understand NAPTRs either. These cobbled together apologies for code just AssUMe that there's going to be a SRV where they expect it. Some new SIP implementations are equally "challenged". 2. You would be wise to check that each of your customers DID actually manage to put a NAPTR into their domain (i.e., they knew exactly what to put into DNS because you told them, and their DNS provider/IT department had the clue and the mechanism to make this so). It's pretty easy to check from anywhere (dig is your friend :), but it helps your customer care staff to know (when a customer calls up with a problem) that the customer may well have shot themselves in the foot. So ... in practice, it's useful for them to put a SRV in their domain as well. Doesn't solve problem 2, but will avoid most of problem 1. As for giving them their own FQDN -- (in your domain): yup, you can do that as well. It does mean that you need to be busy when you need to swap machines out or change machine addresses because some rag'eads are DDoSing you (i.e. if it all goes pete tong every one of your customer FQDNs' A/AAA records all need to be updated ASAP). Personally I'd still have sub-domains with NAPTRs and SRVs pointing to other sub-domains of yours where your server hostnames and their A/AAA records live. It really depends on how much your customers want to have their own brand/identity, and how much you can trust them (and their service providers) to do clueful things. all the best, Lawrence On 9 Jan 2013, at 15:57, Sean Devoy wrote:
Great info Lawrence, especially the MX analogy. Thanks.
I have to take this one more step and ask a question. We have FS configured for multitenant. Of course the "domains" for the tenants are FQDNs. I found it simple to setup and wonderful for setting up customers as their own virtual switches.
Clearly this is a case where the sip address has to contain the FQDN. (It also gives me a chuckle every day when I see those a-holes' registration failures for "100@<ip address>" when a name is required!)
My FS Domains are like "fs_A.xyz.com" and "FS_B.xyz.com" which I currently have as A records with the same IP address. If I add an SRV record for _sip._udp.xyz.com to that IP Address, are you saying I won't need the A records? Or do I need SRV records for each sub-domain?
Of course this is assuming I set my hardware (Cisco SPA 5xx) to "Use SRV? Yes"
Thanks for the information.
Sean
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Lawrence Conroy Sent: Tuesday, January 08, 2013 7:05 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Best practices question about SIP registration
Hi again Steven, with apologies for top-posting ... Re. flowroute.com Many of us have sup-domains for different classes of users -- looks like your sub-domain is sip.flowroute.com.
However, flowroute.com does have a NAPTR (it has two): ;; ANSWER SECTION: flowroute.com. 21600 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.flowroute.com. flowroute.com. 21600 IN NAPTR 102 20 "s" "SIP+D2T" "" _sip._tcp.flowroute.com.
Also, the _sip._udp.flowroute SRV shows: ;; ANSWER SECTION: _sip._udp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com.
as does the _sip.tcp.flowroute.com SRV: ;; ANSWER SECTION: _sip._tcp.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com. _sip._tcp.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com.
so -- if a client is trying to call to sip:1000@flowroute.com, that client looks up the NAPTR set for flowroute.com (the sip domainpart), gets back the two entries, and chooses to look for a SRV under _sip._udp.flowroute.com (if it wants to call using UDP) or _sip.tcp.flowroute.com (if it wants to call using TCP or use sips:). flowroute would prefer that you contacted them by UDP (it has a lower preference -- 10 versus the D2T's 20). If you do contact them, they'd prefer that you used sip-nv1.flowroute.com. (as that has a better/lower preference than sip-cal).
On to the polycoms -- I don't have any of these, so I'm guessing, but ... It looks strongly like the registration server is at fs.domain.local, which has an IP address of 10.10.10.11 for the DNS-challenged, and is listening on port 5060. The AuthID/UserID for this 'phone to use 1000, which is kinda apparent from the SIP address the phone has, which is sip:1000@fs.domain.local. I'd AssUMe that there's also a password field :).
So ... if you had mydomain.com, and for your internal use you had a sub-domain of, say, internal.mydomain.com, and you had one fS handling your local 'phones, running on a machine called fs.internal.domain.com which had an IP address of 10.10.10.11, I'd put into the local view of DNS:
internal.mydomain.com. IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.internal.mydomain.com. _sip._udp.internal.mydomain.com. IN SRV 10 10 5060 fs.internal.mydomain.com fs.internal.mydomain.com. IN A 10.10.10.11
Note that I'm assuming that you'd be using a split-view DNS (i.e., your local DNS server would only give these answers to its local machines) as it's kinda impolite to give private addresses like 10.10.10.11 to the outside world -- clients are sometimes too dumb to realise they can't contact that server using this address. [...which is why we have one way audio -- stupid implementers :]p
Hope that helps, Lawrence
On 8 Jan 2013, at 23:02, Steven Schoch wrote:
On Tue, Jan 8, 2013 at 1:56 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
Hi there, at the risk of butting in on someone else's party ... Nope; your interpretations is NOT best practice.
This party is open to all. I appreciate these answers, and as usual I have noticed that the fastest way to learn is to do it wrong, and then have somebody correct me! Thanks!
With SIP (see RFC 3263), you do a lookup on the SRV record (at _sip._udp.<sipdomain>) to find the machine that handles SIP registrations/incalls for the domain. That also gives you the port on which that machine is listening.
For example, I did a lookup:
$ dig SRV _sip._udp.sip.flowroute.com.
This returns:
_sip._udp.sip.flowroute.com. 43200 IN SRV 20 10 5060 sip-ca1.flowroute.com. _sip._udp.sip.flowroute.com. 43200 IN SRV 10 10 5060 sip-nv1.flowroute.com.
(Yup, you can also have a NAPTR record in the domain to tell you where the SRV record is, but many folks don't bother -- for Best Practice, you should, but ...)
$ dig NAPTR sip.flowroute.com
sip.flowroute.com. 42818 IN NAPTR 100 10 "s" "SIP+D2U" "" _sip._udp.sip.flowroute.com. sip.flowroute.com. 42818 IN NAPTR 102 20 "s" "SIP+D2U" "" _sip._tcp.sip.flowroute.com.
I found that _sip._tcp.sip.flowroute.com does not have a SRV record. I don't know what that means. The RFC says that you should use "SIP+D2T" for TCP.
Now, as this relates to the Polycom phone example, there are these fields:
reg.1.address="1000@fs.domain.local" reg.1.auth.userId="1000" reg.1.server.1.address="10.10.10.11" reg.1.server.1.port="5060"
Since this is a VoIP phone that loads its configuration from the server, not VoIP software that is configured by the user, it really only needs the IP address, so the server address field is kind of moot.
But the example domain here is "fs.domain.local". Why not just "domain.local"? Why didn't Flowroute use "flowroute.com" instead of " sip.flowroute.com"?
And my other question was how is the address "1000@fs.domain.local" used? Does FreeSwitch use that or does it just use the auth.userId?
-- Steve ______________________________________________________________________ ___ 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-use rs 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
_________________________________________________________________________ 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 Wed, Jan 9, 2013 at 1:27 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
IMHO, most DNS providers are the sticking point -- they wouldn't know a NAPTR if it jumped up and bit them on the t*t, and have less desire to change their customer dashboard than pretty much anything; if it works for customer web sites, why would they need to do anything else?
Case in point: On Wed, Jan 9, 2013 at 12:08 PM, QuickServe Support <qs@pair.com> wrote:
Hello Steve,
The "Add New Custom DNS Entries" page does not have a "NAPTR" entry (as specified in RFC 2915). Is this something that can be added?
Unfortunately, the NAPTR DNS record is not supported by our systems at this time. Currently there are no plans to add support for the NAPTR DNS record.
I'm not aware of any third party DNS provide that does offer NAPTR DNS to direct you to.
Best regards, Sean P. pair Networks, Inc. support@pair.com
www.zoneedit.com Enrollment is free. Depending on number of domains and forward zones requirements, you may even remain within the for-free thresholds. /S ————— iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar errors • Thought of the Day – "With all this manure, there must be a pony in here somewhere.” On 2013-01-09, at 17:52, Steven Schoch <schoch+freeswitch.org@xwin32.com> wrote: On Wed, Jan 9, 2013 at 1:27 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
IMHO, most DNS providers are the sticking point -- they wouldn't know a NAPTR if it jumped up and bit them on the t*t, and have less desire to change their customer dashboard than pretty much anything; if it works for customer web sites, why would they need to do anything else?
Case in point: On Wed, Jan 9, 2013 at 12:08 PM, QuickServe Support <qs@pair.com> wrote:
Hello Steve,
The "Add New Custom DNS Entries" page does not have a "NAPTR" entry (as specified in RFC 2915). Is this something that can be added?
Unfortunately, the NAPTR DNS record is not supported by our systems at this time. Currently there are no plans to add support for the NAPTR DNS record.
I'm not aware of any third party DNS provide that does offer NAPTR DNS to direct you to.
Best regards, Sean P. pair Networks, Inc. support@pair.com
_________________________________________________________________________ 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
Also, on the paid dns provider front, easydns.com, a VERY good dns provider, supports the full monty of record types, http://helpwiki.easydns.com/index.php/Editing_NAPTR_record /S ————— iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar errors • Thought of the Day – "With all this manure, there must be a pony in here somewhere.” On 2013-01-09, at 17:52, Steven Schoch <schoch+freeswitch.org@xwin32.com> wrote: On Wed, Jan 9, 2013 at 1:27 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
IMHO, most DNS providers are the sticking point -- they wouldn't know a NAPTR if it jumped up and bit them on the t*t, and have less desire to change their customer dashboard than pretty much anything; if it works for customer web sites, why would they need to do anything else?
Case in point: On Wed, Jan 9, 2013 at 12:08 PM, QuickServe Support <qs@pair.com> wrote:
Hello Steve,
The "Add New Custom DNS Entries" page does not have a "NAPTR" entry (as specified in RFC 2915). Is this something that can be added?
Unfortunately, the NAPTR DNS record is not supported by our systems at this time. Currently there are no plans to add support for the NAPTR DNS record.
I'm not aware of any third party DNS provide that does offer NAPTR DNS to direct you to.
Best regards, Sean P. pair Networks, Inc. support@pair.com
_________________________________________________________________________ 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
https://dns.he.net/ Free to an extent but I can't remember what the limits are. Something like 50 zones. On 9 January 2013 23:35, S. Scott <8f27e956@gmail.com> wrote:
Also, on the paid dns provider front, easydns.com, a VERY good dns provider, supports the full monty of record types,
http://helpwiki.easydns.com/index.php/Editing_NAPTR_record
/S
————— iThing: Big thumbs & little keys. Please excuse typo, spelling and grammar errors • Thought of the Day – "With all this manure, there must be a pony in here somewhere.”
On 2013-01-09, at 17:52, Steven Schoch <schoch+freeswitch.org@xwin32.com> wrote:
On Wed, Jan 9, 2013 at 1:27 PM, Lawrence Conroy <lconroy@insensate.co.uk>wrote:
IMHO, most DNS providers are the sticking point -- they wouldn't know a NAPTR if it jumped up and bit them on the t*t, and have less desire to change their customer dashboard than pretty much anything; if it works for customer web sites, why would they need to do anything else?
Case in point:
On Wed, Jan 9, 2013 at 12:08 PM, QuickServe Support <qs@pair.com> wrote:
Hello Steve,
The "Add New Custom DNS Entries" page does not have a "NAPTR" entry (as specified in RFC 2915). Is this something that can be added?
Unfortunately, the NAPTR DNS record is not supported by our systems at this time. Currently there are no plans to add support for the NAPTR DNS record.
I'm not aware of any third party DNS provide that does offer NAPTR DNS to direct you to.
Best regards, Sean P. pair Networks, Inc. support@pair.com
_________________________________________________________________________
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
-- *Andrew Cassidy BSc (Hons) MBCS SSCA* Managing Director *T <info@cassidywebservices.co.uk> *03300 100 960 *F<info@cassidywebservices.co.uk> *03300 100 961 *E <info@cassidywebservices.co.uk> *andrew@cassidywebservices.co.uk *W <info@cassidywebservices.co.uk> *www.cassidywebservices.co.uk
participants (9)
-
Andrew Cassidy
-
Lawrence Conroy
-
Michael Collins
-
Olle E. Johansson
-
S. Scott
-
Sean Devoy
-
Steven Ayre
-
Steven Schoch
-
Tim St. Pierre