[Freeswitch-users] Best practices question about SIP registration

Lawrence Conroy lconroy at insensate.co.uk
Thu Jan 10 00:27:57 MSK 2013 

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 at 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 at lists.freeswitch.org
> [mailto:freeswitch-users-bounces at 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 at 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 at 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 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.
>>> 
>> 
>> 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 at 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 at fs.domain.local" used?
>> Does FreeSwitch use that or does it just use the auth.userId?
>> 
>> --
>> 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-use
>> rs
>> 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
> 
> 
> 
> _________________________________________________________________________
> 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

Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list