Jul 15 2019 08:08 AM
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
May 21 2020 02:51 AM
Yes we basically got this working with a firmware update on the Audiocodes direct routing SBCs :)
May 21 2020 07:06 AM
@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!
May 21 2020 07:55 AM
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
May 21 2020 08:57 AM
@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?
May 21 2020 09:19 AM - edited May 21 2020 09:32 AM
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
May 27 2020 12:24 AM
@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.
May 27 2020 01:16 AM
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
Oct 01 2020 10:25 AM
i have the same issue, could you please send me the manipulation you did to the response
Oct 03 2020 12:30 PM
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.
Oct 03 2020 12:34 PM
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.
Nov 06 2020 05:51 AM
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).
Nov 07 2020 10:53 AM
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
Nov 28 2020 02:17 AM
@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.
Nov 28 2020 02:24 AM
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.
Nov 29 2020 04:03 PM
@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.
Jan 18 2021 06:01 AM
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.
May 11 2022 10:39 AM
May 11 2022 06:27 PM
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':
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.
May 12 2022 04:18 AM
May 14 2022 12:47 PM