Forum Discussion
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 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
Hi Sim,
We've got exactly the same behaviour when trying to transfer calls that came from PSTN network and got answered by one of our Teams users and when they try to transfer to another Teams user. REFER-TO doesn't contain any LineURI or telephone number to complete the transfer. Did you have any luck fixing this issue? Also, I'm not sure if this was working before or not. But you seem to be correct in regards to Teams treating internal transfer as external one and sending SIP REFER back to SBC without providing any additional details in regards where the call should be actually connected or transferred to. When transferring to external number this works perfectly fine, REFER-TO contains an external number and can be processed by our SBC. BTW, can you tell what SBC are you using? Is it AudioCodes or Ribbon one? Or something not currently certified by Microsoft? Thanks!
Lt_Flash We're using AudioCodes, and config wise its fine. It handles REFERs just fine. The issue here is that MS Teams should never had sent this REFER out the SBC, it should have handled it within the Teams environment as its a transfer from one Teams user to another. This only thing I suspect config wise is voice route regex I'm using, as its pretty much a catch all e.g. ".*"
I've now made it more strict to capture digit patterns rather than all chars to see if the issue persists.It makes no sense as I can call users internally, it only happens when PSTN call comes in from the direct Routing SBC, so Teams appears to be applying a different call routing logic when applying the transfer.
Out of curiosity can you let me know what your voice route pattern looks like? Was it a catch all like mine or is it more strict?
Thanks,
Sim
Yes, I'm using the same voice pattern, ".*" to send all digits without any normalization to our SIP trunk. You're right, maybe the issue is because of that, I will update voice rules tomorrow to make it strictly country-based, like '^+44.*' to see if that helps! Good point, mate!
Also, yes, SIP REFER shouldn't be coming back to PBX when we're doing an internal transfer from one Teams User to another one, but it does for some reason, that's the problem.
I'll let you know here how it goes and thanks for your reply!
Hi for us it's the other way around. Internal calls transfer perfectly fine and transfer to PSTN only works via the Teams Client. We do use some 3PIP Phones from AudioCodes, Yealink and Poly and if we try to transfer a call to an external Number, our SBC does not receive a refer-to number.
Now i have heard from someone, that their AudioCodes SBC receives this from Number even when it's coming from a 3PIP Phone.
Does anybody have an idea, why 3pip Phones or SfB Client for that matter (i know it's not supported but if 3pip should work, the SfB Client should also work) does not send a Refer to number to our SBC? Or is there anyone around who can test it and tell me if it's working with their SBC?
Thanks,
mozzie
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.
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?
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 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?
We had a similar issue, I had "Play RBT To Transferee" set to yes, but didn't realise that SBC didn't have DSP licenses, so the call would drop at this point of the transfer.
