MS Teams Direct Routing - Internal call transfer failure

[Sims_Krastev]

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

[#2]

@DaveChomi 

Yes we basically got this working with a firmware update on the Audiocodes direct routing SBCs :)

[#3]

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

[#4]

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

[#5]

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

[#6]

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

[#7]

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

[#8]

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

[#9]

i have the same issue, could you please send me the manipulation you did to the response

[#10]

@Mohamed Hussein 

You need to modify 'Allow' header in original message coming from MS Teams to your PBX, removing 'REFER' method and then in any responses from PBX you also need to remove 'REFER' method. In this case MS Teams will be sending Re-INVITE packet instead of REFER packets. Hope this helps.

[#11]

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

[#12]

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

[#13]

@G____ 

Some more details on it

Testing the Teams Direct Routing functionality I have came across an issue in the Hold sequence. In nutshell MS does not unhold the call but it creates a new session (new call) to the same endpoint.

Could anyone help me with a SIP log of a working call -> accept -> Teams hold -> Teams unhold sequence? 

Details:

Standard MS public tenant with the regular sip.pstnhub.microsoft.com public endpoints. On our side it is an ACodes SBC with multiple PSTN side trunks. No media bypass or other media optimization is in place. All other call scenarios (simple call, blind and assisted transfer, etc) work nicely.  SBC setup is to handle call hold locally (as per ACodes guidance). The same trunks work nicely for SfB on prem (with slightly different setup for the Skype side IP Group)

a=inactive is handled by our SBC (remote PSTN gets the sendonly and their response of receive only is converted back to inactive), no other error shows up. Even so MS sends out a second re-invite on the top of the OK-d and acknowledged hold inactive invite.  

The high level flow is 

10:04:06 Initial invite from Teams to pstn

Teams -> SBC

Invite SDP ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY,    supported: timer

SBC -> pstn

Invite SDP Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY,       supported: timer, sdp-anat

Teams <- SBC <- pstn

183 Session Progress SDP Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Teams <- SBC <- pstn

183 Session Progress       Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Teams <- SBC <- pstn

180 Ringing                       Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

10:04:08 Call acceptance

Teams <- SBC <- pstn

200 OK SDP                         Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Teams -> SBC -> pstn

ACK                                    ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

Invite SDP                         ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

Teams <- SBC <- pstn

200 OK SDP                      Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Teams -> SBC -> pstn

ACK                                   ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY      

Call runs

 10:04:31-33 Hold on Teams side

Teams -> SBC -> pstn

Invite SDP                      ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

Teams -> SBC

a=label:main-audio

a=mid:1

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:L2vBEmXqbgm9EvI+Cr1o49ICZ4FJafwFnddUrI51|2^31

a=inactive

SBC- > pstn

a=sendonly

a=label:main-audio

Teams <- SBC <- pstn

200 OK SDP                    Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

SBC <- pstn

m=audio 8456 RTP/AVP 8 13 101

a=recvonly

Teams <- SBC

m=audio 6020 RTP/SAVP 8 13 101

a=inactive

c=IN IP4 200.000.000.000

Teams -> SBC -> pstn

ACK                                ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

Processsing it (after 1 000 ms) MS sends out a

2nd re-invite !! from Teams

Teams -> SBC -> pstn

INVITE SDP                   ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

a=sendrecv

Teams <- SBC <- pstn

200 OK SDP                    Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

a=sendrecv

a=silenceSupp:on - - - -

Teams -> SBC -> pstn

ACK                                  ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

Call plays MS hold music

10:04:59 Teams Onhold / resume MS sends out a second invite creating a separate session (new call practically)

Teams -> SBC -> pstn

Invite SDP

CSEQ: 1 INVITE, CALL ID <<net new>>

So new call leg is being created

 The above setup seems to be inline with the MS documentation

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

even so MS does proxy is confused and sends out a second call. 

INVITE SDP

10:04:31.860 ---- Incoming SIP Message from 52.114.75.24:2368 to SIPInterface #3 (Teams) TLS TO(#1575) SocketID(13138) ----

INVITE sip:+447777777777@customer.sbc.hoster.co.uk:5061;transport=tls SIP/2.0

FROM: John McClane<sip:+444444444444@sip.pstnhub.microsoft.com:5061;user=phone>;tag=5dad766e6f574758b8316e3bc83b4fb7

TO: <sip:+447777777777@customer.sbc.hoster.co.uk:5061>;user=phone;tag=3813645846-1203322466

CSEQ: 4 INVITE

CALL-ID: 6008f33f815e51cfac31a797b7eace65

MAX-FORWARDS: 70

VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK87c1ea93

CONTACT: <sip:api-du-c-euwe.pstnhub.microsoft.com:443;x-i=5730a9f8-9dd3-4aa4-ad42-48f65ef6a688;x-c=6008f33f815e51cfac31a797b7eace65/d/8/0afb6cbf29b849c6ae15b756a33fbe79>

CONTENT-LENGTH: 960

MIN-SE: 90

SUPPORTED: timer

USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.10.12.5 i.EUWE.0

CONTENT-TYPE: application/sdp

ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

SESSION-EXPIRES: 3600;refresher=uas

v=0

o=- 818192 2 IN IP4 127.0.0.1

s=session

c=IN IP4 52.113.9.255

b=CT:10000000

t=0 0

m=audio 49374 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118

c=IN IP4 52.113.9.255

a=rtcp:49375

a=ice-ufrag:qf6h

a=ice-pwd:cAKaay5mszWiR21QAfhitBtA

a=candidate:1 1 UDP 1862270719 52.113.9.255 49374 typ prflx raddr 10.0.140.250 rport 49374

a=candidate:1 2 UDP 1862270462 52.113.9.255 49375 typ prflx raddr 10.0.140.250 rport 49375

a=remote-candidates:1 200.000.000.000 6020 2 200.000.000.000 6021

a=label:main-audio

a=mid:1

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:L2vBEmXqbgm9EvI+Cr1o49ICZ4FJafwFnddUrI51|2^31

a=inactive

a=rtpmap:104 SILK/16000

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

200 OK SDP back to device after setting up hold

10:04:31.985 ---- Outgoing SIP Message to 52.114.75.24:2368 from SIPInterface #3 (Teams) TLS TO(#1575) SocketID(13138) ----

SIP/2.0 200 OK

Via: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK87c1ea93

From: "John McClane" <sip:+444444444444@sip.pstnhub.microsoft.com:5061;user=phone>;tag=5dad766e6f574758b8316e3bc83b4fb7

To: <sip:+447777777777@customer.sbc.hoster.co.uk:5061;user=phone>;tag=3813645846-1203322466

Call-ID: 6008f33f815e51cfac31a797b7eace65

CSeq: 4 INVITE

Contact: <sip:+447777777777@customer.sbc.hoster.co.uk:5061;transport=tls>

Supported: sdp-anat

Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Require: timer

Session-Expires: 3600;refresher=uas

Server: Mediant 4000B/v.7.20A.260.095

Accept: application/sdp

Content-Type: application/sdp

Content-Length: 588

v=0

o=MSX123 986564814 57709579 IN IP4 200.000.000.000

s=sip call

c=IN IP4 200.000.000.000

t=0 0

a=ice-lite

m=audio 6020 RTP/SAVP 8 13 101

c=IN IP4 200.000.000.000

a=ptime:20

a=inactive

a=ice-ufrag:b8R5wxoJkXYTLfyh

a=ice-pwd:U6Y4nSE6QuMxd2icJpcXW51e

a=candidate:780296392 1 udp 2130706431 200.000.000.000 6020 typ host

a=candidate:780296392 2 udp 2130706430 200.000.000.000 6021 typ host

a=mid:1

a=rtpmap:8 PCMA/8000

a=rtpmap:13 CN/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15,16

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WohABz54vXekdjP0u2BlGfgxthlk0lZByrVzBBDl|2^31

Then the extra re-invite after 1 000 ms with full voice in it

10:04:33.016 ---- Incoming SIP Message from 52.114.75.24:2368 to SIPInterface #3 (Teams) TLS TO(#1575) SocketID(13138) ----

INVITE sip:+447777777777@customer.sbc.hoster.co.uk:5061;transport=tls SIP/2.0

FROM: John McClane<sip:+444444444444@sip.pstnhub.microsoft.com:5061;user=phone>;tag=5dad766e6f574758b8316e3bc83b4fb7

TO: <sip:+447777777777@customer.sbc.hoster.co.uk:5061>;user=phone;tag=3813645846-1203322466

CSEQ: 6 INVITE

CALL-ID: 6008f33f815e51cfac31a797b7eace65

MAX-FORWARDS: 70

VIA: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK4665a2fb

CONTACT: <sip:api-du-c-euwe.pstnhub.microsoft.com:443;x-i=5730a9f8-9dd3-4aa4-ad42-48f65ef6a688;x-c=6008f33f815e51cfac31a797b7eace65/d/8/0afb6cbf29b849c6ae15b756a33fbe79>

CONTENT-LENGTH: 960

MIN-SE: 90

SUPPORTED: timer

USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.10.12.5 i.EUWE.0

CONTENT-TYPE: application/sdp

ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

SESSION-EXPIRES: 3600;refresher=uas

v=0

o=- 818192 3 IN IP4 127.0.0.1

s=session

c=IN IP4 52.113.9.255

b=CT:10000000

t=0 0

m=audio 49374 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118

c=IN IP4 52.113.9.255

a=rtcp:49375

a=ice-ufrag:qf6h

a=ice-pwd:cAKaay5mszWiR21QAfhitBtA

a=candidate:1 1 UDP 1862270719 52.113.9.255 49374 typ prflx raddr 10.0.140.250 rport 49374

a=candidate:1 2 UDP 1862270462 52.113.9.255 49375 typ prflx raddr 10.0.140.250 rport 49375

a=remote-candidates:1 200.000.000.000 6020 2 200.000.000.000 6021

a=label:main-audio

a=mid:1

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:L2vBEmXqbgm9EvI+Cr1o49ICZ4FJafwFnddUrI51|2^31

a=sendrecv

a=rtpmap:104 SILK/16000

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

2nd 200 OK SDP back the device

10:04:33.141 ---- Outgoing SIP Message to 52.114.75.24:2368 from SIPInterface #3 (Teams) TLS TO(#1575) SocketID(13138) ----

SIP/2.0 200 OK

Via: SIP/2.0/TLS 52.114.75.24:5061;branch=z9hG4bK4665a2fb

From: "John McClane" <sip:+444444444444@sip.pstnhub.microsoft.com:5061;user=phone>;tag=5dad766e6f574758b8316e3bc83b4fb7

To: <sip:+447777777777@customer.sbc.hoster.co.uk:5061;user=phone>;tag=3813645846-1203322466

Call-ID: 6008f33f815e51cfac31a797b7eace65

CSeq: 6 INVITE

Contact: <sip:+447777777777@customer.sbc.hoster.co.uk:5061;transport=tls>

Supported: sdp-anat

Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL

Require: timer

Session-Expires: 3600;refresher=uas

Server: Mediant 4000B/v.7.20A.260.095

Accept: application/sdp

Content-Type: application/sdp

Content-Length: 611

v=0

o=MSX123 986564814 57709580 IN IP4 200.000.000.000

s=sip call

c=IN IP4 200.000.000.000

t=0 0

a=ice-lite

m=audio 6020 RTP/SAVP 8 101 13

c=IN IP4 200.000.000.000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:13 CN/8000

a=sendrecv

a=silenceSupp:on - - - -

a=ptime:20

a=ice-ufrag:b8R5wxoJkXYTLfyh

a=ice-pwd:U6Y4nSE6QuMxd2icJpcXW51e

a=candidate:780296392 1 udp 2130706431 200.000.000.000 6020 typ host

a=candidate:780296392 2 udp 2130706430 200.000.000.000 6021 typ host

a=mid:1

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:WohABz54vXekdjP0u2BlGfgxthlk0lZByrVzBBDl|2^31

[#14]

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

[#15]

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

[#16]

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

[#17]

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.

[#18]

Is disallowing REFER officially documented, or is it considered a workaround? If documented, could you provide links? Thanks!

[#19]

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

[#20]

We're using MS supported Oracle AP3900 SBCs with recent firmware, I would be surprised if REFER is not supported. I think we have more digging to do.

[#21]

As I wrote a little while ago - we have figured out how to use REFER from MS Teams so currently we're using that method instead of prohibiting it on 'Allow:' level. Works fine witout any issues.