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

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

@Sims_Krastev 

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!

@Sims_Krastev 

Hi Sims,

I've removed the ".*" rule from my installation and created all specific rules for DIDs and still no luck, I can see SIP REFER coming back to PBX when I'm trying to transfer call that came from PSTN to Teams user. No luck here, unfortunately. Did you have any luck with this? Thanks.

@Lt_Flash I had no luck with changing the voice route, so ended up raising it with MS support.

Apparently if you disable REFER as an allowed method within your SBC's signalling messages, then MS Teams does not use REFER for transfers and just re-INVITEs to the SBC. That way the internal transfers work perfectly fine.

 

How did you disable REFER? I mean - does your SBC sends some 4xx code when MS sends a SIP REFER message? Or somehow different? Thanks!

@Lt_Flash 

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.

 

 

No, we're using a custom SBC, but yes, that was my second guess - to strip REFERs from packets. Thanks a lot, I'll give it a go and let you know if it works for me!

@Sims_Krastev you seem to be correct! I've just edited all messages that were coming from PSTN side of our SBC and stripped 'REFER' on SBC in 'Allow' field - and yes, Microsoft started to transfer calls correctly! Thanks a lot, mate, I've already read that disabling SIP REFER method helped some people, but I was trying to reply with 4xx or 5xx when receiving REFER from MS side, while I should have just removed that REFER method from SIP 'Allow' list! By the way, looking at the packets coming from Microsoft side I can see that they don't send REFER in allowed method list! Here's an example:

CONTENT-LENGTH: 685
MIN-SE: 90
SUPPORTED: timer
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2019.7.4.9 i.USWE2.4
CONTENT-TYPE: application/sdp
ALLOW: INVITE
ALLOW: ACK
ALLOW: OPTIONS
ALLOW: CANCEL
ALLOW: BYE
ALLOW: NOTIFY
SESSION-EXPIRES: 1800;refresher=uas

Thanks again for your help and I'm glad everything is working fine for you too now!

@Lt_Flash 

 

I can confirm this behavior, just that REFER triggered transfer is most common way for it and only fully standardized one. If your SBC is capable to terminate REFER note that MS still clearly indicates in Refer-To where to send INVITE back: 

REFER-TO: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>
</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>

 

  and making sure you fill RURI with Refer-To and Contact uri-host correctly you will see MS does rest of the job nicely for REFER case too.  

@Matej_Maric 

 

It shows where to send INVITE to, but it doesn't have a DID or username in SIP R-URI so SBC can't figure out where to dial to. SBC uses PSTN-type dialing, so it needs some LineURI or DID to send INVITE to, like +44XXXXXXXX@sip.pstnhub.microsoft.com. Otherwise it can't decide what to put in SIP INVITE method as 'To' field. I've tried to update SIP INVITE to whatever is in REFER-TO header and send it back to Microsoft, but I was getting a 400 Bad Request back.

 

REFER-TO: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689</sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689><sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>

 

There's no user part in this SIP RURI, only host. What should be put in To header? Contact header is obvious, it's our SBC Contact.

@Lt_Flash 

 

the thing is that SBC should only respect Refer-to header by means of SIP. REFER comes without user part but it's still fair enough and legal. So what my SBC does as last resort to send INVITE out is DNS query for hostname in Refer-To and fills RURI and To in same fashion:

 

INVITE sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689;transport=tls SIP/2.0
Via: SIP/2.0/TLS 192.168.65.100:5061;branch=z9hG4bKvahihb0040adpr8tb320.1
CSeq: 1 INVITE
Contact: <sip:sbc.customers.matejandfriends.com:5061;transport=tls>;sip.ice
From: <sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone>;tag=11241SIPpTag011
To: <sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689>
Content-Type: application/sdp
Content-Length: 425
Referred-By: <sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d>
Call-ID: 8f09e11d9183f754c525a0d4ce2aea46
Supported: replaces
Max-Forwards: 70</sip:sip.pstnhub.microsoft.com:5061;x-m=8:orgid:bdc0511a-4a8d-48aa-bf1d-5ea6ef316e2a;x-t=2d88cb42-f810-417a-a0fc-80244a7fdd61;x-ti=9cfa2ad6-c73e-402d-b621-90d9af6ffea2;x-tt=ahr0chm6ly9hcgktzhutys1ldxdllnbzdg5odwiubwljcm9zb2z0lmnvbs92ms9uz2mvy2fsbg5vdglmawnhdglvbj9ky2k9yje2odmxntuwyjuwndg3mzk4nja4ndhlmgflyznimwq%3d></sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:fce2158f-0e99-4ff7-a0b3-5b6b87d16689></sip:+18572996345@sip.pstnhub.microsoft.com:5060;user=phone></sip:sbc.customers.matejandfriends.com:5061;transport=tls> 

 

and that's just enough...

obviously we dont use same vendor SBC but standard wise logic should remain the same

@Matej_Maric 

Thanks for detailed description, I will try to reproduce this behaviour on my SBC, but it looks really strange to me that MS sends a SIP REFER packet back to SBC that connects calls to PSTN and uses LineURI telephone numbers for that. According to RFC it should provide a proper username or DID in such case. From what I can see now it's much simpler to just disallow REFER method and let Microsoft Teams handle internal call transfers on their side, which is more logical, rather than implementing such call forking. Anyway, your help is much appreciated and SIP INVITE packet is a perfect example on what I should try to achieve. Thanks!

@Matej_Maric 

Hi,

Unfortunately, that doesn't work for me, I'm sending same INVITE packet as you do but I'm getting back a '400 Bad Request' with a REASON:

REASON: Q.850;cause=111;text="a5d458f9-14c0-4cc4-8c10-202277af11e9;Unable to parse RURI."

@Matej_Maric 

 

Here's my INVITE packet, I had to remove triangle brackets to make post clear:

 

INVITE sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c SIP/2.0

Via: SIP/2.0/TLS X.X.X.X:5061;branch=z9hG4bKf26f.503bdc4.0;i=54849946

From: "XXXXXXX";tag=a1d8a1ca-d330-4251-811d-35fa1a797c64&;

To: sip:sip.pstnhub.microsoft.com:5061;transport=tls;x-m=8:orgid:7709b36f-1f10-4b1c-8a0f-9c0e5390c86c

Call-ID: 1fa2f0d0-ba41-4e4d-83be-fbef9d0739c6

CSeq: 10432 INVITE

Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER

Supported: 100rel, timer, replaces, norefersub

Session-Expires: 1800

Min-SE: 90

Max-Forwards: 69

Content-Type: application/sdp

Content-Length: 346

Contact: sip:gateway@sbc.xxx.xxx.com:5061;transport=TLS

 

@Matej_Maric 

All right, just to clarify, I've got this sorta working, I was removing REFERRED-BY header when placing a new INVITE and that's why it couldn't connect the call, after leaving that header intact the call can be transferred. But this far for us it's much easier just to remove REFER method from the list of allowed methods, otherwise it's quite a complex setup with our SBC. Thanks everyone for replies, now we have two working methods that allow call to be transferred to internal MS Teams users!

@Lt_Flash 

 

yep, tend to be with you on conclusions. being forced to implement both in real life felt like sharing things people find useful :) Most important is we understand now how to implement both methods and logic MS uses to trigger each.

 

cheers!

@Sims_Krastev 

 

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