MS Teams Direct Routing - Internal call transfer failure

Copper Contributor

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 an issue which is fairly new as I remember testing this months ago, when I was still trying to figure out how to deal with REFERs coming from MS Teams on call transfers.

 

So the call flow is as follows:

Incoming call from SBC to MS Teams -> MS Teams user transfers the call to internal user -> Call fails as MS Teams generates a REFER back to the SBC rather than route the call internally to MS Teams user target.

The issue I'm observing aside from MS Teams routing the transfer leg of the call is that the REFER-TO user part of the URI is blank. Please see the attached screenshot.

Its as if MS Teams is treating this as an external transfer and does not know how to populate the user part of the REFER-TO header. I've tested this with both users set up with Phone system and DDIs assigned to the user and users which have no phone system add-on or assigned DDI.

Please note that if you tried to transfer the call to a PSTN number, that works fine. I'm unsure if this would be something config related within our Teams tenancy or a genuine bug. I'm more inclined that this is the former rather than the latter as it does seem like fairly basic functionality and I'm confident this used to work a few months ago.

Any advice would be appreciated.

Kind Regards,

Sim

61 Replies

@mozziemozz 

Are you typing in full E.164 external number? I have an issue with SFB where it's not sending calls to SBC unless I type in full '+44XXXXX' number even though Teams works fine with local numbers starting with '0' or any other number because we have '.*' VoiceRoute configured. Can't figure out why it's doing so, cooperation mode is set to Islands and SFB can send and receive calls but only when using full E.164 numbers. Some MS built-in normalization rules for the country are kicking in by the looks of it.

@mozziemozz 

Also, maybe your SBC has a rule to remove Refer-To header and sometimes that rule is applied by incorrectly configured Match policy? Have you tried sniffing traffic and decoding TLS to see the actual SIP packet coming from MS before it's handled by SBC?

@Lt_Flash for me it doesn't make a difference if the number starts with +4144 or 044. from the looks of it, the normalization/translation of the number works fine with the SfB Client too. Also works when just dialing 044 (national format) instead of transferring.

 

Does it work for you when you enter full E.164 with the SfB Client or 3PIP Phone?

@Lt_Flash I don't think that the SBC removes the refer, because when I do it via the Teams Client, everything works fine. If I disable Referred-By on the SBC transfers stop working, even internal Teams Transfers. I'm not sure who to do TLS sniffing and decoding. What do I need to do? Run wireshark while i transfer and filter for TLS/TCP packets?

@mozziemozz 

It's not that easy, you will need your SSL certificate and private key in order to decrypt the traffic, you need to google about that. But maybe you just disable REFER support like we did? That's much simpler and works much better and requires less rules on SBC to make calls work. Just strip 'REFER' from any 'Allow:' header coming from SBC on requests and responses.

@Lt_Flash 

It turned out, that there was in fact something wrong with how Microsoft / 3PIP SfB Phones sent the refer to our SBC. (Our SBC did not receive a refer-to number) Microsoft has now fixed the issue and we can correctly transfer calls to external numbers via the Teams Desktop Client and 3PIP Modes with users in TeamsOnly mode.

@mozziemozz 

Hi mate,

Good to know it's all fixed! Yes, the biggest problem when dealing with Microsoft is that you never know if that's an issue with your phone or software or with their end. I was speaking to their official support as we are an official partner and all I got in the end was 'Please post into our techcommunity'.

@Sims_Krastev 

Can you post how to do message manipulation to re-build the allow header for this on AudioCodes?

@Jason Turpin 

Sure - here it is:

 

Action Subject - Header.Allow

Action Type - Modify

Action Value - 'PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL'

 

You can strip out any method you like or match what Microsoft send in their messages if you'd like. Its working fine for me with these.

 

Regards,

Sim

@Sims_Krastev 

Yep, works pretty much same way for me, even though right now I'm not using AudioCodes any more. And I'm analyzing each Allow string to strip only REFER from it instead of replacing Allow with generic one that allows everything.

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

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.

@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

@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. 

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. :) 

 

@Sims_Krastev 

 

Hi,  We are having a similar transfer issue and I see you have the Audiocodes syntax to remove this in the ALLOW header.  Any chance you could send this across so I can try this?

 

'No, not by rejecting the REFER with a response code. I basically did a message manipulation rule to re-build the Allow header for calls to MS Teams without including REFER. Which vendor are you using? If you have an AudioCodes as well, I can give you the rule syntax.'

 

Cheers

Darren

@Darren Ellis 

Have you setup on the opposite trunk (IP Profile for provider SIP trunk or your internal PBX not Teams side) Handle Locally of the REFER messages?

This will do the same job basically and you do not need this special manipulation which I personally consider as too much because it does not give you any chance then manipulate REFER messages.

 

So for IP profile of the SIP trunk towards your provider/on-prem PBX

I would setup these parameters on Audiocodes SBC

Remote REFER ModeHandle Locally 
Remote Replaces ModeHandle Locally 
Play RBT To TransfereeYes 
Remote 3xx ModeHandle Locally

@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 :) 

 

@Lt_Flash  Your reply's allowed me to get transfers to teams users working. Thanks very much!

 

I am currently stuck with on-hold, we send the refer back as we do for the teams transfer, but the hold fails.  Could you share part of a sip trace of a successful hold, or share an invite generated by your sbc for a teams hold?

 

@Matej_Maric