Summary:ASTERISK-01006: Invalid Q.931 setup information for data call
Reporter:Tomica Crnek (tcrnek)Labels:
Date Opened:2004-02-07 12:57:15.000-0600Date Closed:2011-06-07 14:05:16
Versions:Frequency of
Environment:Attachments:( 0) trace.txt
Description:In the situation when you have 2 PRI channels connected and you are making a data ISDN call coming on one channel and directed to Dial() on the other channel, the q.931 setup is not formatted well. The bearer capability on incoming channel differ from the bearer capability that is sent in setup to outgoing channel. Asterisk should copy received setup data from input and make the same call setup to outgoing channel, but it constructs bearer capability in the way that it requests "Unrestricted digital information" together with "User information layer 1: u-Law". This confuses receiving exchange or end-user equipment. The channel is established, but end stations can not communicate through such channel.

Attached are two debug traces that I captured. Both are taken from Ericsson BusinessPhone PBX. The same difference can be seen if you debug incoming and outgoing channels on Asterisk box.
The first one shows the setup that is coming to it's PRI, the call is well established and working, so, this one is ok.
The other one shows the situation when Asterisk is in between. It can be seen that date differ from one situation to another. This is wrong.


I looked in chan_zap.c. On the end of function zt_call() the arguments passed to pri_call() contain "((p->law == ZT_LAW_ALAW) ? PRI_LAYER_1_ALAW : PRI_LAYER_1_ULAW))" as the last argument. It seams that the law bearer capability is always requested. I think the problem is somewhere there.

In q931.c (from libpri) in function q931_setup() there is "if (!userl1) userl1 = PRI_LAYER_1_ULAW;" This forces this bearer capability to be included in setup.

I don't know if this is all, but I think this might help you.
Comments:By: Mark Spencer (markster) 2004-02-07 18:17:59.000-0600

Fixed not to send layer1 info on a data call, but you will also need latest libpri cvs as well as asterisk cvs.  Be sure you use the "d" option to dial to make it use digital mode, like this:

exten => _XXXX,1,Dial(Zap/g2d/${EXTEN})

for example.

By: Tomica Crnek (tcrnek) 2004-02-08 12:40:25.000-0600

Just once, few minutes ago, the data call passed through from PSTN to RAS, but I don't know why, and I can't make it pass again. Every time after "Attempting native bridge ..." I am getting "!! Unknown IE 76 (Unknown Information Element)". Could this be a problem? I can't find what IE type 76 is. Can this IE 76 be forwarded to another trunk when received in the situation like this one when you have to transparently bridge two channels from two trunks?

The other direction, from inside PBX to RAS servers on PSTN, is working with some RAS servers, and with some other it is not.

By: Tomica Crnek (tcrnek) 2004-02-11 11:06:12.000-0600

--- CONNECT trace ---

Remember the first trace attached to first message?!

After SETUP is received by PBX, the CONNECT message is sent back to originator, in this case Asterisk. Here is this CONNECT message taken from PBX trace. There is one "4C" in it. I think this could be the famous "Unknown IE 76".

                         21,6 s  ==>>  CONNECT                    Dest Cr(00F3)
                                        CONNECTED NUMBER   Info-Element-Type
                                          Number Type:               Unknown
                                          Number Plan:        ISDN/Telephony
                                          Presentation Indicator:    Allowed
                                          Screening:            not screened
                                          Number:                    6690290
                                       00 01 04 02 08 02 80 F3 07 4C 09 01 80
                                       36 36 39 30 32 39 30

By: Mark Spencer (markster) 2004-02-11 13:01:48.000-0600

I don't know what the IE 75 is coming from, or what message (maybe you can show), but a native bridge will not affect the PRI signalling and will pass the audio directly.  Can you confirm you do not have echo cancellation enabled?

By: Tomica Crnek (tcrnek) 2004-02-11 16:11:11.000-0600

If you open trace.txt (attached to first message in this bug report) you will see 3 traces, all 3 taken at Ericsson PBX behind Asterisk. All 3 traces are taken during data call coming from PSTN to extension at PBX.

PSTN --- E1/PRI --- PBX
First one is showing the situation when there is no Asterisk, PBX is directly connected to PSTN. This is ok. CONNECT message trace from previous note is from this one.

PSTN --- E1/PRI --- ASTERISK --- E1/PRI --- PBX
The second one is the one when you put Asterisk between PSTN and PBX. There are differences in messages on two PRI interfaces and I am asking; Could this be the cause for data calls not to work? Could this "IE 76" be the cause.

Ignore Layer1 information, this is now solved ok. These traces were taken before solving this problem.

I'll check about echo cancelation, but, how can it affect data calls?!?!

edited on: 02-11-04 16:10

By: zoa (zoa) 2004-02-25 07:43:29.000-0600

Reminder sent to tcrnek

is echo cancellation on ?

By: Tomica Crnek (tcrnek) 2004-02-25 07:48:18.000-0600

Data calls are working now ok after upgrade from CVS. The primary reason for this bug is solved and you may close it.

But, I did not get any answer regarding "Unknown IE 76".

By: Malcolm Davenport (mdavenport) 2004-02-26 12:56:52.000-0600

Closed pending further updates.

By: Digium Subversion (svnbot) 2008-01-15 14:43:08.000-0600

Repository: asterisk
Revision: 2140

U   trunk/channels/chan_zap.c

r2140 | markster | 2008-01-15 14:43:07 -0600 (Tue, 15 Jan 2008) | 2 lines

Omit PRI layer 1 information for data call (need updated libpri too) (bug ASTERISK-1006)



By: Digium Subversion (svnbot) 2008-01-15 14:43:08.000-0600

Repository: asterisk
Revision: 2141

U   branches/v1-0_stable/channels/chan_zap.c

r2141 | markster | 2008-01-15 14:43:08 -0600 (Tue, 15 Jan 2008) | 2 lines

Don't send layer 1 info with data call (bug ASTERISK-1006) (needs updated libpri)