Cube in direct routing configuration against Microsoft Teams fails with TLS, and adjusting revocation-check resolves the issue.
I don't fully understand how the following configuration works and how Cube works in direct routing mode against Microsoft Teams.
crypto pki trustpool policy
cabundle url http://www.cisco.com/security/pki/trs/ios_core.p7b
cabundle url http://www.cisco.com/security/pki/trs/ios.p7b
revocation-check crl
But a few days ago, a TLS negotiation error prevented me from seeing the active SIP Trunk between the Cube and Microsoft Teams. I could also see the following status in a show command.
cube#
TAG TENANT DESTINATION OOD-SessID PRI WT STATUS
2 - sess-svr-grp:1
ipv4:172.16.181.176 1 - - active
ipv4:172.16.181.164 2 - - active
50 200 dns:sip.pstnhub.microsoft.com: busyout
ipv4:52.114.148.0:5061 75859 - - active
51 200 dns:sip2.pstnhub.microsoft.com busyout
ipv4:52.114.75.24:5061 75861 - - active
52 200 dns:sip3.pstnhub.microsoft.com busyout
ipv4:52.114.32.169:5061 75860 - - active
31 - sess-svr-grp:1
ipv4:172.16.181.176 1 - - active
ipv4:172.16.181.164 2 - - active
cube#
After making revisions, we decided to make the following adjustment, and the problem has been solved.
crypto pki trustpool policy
no revocation-check crl
revocation-check none
What doesn't give me peace of mind are the implications of leaving the equipment like this, which would affect it, and how I could continue to review the equipment to better understand the TLS problem.
