[asterisk-bugs] [Asterisk 0017874]: [patch] Q931 - Sending PROGRESS after sending ALERTING is a protocol error

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17874 
====================================================================== 
Reported By:                nic_bellamy
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   17874
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
JIRA:                       SWP-2060 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 282537 
Request Review:              
====================================================================== 
Date Submitted:             2010-08-16 22:41 CDT
Last Modified:              2010-08-20 10:24 CDT
====================================================================== 
Summary:                    [patch] Q931 - Sending PROGRESS after sending
ALERTING is a protocol error
Description: 
The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.

Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.

Issue affects all released versions of Asterisk, plus SVN-trunk.

Protocol specification reference: T-REC-Q.931-199805-I page 235, "Figure
A.5/Q.931 – Overview protocol control (network side) point-point (sheet 3
of 8)"
====================================================================== 

---------------------------------------------------------------------- 
 (0126192) svnbot (reporter) - 2010-08-20 10:24
 https://issues.asterisk.org/view.php?id=17874#c126192 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 283048

U   branches/1.4/channels/chan_dahdi.c

------------------------------------------------------------------------
r283048 | rmudgett | 2010-08-20 10:24:34 -0500 (Fri, 20 Aug 2010) | 22
lines

Q931 - Sending PROGRESS after sending ALERTING is a protocol error

The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.

Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.

Protocol specification reference: T-REC-Q.931-199805-I page 223, "Figure
A.5/Q.931 -- Overview protocol control (network side) point-point
(sheet 3 of 8)"

(closes issue https://issues.asterisk.org/view.php?id=17874)
Reported by: nic_bellamy
Patches:
      asterisk-1.4-r282537_no-progress-after-alerting.patch uploaded by
nic bellamy (license 299)
      asterisk-1.6.2-r282537_no-progress-after-alerting.patch uploaded by
nic bellamy (license 299)
      asterisk-trunk-r282537_no-progress-after-alerting.patch uploaded by
nic bellamy (license 299)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=283048 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-20 10:24 svnbot         Checkin                                      
2010-08-20 10:24 svnbot         Note Added: 0126192                          
======================================================================