Webex Enabled Telepresence

[Graeme Kay]

Hi,

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.

Cheers,
GK

[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?

http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/config_guide/webex_enabled_telepresence/cts_webex_call.html

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

[Graeme Kay]

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,

GK

[shawnangelo]

Graeme,

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.

CSCup75947

CSCum90139

[shawnangelo]

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.

[shawnangelo]

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: 4800@XXXXX.com
  • • Zone (1)
    • • Name: DefaultZone
    • • Type: Default
  • • Path (1)
    • • Hop (1)
      • • Address: 10.254.255.20:5073
    • • Hop (2)
      • • Address: 100.X.X.X:5061
    • • Hop (3)
      • • Address: 10.255.9.20:5060
    • • Hop (4)
      • • Address: 10.255.9.26:5060
• • Destination (1)
  • • Alias (1)
    • • Type: Url
    • • Origin: Unknown
    • • Value: sip:169QzS3GQFSvCQLVaryPM1iA@XXXX.webex.com
• • StartTime: 2014-08-07 10:54:45
• • Duration: 0.67
• • SubSearch (1)
  • • Type: Directed
  • • Path (1)
    • • Hop (1)
      • • Address: WebEx
    • • Hop (2)
      • • Address: 209.197.207.57
  • • SubSearch (1)
    • • Type: Admin Policy
    • • Action: Proxy
    • • ResultAlias (1)
      • • Type: H323Id
      • • Origin: Unknown
      • • Value: sip:169QzS3GQFSvCQLVaryPM1iA@XXXXX.webex.com
    • • 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: sip:169QzS3GQFSvCQLVaryPM1iA@XXXX.webex.com

[Graeme Kay]

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.

GK

[shawnangelo]

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 pxtaspx001.webex.com:5061
CONNECTED(00000003)
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 = me01taspx01.webex.com
verify return:1
---
Certificate chain
 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
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIKPGCAaQAAAAABxDANBgkqhkiG9w0BAQsFADA7MQswCQYD
VQQGEwJVUzEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEUMBIGA1UEAxMLQ2lzY28g
U1NDQTMwHhcNMTQwNzMxMDU0MzE2WhcNMTYwNzMxMDU1MzE2WjB6MQswCQYDVQQG
EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxIzAh
BgNVBAoTGldlYkV4IENvbW11bmljYXRpb25zLCBJbmMuMR4wHAYDVQQDExVtZTAx
dGFzcHgwMS53ZWJleC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDL88u4gyY5D8toiPASgvA9M3kF3+odFXxwaYzCKbQnOGIrejtFDEoAwsB2J35Z
IbmuHcHU5ZLGXc4zQ/zMEqPM/lR3xlk2RnGhHOID3WS8KIZB3WNHlUH1kOgveiBw
rhj8GaLWalZHwWcnzZfHSif0Ec6PMah910e3gEUs1ykFqMI8ZEKt8Ko0/o0KB7x8
vVb9OhEWFjbD2Xe9BY/TBxg5WoBtuqcr+tf/2P8y5mLpxdUuoD9iv8bCjTjv6jzB
AC0T1P6Kfbgdfko1y/IEEaiwicBjemU2x9iN6gj1KNKRzoI8iRG4mVg/u4AnV+TE
R/wVriDY9SIKdqGs94onJ3qvAgMBAAGjggH9MIIB+TBmBgNVHSAEXzBdMFEGCisG
AQQBCRUBAQEwQzBBBggrBgEFBQcCARY1aHR0cDovL3d3dy5jaXNjby5jb20vc2Vj
dXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwCAYGZ4EMAQICMDsGA1UdJQQ0
MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwUGCCsGAQUFBwMGBggrBgEF
BQcDBzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUvPD/
YhyKTf2zsscjxLIFGr8LuT8wLwYDVR0RBCgwJoIVbWUwMXRhc3B4MDEud2ViZXgu
Y29tgg1zaXAud2ViZXguY29tMB8GA1UdIwQYMBaAFCzs1z7K1icAOJY7mTTHt2Eg
oiDvMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3Vy
aXR5L3BraS9jcmwvc3NjYTMtbXR2LTEuY3JsMHsGCCsGAQUFBwEBBG8wbTA9Bggr
BgEFBQcwAoYxaHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRz
L3NzY2EzLmNlcjAsBggrBgEFBQcwAYYgaHR0cDovL3BraWN2cy5jaXNjby5jb20v
cGtpL29jc3AwDQYJKoZIhvcNAQELBQADggEBAG2iJemruJGe4ZdVwI6L0NtbTQzH
9Fs+Xl25ElrtzoGJLBIWywh2+y9SbAnOM206m6AauvIo1biLjR2OXjYn+swMj9n1
eVN799lpHzx8x4NTLXmBDHQmMBnbDzVsDWE6E/EZVWMQj4zimLGkYC2HasqsMh0/
Bd36cQ5RC5fqKTjBh1ENX9kem7HLgFd7MpNCJBsq1+edirGjntAblFxumrGAAnx2
jPY8N4kMv5ryUJMTjzt9eIUFgq6AMjJ2hsIsIkNt4Ut0+sMPgl4AoK65uJJtMb87
XhjG5fqqe5ZKLNFWdl+eylWH1VxZBnt/Fqk66bnyLtap4YOTduZDDfZuKEQ=
-----END CERTIFICATE-----
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
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 53E3B03358EECB87FACE7FCF0C110504EA393219B3BF5E22783D45C028F960C1
    Session-ID-ctx:
    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)
---

[shawnangelo]

Graeme,

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)

[Andrew Bell (Webex PM)]

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.