Music on Hold in Teams & 4 seconds until Hold is in place for caller
There was a time I found out during my tests of our Direct Routing implementation that Microsoft made its promises happened and Music On Hold started to work on regular PSTN calls to Teams users. It was a time when I got a report of the new "issue". Users complained it takes too long until the call is put on Hold after clicking on the button. I was just curious what happened because I remember from previous tests this was just matter of second but users reported 4 seconds. Hmmm.... Then I realized I can hear the music ... wohoooo ... So deeper deep dive showed that Microsoft is handling Hold and Music on Hold in very specific way. At least for me. If you click Hold in Teams during the PSTN call you are basically transferring the call to another Teams "user"/object which is playing music for you. You can even hear the very short ring! Very confusing for the caller on PSTN side but I believe it's about way how you want to handle the Ring message on your SBC at the end. Good reason I believe not to change that behavior because of other reasons. And that's also the explanation why it takes so long time! Imagine with Direct Routing following scenario (below is SIP trace for better understanding) 1/Teams proxy is sending REFER, if you have your SBC setup in proper and recommended way then 2/ SBC sends invite back to Teams Proxy, 3/ then you have Ringing in place, 4/ all the SDP exchange of media sources (we are also running Mediabypass so imagine all ICE lite story happening) and boom, 5/ your call is on hold aka transferred to something else than your Teams user. Obviously the other way around, I mean getting the call back from Hold, is somehow reverted process but without REFER. Teams proxy basically sends new INVITE but now with Teams users media sources. Also takes a while and some users might be confused that they did something wrong or call is gone?! So at the end it's not 4 seconds but slightly around 3 (users are exaggerating a bit, right) I believe that this way of handling MoH is also reason why it will take some time until Microsoft will provide also MoH for Transfer function in Teams. Now if you click transfer or consult transfer the Teams Proxy sends Invite with inactive media session so might be another confusion for PSTN caller that there is just silence. Looking forward for Microsoft delivering these features for 100% and even more I would be happy to provide our management their own company MoH (not only on queues or AA 😉 but for users) Hope this article helps some of you
No MoH from SBC when transferring
Found an interesting scenario that breaks your SBC MoH for call transfers. If you are using the Teams desktop client to answer calls, and you happen to put a call on hold and then resume it, you will then no longer receive re-invites from Teams when you press the Transfer or Consult then Transfer buttons for the rest of the call. This means your SBC has no idea that it is meant to start the local playback of its local MoH file for transfers. This will only happen if you put a call on hold and resume it before attempting transfers. If you attempt a transfer without using hold beforehand then there is no issue. It seems that Teams no longer sends re-invites for calls that are placed on hold and resumed in the desktop client, but then it forgets that it's meant to do it if you want to transfer the calls afterwards. Not and issue on the Poly CCX 400 desk phones that I tested with as they still send re-invites for call hold and resume. Has anyone else come across this and is there anyway to change the Teams behavior of no re-invites for Hold and Resume with the desktop clients? I have tested this on 2 separate Teams tenants with SBCs from different vendors for validation.
Hold Resume MS Direct Routing
Hi, I'm building a new SBC for direct routing with media bypass enabled and can handle REFER method internally and externally so all my call transfers are working just fine. But I'm facing a problem with PSTN HOLD/RESUME scenario ! sometimes it works and sometimes it's not without a single change in the SBC configuration. for any inbound/outbound call from/to teams by clicking on HOLD in teams the following happens when it works MS SIP proxy sends a REFER message internally with x-m and x-t records SBC responds with 202 Accepted SBC sends a new Invite "new dialog" back to MS SIP proxy SBC sends NOTIFY messages 100,180,200 which are all accepted and I hear ringing for 1-2 secs then music on hold starts which is a bit strange from MS but OK for now. MS SIP proxy ends the other leg with a BYE message as the call was transferred to MOH When clicking resume and it takes about 2-3 seconds MS SIP proxy sends a new invite with the same above details with a REPLACE that will replace the MOH call id , from/to tags with this new invite to resume the call and it's handled perfectly from the SBC and call is resumed. When it doesn't work (just randomly without any SBC change) Same scenario in the REFER but MS SIP proxy doesn't send the BYE message when the call is transferred to MOH and the mess starts I'm still on the call leg and when click RESUME MS tries to re-invite the call which is not valid and I got disconnected while the other leg is still there. when disabling media bypass and disabling REFER from the allow SIP methods both transfers and hold/resume scenarios works with only re-invites from MS SIP proxy and they are perfectly fine. anyone facing these problems with REFER and Media Bypass enabled ?
