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?
Teams rejects call with error 422
Hi all, I'm having some trouble with calling from a Swyx pbx to Microsoft Teams direct routing. When I place a call from Swyx pbx to Teams, the call get's denied. When I checked the logs I noticed the following: 422 Session Interval Too Small error Teams is rejecting the call because Swyx is sending a 90 sconds field in the Session Expires Header. I searched the web for adjusting the allow Session Expire field in Teams but can't find anything. According to this document: https://datatracker.ietf.org/doc/html/rfc4028 The rule is to have at least a 90 seconds Header. So Swyx does nothing wrong with that. Can anybody help me with this? Or point me in a good direction. Thanks!Customized name display for Resource Account
Good day, I am struggling to customize a name display when a user makes an outbound call on behalf of a Resource Account. Currently our Resource Accounts are built with a display name of 'CompanyABC Purchasing', 'CompanyABC Operations', etc. As the first 15 characters are delivered to the PSTN, we would like to only display the name 'CompanyABC' instead of 'CompanyABC Purc' and 'CompanyABC Oper'. We attempted to modify the display name by adding five spaces after CompanyABC and then continuing with the remainder of the name, but only one space is shown once the update has been saved. We can build a test Caller ID Policy, but I am unsure how to apply it to the Resource Account or the associated Call Queue we are using for our teams. Any suggestions on how this can be completed? Shane
induce delay on ringback tone
using direct routing with teams phone system ... noticed when a teams client dials out to external pstn number it pretty much straightaway sends calling party the ring back tone ... so there could be 2-3 ring back tones on the calling end (approx. 4-5 secs.) before the called party eventually receives the first ringing tone .. is there a way to induce a delay in that initial ring back tone Teams phone system sends to the Teams client ? i just don't want to start giving ringback tone straight away when 180 ringing from itsp is not received for another good 3-4 seconds. thanks.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:s4XvtaXKNh33jeaNbeFQk35Xw5d1nfForKnSIczODerived trunk in same tenant where the parent trunk is registered
I'd like to find out if it should be possible to use derived trunks in the same tenant in which the parent trunk is configured. My configuration looks like the below: Parent trunk `teamstest.carrier.com` is configured in TAC and connected to a working SBC. The trunk is showing healthy with no issues reported. Base domain and subdomains have been registered in M365, in the same tenant: `teamstest.carrier.com` `account001.teamstest.carrier.com` `account002.teamstest.carrier.com` I am able to create voice routes which use `teamstest.carrier.com` but when I try to create voice routes using the derived trunk, e.g.: New-CsOnlineVoiceRoute -Identity Route1 -OnlinePstnUsages @{add="Account1Record"} -OnlinePstnGatewayList @{add="account001.teamstest.carrier.com"} -NumberPattern ".*" It fails with the error: New-CsOnlineVoiceRoute: Cannot find specified Gateway "account001.teamstest.carrier.com". Is this because I have some incorrect configuration, or is using derived trunks in this manner not supported?Teams 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.
Direct Routing with Local Media Optimization - 6-7 seconds silence
Scenario: Oracle E-SBC (Acme Packet) with internal media interface and public interface for MS Teams Trunk and media. Media Bypass enabled (always) with Local Media Optimisation Client is in corporate network (internal), the media traffic should flow beetween client and internal media interface of the SBC (the Client cannot reach public IP-addresses directly, HTTP only via Proxy, E-SBC media interface is reachable from client network) Problem: Incoming call to MSTeams Client via E-SBC. RTP from caller to callee is fine, but the RTP from the callee to the caller takes 6-7 seconds until it is established. In the SIP flow you can see, that there is a ReINVITE from E-SBC to MSTreams Cloud, directly after the first 200 OK arrives at the SBC. But the Client/MSTeams SBC needs 6-7 seconds to answer the ReINVITE with the 200 OK. After that, everything is fine, and both can hear each other. But it takes 6-7 seconds until the caller can hear the callee. Find attached a schematic SIP sequence diagram with the relevant messages and also a Wireshark capture with absolute times Is that a normal behaviour (it's montioned here, but only for "some cases") or does anybody know how to get around this? Cheers Oliver
