Forum Discussion
MS Teams Direct Routing - Internal call transfer failure
Hi, Sims_Krastev
Just from curiosity, do you use mediabypass already?
I have encountered interesting issue which is causing on PSTN calls to Teams user over SBC and transferred to my internal PBX extension or external number simply No Audio.
Here is the call flow - PSTN - myPBX - SBC - Teams user REFER- SBC - myPBX - phone
Once I manipulated my SBC that Microsoft takes care about sending re-Invite instead of REFER it sends new Invite as you observe BUT obviously as media source it uses the public IP of my SBC in the initial offer (it simply takes the info from original session leg).
My SBC is behind NAT. Properly configured. And it does not recognize that this new Invite is dedicated to media channel reserved already on the SBC 🙂 so it attempts to establish new channel between private IP and public IP of its own interface -sending the media out to its own public IP - which is then visible on our firewall as traffic that is dropped. Even if I allow this traffic between private IP to public IP of the same interface it would cause flow which does not make sense at all.
If mediabypass is not used then it is fine, also for Teams caller transferred to myPBX. Just in case it is PSTN caller transfered back to SBC. (same problem occures also once the Teams user set Forwarding to his mobile for example...call connected but no audio)
DaveChomi - Not I'm not using media bypass. If I have to be honest, I fail to see the benefits of media bypass. High bandwidth data line prices have dramatically decreased over the last couple of years, so by using media bypass you just save Microsoft a tone of bandwidth and infrastructure within their DCs, which I'm more than sure they have the money to pay for and maintain anyway.
Media bypass would probably work in your model for a simple Teams -> SBC -> PSTN or other way around model, when you start hair-pinning both legs of the call (existing and transfer) through existing infrastructure like your SBC and PBX you're just asking for trouble. I'd just disable media bypass if I were you, unless you're really struggling for bandwidth.
Regards,
Sim
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 🙂
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. 🙂
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.
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
- 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.
