Cisco CUCM hold drops calls to MS Teams,

[lliborio05]

Hi 

I have a CUCM Mixed mode cluster with encrypted Signaling and Secure RTP and i have setup a connection via a Cisco Cube with Direct Routing to MS Teams. 

The CUCM to Cube Sip trunk is Secure with Secure SIP and SRTP, and of course the Direct Rounting is also Secure. I can setup calls in boths ways, everything encrypted and works well.

Because it is using SRTP i cannot use MTPs so no early-offer on CUCM. CUCM invites the cube in delayed offer and the cube signals Teams with early offer.

When i put a call on hold. If i put on hold on teams side it works, because teams do not signal the hold, i have no invite or re-invite it just insert's MOH on the channel. 

When i put on hold on CUCM side, CUCM does what it tipically do, sends a Re-invite with SDP Inactive and port 0.0.0.0 and Cube forwards this to teams.

Then CUCM send's another Re-invite without SDP because i have no early offer on CUCM, and the Cube forwards this Re-invite without SDP to teams. The early offer configured in cube do not work with Re-invites. This Re-invite without SDP gets to Teams and Teams reply with 488 Not Acceptable Here, because Teams always need's to have SDP.

Anyone have any experinece or idea on how can i put this to work?

On Cisco Direct Routing documentation it specifically says that you need MTP for mid-call features like hold, but i'm using SRTP so i cannot use MTP, and Cisco documentation only mention the CUCM to Cube RTP scenario not the SRTP.

Thank you

[Jonathan Schulenberg]

Have you seen the interoperability docs, specifically Direct Routing for Microsoft Phone System with Cisco Unified Border Element (CUBE) and the Direct Routing for Microsoft Phone System with Cisco Unified Communications Manager (UCM) via Cisco Unified Border Element (CUBE) supplement?

The latter says they specifically tested end-to-end secure calls - so there is hope. Check the configs there against yours to see if there’s an obvious difference.

[lliborio05]

Hi Jonathan,

Thanks for the reply.

I've re-checked the documents (they where the base for the config) and i cannot see differences from my config, and they both assume:

- The trunk between CUBE and Microsoft Phone System uses TLS/SRTP
- The trunk between CUBE and Cisco UCM uses UDP/RTP

The first doc that has the config, only uses SIP TLS and Secure RTP to MS Teams.

The second one at the end it does say "End-to-End TLS Topology", but it does not specify if they mean SIP TLS only, or if SRTP has been tested because, I've done some more testing and i can have SIP TLS end to end with no SRTP. This way i can force MTP and the hold works, but i'm missing the SRTP part.

Regards 

LL

[Koen Van Impe]

Hi folks,

Interesting to find this recent thread on a topic that resembles strongly what we are seeing in our environment.
The main difference is that we use an AudioCodes SBC in between Teams and Cisco. 

When putting a call on hold on Cisco side, as LL describes there are 2 re-invites:
- The first one deactivates the call media
- The second has no SDP. AudioCodes tries to work around that by adding its own SDP when transmitting to Teams.

Teams accepts with an OK + SDP, which gets transferred to Cisco.
Cisco now ACKs with another SDP. Then the call breaks.
All of the above using SRTP at both sides of the SBC.

MTP required solves the problem, as signaling does not reach the SBC in that case but doesn't seem to be compatible with the need for SRTP. 

If only Cisco would use early offer for MoH...
Curious to hear if any progress was made on your side.

Kind regards,
Koen

[lliborio05]

Hi Koen,

Unfortunatelly not, got stuck there and went to the option of MTP with no SRTP.

Didn't manage to put it to work, it deserved a TAC case to clarify what can be done but since the customer accepted it this way, i didn't opened it.

Regards

LL