ASTERISK-03801: Incorrect "user information layer 1" representation

[Home]

Summary: ASTERISK-03801: Incorrect "user information layer 1" representation

Reporter: klaus3000 (klaus3000) Labels:

Date Opened: 2005-03-29 12:25:00.000-0600 Date Closed: 2011-06-07 14:04:53

Priority: Major Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: When calling asterisk on a zap channel with an UMTS video call, asterisk reports "user information layer 1" as: "G.7xx 384k Video". I couldn't find this term anywhere defined.

Wouldn't it be wise to change the phrase to its real usage (H.324M)?

The changes are trivial and only cosmetic.

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

Index: libpri.h
===================================================================
RCS file: /usr/cvsroot/libpri/libpri.h,v
retrieving revision 1.32.2.1
diff -u -r1.32.2.1 libpri.h
--- libpri.h 27 Oct 2004 14:45:07 -0000 1.32.2.1
+++ libpri.h 29 Mar 2005 17:21:30 -0000
@@ -181,7 +181,7 @@
#define PRI_LAYER_1_ALAW 0x23
#define PRI_LAYER_1_G721 0x24
#define PRI_LAYER_1_G722_G725 0x25
-#define PRI_LAYER_1_G7XX_384K 0x26
+#define PRI_LAYER_1_H324M 0x26
#define PRI_LAYER_1_NON_ITU_ADAPT 0x27
#define PRI_LAYER_1_V120_RATE_ADAPT 0x28
#define PRI_LAYER_1_X31_RATE_ADAPT 0x29
Index: q931.c
===================================================================
RCS file: /usr/cvsroot/libpri/q931.c,v
retrieving revision 1.87.2.1
diff -u -r1.87.2.1 q931.c
--- q931.c 5 Oct 2004 02:19:11 -0000 1.87.2.1
+++ q931.c 29 Mar 2005 17:21:31 -0000
@@ -574,7 +574,7 @@
{ PRI_LAYER_1_ALAW, "A-Law" },
{ PRI_LAYER_1_G721, "G.721 ADPCM" },
{ PRI_LAYER_1_G722_G725, "G.722/G.725 7kHz Audio" },
- { PRI_LAYER_1_G7XX_384K, "G.7xx 384k Video" },
+ { PRI_LAYER_1_H324M, "H324M UMTS Video Call" },
{ PRI_LAYER_1_NON_ITU_ADAPT, "Non-ITU Rate Adaption" },
{ PRI_LAYER_1_V120_RATE_ADAPT, "V.120 Rate Adaption" },
{ PRI_LAYER_1_X31_RATE_ADAPT, "X.31 Rate Adaption" },
s

Comments: By: Mark Spencer (markster) 2005-03-30 00:52:24.000-0600

Where do you find the term you're proposing?
By: Mark Spencer (markster) 2005-03-30 00:53:42.000-0600

Reminder sent to PCadach

Can you take a peek at this bug when you get a chance? You're much more familiar with this stuff than me!
By: klaus3000 (klaus3000) 2005-03-30 02:46:09.000-0600

I didn't find it anywhere, but IMHO it is more realistic. So, i digged into standards to find a correct term. Here is what I found:

- 3G TR 23.972 V3.0.0 (2000-03)
Technical Report 3rd Generation Partnership Project;
Technical Specification Group CN;
Circuit Switched Multimedia Telephony
(Release 1999):
In figure 5, they call it: UIL1P='H223&H245'

- 3G TS 26.112 V.1.0.0 (1999-04)
3rd Generation Partnership Project (3GPP);
Technical Specification Group (TSG) Codec Working Group;
Codec(s) for Circuit Switched Multimedia Telephony Service
Call Set-up Requirements:
In section 4.1 Use of BC and LLC Information Elements:
... User information layer 1 protocol (octet 5)
Bits
54321
00011 Recommendation G.711 A-law
00100 Recommendation G.721 32 kbit/s ADPCM and Recommendation I.460.
00101 Recommendations H.221 and H.242
00110 Recommendations H.223 and H.245

Thus, I guess the correct term would be: "H.223 and H.245".
According to the previous document, also the term for 0x25 can be changed to "H.221 and H.242".

These terms are from 3GPP documents. I don't know if they are also defined somewhere else in the ISND world.
By: klaus3000 (klaus3000) 2005-03-30 08:01:01.000-0600

I just saw that 3G TS 26.112 was withdrawn and transferred into TS 24.008, but there is no description in 24.008 about the "User information layer 1" signaling. :-(
By: Paul Cadach (pcadach) 2005-03-30 08:48:08.000-0600

IMHO unrestricted digital connections needs to have adaptive data flow recognition, because at least EuroISDN isn't specified/uses layer 1 capabilities IE, so usage of L1CAP IE is restricted to American-based ISDN.
By: klaus3000 (klaus3000) 2005-04-05 09:39:19

There are some more things which prevent using asterisk/zaptel with 3G-H.324M. Setting up a video call requires bearer information "Unrestricted digital information" and the proper "user information layer 1" (0x26).

But those lines of code prevent signaling the layer 1 info:
file: q931.c, function: static FUNC_SEND(transmit_bearer_capability)

if ((tc & PRI_TRANS_CAP_DIGITAL)&&(pri->switchtype == PRI_SWITCH_EUROISDN_E1)) {
/* Apparently EuroISDN switches don't seem to like user layer 2/3 */
return 4;
}

I'm in Austria using a PRI from Telekom Austria and removing the above lines works fine - I just bridged a UMTS Video Call via asterisk.

Can these lines be removed, or make them somehow configureable?
The statements mentions layer 2/3. But it also prevents layer 1 signaling. Thus, maybe we can solve the problem by using the following condition:

if ((tc & PRI_TRANS_CAP_DIGITAL)&&(pri->switchtype == PRI_SWITCH_EUROISDN_E1)&&(call->transmoderate == TRANS_MODE_PACKET)) {
By: Clod Patry (junky) 2005-05-25 20:35:03

Where are we at here?
Any improvements?
klaus3000 please attach all patches (diff -u format), like said in the bug guidelines.

Thanks.
By: klaus3000 (klaus3000) 2005-05-30 00:49:18

Sorry! I will be out of office this week. I will suply the patch next week.
By: klaus3000 (klaus3000) 2005-06-10 04:59:32

@PCadach: You say EuroISDN does not use layer 1 capabilities IE. But then, why do I say them here in Austria (=EuroIsdn)?
By: klaus3000 (klaus3000) 2005-06-10 09:42:52

I'm tried to bring my patch up2date - but Asterisk-CVS has changed meanwhile and I observe a new behaviour. In my setup, I receive a H.324M call on the PRI, and immediately start dialing on the same PRI to another mobile phone. IMO, asterisk should setup the 2nd call with the same bearer capabilities as the received one. This is not the case - please see the following log:

[Span 0 D-Channel 0]< Protocol Discriminator: Q.931 (8) len=42
[Span 0 D-Channel 0]< Call Ref: len= 2 (reference 420/0x1A4) (Originator)
[Span 0 D-Channel 0]< Message type: SETUP (5)
< [a1]
[Span 0 D-Channel 0]< Sending Complete (len= 1)
< [04 03 88 90 a6]
[Span 0 D-Channel 0]< Bearer Capability (len= 5) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)
[Span 0 D-Channel 0]< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
[Span 0 D-Channel 0]< Ext: 1 User information layer 1: G.7xx 384k Video (38)
< [18 03 a9 83 81]
[Span 0 D-Channel 0]< Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
[Span 0 D-Channel 0]< ChanSel: Reserved
[Span 0 D-Channel 0]< Ext: 1 Coding: 0 Number Specified Channel Type: 3
[Span 0 D-Channel 0]< Ext: 1 Channel: 1 ]
< [6c 0c 21 83 36 36 34 33 38 33 35 35 37 35]
[Span 0 D-Channel 0]< Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
[Span 0 D-Channel 0]< Presentation: Presentation allowed of network provided number (3) '6643835575' ]
< [70 04 81 31 30 36]
[Span 0 D-Channel 0]< Called Number (len= 6) [ Ext: 1 TON: Unknown Number Type (0) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '106' ]
< [7c 04 88 90 26 90]
[Span 0 D-Channel 0]< IE: Low-layer Compatibility (len = 6)
[Span 0 D-Channel 0]-- Making new call for cr 420
[Span 0 D-Channel 0]-- Processing Q.931 Call Setup
[Span 0 D-Channel 0]-- Processing IE 161 (cs0, Sending Complete)
[Span 0 D-Channel 0]-- Processing IE 4 (cs0, Bearer Capability)
[Span 0 D-Channel 0]-- Processing IE 24 (cs0, Channel Identification)
[Span 0 D-Channel 0]-- Processing IE 108 (cs0, Calling Party Number)
[Span 0 D-Channel 0]-- Processing IE 112 (cs0, Called Party Number)
[Span 0 D-Channel 0]-- Processing IE 124 (cs0, Low-layer Compatibility)
[Span 0 D-Channel 0]> Protocol Discriminator: Q.931 (8) len=10
[Span 0 D-Channel 0]> Call Ref: len= 2 (reference 420/0x1A4) (Terminator)
[Span 0 D-Channel 0]> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
[Span 0 D-Channel 0]> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
[Span 0 D-Channel 0]> ChanSel: Reserved
[Span 0 D-Channel 0]> Ext: 1 Coding: 0 Number Specified Channel Type: 3
[Span 0 D-Channel 0]> Ext: 1 Channel: 1 ]
-- Accepting call from '6643835575' to '106' on channel 0/1, span 1
-- Executing Dial("Zap/1-1", "Zap/g2/069911160036") in new stack
[Span 0 D-Channel 0]-- Making new call for cr 32770
-- Requested transfer capability: 0x08 - DIGITAL
[Span 0 D-Channel 0]> Protocol Discriminator: Q.931 (8) len=43
[Span 0 D-Channel 0]> Call Ref: len= 2 (reference 2/0x2) (Originator)
[Span 0 D-Channel 0]> Message type: SETUP (5)
> [04 02 88 90]
[Span 0 D-Channel 0]> Bearer Capability (len= 4) [ Ext: 1 Q.931 Std: 0 Info transfer capability: Unrestricted digital information (8)
[Span 0 D-Channel 0]> Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
[Span 0 D-Channel 0]> Ext: 0 User information layer 1: Unknown (24)
> [18 03 a9 83 82]
[Span 0 D-Channel 0]> Channel ID (len= 5) [ Ext: 1 IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
[Span 0 D-Channel 0]> ChanSel: Reserved
[Span 0 D-Channel 0]> Ext: 1 Coding: 0 Number Specified Channel Type: 3
[Span 0 D-Channel 0]> Ext: 1 Channel: 2 ]
> [6c 0c 21 81 36 36 34 33 38 33 35 35 37 35]
[Span 0 D-Channel 0]> Calling Number (len=14) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
[Span 0 D-Channel 0]> Presentation: Presentation permitted, user number passed network screening (1) '6643835575' ]
> [70 0d c1 30 36 39 39 31 31 31 36 30 30 33 36]
[Span 0 D-Channel 0]> Called Number (len=15) [ Ext: 1 TON: Subscriber Number (4) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '069911160036' ]
-- Called g2/069911160036
[Span 0 D-Channel 0]< Protocol Discriminator: Q.931 (8) len=10

The "User information layer 1" is not set correct. The bug is in chan_zap.c in function zt_call - the bearer is always set to -1 in case of digital calls. This is wrong. Is there a reason why the bearer is set to minus 1?

pri_sr_set_bearer(sr, p->digital ? PRI_TRANS_CAP_DIGITAL : ast->transfercapability,
(p->digital ? -1 :
((p->law == ZT_LAW_ALAW) ? PRI_LAYER_1_ALAW : PRI_LAYER_1_ULAW)));

I'm not that familiar with chan_zap, thus I ask how to copy the userlayer1 from the incoming call leg to the outgoing call leg.
By: Michael Jerris (mikej) 2005-07-20 23:47:24

matt- can you provide any insight into this one?
By: Michael Jerris (mikej) 2005-08-27 00:57:31

suspended due to no activity. If you would like to persue this, I suggest you try discussing with mattf (Cresl1n on irc) as he may have some insight. Feel free to re-open when you have something to report.