Nicely written "Totally wrong payload" :) Seeing debug logs of the SBC I found what happened actually when I press any digit on Inbound calls to Teams. see the capture with response from Teams SIP proxy. Well, not a problem as Microsoft sends as response INVITE where obviously accepts that value too. 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. Ups, not standard value as far as I have seen. So jumping into SIP messages I do see that call is offering in INVITE payload type rtpmap:96 for telephone-event.
Dialpad is beeping but other side does not receive anything. Teams user press desired combination but nothing happens. Teams User receives PSTN call from competitor conferencing service and needs to dial hash sign or some digits in order to confirm joining conference.
Just more deep dive for those who likes that :) I believe this could be a bug which is visible in very specific setup and just on inbound calls. 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.
The other day of Microsoft Direct Routing life in our enterprise environment and another nice issue appeared as reported from users.
0 kommentar(er)
