Forum Discussion
MS Teams Direct Routing - Internal call transfer failure
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 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.
