MS Teams Direct Routing - Internal call transfer failure

shyam2021 

Microsoft is constantly changing Direct Routing, read their updated articles about Planning DR and Configuring DR. We are not experiencing any issues with transfers right now and we didn't change configuration for quite a while.

Lt_Flash  Suddenly having this issue one of remote sbc. We have proxy-remote sbc configuration. All other remote SBC can handle internal call transfer but only one fails. All remote SBCs have same configs. So not sure why it is failing for only one SBC. It has the same unable to purse RURI message from Teams.

DaveTheTeamsGuy 

It's both. If your SBC can't handle REFERs - it's a workaround. If it can - you still can prohibit REFERs and use INVITEs as per SIP RFC.

Here's an official explanation:

https://docs.microsoft.com/en-us/microsoftteams/direct-routing-protocols-sip

Section 'Call Transfer':

Call transfer

Direct Routing supports two methods for call transfer:

• Option 1. SIP proxy processes Refer from the client locally and acts as a Referee as described in section 7.1 of RFC 3892.

  With this option, the SIP proxy terminates the transfer and adds a new Invite.

• Option 2. SIP proxy sends the Refer to the SBC and acts as a Transferor as describing in Section 6 of RFC 5589.

  With this option, the SIP proxy sends a Refer to the SBC and expects the SBC to handle the Transfer fully.

The SIP proxy selects the method based on the capabilities reported by the SBC. If the SBC indicates that it supports the method “Refer”, the SIP proxy will use Option 2 for call transfers.

DaveChomi Yes, since the time of this topic I can confirm that call transfers, including internal ones, are working fine. We just had to figure out that Teams would send REFER back to SBC and expect SBC to send new INVITE back to Teams using passed Refer-To header with MS-style 'x-t' and 'x-m' tags. Also original Referred-By header must be preserved on new call.

G____ 

As I already stated I do not see any issue with using REFER so I would not remove REFER from Allow in Sp headers. 

Here is the description which I wrote last year I believe and there is also working SIP flow of Hold with REFER. 

One member of community mentioned issues in APAC region due to missing MoH bot there which was also causing issues for them. 

https://techcommunity.microsoft.com/t5/microsoft-teams/music-on-hold-in-teams-amp-4-seconds-until-hold-is-in-place-for/m-p/977517

Lt_Flash 
I don't see any issue with REFER over the last year on our infrastructure and we are using almost every type of DR configuration even with Local Media Optimization and proxy SBC. The only issue I had with REFER was that our firewall was setup all the time wrongly for mediabypass (first version) when SBC wanted to reach it's own public IP for media flow and crazy hairpin was needed over the FW. 

G____ 

Some more details on it

DaveChomi

We are having similar issues with AudioCodes direct routing to Teams.

All unhold (resume) action from Teams creates a net new call leg in Teams (new call ID, cseq:1).

On the other hand, the transfer and the cons transfer works nicely. We did not have to mess with REFERs (as we have no refer in the allowed list at all, in any part of the messaging).

Is it a known issue, you think? 

and the same story working nicely with Skype (all the rest is the same, the only difference is Teams instead of Skype on prem endpoint).

davidmcgrath 

Sorry, somehow I have missed your reply and didn't receive a notification about your answer. You need to block 'REFER' method in both initial requests coming from PBX or MS side and in replies too, in that case MS will be sending just Re-INVITES as per my SIP dump above. But currently, in October 2020, it looks like they've fixed REFERs, we're actually testing if they're working fine now, but haven't come to conclusion yet. Looks like REFERs are working, but we haven't finished full testing procedure in our company.

Hi DaveChomi 

Thanks for the reply, that makes a lot of sense now!

Would it be possible to share an example of the invite that you generate from the on hold REFER. We handle this refer in the same way that we handle the refer that is generated when you transfer a call to a teams user.  We are clearly being transferred to the MOH server, but the call in the teams client hangs up when the call goes on hold and then its not possible to retentive the call.

Thanks in advance

David

Lt_Flash davidmcgrath  
Putting call on hold you are transferring the call to music on hold entity which is playing the MoH for PSTN calling party. That is the reason why you see REFER afrer putting call on hold. 

Hi Lt_Flash 

I can share a fill PCAP for a call, but don't want to share it publicly. Is there a way I can share it directly with Lt_Flash.?

I have attached a screen shot of the sip flows from wire-shark. I have also added the refer and invite packets as well.

We don't understand why MS Sends a REFER after the re-invite. If you look at the attached png ,I click the hold button in teams at 12.205 secs, we respond to the re-invite, then MS sends us a REFER, which we respond to in the same way as we respond to a teams transfer request,

Any attempts to un-hold the call do not work after this. The call drops and a popup appears in the top left corner of teams client showing the call is on hold. MOH plays on the pstn leg. No more packets are sent from MS to my SBC.

Regards

David

davidmcgrath Well, in first place, why is it sending REFER if you're putting call on hold? It should just send a SIP re-INVITE with SDP a=inactive. SIP REFER is used for blind and/or attended transfers as per RFC5589. If you're getting an INVITE and then REFER - probably INVITE has SDP with a=inactive thus putting call on hold, but REFER is definitely for transferring calls somewhere else, can you post a tcpdump of these two packets you're seeing? And what happens after you press un-hold in Teams client - do you get any packets coming from MS side to your SBC?

Hi Lt_Flash 

Thanks for the reply. After reading your reply's above, we enabled REFER support on our SBC. We use the refer-to tag to work out who to send the refer back to as you suggested. 

So we have REFER enabled. If teams calls PSTN, then teams clicks hold, wee get a re-invite and then a refer. we respond to the refer is the same way we would do for a transfer to another teams user (that works) but when we do the teams client is unable to take the call off hold.

I wondered if you had an example of on hold with REFER support works with teams.

There is useful documentation about how to handle transfers to teams uses with REFER support but nothing about on-hold.

Regards

David

davidmcgrath Hi,

I'm glad that transfers are working for you! Basically, holds are working same way, you need to strip off 'REFER' method from all 'Allow' headers on packets in BOTH directions - from MS side and to MS side, make sure you're doing that! Often people block it just in one way and the response packets are not modified and thus nothing works.

In regards to putting call on hold when REFER is prohibited - MS would be sending Re-INVITE with a=inactive field and on resume it sends a=sendrecv in Re-INVITE packet. Here's an example of such packet:

SIP packet from 52.114.7.24:3200, Method is INVITE, RU: sip:asterisk@xxxxxxxxx:7061;transport=TLS, message is
INVITE sip:gateway@sbc29356.xxxxxxxxx:5061;transport=TLS SIP/2.0
FROM: <sip:+xxxxxxxx@xxxxxxxx>;tag=9b78f08b34304f01a31dd37a672d0666
TO: <sip:+xxxxxxxxxxx@xxxxxxxxx>;tag=4d0e1385-8a08-432b-aab9-ab3db28ae9a4
CSEQ: 1 INVITE
CALL-ID: f9697203-ea28-4fbc-a231-aee1aa966150
MAX-FORWARDS: 69
VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKb18bed37
CONTACT: <sip:api-du-a-asea.pstnhub.microsoft.com:443;x-i=3386d5e5-0edb-4119-827b-8a9b0a2d585e;x-c=a91fa114301d55868b3b456ced8387dc/s/1/52fa38a6554142a0969332b91cbd3827>
CONTENT-LENGTH: 689
MIN-SE: 90
SUPPORTED: timer
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.5.13.3 i.ASEA.3
CONTENT-TYPE: application/sdp
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SESSION-EXPIRES: 3600;refresher=uac

v=0
o=- 216948 2 IN IP4 127.0.0.1
s=session
c=IN IP4 52.114.23.32
b=CT:10000000
t=0 0
m=audio 52762 RTP/SAVP 104 117 9 103 111 18 0 8 97 101 13 118
c=IN IP4 52.114.23.32
a=rtcp:52763
a=label:main-audio
a=mid:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:c0XKJbLpvv1/IjlH73TVf3fH2qA8YIfulNDFhal4|2^31
a=inactive
a=rtpmap:104 SILK/16000
a=rtpmap:117 G722/8000/2
a=rtpmap:9 G722/8000
a=rtpmap:103 SILK/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=ptime:20

And here it's taking call off-hold:

SIP packet from 52.114.7.24:3200, Method is INVITE, RU: sip:asterisk@xxxxxxx:7061;transport=TLS, message is
INVITE sip:gateway@sbc29356.xxxxxxxxxxxx:5061;transport=TLS SIP/2.0
FROM: <sip:+xxxxxxxxx@xxxxxxxxxxxxxxxx>;tag=9b78f08b34304f01a31dd37a672d0666
TO: <sip:+xxxxxxxxxxxxxx@xxxxxxxxxxxxxxxx>;tag=4d0e1385-8a08-432b-aab9-ab3db28ae9a4
CSEQ: 3 INVITE
CALL-ID: f9697203-ea28-4fbc-a231-aee1aa966150
MAX-FORWARDS: 69
VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKa3cf90b1
CONTACT: <sip:api-du-a-asea.pstnhub.microsoft.com:443;x-i=3386d5e5-0edb-4119-827b-8a9b0a2d585e;x-c=a91fa114301d55868b3b456ced8387dc/s/1/52fa38a6554142a0969332b91cbd3827>
CONTENT-LENGTH: 689
MIN-SE: 90
SUPPORTED: timer
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.5.13.3 i.ASEA.3
CONTENT-TYPE: application/sdp
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
SESSION-EXPIRES: 3600;refresher=uac

v=0
o=- 216948 3 IN IP4 127.0.0.1
s=session
c=IN IP4 52.114.23.32
b=CT:10000000
t=0 0
m=audio 52762 RTP/SAVP 104 117 9 103 111 18 0 8 97 101 13 118
c=IN IP4 52.114.23.32
a=rtcp:52763
a=label:main-audio
a=mid:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:c0XKJbLpvv1/IjlH73TVf3fH2qA8YIfulNDFhal4|2^31
a=sendrecv
a=rtpmap:104 SILK/16000
a=rtpmap:117 G722/8000/2
a=rtpmap:9 G722/8000
a=rtpmap:103 SILK/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=ptime:20

Also I recommend turning off SIP session timers on PBX side or else you may encounter calls dropping at 59 mins and 28 seconds (in case with Asterisk PBX) as Asterisk can't correctly negotiate who would be session refresher in many cases.

Hope this helps!

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 

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!

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!

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 

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 

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!

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