Comments are inline.
On 03/23/2016 08:05 PM, Holger Freyther wrote:
Can you please elaborate about the intention of this method? You try to undo a failed mapping and do this by disconnecting the call? Is that the right thing to do? Has there been any side effect by the call of tch_map?
Right now the call with incompatible channels is patched through and we hear broken audio. This method instead disconnects the call for both subscribers as bug suggested.
In the long run should there be a MNCC_BRIDGE_REJ answer to the MNCC_BRIDGE call?
I don't think it's worth changing the protocol - this situation only happens with internal MNCC handler on particular configuration (mixed TCH/F and H) because we do not support transcoding. We can assume that all the external MNCC handlers can hadnle it just fine - otherwise there's no point in using them. We should document that mixing F and H channels is discouraged when no external MNCC handler is available.