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

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-21151:
------------------------------------

    Summary: 'Squelching' early media in DAHDI (sig_pri)  (was: "Squelching" early media in DAHDI (sig_pri))
    
> 'Squelching' early media in DAHDI (sig_pri)
> -------------------------------------------
>
>                 Key: ASTERISK-21151
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21151
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_dahdi
>    Affects Versions: 1.8.19.1
>            Reporter: Gianluca Merlo
>         Attachments: 381844_simple_fix.patch
>
>
> 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