An example of AAC capability in H.245

Got mails continuously from everywhere throwing question to me about AAC audio in H.323.

So I arranged this post to example my previous posts: http://rg4.net/archives/1480.htmlhttp://rg4.net/archives/1126.htmlhttp://rg4.net/archives/1112.html

The pcap file for this example can be downloaded here: HUAWEI_TE600-vs-ZTE_T800.pcapnp

Here it is.

1. Basic knowledge: AAC LD descriptions in 14496-3

It operates at up to 48 kHz sampling rate and uses a frame length of 512 or 480 samples, compared to the 1024 or 960 samples used in standard MPEG-2/4 AAC to enable coding of general audio signals with an algorithmic delay not exceeding 20 ms. Also the size of the window used in the analysis and synthesis filterbank is reduced by a factor of 2.

And Table 1.3 — Audio Profiles definition of 14496-3 explained AAC format definition, AAC LC or AAC LD.

2. Basic knowledge: AAC capability in description of H.245 TCS

maxBitRate: 640
noncollapsing:
ProfileAndLevel: nonCollapsing item –> parameterIdentifier: standard = 0
AAC format: nonCollapsing item –> parameterIdentifier: standard = 1
AudioObjectType: nonCollapsing item –> parameterIdentifier: standard = 3
Config(Including sample rate and channel parameters): nonCollapsing item –> parameterIdentifier: standard = 4
MuxConfig: nonCollapsing item –> parameterIdentifier: standard = 8

3. H.245 TCS of HUAWEI TE60 and ZTE T800

HUAWEI TE60: 172.16.219.105
————————————————–
There are two AAC capabilities:
Capability 1:
collapsing:
collapsing item –> parameterIdentifier=2, parameterValue=2
collapsing item –> parameterIdentifier=5, parameterValue=1
noncollapsing:
ProfileAndLevel: 24
AAC format: logical (0)
AudioObjectType: 23

Capability 2:
collapsing:
collapsing item –> parameterIdentifier=2, parameterValue=2
collapsing item –> parameterIdentifier=5, parameterValue=1
noncollapsing:
ProfileAndLevel: 24
AudioObjectType: 23

ZTE T800: 172.16.219.103
————————————————–
There are four AAC capabilities:
Capability 1:
Capability 2:
Capability 3:
Capability 4:

4. Detail parameters in OLC command

TE60 OLC to T800:
————————————————–
maxBitRate: 1280
collapsing:
item 0 –> parameterIdentifier=2, parameterValue=2
item 1 –> parameterIdentifier=5, parameterValue=1
noncollapsing:
item 0 –> parameterIdentifier=0, value=25
item 1 –> parameterIdentifier=1, value=logical (0)
item 2 –> parameterIdentifier=3, value=23
item 3 –> parameterIdentifier=6, value=logical (0)
item 4 –> parameterIdentifier=8, octetString = 41 01 73 2a 00 11 00
item 5 –> parameterIdentifier=9, octetString = 00 00 00

Explanation:
AOT=23 –> AAC LD
MuxConfig = 41 01 73 2a 00 11 00 –> LATM format
Sample rate = (MuxConfig[2]&0x0f) = 0x73 & 0x0f = 3 = 48K Hz
Channel = (MuxConfig[3]&0xf0)>>4 = (0x2a & 0xf0) >> 4 = 0x20 >> 4 = 2 = Stereo

HUAWEI sent open logical channel with AAC LD stereo to ZTE.

T800 OLC to TE60:
————————————————–
maxBitRate: 1280
collapsing:
item 0 –> parameterIdentifier=2, parameterValue=2
item 1 –> parameterIdentifier=5, parameterValue=1
noncollapsing:
item 0 –> parameterIdentifier=0, value=25
item 1 –> parameterIdentifier=1, value=logical (0)
item 2 –> parameterIdentifier=3, value=23
item 3 –> parameterIdentifier=6, value=logical (0)
item 4 –> parameterIdentifier=8, octetString = 41 01 73 1a 00 11 00
item 5 –> parameterIdentifier=9, octetString = 00 00 00

Explanation:
AOT=23 –> AAC LD
MuxConfig = 41 01 73 1a 00 11 00 –> LATM format
Sample rate = (MuxConfig[2]&0x0f) = 0x73 & 0x0f = 3 = 48K Hz
Channel = (MuxConfig[3]&0xf0)>>4 = (0x1a & 0xf0) >> 4 = 0x10 >> 4 = 1 = Mono

ZTE sent open logical channel with AAC LD mono to HUAWEI.
Any furture questions?

About H.235 encryption algorithms

[20150822 Update] For the record, I didn’t find the right ITU-REC document when I wrote this post, and misguided by a claim of HUAWEI VP9650 which says it has AES256 supported, but when I sending out a call from VP9650, it showed a new DH group DH1536, so I made my conclusion arbitary, DH1536 means AES256, obviously, it’s a terrible mistake.

Planning to upgrade to H.235 encryption from AES128 to AES256, but don’t know where to start.

Did not find a short way to achieve that.

We wished to get some informations about AES256 by capturing some pcap files of some other Video Conference solution providers.

But did not find a device which actually supports H.235 + AES256 feature.

So we returned to the ITU-REC document for more details.  The right ITU-REC should be T-REC-H.235.6-201401-I!!PDF-E.pdf.

Some key steps of implementing H.235.

1. SETUP: Caller send a public key token DHSet of in H.225 SETUP, which includes:

1) halfkey: contains the random public key of one party

2)modsize: contains the DH-prime

3)generator: contains the DH-group

1. Public key token DHSet of in H.225 SETUP
1. Public key token DHSet of in H.225 SETUP

2. CONNECT: Callee generate a private key token by using the public key of caller, and send it back to the caller in its H.225 CONNECT, also including halfkey, modsize and generator.

2. Private key token of DHSet in H.225 CONNECT
2. Private key token of DHSet in H.225 CONNECT

3. TCS: Both caller and callee send their H.245 TCS with H.235 capabilities.

3. Sample H.245 TCS with H.235 capability
3. Sample H.245 TCS with H.235 capability

4. MasterSlave determination

5. Master generate a media key which will be used to encrypt/decrypt the media.

5a. OLC(from master): Open a logical channel with a specified H.235 media, and send to the slaver

H235Key in H.245 OLC
H235Key in H.245 OLC

5b. OLC ACK(from master): Reply the media key to the OLC requester(Slaver)

H235Key in H.245 OLC ACK
H235Key in H.245 OLC ACK

6. Some other H.245 request/indication messages, such as encryptionUpdateRequest, encryptionUpdate.

H.235 encryption related node definitions:

1. The tokenOID in H.225 SETUP and CONNECT message:
1a. H600’s tokenOID
Item0: 0.0.8.235.0.1.5
Item0: 0.0.8.235.0.1.5
Item2: 0.0.8.235.0.3.24
Item3: 0.0.8.235.0.3.43

1b. Huawei MCU’s tokenOID
ProductId: VP9650, versionId: V200R001C02B018SP07 Apr 28 2014 16:15:31+08
1. Public key token DHSet of in H.225 SETUP - HUAWEI-MCU-VP9650 3. Sample H.245 TCS with H.235 capability - HUAWEI-MCU-VP9650
Item0: 0.0.8.235.0.1.5
Item1: 0.0.8.235.0.3.44
Item2: 0.0.8.235.0.3.43
Item3: 0.0.8.235.0.3.24

1c. Huawei TE40’s tokenOID
ProductId: TEx0, versionId: Release 1.1.24.5
Item0: 0.0.8.235.0.3.43
Item1: 0.0.8.235.0.3.24

http://www.oid-info.com/get/0.0.8.235.0.1.5
http://www.oid-info.com/get/0.0.8.235.0.3.24
http://www.oid-info.com/get/0.0.8.235.0.3.43
http://www.oid-info.com/get/0.0.8.235.0.3.44

“T”      {itu-t (0) recommendation (0) h (8) 235 version (0) 2 5} {itu-t (0) recommendation (0) h (8) 235 version (0) 1 5} Used in Procedures I and IA as the baseline ClearToken for the message authentication and replay protection and optionally also for Diffie-Hellman key management as described in D.7.1.
“DH1024” {itu-t (0) recommendation (0) h (8) 235 version (0) 2 43} 1024-bit DH group
“DH1536” {itu-t (0) recommendation (0) h (8) 235 version (0) 3 44} 1536-bit DH group
From chapter D.11 List of object identifiers of <T-REC-H.235-200308-S!!PDF-E.pdf>, P.70-71

[20150822 Update]

Earlier when I wrote this post, I didn’t find the right ITU/T standard(T-REC-H.235.6-201401-I!!PDF-E.pdf).

The information I got was that HUAWEI VP9650 supports AES256, and when I tried to sending out a call on VP9650, I got  to know it supports following DH groups:

Item0: 0.0.8.235.0.1.5
Item1: 0.0.8.235.0.3.44
Item2: 0.0.8.235.0.3.43
Item3: 0.0.8.235.0.3.24

So I made my conclusion arbitarty that DH1536 is our goal: AES256, but turned out I was terribly wrong. (I don’t know why VP9650 sending out max to DH1536 while it claims having AES 256 supported)

DH group - DH1536

2. Media encryption algorithm definitions on H.245 TCS, OLC, OLC ACK,etc:

The most frequently used/seem types are:
2a. AES 128 bit CBC: 2.16.840.1.101.3.4.1.2
2b. DES 56 bit CBC(Voice encryption using DES in CBC mode and 512-bit DH-group): 1.3.14.3.2.7

2.16.840.1.101.3.4.1.1 – id-aes128-ECB
2.16.840.1.101.3.4.1.2 – id-aes128-CBC
2.16.840.1.101.3.4.1.3 – id-aes128-OFB
2.16.840.1.101.3.4.1.4 – id-aes128-CFB
2.16.840.1.101.3.4.1.6 – id-aes128-GCM
2.16.840.1.101.3.4.1.7 – id-aes-CCM
2.16.840.1.101.3.4.1.21 – id-aes192-ECB
2.16.840.1.101.3.4.1.22 – id-aes192-CBC
2.16.840.1.101.3.4.1.23 – id-aes192-OFB
2.16.840.1.101.3.4.1.24 – id-aes192-CFB
2.16.840.1.101.3.4.1.26 – id-aes192-GCM
2.16.840.1.101.3.4.1.27 – id-aes192-CCM
2.16.840.1.101.3.4.1.41 – id-aes256-ECB
2.16.840.1.101.3.4.1.42 – id-aes256-CBC
2.16.840.1.101.3.4.1.43 – id-aes256-OFB
2.16.840.1.101.3.4.1.44 – id-aes256-CFB
2.16.840.1.101.3.4.1.46 – id-aes256-GCM
2.16.840.1.101.3.4.1.47 – id-aes256-CCM

Source : http://www.alvestrand.no/objectid/2.16.840.1.101.3.4.1.html

About DH key exchange:
1. http://baike.baidu.com/view/551692.htm
2. http://www.rosoo.net/a/201507/17349.html
3. Diffie-Hellman, http://www.cryptopp.com/wiki/Diffie-Hellman
4. rfc3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE), https://www.ietf.org/rfc/rfc3526.txt
5. Huawei VP9650(which claims having AES256 supported): http://e.huawei.com/cn/related-page/products/enterprise-network/telepresence-video-conferencing/infrastructure/vp9600/TPVC_MCU_VP9600

AAC音频能力协商问题

视频会议中,通常音频能力的比较是比较简单的,通常是只是比较一下格式就行了。但是aac系列音频就是一个例外。它有一个复杂的能力表示方式,在交互的时候也不会明确的指明确切的采样率,通道数,而是像264格式一样,给出的是能力的level上限,需要我们去匹配比较。这里简单的介绍一下aac能力,和工作中碰到的问题的总结。 Continue reading “AAC音频能力协商问题”