Avaya Session Border Controllers Certified for Microsoft Teams Direct Routing Non Media Bypass
After Cisco Cube/Voice Gateway/SBC was certified for Microsoft Teams Direct Routing its now another vendor which has been certified for Teams Direct Routing Services. Avaya SBC are now certified for Microsoft Teams Direct Routing enabling the organization who are using the Avaya SBC to interop with the PSTN Integration with Microsoft Teams. Currently SBC Avaya Session Border Controller for Enterprise (ASBCE) with the Release 8.1.1 version is Certified for Microsoft Teams Direct Routing. This will only support the Non-Media-Bypass Test Cases for Microsoft Teams Direct Routing. Microsoft Roadmap reference 66465 Reference: - All the SBC Certified for Microsoft Teams Direct Routing List here. With Regards, Satish U
Teams Toast Notification Showing "Unkown Users" When the Call Comes from Auto Attendant
We are running in problem where if I assign a direct number to the teams user and call that number the Caller ID of the caller is displayed in Teams Toast notification. But if we route the call via Auto Attendant and then to a call queue like: PSTN>SBC>Auto Attendant>Call Queue and put the same user in the queue, (who was called Earlier) then the Caller ID of the same caller is shown as "Unknown Users". We are using the setup with Direct Routing and Ribbon SBC 1000. Secondly, If we direct the same caller to a "Person in Organization" and direct all the incoming calls to the same user (Might be an operator) then again the called ID of the caller is "RECEVIED" properly. But whenenver the call enters a call queue, the caller ID turns into "Unknown Users". The incoming call format is already in E.164 Format. We have cleared the cache of the Teams Application, enabled/disabled the Caller ID policies. Even changing the caller ID policies does not have any affect on the incoming call. The version of the Teams App is "1.5.00.17656 (64-bit)". Any Suggestions?How does Azure Load Balance SIP? Ref: Direct Routing setup with virtual SBC in Azure Cloud
With options under "health probe" to monitor TCP,HTTP and HTTPs ports can anyone help me understand how does the health probe monitors if the SIP services is accepting requests. Based on my reading, for HTTP, the health probe waits of 200 OK message. Will it be same for SIP ports (5060, 5061 or any other)? Example scenario, I have got 3 x virtual SBCs setup in an availability group with each SBC set for max 200 connections/sessions via CAC. I want that if all the 600 sessions on 1st SBC is occupied, the load balancer would sent new requests to 2nd SBC and so on. Now, if the Azure Load Balancer would just monitor if the SIP port is up, it won't find any issues since port 5060 (or any other as defined) would still be open on SBC01. I wanted to understand which kind of SIP message gets exchanged by the Azure Load balancer's health probe monitoring SIP interface/port.
Teams doesn't reply ACK for 200 OK
Hi, My SBC domain is sbc.portsip.io and resolved to 218.76.62.10, the SBC private IP is 192.168.0.11, and the TLS transport is 5078 for communicating with Teams, and used port 5069 on TCP for communication with backend PBX. When I dialed from teams, and the PBX extension answered the call, SBC send the below 200 OK to teams, voice is good but the teams is not replied ACK to SBC cause the call is hangup after a while, where is wrong? SIP/2.0 200 OK Via: SIP/2.0/TLS 52.114.32.169:5061;branch=z9hG4bKb34e2036 Record-Route: <sip:AAAAAAEAAAAAAscTwKgAEGIwNTdkZTRiNDIzZGZhZmFmNzViMDAwZTE1MjY3OTlh@192.168.0.11:5069;transport=tcp;lr;drr> Record-Route: <sip:7AcAAAIAAAAAAQFqNHIgqWRjYTM1OWQ2NDJjMmM4ODFhOGI0YjcwMmQ4YWEwYmJl@sbc.portsip.io:5078;transport=tls;lr;drr> Record-Route: <sip:sip-du-a-as.pstnhub.microsoft.com:5061;transport=tls;lr> Require: timer Contact: <sip:sbc.portsip.io:5078;transport=tls> To: <sip:+86101@sbc.portsip.io:5078;user=phone>;tag=2f928937 From: "Thomas Oliveri"<sip:+1001@sip.pstnhub.microsoft.com:5061;user=phone>;tag=6ce7fe294b6641e194ea839c798d6295 Call-ID: 677fb489e2ac5661b78a1339affa2029 CSeq: 1 INVITE Session-Expires: 3600;refresher=uac Accept-Language: en Allow: REGISTER, INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, SUBSCRIBE, UPDATE, INFO, MESSAGE, PUBLISH Content-Type: application/sdp Server: PortSIP SBC v10.0.0.22 Supported: replaces, norefersub, tdialog, join, timer User-Agent: PortSIP UC - Call Manager 16.0.0.175 X-Session-Id: 611040612304556032 X-Trunk-Name: Teams Direct Routing X-CID: 2vaVDqa6gvIvCq5L7Nw_Fw.. Content-Length: 387 v=0 o=- 420019946 1 IN IP4 192.168.0.16 s=ps c=IN IP4 218.76.62.10 t=0 0 m=audio 30006 RTP/SAVP 18 0 8 101 c=IN IP4 218.76.62.10 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=mid:audio a=sendrecv a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:s4XvtaXKNh33jeaNbeFQk35Xw5d1nfForKnSIczO
Need a guaidance for Direct Routing set up
Hi Everyone! I hope you are doing well. I am looking for step by step guidance to set up Direct Routing with different SBCs. Could you please share the links or documents if you have, and I would like to schedule a meeting to meet and learn. email address removed for privacy reasons Regards,Direct Routing in Carrier mode. Transport connection all non-operational
Hi Guys, We're running an Anynode SBC with a carrier tenant and currently 2 customer tenants. The other day all of the transports for calls to Teams (sip[2,3].pstnhub.microsoft.com) all went non-operational for no apparent reason. I have a called logged with MS but have not received anything back from them as yet. I cannot figure out what has broken. There have been ZERO changes in our Teams environment and the SBC for the past month. Nothing has changed in the config at all. It just stopped working. I've checked everything I can think of and everything looks to be exactly as it was and configured correctly. Cert has not expired. I am baffled. Hoping someone has seen this behaviour and has some clue that can help. The only thing I haven't tried is a complete rebuild of the VM running Anynode. There are no DNS issues, I am at a total loss. This has been running perfectly since we implemented it a couple of years ago. If anyone has any clues, I'd love to here them. Outbound calls from Teams are working fine - it's just inbound not working (because the transports are all offline). Thanks, Glenn
