[Freeswitch-users] Best practices question about SIP registration

Thu Jan 10 12:31:29 MSK 2013

> 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

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 at 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 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
>
>
> _________________________________________________________________________
> 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