DECT 112 (RFP 12) - One-Way Audio on hold or Internal Call Transfer

[bioreit]

Hi all,

This is a really weird one. We have Mitel 112 DECT phones, connecting via RFP 12 base stations - not loads, just a few, but as is typical they're some of the more important users! We've found that when external callers dial in (either to our Attendant consoles or a Mitel 6930) and are then internally transferred to these DECT phones, we end up with one-way audio - the DECT user cannot hear the original caller.

If an Attendant console or 6930 does an attended transfer, then the audio is fine until the transfer is completed, then it's one-way.

If they start an ad-hoc conference and all three parties are present, then audio is fine. As soon as the original destination drops out, leaving the caller and the DECT phone, audio becomes one-way.

Testing has revealed the same is true if an external caller dials a DECT phone directly and is then placed on hold - when brought off hold the audio becomes one-way when previously it was working fine.

If the call is transferred to the DECT phone via its DID number, then two-way audio is fine (unless it's placed on hold....).

Causes potentially ruled out:
Class of Service - we have other phones in use as Generic SIP with the same Cos which don't experience the issue
SIP Device Capabilities - as above, other phones using the same don't have the issue. Also checked other settings to make sure there wasn't anything obviously incorrect, couldn't see anything (doesn't mean I didn't miss it though!)
Firewall - nothing on the firewall to indicate traffic being dropped or blocked. Ports reported by all connected devices as being used in calls are in the firewall as permitted for those IP ranges
RFP 12 Settings - Checked Hold Behaviour, DTMF Signalling, Codecs, SIP Ports and ToS/QoS (tried every possible combination, apart from ToS/QoS - far too many for that!)
SIP Trunk MiVB - SIP Peer Profile tried various changes under SDP Options and Signaling and Header Manipulation


All reported to our support provider but they're equally as stumped!


It did all seem to suggest to me that this is a codec negotiation issue, or similar:
A calls B, negotiates a codec. B initiates transfer to C potentially with another codec, completes the transfer joining A and C.
A is communicating on the codec negotiated with B, C is communicating on the (different) codec negotiated with B, one-way audio results.
Seeing as A <--> C works fine if B uses C's DID to transfer, I guess because the MBG is involved it is renegotiating the codec correctly between A and C? Or is this me barking up the wrong tree?
Tried removing all codecs from the DECT apart from G711A (packet captures point to this as the codec negotiated in all conversations) but didn't improve matters. So perhaps I am getting (wrongly) fixated on that as a potential cause...


Any random ideas gratefully received!



Setup:
MiVoice Business, Active Embedded 3300 v 14.0.1.29, MiVoice Business Blade v 8.0.1.25, running MSL 10.5.19.0
MiCollab 8.0.0.40 using flow-through provisioning for Hot Desk users, remainder such as DECT created on MiVBs as Generic SIP
MBG 10.0.0.116, MSL version 10.5.19.0
SIP Trunking to MiVB servers
RFP 12 Base Station Firmware:    IPDECT/03.55/B0007/23-Oct-2015 11:24

Hot Desk users: Mitel 6930
Generic SIP: Mitel 112 DECT, Aastra 6731i, a few other random types

[bioreit]

Thought I'd report back that this is now fixed; after many weeks of head-meets-desk, turns out that really all that needed changing was disabling RTP Collision Detection under Network Settings on the RFP 12 base station.

Thing is, this setting had definitely been changed in earlier attempts, so all I can assume is that another changed setting somewhere was interfering - by starting again from scratch and disabling only that setting, the issue is resolved. But to muddy the waters, changing other settings under Network or Servers doesn't seem to break any of the phones again, so it's a bit of a mystery!