|Summary:||ASTERISK-21151: 'Squelching' early media in DAHDI (sig_pri)|
|Reporter:||Gianluca Merlo (gian)||Labels:|
|Date Opened:||2013-02-22 07:42:50.000-0600||Date Closed:||2013-04-03 15:28:29|
|Environment:||Attachments:||( 0) 381844_simple_fix.patch|
|Description:||I am creating this issue following the suggestion made by Richard Mudgett in the asterisk-dev mailing list:
The issue itself, in 18.104.22.168, is that DAHDI starts returning voice frames as soon as a CALL PROCEEDING indication is received on PRI, even in the absence of a "progress indicator" suggesting the availability of inband progress information.
As Mr. Mudgett said, channels/sig_pri.c contains an improvable call to sig_pri_set_dialing() in the handling of PRI_EVENT_PROCEEDING, which could be made (eventually by a chand_dahdi configuration option) to both restore "strict" compatibility with Q.931 and accomodate broken peers such as the one in ASTERISK-17834.
Including the relevant part of the referenced development list email for easy reference:
> As I said, not to bother you too much, and following my initial
> research path,
> I went back with the help of a friend and colleague to verify the
> part of the
> code you pointed out in your patch, and more specifically the
> handling of
> PRI_EVENT_PROCEEDING immediately after the part you suggested to
> After some trial and error, I seem to trace the origin of the
> behaviour to the
> call to sig_pri_set_dialing(), which is performed right before
> sig_pri_unlock_private() and breaking out of the case statement
> (channels/sig_pri.c:5671 in 22.214.171.124). It seems that the "dialing"
> member of
> the DAHDI private struct (which is set to 0 by this call) affects
> calls to dahdi_read(), leading it to return voice frames when it
> (imho) should
> not, which in turn get sent over to the SIP channel.
> Apart from this description, I hope that you can answer some
> regarding these parameters and calls:
> - What is the expected role of the "dialing" dahdi private struct
> member? Are
> my assumptions, by your advice, correct?
For sig_pri that flag is really a Rx squelch. The flag originally
comes from POTS support for when the line is dialing. Even there I
think it was really for Rx squelch. It is poorly named.
> - I see that apparently calls to sig_pri_set_dialing() like the one
> I am
> supposing as the origin of my issue generally come when you call
> sig_pri_open_media() and when there is a progress indication which
> that inband information is available on the channel. You
> explicitly comment
> many parts like these in the code with the comment "Bring voice
> path up". Is
> it correct that the handling of PRI_EVENT_PROCEEDING is seemingly
> the only
> exception, having a call to sig_pri_set_dialing() irregardless of
> presence of a progress indication in Q.931 signalling, and of a
> call to
Yes and it is because of the issue you point out next.
> - This is partly related to my previous question, but is it correct
> that all
> this is related to the issue in:
> and that it seems that the call to sig_pri_set_dialing() was moved
> to be
> made even without a proper progress indication (and a call to
> sig_pri_open_media()) to accomodate the scenario in this issue?
Yes, you are correct in your analysis. If you move the line back to
before the sig_pri_open_media() call does it clear up your issue?
Further history is with ASTERISK-12346 where the dialing flag was
originally misplaced in the provided patch that was committed.
Q.931 Section 5.1.2 says when we should attach in this paragraph:
"The user need not attach until receiving a CALL PROCEEDING/SETUP
ACKNOWLEDGE/PROGRESS/ALERTING message with the progress indicator
No. 8, in-band information or appropriate pattern is now available,
or progress indicator No. 1, call is not end-to-end ISDN; further
call progress information may be available in-band. Prior to this
time, the network cannot assume that the user has attached to the
B-channel. After this time, the user shall be connected to the
B-channel, provided the equipment does not generate local tone.
Upon receipt of the CONNECT message, the user shall attach to the
B-channel (if it has not already done so)."
I am now thinking ASTERISK-17834 was really to accommodate a broken peer
and should have been handled as a config option instead. I think
an option like force_early_media with a chan_dahdi.conf.sample
description saying that in-band information is assumed when a
PROCEEDING message is received.
|Comments:||By: Gianluca Merlo (gian) 2013-02-22 07:51:21.176-0600|
Simple Q.931-strict fix