[Home]

Summary:ASTERISK-08491: Stack gets confused when Protocol error received after SETUP
Reporter:raarts (raarts)Labels:
Date Opened:2007-01-05 03:09:51.000-0600Date Closed:2007-01-29 13:29:25.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) libpri-prot-error-trace.txt
Description:Hi, this is technically a minor problem, but has resulted in an unexpectedly high
phone bill for one of my customers.

Some switches (at least here in The Netherlands) require setting pridialplan to dynamic. If you set pridialplan to unknown, they *do* connect the call, but first they send you a Protocol Error. Problem is, that this Protocol Error confuses the libpri protocol stack in such a way that when asterisk tells the stack to tear down the call, asterisk is lead to think the call is finished when in fact no disconnect message has been send to the ISDN switch.

This has resulted in an unexpected high phonebill when someone dialed a premium number which in its turn answered the line and played ringing sound....
The caller *thought* the call was not answered, hung up, but the libpri stack was confused, did not hang up, and the call was up for over 24 hours...

Is it possible to either terminate the call on protocol error after call setup, or ensure that the state machine does not get confused?

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

I hope you do not ask for more traces, I would need to jump through hoops with this angry customer to produce them..



1 -- Making new call for cr 130
   -- Requested transfer capability: 0x00 - SPEECH
1 > Protocol Discriminator: Q.931 (8)  len=38
1 > Call Ref: len= 1 (reference 2/0x2) (Originator)
1 > Message type: SETUP (5)
1 > [1 041  031  801  901  a31 ]
1 > Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
1 >                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
1 >                              Ext: 1  User information layer 1: A-Law (35)
1 > [1 181  011  811 ]
1 > Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Preferred Dchan: 0
1 >                        ChanSel: B1 channel
1                          ]
1 > [1 6c1  0b1  211  801  351  351  351  371  361  381  301  341  341 ]
1 > Calling Number (len=13) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163 ) (1)
1 >                           Presentation: Presentation permitted, user number not screened (0) '555768044' ]
1 > [1 701  0a1  a11  321  301  351  361  321  381  321  391  321 ]
1 > Called Number (len=12) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163)  (1) '205628292' ]
1 > [1 a11 ]I>
1 > Sending Complete (len= 1)
   -- Called g1/0205628292
Aug 26 10:32:05 ERROR[19197]: app_mixmonitor.c:181 mixmonitor_thread: Cannot open /home/services/asterisk/var/s pool/asterisk/monitor/dummy.raw
1 < Protocol Discriminator: Q.931 (8)  len=12
1 < Call Ref: len= 1 (reference 130/0x82) (Terminator)
1 < Message type: STATUS (125)
1 < [1 081  031  821  e41  6c1 ]
1 < Cause (len= 5) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local  user (2)
1 <                  Ext: 1  Cause: Unknown (100), class = Protocol Error (6) ]
1 <              Cause data 1: 6c (108)
1 < [1 141  011  011 ]
1 < Call State (len= 3) [ Ext: 0  Coding: CCITT (ITU) standard (0) Call state: Call Initiated (1)
1 -- Processing IE 8 (cs0, Cause)
1 -- Processing IE 20 (cs0, Call State)
1 < Protocol Discriminator: Q.931 (8)  len=7
1 < Call Ref: len= 1 (reference 130/0x82) (Terminator)
1 < Message type: CALL PROCEEDING (2)
1 < [1 181  011  891 ]
1 < Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
1 <                        ChanSel: B1 channel
1                          ]
1 -- Processing IE 24 (cs0, Channel Identification)
   -- Zap/1-1 is proceeding passing it to Local/0205628292@eduvision-pre-outbound-9cec,2
1 < Protocol Discriminator: Q.931 (8)  len=29
1 < Call Ref: len= 1 (reference 130/0x82) (Terminator)
1 < Message type: CONNECT (7)
1 < [1 1e1  021  811  821 ]
1 < Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network ser ving the local user (1)
1 <                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
1 < [1 291  061  061  081  1a1  0a1  201  061 ]
1 < Time Date (len= 8) [ 1 061 -081 -261  101 :321 :061  ]
1 < [1 4c1  0b1  211  831  321  301  351  361  321  381  321  381  321 ]
1 < COLP (len=13) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
1 <                           Presentation: Presentation allowed of network provided number (3) '205628282' ]
1 -- Processing IE 30 (cs0, Progress Indicator)
1 -- Processing IE 41 (cs0, Date/Time)
1 -- Processing IE 76 (cs0, Connect Line ID Presentation)
1 > Protocol Discriminator: Q.931 (8)  len=4
1 > Call Ref: len= 1 (reference 2/0x2) (Originator)
1 > Message type: CONNECT ACKNOWLEDGE (15)
Comments:By: raarts (raarts) 2007-01-22 05:18:32.000-0600

Would someone care to at least comment?
By: Matthew Fredrickson (mattf) 2007-01-22 10:17:51.000-0600

Are you using the OFFICIAL release of Asterisk/libpri/zaptel?  Your pri debug message looks like you're using bristuff.  Bristuff patches up libpri/chan_zap/Asterisk and we don't provide support for it on this bug tracker.  If you are, we suggest you go to the author of those patches for problems with bugs.
By: raarts (raarts) 2007-01-23 02:19:39.000-0600

I'm sorry, I should have added that this happens regardless of
applied bristuff patches. Indeed the traces that I supplied were
from a bristuff patched machine.

I see that you committed a fix for this bug in r389. I'll
test it, and report back tomorrow. Thanks for looking into this.
By: raarts (raarts) 2007-01-23 14:11:38.000-0600

Ok, this problem is fixed now. Thanks.