[Freeswitch-users] Best practices question about SIP registration

[Michael Collins]

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


-- 
Michael S Collins
Twitter: @mercutioviz
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130108/cd182ebc/attachment.html