AudioCodes, Avaya, Media Bypass, and BackToBackBypass offer was declined by Peer

[jangliss]

Hello All,

We're running into a small issue with enabling Media Bypass with Teams and AudioCodes.  After configuring Avaya, AudioCodes, and Teams, we have verified Direct Routing is all working fine (after some tweaks).  When toggling ICE Lite on for the AudioCodes, and turning on Media Bypass in Teams, all is well except calls from Avaya to Teams.  Audio on the Avaya side drops after about 3 seconds, so the Teams recipient can hear the Avaya side for 3 seconds before dead air. Audio in the other direction is fine.

We do notice in the SIP trace that the Avaya sends another INVITE message, which is forwarded by the AudioCodes.  AudioCodes then sends to Teams, but Teams rejects with the error message:

REASON: Q.850;cause=0;text="5a0345d0-37ff-41fd-8eb7-df1d9fa29aa2;BackToBackBypass offer was declined by Peer"

This suggests that Teams was not expecting another INVITE message, and as such dropped the request.  This is about the same point we lose the Avaya side audio.  The AudioCodes is configured exactly the same as recommended in the configuration note mentioned here: https://www.audiocodes.com/solutions-products/products/products-for-microsoft-365/direct-routing-for...

Has anybody seen the error? Or got Direct Routing, Media Bypass, Avaya, and AudioCodes working together?

Cheers

Jonathan

[#2]

@jangliss I don't have a solution, but I'm here to report the similar problem. I don't know if there is Avaya at the other end of this, because that particular call is connected to PSTN network, but the extra INVITE coming the other direction and BackToBackBypass error message are the same symptoms in my case, too. So if anybody else experienced that or found a solution to that, it would be nice to know. Thanks.

[#3]

@Tomas_Chrapek 

I have been scratching my head trying to remember how I resolved this issue and I think it popped up again last week with a different customer and saw the cause. The cause of the problem in both cases was the SBC was sending the private IP address of the SBC to MS Teams.

Take a look at the INVITE and any SDP messages to see what is in the connect body.  For example:

INVITE sip:+19725555555@sbc.mydomain.com SIP/2.0
Via: SIP/2.0/TLS sbc.mydomain.com:5061;alias;branch=z9hG4bKac1645244142
Max-Forwards: 67
From: "ALICE RECEPTIONIST" <sip:9725551234@1.2.3.4;user=phone>;tag=1c213210496
To: "User 9725555555" <sip:+19725555555@sbc.mydomain.com>
Call-ID: 123456789@sbc.mydomain.com
CSeq: 1 INVITE
Contact: <sip:1.2.3.4:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 853

v=0
o=BroadWorks 1996477202 1494450535 IN IP4 10.1.2.3
s=-
c=IN IP4 10.1.2.3
t=0 0
a=ice-lite
m=audio 50490 RTP/SAVP 0 100

Notice the "c=IN IP4 10.1.2.3" has the SBC private IP address.  This causes Microsoft to reject the call. It must be the SBCs public IP address for Media Bypass.

There has been the introduction of Media Bypass and Local Media Optimizations which allow you to route traffic to internal SBCs and use the private IP addresses of the SBC as well, but the initial invite should still be announcing the public IP (from my testing).  More details on that setup here https://docs.microsoft.com/en-us/MicrosoftTeams/direct-routing-media-optimization

[#4]

@Tomas_Chrapek 

I should add, when I had this issue with a customer that was using PSTN, we ended up adding another IP Group and Proxy Set on the AudioCodes SBC that was used as an intermediary between the SIP connection to MS Teams and the Gateway functionality on the AudioCodes.  The call route essentially ended up looking like:

Teams -> SBC -> SBC IP Group -> SBC Gateway -> PSTN

This resolved the issue because the extra SIP handoff allowed the AudioCodes to correctly handle the headers.