Forum Discussion

afouad5's avatar
afouad5
Copper Contributor
Nov 10, 2020
Solved

Teams Direct routing media bypass mode ICE controlled

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 ?

 

 

CONTROLLED
CONTROLLING
ICE
media bypass
  • afouad5's avatar
    afouad5
    Dec 10, 2020

    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.

9 Replies

Sort By
  • AlainC's avatar
    AlainC
    Copper Contributor
    Dec 04, 2020

    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 ?

    • afouad5's avatar
      afouad5
      Copper Contributor
      Dec 04, 2020

      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.

      • AlainC's avatar
        AlainC
        Copper Contributor
        Dec 06, 2020

        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-5be0800df1a4  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

Resources