[ASTERISK-112] chan_dahdi: Raw power ring audible on recall ring from IAX2 to DAHDI

Make a call from A (which could be anything), over an IAX2 to trunk to a DAHDI phone, B (in my testing, A and B are on different Asterisk systems). threewaycalling must be enabled (at least for B).
Answer B, then flash to put A on hold.
OBSERVATION #1: If Set(CHANNEL(musicclass) is used to set MOH for the call, a DAHDI to DAHDI call but not an IAX2 to DAHDI call (such as this one) will hear MOH. The IAX2 call will just be silent, for some reason.
Hang up B, which will trigger a recall ring for the call on hold.
BUG #1: A will hear "power ring" (the actual audio as if you were listening to dahdi_monitor) for the recall ring to B, until B answers. This is actually really cool, but this should NOT be happening. For one, this is "information leakage" which is not allowed from a security perspective. A should never know if B is simply off hook or has hung up and receiving a recall ring. This exposes this information since when B hangs up, the call goes from silence to hearing power ring until the call is answered again.

Note that this power ring will sound different on each system. On one system with a 24-port analog card, it sounds really cool, almost like a city ringback tone, and on another system with a 4-port analog card, you don't really hear much "power ring at all", it's almost silent. Makes sense and adds to the uniqueness of this functionality!

This all happens even without the hearpulsing setting enabled (though the patches are present) in 21.3.1.

ACTION ITEM: Fix BUG #1 so it doesn't happen. The obvious first step is compare a DAHDI to DAHDI call and IAX2 to DAHDI and see what's different (control frame differences?) Part of the fix may entail in chan_dahdi dropping audio towards the caller (e.g. dahdi_read) if a recall ring is ongoing.

It would be very nice to be able to hear power ring as the regular ring, in general - so not in this scenario, since that isn't allowed (A should hear MOH or just silence the whole time), but in general when A calls B, instead of precise ringback, we have the option to provide the actual power ringing audio. This can actually be accomplished by enabling "hearpulsing=yes". It does exactly what we would want and expect here. As such, this provides a clue towards resolution, effectively "hearpulsing" is active on recall ring in the IAX2 to DAHDI scenario, even though it shouldn't be. So, really, there are 2 things to do here:

Fix chan_dahdi so that this audio is dropped (no hearpulsing) during recall rings.
Investigate why chan_iax2 differs from a DAHDI to DAHDI call in this case.

Fixes should be done at the same time (but only one at a time and then reverted) so both can be verified: i.e. if 2 is fixed first, it will be difficult to verify if 1 is resolved, and if 1 is resolved, it will be difficult to (audibly) investigate 2.

As far as #1 goes, this seems like a possible solution:

change if (p->cidspill || p->cid_suppress_expire) { to if (p->cidspill || p->cid_suppress_expire || !p->owner) {, since whenever this happens, we see "Dropping frame since there is no active owner on DAHDI/16-1"

Comments

You must be logged in to leave a comment.