Forum Discussion
MS Teams Direct Routing - Internal call transfer failure
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.
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...
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.
- 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.
- 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.
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.
- Is disallowing REFER officially documented, or is it considered a workaround? If documented, could you provide links? Thanks!
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.
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.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
