Showing results for 
Search instead for 
Did you mean: 

Webex Enabled Telepresence

Graeme Kay


We are working on the webex enabled telepresence and I am getting a DNS error, however our normal DNS zone works ie I can call the OSLO traffic cam's SIP uri and others outside of our business. From the VCSe I can also do an nslookup and see the A records for our webex domain and the domain.

Looking at the search history I get the 'resolution failed' attached.

Everything else is working with the WET apart from the actual call! It will schedule etc, telepresence endpoints gather in the MCU and other participants gather in webex but the MCU fails to dial through.

On setup, the deployment document was followed point for point but just need to finish this final step.


9 Replies 9

Martin Koch

The site you are trying to connect is also webex one touch enabled yes?

Did you try to do a manual dns lookup for your webex enabled site, either from the vcs or also from your computer.

TLS is enabled in your enviroment right?

Did you follow the guide?

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

Hi Martin,

Thanks for your reply, apologies my original port may not have been clear. Below is what we have tried:

  • Originally followed the April Configuration Document, took some time getting our webex acc enabled for WET so when we picked it back up the the latest release was the August document so we followed this right the way through in case anything was missed.
  • We have tried a manual DNS lookup using the nslookup tool on the VCSe, I can also do this from a laptop sitting on the internet and results come back. Whether they are correct I guess I need to clarify.
  • We do have TLS enabled in our environment
  • Our webex acc is one touch enabled.

I have attached the results of our DNS look up from the VCSe.

Many thanks,




I am not sure what version you are running or whether or not you are using Static NAT, but I found these related bugs (the first one especially) and am going to try to update from 8.2 to 8.2.1 to see if it helps.




If you are using on your webex zone config, try using just


Also make sure you have the latest DST X3 ca cert on your trust list. Both of these bit me. If you google "cisco 'whatever the specific name of the cert is I can't remember'" you will get a result to download the ca from cisco and you can put that in your trust list.


i had migrated from what was originally a x6.1 vcs and was not using a CRL which had an older DST cert in the trust list.


I am having a similar issue, however it looks as if my VCSe is resolving. The call setup request is simply timing out. Here is my search history output, I will share any information I find on this, looking into it now. I have set this up for about three customers thus far without a hitch, but of course doing it in house would have issues... :P



  • Search (72)
    • State: Completed
    • Found: False
    • Reason: Request Timeout
    • Info: Request Timeout
    • Type: SIP (INVITE)
    • CallSerial Number: 1df07225-3bb3-454c-9b64-87cfe513cf8c
    • Tag: 94f32101-f7c0-4841-a5ed-878bb1ced24b
    • Source (1)
      • Authenticated: True
      • Aliases (1)
        • Alias (1)
          • Type: Url
          • Origin: Unknown
          • Value:
      • Zone (1)
        • Name: DefaultZone
        • Type: Default
      • Path (1)
        • Hop (1)
          • Address:
        • Hop (2)
          • Address: 100.X.X.X:5061
        • Hop (3)
          • Address:
        • Hop (4)
          • Address:
    • Destination (1)
      • Alias (1)
        • Type: Url
        • Origin: Unknown
        • Value:
    • StartTime: 2014-08-07 10:54:45
    • Duration: 0.67
    • SubSearch (1)
      • Type: Directed
      • Path (1)
        • Hop (1)
          • Address: WebEx
        • Hop (2)
          • Address:
      • SubSearch (1)
        • Type: Admin Policy
        • Action: Proxy
        • ResultAlias (1)
          • Type: H323Id
          • Origin: Unknown
          • Value:
        • Zone (1)
          • Name: WebEx
          • Type: DNS
          • Protocol: SIP
          • Found: False
          • Reason: Request Timeout
          • StartTime: 2014-08-07 10:54:45
          • Duration: 0.34
          • Gatekeeper (1)
            • Alias (1)
              • Type: H323Id    <------I have seen this before and I believe it was just a cosmetic bug, I have turned H323 off on both VCS's
              • Origin: Unknown
              • Value:


Hi Shawn,

I have recently setup another internally and I was getting the same results. However, it appeared that the configuration at the webex end was not completely finished. It may be worth checking that out. One of the ways I figured it out was that I was missing a few settings on our webex site that I believe only appear when Webex enable the TP side.

It would also be worth checking the certificate side as I have since had an issue that the CA was not populated correctly but came back with no relevant information in the search history.

Let me know how you get on.


Thanks Graeme,

I am glad to hear this. I have been troubleshooting it since this AM, and I was feeling lie the issue had to be on ciscos side but I rekeyed and reinstalled my SSL cert (which I needed to do for other reasons anyway), and still no luck. What I did notice is that when I try to validate via OpenSSL from VCSe root, I get the following which looks like WebEx site is not even asking me for a cert.... I think... I'm not very adept with certs. But I also get a return 0 at the bottom and did not see anything else that jumped out as an error.....

That being said the site enablement was only completed yesterday AM. But the email said "Remaining steps to complete WXeTP enablement include: 1) Completion of the on-premise implementation and 2) enablement of TSP audio, if necessary."


Perhaps there are some backend syncronization remaining tasks on the WebEx end... Ill let you know if I find anything new.


~ # openssl s_client -CAfile /tandberg/persistent/certs/ca.pem -cert /tandberg/persistent/certs/server.pem -key /tandberg/persistent/certs/privkey.pem -connect
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Cisco Systems, CN = Cisco SSCA3
verify return:1
depth=0 C = US, ST = California, L = San Jose, O = "WebEx Communications, Inc.", CN =
verify return:1
Certificate chain
 0 s:/C=US/ST=California/L=San Jose/O=WebEx Communications, Inc./
   i:/C=US/O=Cisco Systems/CN=Cisco SSCA3
 1 s:/C=US/O=Cisco Systems/CN=Cisco SSCA3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
Server certificate
subject=/C=US/ST=California/L=San Jose/O=WebEx Communications, Inc./
issuer=/C=US/O=Cisco Systems/CN=Cisco SSCA3
No client certificate CA names sent
SSL handshake has read 3500 bytes and written 397 bytes
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
    Protocol  : TLSv1
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 53E3B03358EECB87FACE7FCF0C110504EA393219B3BF5E22783D45C028F960C1
    Master-Key: 2918FEC2984139A4E027DF19F15A35FE30EC03DF1D835297668D826C7614E8375695B0B3D72659974E9349A7E08BEA13
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1407430707
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)





I am not sure if you resolved this as of yet, but I was able to fix my issue. If you are using v14.4 guide for implementation, the guide states that you need the TLS Verify Subject Name on the WebEx Zone to I overlooked this as my previous implementations just used The reality is that Cisco has not yet added the SAN for sipbts to it's server certificates on the WebEx cloud servers. Once I changed it to everything started working.


Also, you may want to check and make sure the DST Root CA X3 is correct, as I was not using a CRL and the one I had on the server was actually incorrect. I had to fix that as well by removing it and replacing it with the one I found here:


I hope this helps resolve your issue.


CertificateO=Digital Signature Trust Co., CN=DST Root CA X3O=Cisco Systems, CN=Cisco SSCA3Sep 26 2018ValidView (decoded)
CertificateO=Digital Signature Trust Co., CN=DST Root CA X3Matches IssuerSep 30 2021ValidView (decoded)

Just FYI.  WebEx has a test environment called BTS where they test out new builds.  Alpha and EFT use these environments.  BTS has a certificate with a SAN of  So you must have got some documentation for EFT and configured your DNS Zone that way.  But your WebEx site was on production, not BTS.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers