...

An A record is a typical host name pointer to an IP address. So, sipxsipxecs.xyzcompanyexample.com might be an A record that points to 127.1.1.43. In this example, sipx sipxecs is the host name, xyzcompanyexample.com is the domain name and sipxsipxecs.xyzcompanyexample.com is referred to as the fully qualified domain name (fqdn). We use A records because it's easier to remember computer names than a series of numbers (for most people anyway). Most Asterisk configurations the author has seen run with an A record setup for the PBX.

SRV records (service records) are used by newer Internet protocols to locate a type of service that might be available for a domain. MX records (mail exchange) work similarly to SRV records but are used specifically for mail. SRV records can be used for any number of services. A SIP service record will look like _sip._udp.xyzcompanyexample.com. In this example a SIP device can query DNS for domain xyzcompanyexample.com and find an IP address or host name for SIP services running on the UDP protocol. Similarly, _sip._tcp.xyzcompanyexample.com would return an IP address or host name for SIP services running on the TCP protocol. So, a phone registering to the xyzcompanyexample.com domain would lookup _sip._udp.xyzcompanyexample.com and have the host name sipxsipxecs.xyzcompanyexample.com returned. Why not just cut to the chase and use the A record? You'll see why in a bit.

...

Internally DNS zone file for the xyzcompanyexample.com domain would have an A record setup pointing to the IP of the PBX:

sipxsipxecs         A          192.168.10.2

Have your ISP (or if you can do it yourself with a self-managed DNS hosting provider) add an A record for your pbx pointing at the external IP address of your firewall/SBC.

Externally, DNS would have an A record setup pointing to the external IP which is mapped to the internal IP of the PBX:

sipxsipxecs         A          127.1.1.43

Testing A Record Configuration

Verify that it all works properly by pinging the PBX by name from both inside the firewall and from outside the firewall using the same DNS domain name.  For example:

ping sipxsipxecs.xyzcompanyexample.com

Should return something like:

Pinging sipxsipxecs.xyzcompanyexample.com [192.168.10.2] with 32 bytes of data:

Reply from 192.168.10.2: bytes=32 time=1ms TTL=64

Reply from 192.168.10.2: bytes=32 time=1ms TTL=64

Reply from 192.168.10.2: bytes=32 time=1ms TTL=64

Reply from 192.168.10.2: bytes=32 time=1ms TTL=64


Ping statistics for 192.168.10.2:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 1ms, Maximum = 1ms, Average = 1ms

...

So, why are SRV records typically used by sipXecs? Well, they allow us to be contacted with the same address used to deliver e-mail and SRV records allow for to provide server redundancy and load balancing.

Take for example the top salesperson for XYZ Example Company, Joe User. Joe's phone extension is 512 and he has an email address of joe.user@xyzcompanyuser@example.com. SRV records allow Joe User to be contacted at [] and if an alias is put on his user account he can also be called by phone at []. If xyzcompanyexample.com were using A records for their sipXecs installation, Joe's phone number and alias would have be [] and [] respectively (unless of course the addresses are transformed by the SBC, but then we get into the whole problem of inside the network and outside the network).

...

_sip._udp.example.com 86400 IN SRV 0 5 5060 sipxsipxecs.xyzcompanyexample.com.

This SRV record points to a server named sipxsipxecs.xyzcompanyexample.com listening on UDP port 5060 for SIP protocol connections. The priority given here is 0, and the weight is 5.

...

_sip._udp.example.com 86400 IN SRV 10 60 5060 sipx1.xyzcompanyexample.com.

_sip._udp.example.com 86400 IN SRV 10 20 5060 sipx2.xyzcompanyexample.com.

_sip._udp.example.com 86400 IN SRV 10 20 5060 sipx3.xyzcompanyexample.com.

_sip._udp.example.com 86400 IN SRV 20 0 5060 sipx4.xyzcompanyexample.com.

The first three records share a priority 10, so the weight field's value will be used by clients to determine which host to contact. The sum of all three values is 100, so sipx1.xyzcompanyexample.com will be used 60% of the time. The other two hosts, sipx2 and sipx3, will be used for 20% of requests each. If sipx1.xyzcompanyexample.com is unavailable, these two remaining machines will share the load equally, since they will each be selected 50% of the time.

If all three hosts with priority 10 are unavailable, the record with the next highest priority value will be chosen, which is sipx4.xyzcompanyexample.com. This might be a machine in another physical location, presumably not vulnerable to anything that would cause the first three hosts to become unavailable.

...

So, internally DNS zone file for the xyzcompanyexample.com domain would have an A record setup pointing to the IP of the PBX:

sipxsipxecs         A         192.168.10.2

And then the SRV records would be setup as follows:

_sip._udp.xyzcompanyexample.com   86400     IN        SRV        10          100         5060        sipxsipxecs.xyzcompanyexample.com

_sip._tcp.xyzcompanyexample.com   86400     IN        SRV        10          100         5060        sipxsipxecs.xyzcompanyexample.com

Externally, DNS would have an A record setup pointing to the external IP of the PBX (which would have a 1:1 NAT mapping to the internal IP address of the PBX and be firewalled appropriately):

 sipxsipxecs        A         127.1.1.43

And then the SRV records would be setup exactly as they were internally (note, if you are using OpenSBC it only needs the UDP record):

_sip._udp.xyzcompanyexample.com   86400     IN        SRV        10          100         5060        sipxsipxecs.xyzcompanyexample.com

_sip._tcp.xyzcompanyexample.com   86400     IN        SRV        10          100         5060        sipxsipxecs.xyzcompanyexample.com

Testing SRV Configuration

...

dig --t SRV _sip._udp.xyzcompanyexample.com

The following will be displayed:

; <<>> DiG 9.3.4-P1 <<>> -t SRV _sip._udp.xyzcompanyexample.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48387
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_sip._udp.xyzcompanyexample.com. IN      SRV

;; ANSWER SECTION:
_sip._udp.xyzcompanyexample.com. 0 IN SRV      0 0 5060 sipxsipxecs.xyzcompanyexample.com.

;; Query time: 3 msec
;; SERVER: 172.16.1.254#53(172.16.1.254)
;; WHEN: Sat Jan 3 15:46:12 2009
;; MSG SIZE rcvd: 81

From the ANSWER: 1 in the returned information and the sipxsipxecs.xyzcompanyexample.com in the ANSWER SECTION: we know that the SRV record is working properly.

...

Default Server: UnKnown
Address: 172.16.1.254
> set querytype=SRV
> _sip._udp.xyzcompanyexample.com
Server: UnKnown
Address: 172.16.1.254

_sip._udp.xyzcompanyexample.com SRV service location:
          priority         = 0
          weight           = 0
          port             = 5060
          svr hostname     = sipxsipxecs.xyzcompanyexample.com

Scenario 1 – sipXecs PBX on the Data Network

Ok, so most companies aren't hiding under rocks and they are already using DNS internally on their networks.  Like many, the internal network DNS domain name may not be the same as their Internet facing domain.  Consider the following network scenario:

With our fictitious company (sorry if it's not), the internal computer network has an existing DNS domain of xyzcompanyexample.corp which is being used by Active Directory.  DHCP and DNS are being handled by the file server at 192.168.10.10.  The simplest approach to integrating sipXecs into this network is to leave DNS and DHCP on the file server and add the required SRV records and DHCP options to it.

...

1. The operation of your phone system is dependent on DNS working.  If DNS or your File Server has problems, your phone system is also down.
2. Mobile users that need to roam to different networks outside of the organization will not be able to resolve the xyzcompanyexample.corp domain from the internet.
3. Users outside of your organization can not call your system via a SIP URL (sip:ext@xyzcompanyext@example.com).

Problems 2 and 3 can be worked around, but problem 1 is the bigger issue.  Making sure that you have a robust DNS configuration is important to your computer network and your phone network.

...

Add a new host record for the PBX (in the above example it would be something like sipxsipxecs.xyzcompanyexample.corp) pointing to the IP address of the PBX.

Add SRV records for _sip._udp.xyzcompanyexample.corp, _sip._tcp.xyzcompanyexample.corp and _sip._tcp.rr.sipxsipxecs.xyzcompanyexample.corp all pointing to sipxsipxecs.xyzcompanyexample.corp (if you are doing this in a Microsoft Windows environment, see document mentioned in beginning of this whitepaper).

In a bind (Linux DNS) configuration file these records would look something like this:

_sip._tcp.xyzcompanyexample.corp.         IN SRV 1 0 5060 sipxsipxecs.xyzcompanyexample.corp.
_sip._udp.xyzcompanyexample.corp.         IN SRV 1 0 5060 sipxsipxecs.xyzcompanyexample.corp.
_sip._tcp.rr.sipxsipxecs.xyzcompanyexample.corp. IN SRV 1 0 5070 sipxsipxecs.xyzcompanyexample.corp.
sipxsipxecs.xyzcompanyexample.corp.              IN A            192.168.10.2

Configure DHCP

...

subnet 192.168.10.0 netmask 255.255.255.0 {
        range 192.168.10.20 172.168.10.254;  #IP Range
        default-lease-time 21600;
        max-lease-time 43200;
        option routers 192.168.10.1;  # Default gateway
        option subnet-mask 255.255.255.0;  # Subnet mask
        option domain-name "xyzcompanyexample.corp";  #DNS Domain Name
        option domain-name-servers 192.168.10.10;  #DNS Server IP
        option time-offset 18000;  # Eastern Standard Time
        option tftp-server-name "sipxsipxecs.xyzcompanyexample.corp";  #phone provisioning
        option ntp-servers 192.168.10.10;  #get time from file server
        }

...

If users are connecting from the Internet they are never going to be able to resolve xyzcompanyexample.corp because it isn't a valid DNS domain name. Your organization more than likely has something like xyzcompanyexample.com that is registered with an organization like Network Solutions and hosted either there or at another DNS hosting provider. The following host record and SRV records must be configured at your DNS hosting provider:

_sip._tcp.xyzcompanyexample.com.        IN SRV 1 0 5060 sipxsipxecs.xyzcompanyexample.com.
_sip._udp.xyzcompanyexample.com.        IN SRV 1 0 5060 sipxsipxecs.xyzcompanyexample.com.
sipxsipxecs.xyzcompanyexample.com.             IN A            127.1.1.43  # Change to outside IP of your FW

...

One last step needs to be completed. sipXecs allows for domain name aliases (System Menu -> Domains). Add a domain alias for xyzcompanyexample.com. An alias allows the sipXecs system to respond to requests made to domains other than the domain it is setup with. It thus should be possible to setup your mobile users differently than your fixed position hard phone users and do a translation of xyzcompanyexample.com to xyzcompanyexample.corp.

Dynamic DNS

Wondering what about the case where the external IP address may change like with a Cable Modem or DSL connection?  Usually the only way you will be able to deal with SRV records is by owning your own domain.  Drop $20 a year with a hosting provider like GoDaddy.com or similar (just make sure they let you have SRV records) and get yourself a domain name.

...

The dynamic DNS provider will let you determine your own host name and tag it to one of their domain names. For instance, xyzpbxexamplecorp.dyndns.net might be a host name you could specify. We can then point to this dynamic DNS name from our own domain.

For pointing a host name at another host name we'll use a CNAME record (canonical name). So, externally the DNS would have a CNAME record setup pointing to the dynamic DNS name:

sipxsipxecs                CNAME                yzpbxexamplecorp.dyndns.net

And then the SRV records would be setup also pointing to the dynamic DNS name as follows:

_sip._udp.xyzcompanyexample.com 86400 IN SRV 10 100 5060 xyzpbxexamplecorp.dyndns.net
_sip._tcp.xyzcompanyexample.com 86400 IN SRV 10 100 5060 xyzpbxexamplecorp.dyndns.net

Advanced DNS configuration

...