Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Does 8710 support DNS SRV for sip/h323 regisration failover?

Does the 8710 support DNS SRV for sip/h323 registration to handle SIP/H323 registraion failover on the VCS?  

We recently added a second VCS peer for redundancy.    We are planning to use two sip proxy on the video endpoints (TC6.3).   The 8510 supports DNS SRV according to the documentation.    However, most of our core work involves using scheduling with TMS and "one button to push" which relies on the 8710 cluster as the primary conferencing resource.    I am not able to find any documentation that state sthe 8710 supports DNS SRV or any registration redundancy whatsoever.  I have a case with cisco TAC open to confirm support.  Cisco TAC says the 8710 does support DNS SRV but they are trying to find out why there is no documentation on it.  And to provide documentation if it does exists.

Have anyone in the community used DNS SRV for the 8710?   Or are there any other methods for registration redundancy? 

The situation we are tryign to solve for is if the primary VCS fails in the middle of the day (and it happened recently) and we have conferences already scheduled, I would like the 8710 to re-regiser to the secondary VCS like the endpoints do so it will register those new conferences onto that secondary VCS.

Referenced Doc:  vcs cluster deployment for 14.1 and x7.2.2

Software versions:

VCS version x7.2.2

TPS 8710 version 3.0

TMS version 3.0

 

Thanks in advance!

Van

2 REPLIES

I just shortly tried to set

I just shortly tried to set up a pair of SRV records for h323(rs/ls) and sip(tls/tcp).

And at least the sip registered fine (tls) to the second peer with lower priority.

 

I did not see that it worked on h323, but from how I recall it on the MCU it also

used the gatekeepers alternate rather than SRV.

So your second vcs would need to be part of a cluster for that. (but I did not test this now if it would work)

 

How did you deploy it? I think the TPS makes in many cases sense to be deployed with

the conducter, but in that mode the registration is off anyhow and the trunk only mode is used.

 

But even in local managed more you could set it to trunk, use conference aliases which all start

with some kind of prefix which makes it easier to point search rules for them to a neigbor zone

pointing to the TPS.

That should work fine in your scenario as well and then you would not need to worry.

Please remember to rate helpful responses and identify

New Member

Hi Martin, Thanks for

Hi Martin,

 

Thanks for checking!   Can you check if the primary VCS fail, does the 8710 auto-matically re-register to the VCS with the higher priority?   

Ideally, if the primary VCS has a hard-down in the middle of the day, the 8710 will re-register to the new VCS.   This way the TMS will instruct the 8710 to register the new conference number prior to the conference starting successfully. 

Our setup is pretty straight-forward.  

- We use TMS 14.3, VCS x7.2.2, and TPS (MSE 8710 cluster) ver 3.0 to handle scheduling which is the core of the business.   They like the idea of coming into a system and pressing one button to join a conference.    

- All the endpoints are cisco/tandberg endpoints with TC6.3+.    They are register to the single VCS currently.   

- The 8710 cluster also registers to the single VCS.  

Currently, from my understanding, the conductor does not yet support scheduled conferencing.  

 

Van

56
Views
0
Helpful
2
Replies
CreatePlease to create content