| 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 | ||||
| Priority: | Major | Regression? | |||||
| Status: | Closed/Complete | Components: | Channels/chan_dahdi | ||||
| Versions: | 1.8.19.1 | Frequency of Occurrence | Constant | ||||
| Related Issues: |
| ||||||
| 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:
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} | ||||||
| Comments: | By: Gianluca Merlo (gian) 2013-02-22 07:51:21.176-0600 Simple Q.931-strict fix | ||||||