[asterisk-bugs] [JIRA] (ASTERISK-21175) 'Squelching' early media in DAHDI (sig_pri)

[Rusty Newton (JIRA)]

Rusty Newton created ASTERISK-21175:
---------------------------------------

             Summary: 'Squelching' early media in DAHDI (sig_pri)
                 Key: ASTERISK-21175
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21175
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_dahdi
    Affects Versions: 1.8.19.1
            Reporter: Gianluca Merlo


I am creating this issue following the suggestion made by Richard Mudgett in the asterisk-dev mailing list:

http://lists.digium.com/pipermail/asterisk-dev/2013-February/058764.html

The issue itself, in 1.8.19.1, 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:
{quote}
> 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 1.8.19.1). 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.
{quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira