Forum Discussion
MS Teams Direct Routing - Internal call transfer failure
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?
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.
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.
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.
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
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-protocolsven 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
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).
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
