cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4569
Views
0
Helpful
15
Replies

VCS Cluster - FQDN and SRV Records

Patrick Sparkman
VIP Alumni
VIP Alumni

I'm having trouble understanding the VCS Cluster's FQDN and associated SRV records for incoming calls and registrations.

According to the VCS Cluster Deployment Guide:

Example: DNS SRV records for 2 peers of a VCS Expressway cluster for company.com

Where:

  • FQDN of VCS Expressway peer 1: vcse1.company.com
  • FQDN of VCS Expressway peer 2: vcse2.company.com
  • FQDN of VCS Expressway cluster: company.com

_sips._tcp.company.com. 86400 IN SRV 1 1 5061 vcse1.company.com.

_sips._tcp.company.com. 86400 IN SRV 1 1 5061 vcse2.company.com.

    Where does the Cluster's FQDN play a part in the SRV records, and also the cluster peers. It's my understanding that in the above SRV records, company.com would be the SIP domain, not the cluster FQDN.  I understand SRV records, as we have 1 VCS, adding a second to be clustered, so the cluster FQDN is throwing me for a loop.  I've been reading over all the guides and posts here in the forums, but I just can't wrap my head around it. 

    Would the following be correct, looking from the outside going in at the DNS records:

    • FQDN for registrations and/or calls (video.domain.com)
      • _sips._tcp.video.domain.com. 86400 IN SRV 1 1 5061 vcsgw.domain.com.
    • VCS Cluster FQDN (vcsgw.domain.com)
      • _sips._tcp.vcsgw.domain.com. 86400 IN SRV 1 1 5061 vcs-c1.domain.com. (VCS Peer1)
      • _sips._tcp.vcsgw.domain.com. 86400 IN SRV 1 1 5061 vcs-c1.domain.com. (VCS Peer2)

    I also understand that A records need to be in place for the Cluster FQDN to point to each cluster peer, however they are not shown in this example.

    Thanks!

    15 Replies 15

    Hi Patrick, my experience my differ to yours and it's been a while since I had endpoints registering to a VCS, but my understanding is that your assumptions are correct.

     

    I'm 90% sure you can configure a cluster of peers without actually needing the SRV record, the SRVs are used for endpoints to failover between peers.  They can also be used for zones, although I would generally suggest listing each peer individually instead.  The SRV record would contain A records for each peers in the cluster, then your endpoints would point to the SRV, e.g.:

     

    SIP SRV for domain.com on internal DNS, points to both vcsc1.domain.com and vcsc2.domain.com.

    Your endpoints then point to domain.com as their SIP proxy.

     

    Same again on your public DNS, but pointing to vcse1.domain.com and vcse2.domain.com.  Your endpoints can continue to point to domain.com.

     

    Does this clear things up?