Forum Discussion

jangliss's avatar
jangliss
Iron Contributor
Feb 27, 2020

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

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 f...
microsoft teams
Tomas_Chrapek's avatar
Tomas_Chrapek
Copper Contributor
Mar 24, 2021

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.

  • jangliss's avatar
    jangliss
    Iron Contributor
    Apr 15, 2021

    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.

  • jangliss's avatar
    jangliss
    Iron Contributor
    Apr 15, 2021

    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

     

     

Resources