Teams Direct routing media bypass mode ICE controlled

[afouad5]

I've a strange scenario when I enabled media bypass on my SBC and thought to check with everyone here first before contacting MS.

Outbound calls from Teams to PSTN works with ICE being CONTROLLING from Teams end (FULL ICE) and once the call is established Teams starts nominating the ICE candidates via a re-invite and it's handled correctly and audio is flowing in both directions.

Inbound calls from PSTN to Teams is having a strange problem from Teams endpoint as the SBC should be ICE-LITE mode (controlled) and not doing any connectivity checks , just responding to them.

and SDP being sent looks perfect like the following

a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/MdAvE9GIDAg7H6ydytIrVyKbgrirK614YLxHj/F|2^31
a=ice-lite
a=ice-ufrag:wIoWCV4A
a=ice-pwd:fD9WHcj3cCbNPcxDjU9Cp0AUEt
a=candidate:CeTxOSQoHkYUy9st 1 UDP 2130706431 xxx.xxx.xxx.xxx 30036 typ host

however Teams endpoints are sending their STUN requests as CONTROLLED !! while it should be CONTROLLING.

yes audio is flowing fine but am not getting the nomination via the re-invite which of course is wrong

any suggestions ?

[#2]

I see exactly the same issue. The result is that, for inbound calls from PSTN, the RTP flows comes directly from the Teams client to SBC but a media relay is used for the other way (sbc to Teams user). And there is no RE-INVITE sent to the SBC.

Did you get an answer from MS ?

[#3]

@AlainCYes make sure you have a=ice-lite in all requests sent to MS Teams to make sure SBC is in controlled state while Teams endpoints are full-ICE with controlling attribute.

[#4]

@afouad5 Thanks . yes, a=ice-lite is included in the initial SIP INVITE sent by the SBC. And I still see ICE-CONTROLLED in the stun binding resquests coming from the called Teams agent.

So, the issue on your setup is it fixed ? Does your SBC receive a RE-INVITE (with a=remote-candidates) and c= with the remote Teams agent IP address after it received the 200 OK ?  Is it possible to have a trace of a call ?

note : the issue is only for calls that are initiated by the SBC to a Teams agent. It works as expected for calls from Teams agent to SBC : SBC receives stun requests with ICE-CONTROLLING, RE-INVITE received by SBC (after it sends 200 OK) with c= indicating the Teams agent remote address.

In this link https://docs.microsoft.com/en-us/openspecs/office_protocols/ms-sdpext/fca7a99e-5408-47a6-9793-5be080...  It is written "This means that the caller MUST send the ICE re-INVITE". I do not know if this is relevant for a SBC which supports only ice-lite but I was wondering if the SBC should send such RE-INVITE (maybe will it receive the remote IP address in the 200 OK/c= attribute) and what to indicate in a=remote-candidates attribute

[#5]

Hi @AlainC
What is your SBC model ?

[#6]

@afouad5 We are doing a POC with our own SBC to check interoperability. 

As you had the same issue and as it seems to be fixed now, what would be nice is to have a sip trace / debug logs  of an outbound successfull call. Bellow the configuration of our sbc in O365, maybe is there something wrong (we tried to enable BypassMode "Always", but no effect) ? :

Thanks

[#7 · Accepted solution]

@AlainCPlease check https://tools.ietf.org/html/rfc5245#page-75

"ice-lite" is a session-level attribute only, and indicates that an
   agent is a lite implementation.

In your trace you have it within the media part , once you have it in the right position before m=audio

you will get the correct controlled state and nomination.

[#8]

@afouad5 , many thanks, it works now :)

[#9]

Perfect :)

[#10]

Hello @afouad5 

With our SBC, everything works fine in media bypass mode except when the SBC sends a hold and retrieve (REINVITE with a=inactive for HOLD, REINVITE with a=sendrcv for RETRIEVE). Then we have a similar issue (one-way voice path)

Description :

- before the HOLD, the ice is completed and RTP flows are properly exchanged between the SBC and the Teams agent.

- To the REINVITE offer with a=inactive, MS Proxy replies an answer with new candidates and c=media relay IP@. No REINVITE from MS Proxy to conclude the ice handshake. I guess it is normal, as the voice traffic is on hold. Voice traffic is stopped on both ways (OK)

- To the REINVITE offer with a=sendrcv, MS Proxy replies an answer with the same candidates as the previous anwer

- But no RE-INVITE from MS Proxy to conclude the ice handshake. The SBC receives RTP flow from teh MS client and sends flow to the Media Relay. The Teams client hears nothing but the voice path Teams client -> SBC is fine.

- During all the session (before the HOLD, between the HOLD and RETRIEVE an after the RETRIEVE, the SBC receives STUN binding requests from the Teams client every seconds with ICE-CONTROLLING and the SBC properly answers to all these STUN requests

- After around 20 seconds, MS Proxy sends a BYE with reason "CallEndReasonMediaError"

Attached the sip trace (@IP replaced by XXXX for SBC and YYYY for the teams client)

Thanks for your feeback