[Freeswitch-users] Best practices question about SIP registration

Wed Jan 9 02:35:58 MSK 2013

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 at 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 at 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 at sipdomain>
>> The sip domain is similar to an email domain -- e.g., <mailto:
>> user at 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 at 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 at 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 at 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 at 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 at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>> 
>>> 
>>> 
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>> 
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at 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 at freeswitch.org
>> http://www.freeswitchsolutions.com
>> 
>> 
>> 
>> 
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>> 
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org