Tag: Jabber

Revisiting Cisco Jabber SRV Records

From time to time I like to revisit previously discussed topics, today is the day for Cisco Jabber SRV records. Previously I had written a post talking about internal Jabber SRV records and how to configure and use them. That post is located here for your viewing pleasure.

The truth is that internal SRV records, when it comes to Cisco Jabber, are only half of the story. To tell the whole story, you need to have at least a partial understanding (and hopefully a working knowledge) of Cisco’s Collaboration Edge. If you do not, this will be a bit out of context for you, but the theory is easy enough to understand.

So you have an on premise Cisco IM & Presence installation and you have users on your internal network that are using Cisco Jabber. It is a very powerful business tool; instant messaging, screen sharing/control, and desktop video/voice all from one convenient and surprisingly well built application. What happens when your users leave your internal network? Do they VPN? Do they use WebEx? Or perhaps something less IT friendly? What if they could use Cisco Jabber wherever they are, without the hassle of VPN and securely from any device? The truth is, they can!

In comes Collaboration Edge, it goes by a few other names, but this post isn’t about Collaboration Edge…directly, its about a very handy SRV record that sits on your external DNS server(s) to make the Collaboration Edge integration possible. For a 1000ft view, Collaboration Edge includes two appliances, one on the LAN and one on the Internet or DMZ. These two appliances talk together using magic, pixie dust, tiger blood and SSL certificates (those are the ones that really scare me, but that is for a different post). With these two appliances talking, they are also linked to CUCM and voila’ we have extended CUCM’s capabilities to the information super-highway known as the Internet. It’s certainly not that simple, but you get the idea.

We know from my previous post that Cisco Jabber can discover it’s  network services via DNS SRV records. Internally it can discover both CUCM (for directory services and service profiles) and IM&P (for login and instant messaging, etc.). The process for discovering services outside of the network is very similar, but the differences are worth noting.

Cisco Jabber always searches for the same services i.e. SRV records no matter what network it is on. Whether it is on your internal network or just sitting on the Internet i.e. a home network the discovery is the same.

When you put in your Jabber ID (JID) i.e. someone@somewhere.com Jabber queries the following records based on the domain of your JID.

  • Jabber looks for WebEx Connect (Cloud instant messaging services).
  • Jabber looks for Internal SRV records i.e. cuplogin and cisco-uds (as shown below).

_cisco-uds._tcp.example.com

_cuplogin._tcp.example.com

  • If Jabber does not get a response from either of these records it looks for collab-edge which is pointing at the Collaboration Edge – Internet side appliance from earlier (as show below).

 

_collab-edge._tls.example.com

The collab-edge record configuration looks like this…

_collab-edge._tls.example.com   SRV service location:
          priority       = 3
          weight         = 7
          port           = 8443
          svr hostname   = vcse1.example.com

 

Assuming that no other records above the collab-edge record answer, Jabber sends its login request to the device attached to SRV record and logs into internal IM & Presence server as well as CUCM and any other services configured in the service profile.

A couple of import things to remember when talking about external DNS. First, some well-meaning DNS administrators will put a catch-all in their external DNS configuration so that anything destined for *.somewhere.com goes to their website. This is fine, but it will break your external Jabber connectivity. This break occurs because even though it doesn’t exist cuplogin.somewhere.com will still be caught by the catch-all. Second, collab-edge goes in the external DNS environment only. Just like cisco-uds and cuplogin are only internl, collab-edge is only external. Forgetting or disregarding this will surely make your troubleshooting much more interesting to say the least…

I hope this has been helpful to someone. Cisco Jabber is a power tool and when paired with Collaboration Edge the possibilities are endless. Hopefully some day soon I’ll be able to write a series about Collaboration Edge and its many facets but until then, thanks for reading.

-Justin

Advertisement

Cisco Jabber SRV Records: Being a Knowledgeable & Helpful Collaboration Engineer

If you’ve deployed Cisco’s IM & Presence (formerly Cisco Unified Presence or CUPS) and its associated Jabber product line, you know all about DNS SRV records, or at least you should.
If you don’t know about them or if you are a little rusty, Cisco has a good document (link below) that you should get to know intimately…
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html

SRV records allow servers to advertise service locations within the core of the DNS architecture. For example: _cuplogin._tcp.example.com is an SRV record the Jabber looks for during service discovery and sign-in. The record above points at the IM & Presence service across port 8443 which happens to be what Jabber/IM&P uses for authentication. There are SRV records that Jabber looks for for directory services as well as Collaboration Edge (Cisco Expressway) which is its own animal.

Without SRV records flexible Jabber deployment becomes difficult and Collaboration Edge integration becomes next to impossible.

So we know that SRV records are important, but are they really our problem as Collaboration Engineers? I guess that depends on how broad your IT shop or your customer’s IT shop is. You may have, at your disposal, wonderful Server Engineers who know DNS like you know Call Manager, but not every situation is that clean.

I realize that not every enterprise uses Windows for internal DNS, but since the majority seem to, we’ll cover Windows DNS. My system is a 2008 Server Standard instance.

– What SRV records do we need to add? Cisco gives us a good run down in the document referenced above, I copied the below passage from that document.

The following is an example of the _cisco-uds SRV record:
_cisco-uds._tcp.example.com 
priority       = 1
weight         = 5
port           = 8443
svr hostname   = cucm1.example.com

The following is an example of the _cuplogin SRV record:
_cuplogin._tcp.example.com
priority       = 5
weight         = 100
port           = 8443
svr hostname   = cup1.example.com

**There are additional records required for Collaboration Edge**

In the outputs above, you’ll see the SRV record and its priority, weight, port  and host the has the service. You’ll notice in the SRV record itself that TCP is called out. If these were UDP SRV records you would of course see UDP in the SRV.

– How does this translate to Windows DNS? Pretty easily actually…

Below is the DNS Manager screen from my server.

                      DNS Management

You’ll see that under my domain’s Forward Lookup Zones there are several folder entries including _tcp, _udp, and others.

If you right click on the domain (image below)  you’ll able to add Other New Records and from here you can select SRV records

New Other RecordsSelect SRV Record Type

Once you select your SRV record type you can begin configuring the SRV record (shown below)

SRV Record Config

Once you fill in the particulars and click OK, you’ll see your record(s) under the _tcp organizational folder (shown below)

Show SRV Records

From there, repeat the process to add the other records that you need.

We haven’t really talked about priority and weight and they do exactly what you might expect them to do. Multiple systems can respond to the same SRV record within the same DNS domain. Like anything else, someone has to be first. Assigning a priority and a weight allows you to both build redundancy and load balance across multiple hosts. For instance if you have a CUCM PUB and a SUB, you may be want the SUB to respond first and thus would give it a higher priority for its _cisco-uds record.

In closing, you may never need to know how to add SRV records but if you do, hopefully you’ll remember this post and be successful in your deployment.

-Justin