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