[asterisk-dev] Regression in libpri 1.4.11 - handling ROSE

[Pavel Troller]

Hi!
  I've upgraded libpri to 1.4.11 and I've found that I cannot see the QSIG
calling name for incoming calls now. The problem is, that there is 
an unhandled operation (85) before the Calling Name operation, and libpri
now fails to continue interpreting the facility contents. 

The facility in binary looks like this:

[1c 35 9f aa 06 80 01 00 82 01 00 8b 01 00 a1 10 02 01 01 02 01 55 30 08 82 03 01 30 40 86 01 01 a1 15 02 01 02 02 01 00 80 0d 50 61 76 65 6c 20 54 72 6f 6c 6c 65 72]

The old system (libpri-1.4.10.1) handles all the problems gracefully:

PROTOCOL 1F
AA 0006 (CONTEXT SPECIFIC [10])
  80 0001 00 (CONTEXT SPECIFIC [0])
  82 0001 00 (CONTEXT SPECIFIC [2])
8B 0001 00 (CONTEXT SPECIFIC [11])
A1 0010 (CONTEXT SPECIFIC [1])
  02 0001 01 (INTEGER: 1)
  02 0001 55 (INTEGER: 85)
  30 0008 (SEQUENCE)
    82 0003 01 30 40 (CONTEXT SPECIFIC [2])
    86 0001 01 (CONTEXT SPECIFIC [6])
A1 0015 (CONTEXT SPECIFIC [1])
  02 0001 02 (INTEGER: 2)
  02 0001 00 (INTEGER: 0)
  80 000D 50 61 76 65 6C 20 54 72 6F 6C 6C 65 72 (CONTEXT SPECIFIC [0])
< [1e 02 81 83]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
<                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
< [6c 06 01 81 37 35 38 32]
< Calling Number (len= 8) [ Ext: 0  TON: Unknown Number Type (0)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number passed network screening (1)  '7582' ]
< [9d]
< Non-Locking Shift (len=01): Requested codeset 5
< [31 01 80]
[May 31 09:39:04] ERROR[1204]: chan_dahdi.c:10774 dahdi_pri_error: !! < Unknown IE 49 (cs5, len = 3)
-- Making new call for cr 30488
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 28 (cs0, Facility)
Q.932 Network facility extensions component is not handled
Q.932 Interpretation component is not handled
Handle Q.932 ROSE Invoke component
  [ Handling operation 85 ]
!! Unable to handle ROSE operation 85 [ 30 08 82 03 01 30 40 86 01 01 ] - [0....0 at ...]
Handle Q.932 ROSE Invoke component
  [ Handling operation 0 ]
  Handle Name display operation
    Received simple calling name 'Pavel Troller'



The new system (1.4.11) fails (the call is from another exchange so the binary
code of the facility differs, including the name, but the problem is the same):



-- Delayed processing IE 28 (cs0, Facility)
ASN.1 dump
  Context Specific/C [10 0x0A] <AA> Len:6 <06>
    Context Specific [0 0x00] <80> Len:1 <01>
      <00> - "~"
    Context Specific [2 0x02] <82> Len:1 <01>
      <00> - "~"
  Context Specific [11 0x0B] <8B> Len:1 <01>
    <00> - "~"
  Context Specific/C [1 0x01] <A1> Len:16 <10>
    Integer(2 0x02) <02> Len:1 <01>
      <01> - "~"
    Integer(2 0x02) <02> Len:1 <01>
      <55> - "U"
    Sequence/C(48 0x30) <30> Len:8 <08>
      Context Specific [2 0x02] <82> Len:3 <03>
        <01 30 40> - "~0@"
      Context Specific [6 0x06] <86> Len:1 <01>
        <01> - "~"
  Context Specific/C [1 0x01] <A1> Len:19 <13>
    Integer(2 0x02) <02> Len:1 <01>
      <02> - "~"
    Integer(2 0x02) <02> Len:1 <01>
      <00> - "~"
    Context Specific [0 0x00] <80> Len:11 <0B>
      <4D 6F 64 65 6D 20 44 69-73 63 6F> - "Modem Disco"
ASN.1 end>
  nfe NetworkFacilityExtension Context Specific/C [10 0x0A]
  sourceEntity Context Specific [0 0x00] = 0 0x0000
  destinationEntity Context Specific [2 0x02] = 0 0x0000
  interpretation Context Specific [11 0x0B] = 0 0x0000
INVOKE Component Context Specific/C [1 0x01]
  invokeId Integer(2 0x02) = 1 0x0001
  operationValue Integer(2 0x02) = 85 0x0055
  operationValue = ROSE_Unknown
  Skipping unused constructed component octets!
  21 byte(s) of trailing data not consumed.
!! ROSE invoke operation not handled! ROSE_Unknown


The problem is that the new libpri now skips the rest of the facility
(probably, as stated in the debug), so the Calling Name is not
"discovered".

Is it a known behaviour, or a bug ?


With regards, Pavel Troller