Summary:ASTERISK-21151: 'Squelching' early media in DAHDI (sig_pri)
Reporter:Gianluca Merlo (gian)Labels:
Date Opened:2013-02-22 07:42:50.000-0600Date Closed:2013-04-03 15:28:29
Versions: Frequency of
is caused byASTERISK-17834 [patch] pri early media won't ring
is related toASTERISK-12346 [patch] 183 response although progressinband=never
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, 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
> patch.
> 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 It seems that the "dialing"
> member of
> the DAHDI private struct (which is set to 0 by this call) affects
> subsequent
> 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
> questions
> 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
>    suggests
>    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
>    the
>    presence of a progress indication in Q.931 signalling, and of a
>    call to
>    sig_pri_open_media()?

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:
>    ASTERISK-17834
>    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