Categories

CUC (6) CUCM (27) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Sunday, 12 May 2013

Using SRV records for redundancy and server discovery in Presence, Jabber and CUCM

As most of the time, I stumbled across this topic, and I was really thinking about posting something about UCCX again, but things change dont they. Especially when working on tightly scoped, well documented and designed implementation, ;-).

I have never really given the possibilities of using SRV records much thought, so most of this post is a bit of research for myself as well


Before I go into SRV records, here is a definition, for those who are not yet familiar with the mechanism.



DNS records consist of a series of entries that match a server name to a single IP address in a networked environment. Every one knows this! DNS SRV records differ in that they match a service with a server (hostname), or set of servers, in a networked environment.  In doing this, DNS SRV allows a client to only have to know what type of service it is looking for instead of the actual server.  This aids deployment, server management, and service failover because most networked environments have multiple, load balanced servers attending to the needs of a particular service.


As you can see in the table below, there are a good few services that can be requested/discovered from the various Collaboration clients, using the mechanism of SRV records.

ServiceDNS SRV Record
Cisco WebEx Messenger_xmpp-client._tcp
Cisco Unified Presence_cuplogin._tcp
Cisco Unified Communications Manager TFTP_cisco-phone-tftp._tcp
Cisco Unified Communications Manager CCMCIP_cisco-phone-http._tcp
Cisco TelePresence Video Communication Server (Internal)_sip._tcp.internal
Cisco TelePresence Video Communication Server (External)_sip._tcp.external
Cisco Jabber Video for TelePresence_ciscowtp._tcp
Cisco WebEx TelePresence_ciscowtp._tcp

source: http://www.cisco.com/en/US/docs/voice_ip_comm/jabber/iPad/9_x/JABP_BK_J3C828CB_00_jabber-for-ipad-admin_chapter_01000.html

(On Jabber TFTP and CCMCIP will not be used as they are pushed out by CUPS as soon as a user logs in, through CCMCIP profile and TFTP server settings in CUPS). 


Applications:


SRV records are an easy way to build  a redundant SIP Publish trunk between CUCM and CUPS. (The conventional way would be to add to separate destinations, using port 5060, in the screenshot below. You could argue that that would be a more robust way, when using IP addresses i.e. no DNS dependency).


As you can see below, the SIP trunk configured on the CUCM side, is configured as presence.lala.com.au. The Destination address is SRV is ticked.



The DNS SRV record for _sip._tcp is set up to point to two different CUPS servers, with varying priority.

Test redundancy and SRV records out, by issuing:

nslookup
> set type=srv
> _sip._tcp.presence.lala.com.au   <-----this is your SRV destination address
Server:  lala.com.au
Address:  89.10.10.10

_sip._tcp.presence.lala.com.au       SRV service location:
          priority       = 20
          weight         = 0
          port           = 5060
          svr hostname   = bun-cups-sub.lala.com.au
_sip._tcp.presence.lala.com.au       SRV service location:
          priority       = 10
          weight         = 0
          port           = 5060
          svr hostname   = bun-cups-pub.lala.com.au
lala.com.au  nameserver = s1.lala.com.au
lala.com.au  nameserver = s2.lala.com.au
bun-cups-pub.lala.com.au     internet address = 10.11.255.21
bun-cups-sub.lala.com.au     internet address = 10.11.255.41
s1.lala.com.au     internet address = 89.10.10.10
s2.lala.com.au     internet address = 89.10.10.10

as you can see, the SRV record returns two servers, one CUPS subscriber and one CUPS Publisher.



Automatic Server discovery (Jabber for Windows only)

You can also use SRV records, to do Automatic Server discovery for Jabber. This makes deployment a bit easier as users do not have to manually type in the presence server host address.
This is required when you use the default server as the login server for Jabber for Windows. (automatic server discovery does NOT work with iphone and ipad where a CUPS hostname or IP address is required).



It is my understanding that this will also use _sip._tcp, but according to the


> _cuplogin._tcp.lala.com.au
Server:  s2.lala.com.au
Address:  131.172.2.2

_cuplogin._tcp.lala.com.au   SRV service location:
          priority       = 20
          weight         = 0
          port           = 8443
          svr hostname   = bun-cups-sub.lala.com.au
_cuplogin._tcp.lala.com.au   SRV service location:
          priority       = 10
          weight         = 0
          port           = 8443
          svr hostname   = bun-cups-pub.lala.com.au
lala.com.au  nameserver = s1.lala.com.au
lala.com.au  nameserver = s2.lala.com.au
bun-cups-pub.lala.com.au     internet address = 10.11.255.21
bun-cups-sub.lala.com.au     internet address = 10.11.255.41
s1.lala.com.au     internet address = 89.172.2.10
s2.lala.com.au     internet address = 89.172.2.11
>




Reference:
http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/deploy.html


Hope this post is usefull, and inspired you to look into the possibilities that SRV record can provide. If you have any useful scenarios, especially in the Unified Comms playing field, please share them or inbox me.

Thanks




1 comment:

  1. Note of the above - DNS SRVs for the SIP PUBLISH Trunk are not supported with IM and Presence High Availability deployments. Please refer to the Collaboration SRND.

    ReplyDelete