Inbound calls From MS-Teams to CUBE cut off after three seconds

[Gordon Ross]

I've followed the configuration at https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf to configure my CUBE (an ISR 4331 running IOS-XE 17.3(3) ) to connect to MS-Teams with Direct Routing.

Outbound calls from CUBE to MS-Teams work a treat.

Inbound calls from MS-Teams to CUBE disconnect after three seconds - with MS-Teams sending a "BYE" message to CUBE.

Has anyone seen this before (and know of a solution!)

[Scott Leport]

Hi,

Not seen that issue myself, but you could try one of the other MS Teams SIP proxy servers to see if you get the same issue.  

Doesn't sound related to your issue, but I had to disable CRL checking on the Baltimore cert. The TLS trunk between CUBE and the MS Teams SIP didn't come up without disabling it from my experience. You could try it and see what comes of that.

Also if you issue the "show sip-ua connections tcp tls" command, is the trunk up and stable?

[Gordon Ross]

As this is inbound calls I can't change the MS SIP proxy server. As I said, outbound calls from CUBE to MS-Teams work a treat.

[Scott Leport]

Sorry for the misunderstanding. What do your debugs say? 

[VON CLAWSON]

I think your first step has to be to get the debugs from the CUBE. I would get debug ccsip message, debug ccsip error. Go through the messages and see what they say. If MS Teams is sending the BYE message what is the cause code? and are there any messages before the BYE indicating what might be happening. Three seconds sounds like it could be a timing issue but would have to see the debugs to determine that.

[Hafthor Hilmarsson O'Connor]

This is probly cause by CRL towards the Baltimore Cert in Microsoft, you could skip CRL , or fix the cert part.

[Nuno Melo]

What is the reason code for the BYE from Microsoft. Usually Microsoft send a very descriptive reason for the BYE messages.

Had some issues with tls sessions disconnecting due to a earlier version of the cisco direct routing document having conn-reuse enabled. Which makes the tls sessions with microsoft not negotiate properly

Also be careful with the config variation between direct-routing with media-bypass and without-media bypass. Without media-bypass sofar has been a more stable scenario from my experience.