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 sip.webex.com 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.
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
Thanks for your reply, apologies my original port may not have been clear. Below is what we have tried:
I have attached the results of our DNS look up from the VCSe.
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 sipbts.webex.com on your webex zone config, try using just sip.webex.com.
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
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.
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 pxtaspx001.webex.com:5061
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
depth=1 C = US, O = Cisco Systems, CN = Cisco SSCA3
depth=0 C = US, ST = California, L = San Jose, O = "WebEx Communications, Inc.", CN = me01taspx01.webex.com
0 s:/C=US/ST=California/L=San Jose/O=WebEx Communications, Inc./CN=me01taspx01.webex.com
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
subject=/C=US/ST=California/L=San Jose/O=WebEx Communications, Inc./CN=me01taspx01.webex.com
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
Protocol : TLSv1
Cipher : EDH-RSA-DES-CBC3-SHA
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 sipbts.webex.com. I overlooked this as my previous implementations just used sip.webex.com. 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 sip.webex.com 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: http://www.cisco.com/security/pki/
I hope this helps resolve your issue.
|Certificate||O=Digital Signature Trust Co., CN=DST Root CA X3||O=Cisco Systems, CN=Cisco SSCA3||Sep 26 2018||Valid||View (decoded)|
|Certificate||O=Digital Signature Trust Co., CN=DST Root CA X3||Matches Issuer||Sep 30 2021||Valid||View (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 sipbts.webex.com. 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.