cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5993
Views
56
Helpful
43
Replies

Ask the Expert: Cisco TelePresence for the Enterprise

ciscomoderator
Community Manager
Community Manager

Welcome to the Cisco® Support Community Ask the Expert conversation.  This is an opportunity to learn and ask questions about Cisco Telepresence® for the enterprise. 

Cisco experts Jaret, Fernando, and Fred will be covering all Cisco TelePresence products.  Topics include Cisco TelePresence endpoints and TelePresence infrastructure such as the Cisco TelePresence Video Communication Server (VCS), Cisco Expressway Series, Cisco Unified Communication Manager (CallManager), Cisco TelePresence Servers (MSE 8710, on Virtual Machine, etc.), MCU (MSE 8510, etc.), Cisco TelePresence Management Suite (TMS), and all other Cisco TelePresence related devices.

 

Jaret Osborne is an 8-year Cisco Advanced Services veteran.  In his Advanced Services tour, Jaret has covered all aspects of Cisco Unified Communications and TelePresence products, including both enterprise and service provider verticals. Most recently Jaret has been working with global service providers supporting their Cisco TelePresence as a Service offerings while also incubating new cloud services at Cisco.

 

 

Fernando Rivas is a Cisco Advanced Services NCE, starting in the Cisco Technical Assistance Center (TAC), 2007, on the Collaboration Technology Team mastering the Cisco Unified Communication  technologies and specialized in call control CUCM,VCS) and  conferencing (MeetingPlace, Telepresence). In 2011, he joined Cisco Advanced Services as a member of the Cisco Collaboration team and participated in several Cisco TelePresence and video-related technologies deployments. Currently he is a member of the Video Cloud Technology Team, supporting video exchanges in several and architecting new private video cloud solutions for large enterprises. Fernando holds a routing and switching CCIE® certification (22975).

 

Fred Mollenkopf  is a Cisco Advanced Services Network consulting engineer working at Cisco for the last 7 years. Fred has led some of the largest Cisco Unified Communication and Collaboration deployments done for Cisco customers and partners. Over 15 years’ experience in data networking with a specialization in Cisco Unified Communications in 2004. Currently he is a member of the SP Video Advanced Services Team, supporting SP video exchanges and the Cisco Telepresence solutions.  Fred maintains an active CCIE® in Voice (17521).

 

Remember to use the rating system to let Jaret, Fernando, and Fred know if you have received an adequate response. 

Because of the volume expected during this event, Jaret, Fred, and Fernando might not be able to answer every question. Remember that you can continue the conversation in the Collaboration, Voice and Video Community, under the sub-community TelePresence, shortly after the event. This event lasts through August 15, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

 

43 Replies 43

Hi guys,

geat topic, thanks for the opportunity to ask questions!

I'm trying to configure Mobile and Remote Access feature but using only CUCM without Presence server, meaning my Jabber for Windows client is running in phone-only mode. Currenly I'm trying to understand what should the Service Profile contain in that specific case: I'm currently using completely empty Service Profile and would like to know if that is correct? If I'm adding something in the Service Profile I would like to know why it is necessary for this particular configuration.

Second question is still related to the same case: is it necessary to create jabber-config.xml file or it will work without any modifications, i.e. with default values for all "hidden" parameters.

I'm aware my questions require testing it in a lab but I hope you'll find couple minutes to confirm that it is working.

Thanks,

Tenaro

Hi Tenaro - We're setting this up in our lab and reviewing some documentation.  Will hopefully have an update in a few hours.  Thanks for the question!

Regards,

-Jaret

Great! Thanks!

It's taking a lot longer than we anticipated.  Our lab did not have MRA setup and we spent most of yesterday getting it configured.  At this point, we have been unable to get Jabber in phone-only mode to register via MRA, but I believe we have something incorrectly configured with the authentication.  I'm hoping to have some progress in a few hours.

Were you able to get it working or is that the reason for your question?

-Jaret

It is not working in my lab either. Full UC mode is working fine (inside and outside) but phone-only mode is working only inside while outside it fails after entering credentials (meaning it starts doing something but it can not complete the registration).

Thanks for your effort guys!

Thanks for the details.  That is exactly how it is working in our lab.  Since we didn't have MRA working previously, we aren't sure if it's a mis-configuration of MRA or something that is not supported.  We will continue to try to get this topology working and I will also reach out to the development teams for comment.

Finally, we have it working.  I'm guessing your certificates on your Expressway -E and -C are missing some entries. You need to have the domain that you are using to log in as part of the Alternative Name in the -E cert.  When you go to generate a CSR on the Expressway-E, it will ask you for any additional DNS names to add to the cert.

Also, if you are using a Microsoft CA, you need to edit the template that you are using to create the Cert.  You can copy the default "Web Server" template and then edit the copied template: Extensions > Edit > Add > Client Authentication, then click OK, OK, OK.  You then need to publish the certificate template you just created.  Finally, create the -E and -C cert using the new template.

Good news and bad news....  The development team has confirmed that what you are trying to do is officially supported.  Bad news, we still haven't gotten MRA fully operational in our lab.  We haven't given up as we would like this configured too, will keep trying.

Tenaro,

Please attach a Diag Log if possible from your EW-C and EW-E and we can look to see where your client may be failing in the login flow.  

Also could you verify the versions of the Jabber Client, EW and CUCM that you are using.

 

Thanks

Fred

Tenaro,

Additionally here are the most common login issues.  Unfortunately this includes items related to Presence implementation but I commented where we did not use these in our lab setup for CUCM Phone Capabilities only.  

 

Login Issues

 

Problem:

Jabber Unable to Sign-in Through MRA

 

Solution

This can be caused by a number of things, a few of which are outlined below.

 

 1.  Collaboration Edge SRV record not created and/or port 8443 unreachable

For a jabber client to be able to login successfully using MRA, a specific collaboration edge SRV record must be created and accessible externally. When a jabber client is initially started it will make server DNS SRV queries:

 

  1. _cisco-uds : this SRV record is used to determine if a CUCM server is available.

  2. _cuplogin : this SRV record is used to determine if an IM&P server is available.

  3. _collab-edge : this SRV record is used to determine if MRA is available.

If the jabber client is started and does not receive an SRV answer for _cisco-uds and _cuplogin, and does receive an answer for _collab-edge then it will use this answer to try to contact the Expressway-E listed in the SRV answer.

 

The _collab-edge SRV record should point to the FQDN of the Expressway-E using port 8443. If the _collab-edge SRV is not created, or is not externally available,  or if it is available, but port 8443 is not reachable, then the jabber client will fail to login.

 

 

 2.  Unacceptable or No Available Certificate on VCS Expressway

After the jabber client has received an answer for _collab-edge, it will then contact the expressway using TLS over port 8443 to try to retrieve the certificate from the expressway to setup TLS for communication between the jabber client and the expressway.

 

If the Expressway does not have a valid signed certificate that contains either the FQDN or domain of the Expressway, then this will fail and the jabber client will fail to login.

 

If this is occurring, the you should use the CSR tool on the Expressway, which will automatically include the FQDN of the expressway as a Subject Alternative Name.

 

MRA requires secure communication between the Expressway-C and Expressway-E, and between the Expressway-E and external endpoints.

 

Expressway-C Server Certificate Requirements:

  1. The Chat Node Aliases configured on the IM&P servers. This is required if you are doing XMPP federation.  The Expressway-C should automatically include these in the CSR provided that an IM&P server has already been discovered on the Expressway-C.
  2. The names in FQDN format of all Phone Security Profiles in CUCM configured for TLS and used on devices configured for MRA. This allows for secure communication between the CUCM and Expressway-C  for the devices using those Phone Security Profiles.

 

Expressway-E Server Certificate Requirements:

  1. All domains configured for Unified Communications. This includes the domain of the Expressway-E and C, e-mail address domain configured for Jabber, and any presence domains.
  2. The Chat Node Aliases configured on the IM&P servers. This is required if you are doing XMPP federation. 

 

The MRA Deployment guide describes this in greater detail on pages 17-18. (http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-1/Mobile-Remote-Ac...

 

Note: In our lab for testing Phone Capabilities only, we did not include the Chat Node Aliases in the certificate as we were not using IM&P.

 

 3.  No UDS Servers Found in Edge Config

After the Jabber client successfully establishes a secure connection with the Expressway-E, it will ask for its edge config. This edge config will contain the SRV records for _cuplogin and _cisco-uds. If these SRV records are not returned in the edge config, then the jabber client will not be able to proceed with trying to login.

 

To fix this, make sure that _cisco-uds and _cuplogin SRV records are created internally and resolvable by the Expressway-C

 

More information on the DNS SRV records can be found on page 10 of the MRA deployment guide for X8.1.1 (http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-1/Mobile-Remote-Access-via-Expressway-Deployment-Guide-X8-1-1.pdf)

 

Note: In our lab for testing Phone Capabilities only, we did not include the DNS SRV for _cuplogin.

 

 4.  The Expressway-C logs will indicate the following error: XCP_JABBERD  Detail="Unable to connect to host '%IP%', port 7400:(111) Connection  refused"

If Expressway-E NIC is incorrectly configured, this can cause the XCP server to not be updated. If the Expressway-E meets the following criteria, then you will likely have this issue:

 

  1. Using a single NIC
  2. Advanced Networking Option Key is installed
  3. Use Dual Network Interfaces option is set to “Yes”

To correct this problem, change the “Use Dual Network Interfaces” option to “No”

 

The reason this is a problem is because the Expressway-E will be listening for the XCP session on the wrong network interface, which will cause the connection to fail/timeout. The Expressway-E listens on TCP port 7400 for the XCP session. You can verify this by using the netstat command from the VCS as root.

 

Note: We used a Dual Network Interface Expressway for testing but were not using XCP, so this was not applicable to us.

 

 5.  VCE-E Server hostname/domain name does not match what is configured in the _collab-edge SRV.

If the Expressway-E Server hostname/domain name does not match what was received in the _collab-edge SRV answer, the jabber client will not be able to communicate to the Expressway-E. The Jabber client uses the xmppEdgeServer/Address element in the get_edge_config response to establish the XMPP connection to the Expressway-E.

 

This is an example of what the xmppEdgeServer/Address would look like in the get_edge_config response from the Expressway-E to the Jabber client:

 

<xmppEdgeServer>

<server>

<address>ott-vcse1.vcx.cisco.com</address>

<tlsPort>5222</tlsPort>

</server>

</xmppEdgeServer>

 

To avoid this, make sure that the _collab-edge SRV record matches the Expressway-E hostname/domain name. Enhancement CSCuo83458 has been filed for this. 

 

Note: This was one of our issues when we first setup.  We adjusted our Expressway-E to insure the below:

  • System > Administration > System Name this was the FQDN
  • System > DNS > System Host Name was the host portion of the FQDN
  • System > DNS > Domain Name was the domain portion of the FQDN
  • System > Clustering > Cluster Name (FQDN for Provisioning) was the FQDN

 

 6. Unable to log into certain IM&P servers. VCS logs say "No realm found for host cups-example.domain.com, check connect auth configuration"

 

From the Expressway-E, go to Configuration -> Unified Communications -> IM&P Servers. Open each server and click "Save" again. Not sure exactly why this happens.

 

Note:  This was N/A to our test and can be ignored with Phone Capabilities only.

 

 

Thanks

 

Fred

stoian.adrian
Level 1
Level 1

Hello,

A couple of question regarding Telepresence Server:

1. We have Telepresence Server 3.1(1.95). Is there any posibility to change the layout during the conference ?

2. Can we customize the audio prompts of the of the system? (eg: audio prompt for PIN entry)

Hello, thanks for your questions.

1. Yes, there are two ways to change the layout during the conference.  If the environment supports Active Control you can change via the Active Control capabilities on the endpoint.  If not using Active Control, you can change the layout using DTMF key's 2 and 8 or you can use the far end camera on the endpoint.  More details can be found on page 8:

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/ts/release_note/Cisco_TelePresence_Server_Software_Release_Notes_3-1_1-95.pdf

 

2. I do not believe that is possible, however I will do some research and get back to you.

 

Thanks,

Fernando and Jaret

 

1. Ok. We are using TMS for scheduling and we are taking into consideration to move from MCU to Telepresence Server.

The techniques you mentioned are used to change the layout from a user / endpoint perspective.

We are looking to change the layout from an admin perspective (this is how we use this feature now); let's say changing the layout for all the participants at the same time.

I'm not sure if this is possible with TMS and Telepresence Server ...

2. Thanks. I will wait for your response.

Thanks.

1. The TelePresence server has a "Default Endpoint Settings" where you can specify the default layout for all conferences.  You could also use the endpoint database on the 8710 to specify specific layouts for specific endpoints (although this can be troublesome to maintain - very admin intensive).  Finally, on TMS, when you schedule the conference you can select Voice Switched, Continuous Presence, or Enhanced Continuous Presence layouts.  I'm working on testing these layouts to confirm they work properly on the 8710 in the lab and will update once done.

2. The developers confirmed it is not possible to change the audio prompts.