Most calls with Teams Direct Routing become one way audio
Have set up Direct Routing with an Audiocodes SBC and am testing features with my account in Teams only mode. I can make and receive calls just fine but it seems on most calls after about a minute or so the audio becomes one way - initially the call would just drop and I saw in the syslog the AC was showing an rtp broken connection error so I set broken connection mode to ignore but now the audio just becomes one way where I can hear the remote person but they can't hear me. Audiocodes syslog isn't helping much and just shows an rtp broken connection error. Anyone else see this or have any ideas? I would suspect it's the firewall except for the fact that in some of my testing the calls are fine and don't become one way.
Delay transferring out from auto attendant
We have been testing Teams with Direct Routing trunks provided by a carrier partner. All inbound and outbound calls direct to/from Teams users connect without issue. We are using the Teams apps on Windows and iOS - no deskphones are involved yet. I have a simple auto attendant set up which greets the caller with the text-to-speech feature, and then transfers to a queue. This queue plays the default music on hold while alerting queue members. The problem I have is that a caller will dial the number associated with the auto attendant, the call will be answered within a couple of seconds, and then immediately the greeting will be read out and the user will be transferred to the call queue. There is then a silent period of between 5-10 seconds before the music on hold for the queue is heard - this varies with each call, at the lower end it's an acceptable delay, but when it gets to 10s of silence it really isn't workable. If I set the routing on the call queue to put the caller back into the auto attendant after a wait period this happens without any silence - the maximum wait period for the queue is reached and the greeting is played as soon as the music on hold ends. I am not able to determine whether the delay is happening within the auto attendant as it just waits after playing the greeting, or whether it's an issue at the start of the call queue. I opened a support ticket and was told that this delay is expected behavior and it is designed that way - the problem is that it's long enough for people to abandon calls as they think there is a problem. The queue is in conference mode, but this isn't an issue with users answering calls from queues so I don't think that is relevant anyway. Is it true that this delay is expected behavior? Is it expected due to a technical limitation or is it really designed that way?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
Microsoft Teams Direct Routing Outbound Calls not working (error 504)
Hello, I am trying to configure Direct Routing on my tenant, using my carrier's hosted multi-tenant SBC. They connected to my tenant with powershell and made all the needed configurations with these Powershell commands, after they validated the SBC domain in my office 365 tenant and created a user with that domain: Set-CsOnlinePstnUsage -Identity Global -Usage @{Add ="TeamsVoice"} New-CSOnlineVoiceRoute -Identity "DefaultRoute" -NumberPattern ".*" -OnlinePstnGatewayList <sbc fqdn> -Priority 1 -OnlinePstnUsages "TeamsVoice" New-CsOnlineVoiceRoutingPolicy "VP-TeamsUser" -OnlinePstnUsages "TeamsVoice" Set-CsUser -Identity user@domain.com -EnterpriseVoiceEnabled $true -HostedVoiceMail $true -OnPremLineURI tel:<phonenumber> Grant-CsOnlineVoiceRoutingPolicy -Identity "user@domain.com" -PolicyName "VP-TeamsUser" Don't need to add the SBC because of the multi-tenant config as specified in this articlehttps://docs.microsoft.com/en-us/microsoftteams/direct-routing-sbc-multiple-tenants Inbound calls are working correctly, but outbound calls are not. My carrier's SBC is not receiving anything, and if I go to my PSTN direct routing report I get the SIP Error 504 "Unable to deliver INVITE: No such host is known" with the microsoft final code569002. My carrier believes it is a Microsoft Teams backend problem because they have other customers with the same config and they work properly. What can I do? I also opened a ticket with Microsoft but I wanted to double up by also asking in here. My user has got Office 365 E3 + Microsoft Phone System licenses and I have access to the number dial pad in the calls section of the app. Thanks for the helpTeams Direct Routing - DTMF tones on Inbound Calls not working
The other day of Microsoft Direct Routing life in our enterprise environment and another nice issue appeared as reported from users. Might be it will help somebody. Long story short: Microsoft accepts also not so standard DTMF type value than the more usual 101 on inbound calls to Teams users from PSTN side but at the end it sends payload which is not expected by on-premise SBC using 101. I believe this could be a bug which is visible in very specific setup and just on inbound calls. Just more deep dive for those who likes that 🙂 Imagine that. Teams User receives PSTN call from competitor conferencing service and needs to dial hash sign or some digits in order to confirm joining conference. Teams user press desired combination but nothing happens. Dialpad is beeping but other side does not receive anything. I love Syslog viewer from Audiocodes. Already helped me a lot. So jumping into SIP messages I do see that call is offering in INVITE payload type rtpmap:96 for telephone-event. Ups, not standard value as far as I have seen. Value was basically coming all the way through on-prem PBX from our voice ingress of one remote site from ISDN gateway which was setup with this value. Well, not a problem as Microsoft sends as response INVITE where obviously accepts that value too... see the capture with response from Teams SIP proxy. Okay, what could be he problem then. Seeing debug logs of the SBC I found what happened actually when I press any digit on Inbound calls to Teams. Nicely written "Totally wrong payload" 🙂 Teams client was sending payload type 101 to the SBC. That's obviously not the right way. So we basically changed the payload type on our ISDN gateway to provide payload type 101 which does not affect anything else but perfectly fix our issue with Teams 🙂 Probably quicker solution than fighting over Microsoft Support. But I believe somebody will catch this article and might provide fix.
Teams call transfer failed - Audiocodes VE
Dear Colleagues, I have setup an Audiocodes VE Direct Routing SBC, but during the tests I noted that I was not able to forward calls. As I can see, during the REFER process there is a 488 Not Acceptable answer, because of media mismatch between the Mediant and the O365. The p2p calls are working properly in every direction. Have you experienced this kind of problem? I have attached the SIP log (in .xlsx format, since .txt is not allowed), and the participants are: 10055 – Teams (Transferor) 20055 – CUCM registered phone (Transferee) 80000 – Mediant registered phone (Transfer target) Thanks, LaszloOutgoing calls from teams dropped
All outgoing calls are being dropped after about 10 seconds of silence with Q.850 ;cause=22 being returned to the SBC and the following error displayed to the user: It only happens in one of our offices if the same account logs into a machine in a different office it's fine and it never occurs on the WebClient only the desktop client. Anyone seen this before?
