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

[Richard Mudgett]

Please file a bug report with this information.

Richard

----- Original Message -----
> 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
> 
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev