[Home]

Summary:ASTERISK-16579: [patch] Q931 - Sending PROGRESS after sending ALERTING is a protocol error
Reporter:Nic Bellamy (nic_bellamy)Labels:
Date Opened:2010-08-16 22:41:45Date Closed:2010-08-20 10:39:24
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.4-r282537_no-progress-after-alerting.patch
( 1) asterisk-1.6.2-r282537_no-progress-after-alerting.patch
( 2) asterisk-trunk-r282537_no-progress-after-alerting.patch
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)"

****** ADDITIONAL INFORMATION ******

Allowed example (network state shown, >>> from network, <<< from Asterisk):

>>> SETUP -> state 6 "Call present"
<<< CALL PROCEEDING -> state 9 "Incoming call proceeding"
<<< PROGRESS -> state 9 "Incoming call proceeding"
<<< ALERTING -> state 7 "Call received"

Disallowed example:

>>> SETUP -> state 6 "Call present"
<<< CALL PROCEEDING -> state 9 "Incoming call proceeding"
<<< ALERTING -> state 7 "Call received"
<<< PROGRESS *boom* - not allowed in Q.931 state 7.
Comments:By: Digium Subversion (svnbot) 2010-08-20 10:24:35

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 ASTERISK-16579)
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
By: Digium Subversion (svnbot) 2010-08-20 10:31:02

Repository: asterisk
Revision: 283049

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r283049 | rmudgett | 2010-08-20 10:31:01 -0500 (Fri, 20 Aug 2010) | 29 lines

Merged revisions 283048 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r283048 | rmudgett | 2010-08-20 10:24:36 -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 ASTERISK-16579)
 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=283049
By: Digium Subversion (svnbot) 2010-08-20 10:35:37

Repository: asterisk
Revision: 283050

_U  branches/1.8/
U   branches/1.8/channels/sig_pri.c

------------------------------------------------------------------------
r283050 | rmudgett | 2010-08-20 10:35:36 -0500 (Fri, 20 Aug 2010) | 36 lines

Merged revisions 283049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r283049 | rmudgett | 2010-08-20 10:31:03 -0500 (Fri, 20 Aug 2010) | 29 lines
 
 Merged revisions 283048 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r283048 | rmudgett | 2010-08-20 10:24:36 -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 ASTERISK-16579)
   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=283050
By: Digium Subversion (svnbot) 2010-08-20 10:39:23

Repository: asterisk
Revision: 283051

_U  trunk/
U   trunk/channels/sig_pri.c

------------------------------------------------------------------------
r283051 | rmudgett | 2010-08-20 10:39:23 -0500 (Fri, 20 Aug 2010) | 43 lines

Merged revisions 283050 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r283050 | rmudgett | 2010-08-20 10:35:38 -0500 (Fri, 20 Aug 2010) | 36 lines
 
 Merged revisions 283049 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r283049 | rmudgett | 2010-08-20 10:31:03 -0500 (Fri, 20 Aug 2010) | 29 lines
   
   Merged revisions 283048 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r283048 | rmudgett | 2010-08-20 10:24:36 -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 ASTERISK-16579)
     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=283051