Forum Discussion

Sims_Krastev's avatar
Sims_Krastev
Copper Contributor
Jul 15, 2019

MS Teams Direct Routing - Internal call transfer failure

Hi all,   My organisation is planning a move to direct routing. We have an AudioCodes VE SBC. I've been working on this for awhile and got everything to a pretty decent state.   I've come across ...
microsoft teams
DaveChomi's avatar
DaveChomi
Iron Contributor
Sep 12, 2019
I got your point. 🙂 It's just about reasonable routing of calls also to internal infrastructure and trying to keep media path short from central sip services towards clients. So far it really brings headaches to me but also it brought better quality of calls so I have seen benefit in get over the pain to make proper setup.
Sims_Krastev's avatar
Sims_Krastev
Copper Contributor
Sep 16, 2019

DaveChomi That's very interesting I guess it really depends on what your deployment looks like.  We do more of a multi-tenanted carrier deployment in which RTP would never leave the customer LAN for internal calls and for external calls it would always go from the Customer LAN <-> MS <-> us. If you've deployed an enterprise model, where your SBC is deployed within your LAN there really is no point in flinging media packets all the way to MS just to receive them back to your LAN and then send them out again via your SBC. I can see how that can have an impact on quality. 

Can you share the syslog for a call like that from the AudioCodes SBC? I'd be very interested to see what its doing hone its trying to negotiate the call transfer leg.

Regards,

Sim

  • DaveChomi's avatar
    DaveChomi
    Iron Contributor
    Oct 29, 2019

    Sims_Krastev 

    Hi, in meantime I got this resolved. 

    It's basically correct behavior that Microsoft sends public IP of my SBC as source of media on new call leg for that transferred call, while mediabypass is enabled. It just really require that you will setup enterprise firewall to communicate from NATed private IP to its own public IP and loopback this communication. This is what basically SBC does, Sends the media stream from its own private IP to its own public IP and expects the media back 🙂  So it is very ugly hairpin on firewall even not documented in firewall prerequisites. I would say SBC should have some logic to handle this by itself by as long as this is the only way we need to make security guys believe this is absolutely normal request 🙂 

  • DaveChomi's avatar
    DaveChomi
    Iron Contributor
    Sep 20, 2019

    Screenshots are basically refering to call from +420702XXXXXX to Teams user on number +420544137XXX which was transffered to +420723XXXXXX.

    New call is visible on SBC. 

    And on that second call the SBC refers to Teams hey the media are on my public IP and Teams refers hey and I have media on your public IP. 🙂 

     

  • DaveChomi's avatar
    DaveChomi
    Iron Contributor
    Sep 20, 2019

    Sims_Krastev 

    I can provide later the syslog, just do not want to publish all our IP addresses etc. on forum

    Currently if I set our SBC to handle all REFERs locally it simply takes REFER from Teams, SBC accept and sends new Invite to Teams. Teams takes that and create new SIP call where as source IP for media presents public IP of our SBC. This call will come as new SIP call to our SBC and SBC simply tries to connect media between private IP and public IP of our WAN interface. And this is failing basically because SBC sends the traffic to its own public IP through WAN interface out of the SBC. There is then firewall which is dropping that from obvious reason.