[HELP] Low Layer Compatibility (LLC) not forwarded


#1

Hello *-users,

this is my first post in this forum and here I have a first problem for you… :unamused:

I use Asterisk with the Bristuff-Patches and a Digium TE405P plus a quadBRI-card (european ISDN).
Everything I tried (calls with speech via BRI, SIP and POTS) was succesful except the current task. I try to establish a data call (V.110) originating in a BRI terminal going to an E1-ISDN-Router.
The E1-station checks whether an LLC-information is contained in the SETUP-Message and then accepts the call.

Now I can see while I debug the channel (Asterisk CLI -> pri debug span #) that the LLC is received by the PBX but not sent to the PRI… :frowning:
The result is that the PRI-station rejects the call with Cause: Incompatible destination.

Here’s the incoming (BRI) line:

[code]asterisk1CLI> bri debug span 2
asterisk1
CLI> Enabled debugging on span 2

asterisk1*CLI>
Protocol Discriminator: Q.931 (8) len=31
Call Ref: len= 1 (reference 125/0x7D) (Originator)
Message type: SETUP (5)
[04 02 88 90]
Bearer Capability (len= 4) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)
Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
Ext: 0 User information layer 1: Unknown (24)
[18 01 83]
Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Preferred Dchan: 0
ChanSel: Any channel selectedNo channel selected
]
[70 0a 80 35 31 32 38 30 30 35 30 32]
Called Number (len=12) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘512800502’ ]
[7c 06 88 90 21 45 20 bb]
IE: Low-layer Compatibility (len = 8)
– Making new call for cr 125
– Processing Q.931 Call Setup
– Processing IE 4 (cs0, Bearer Capability)
– Processing IE 24 (cs0, Channel Identification)
– Processing IE 112 (cs0, Called Party Number)
– Processing IE 124 (cs0, Low-layer Compatibility)
Protocol Discriminator: Q.931 (8) len=7
Call Ref: len= 1 (reference 253/0xFD) (Terminator)
Message type: CALL PROCEEDING (2)
[18 01 8a]
Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
ChanSel: B2 channel
]
Protocol Discriminator: Q.931 (8) len=8
Call Ref: len= 1 (reference 253/0xFD) (Terminator)
Message type: ALERTING (1)[/code]

The outgoing (PRI) line shows:

[code]asterisk1CLI> pri debug span 5
asterisk1
CLI> Enabled debugging on span 5



asterisk1CLI>
– Accepting data call from ‘’ to ‘512800502’ on channel 0/2, span 2



– Making new call for cr 32770
– Requested transfer capability: 0x08 - DIGITAL
asterisk1
CLI>

Protocol Discriminator: Q.931 (8) len=27
Call Ref: len= 2 (reference 2/0x2) (Originator)
Message type: SETUP (5)
[04 02 88 90]
Bearer Capability (len= 4) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)
Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
Ext: 0 User information layer 1: Unknown (24)
[18 03 a1 83 81]
Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
ChanSel: Reserved
Ext: 1 Coding: 0 Number Specified Channel Type: 3
Ext: 1 Channel: 1 ]
[6c 02 00 c3]
Calling Number (len= 4) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0)
Presentation: Number not available (67) ‘’ ]
[70 06 c1 31 33 2d 32 37]
Called Number (len= 8) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) ‘13-27’ ]
[a1]
Sending Complete (len= 1)
– Called 13-27
asterisk1*CLI>

Protocol Discriminator: Q.931 (8) len=9
Call Ref: len= 2 (reference 32770/0x8002) (Terminator)
Message type: RELEASE COMPLETE (90)
[08 02 80 d8]
Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0 Location: User (0)
Ext: 1 Cause: Incompatible destination (88), class = Invalid message (5) ]
Processing IE 8 (cs0, Cause)
– Channel 0/1, span 5 got hangup [/code]

Do you have any ideas if Asterisk supports LLC at all or what the solution could be?

Thanks in advance,
Poschi


#2

Please any one help in this case…


#3

As Asterisk is a back to back user agent, I wouldn’t expect this to be supported, but, in any case, the general policy for ISDN related hardware use is that you should obtain support from the vendors of that hardware, not the open source community.


#4

Thanks for your prompt response.

Can you please confirm which hardware we are getting this issue means getting cause from PRI card (Allo, Caudal-fin )OR other PBX server…like Avaya, Panasonic…


#5

Please give suggestion here…???