Direct Routing for Microsoft Phone System with Cisco Unified Border Element

[takahashi-ta]

I am using vCUBE (on CSR1000v) to build direct routing for Microsoft Teams Phone System.
ITSP is using Twilio.
In this environment, I can make and receive outgoing calls from Microsoft Teams Client to Twlio direction, but the signaling is not working well from Twilio to Microsoft Teams Client direction.
I used TranslatorX to draw a SIP ladder sequence from the results of the debug ccsip messages and found that the CUBE is not receiving any response to the INVITE it sent to the Micorosoft Teams Phone System.

The TLS connection is normally working as shown below.

(ex)
Remote-Agent:52.114.76.76, Connections-Count:3
Remote-Port Conn-Id Conn-State WriteQ-Size Local-Address TLS-Version Cipher Curve
=========== ======= =========== =========== ============= =========== ============================== =====
5061 140 Established 0 x.x.x.x TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 P-384
3521 142 Established 0 x.x.x.x TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 P-256
3520 141 Established 0 x.x.x.x TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 P-256

However, the moment I make a call from Twilio to the Micorosoft Teams Client, I get the following message.

%SIP-3-INTERNAL: Connection failed for addr=52.114.76.76, port=5061, connId=140

For some reason, the TCP TLS connection seems to be failing momentarily, and I suspect this is why the signaling is not working properly.

Is there any configuration I should review?

By the way, I am referring to the following document for setting up the CUBE.
https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf

[mrvoipstuff]

that would disable the REFER altogether and use INVITE in lieu of REFER. Nothing wrong with that until your users experience any transfer related issues in which case MSFT won't support it until you use REFER. 

[mrvoipstuff]

In my failure debug output around the time REFER is received there are TLS teardown messages from MSFT. 

I noticed in my CUBE I am missing the below

ip tcp synwait-time 5

In absence of that tcp default timeout is 30 secs. so I am thinking CUBE will wait 30 seconds for timeout for existing TLS session to MSFT who has now already closed the TLS session. So 5 seconds would mean it will re-attempt handshake after 5 seconds max instead of previous 30 ?  wonder if that's the reason they included 'ip tcp synwait-time 5' in CUBE direct routing guide keeping in view how MSFT closes the connection every so often ??