An issue when collaborating with HUAWEI VP9650 with H.460

Sympton:
——————————————-
TE40 caller : 202.102.40.211, E.164: 02510000
TE40 caller : 192.168.0.109,  E.164: 02510000
H600 callee : 192.168.0.105,  E.164: 654320
VP9650: 202.102.40.219

Pcap file was captured on H600 side.

All exchanged signaling commands between H600 and VP9650:
->SCI
<-SCR,facility
->setup
<-ARQ
->ACF
<-alerting,connect
->facility
->TCS
…Twenty seconds later…
–>ReleaseComplete, DRQ

(h225 or h245) and ((ip.dst eq 192.168.0.105 and ip.src eq 202.102.40.219) or (ip.src eq 192.168.0.105 and ip.dst eq 202.102.40.219))

Sympton:
H600 after received TCS from VP9650 did not response with any further commands, and led to a ReleaseComplete of VP9650.

Trouble shooting:
Checked the facility commands of VP9650, found that its Q.931 crv value was 0, but with a facility reason of 5(startH245)

HUAWEI format of facility msg of H460 startH245
But we did not support that kind of rules.
Checked the ITU/T documents, found out it’s a standard procedure.

Solution:
You know what should be done.

Does ZTE T800 and HUAWEI TEx0 support T.140?

Both ZTE T800 and HUAWEI TEx0 claim to have T.140 supported, but when I digging into these entities by running some tests between T800, TE40 and TE60, my current status is I’m not persuaded.

Maybe only because I don’t know how to configure them to make T.140 enabled.

Here is some T.140 related information, and my steps to analysis to the protocols of HUAWEI TEx0 and ZTE T800.

A screen shot of HUAWEI TEx0’s administration manual about T.140.

HUAWEI-TEx0-AdministraterManualSource:

http://support.huawei.com/ehedex/pages/DOC1000063904NZD1231E/01/DOC1000063904NZD1231E/01/resources/webhlp/te_webhlp_00005.html#te_webhlp_00005__tb5

1. T.140 related standard documents

1)T-REC-H.323-200002-S!AnnG!PDF-E.pdf

2)T-REC-H.224-200501-I!!PDF-E.pdf

3)T-REC-T.140-199802-I!!PDF-E.pdf

5)T-REC-T.140-200002-I!Add1!PDF-E.pdf

6)RFC4103 – RTP Payload for Text Conversation.pdf

2. Major descriptions of implementing T.140

T.140 related descriptions in T-REC-H.323-200002-S!AnnG!PDF-E.

1) H.245 TCS for T.140

In the capabilities exchange, when using a reliable channel, specify:

DataApplicationCapability.application = t140
DataProtocolCapability = tcp

In the capabilities exchange, when using an unreliable channel, specify:

DataApplicationCapability.application = t140
DataProtocolCapability = udp

2) H.245 Open Logical Channel

In the Open Logical Channel procedure, specify:

OpenLogicalChannel.forwardLogicalChannelParameters = dataType
DataType = data

And select a reliable or unreliable channel for the transfer of T.140 data by specifying the DataApplicationCapability and the DataProtocolCapability as above.

According to the description in T-REC-H.224-200501-I!!PDF-E, there should be only one H.221 channel, we can still send multiple protocols, like FECC, T.120 and T.140, in one single channel, this type of channel has a name: H.221 MLP data channel.

3) Packetization of T.140 data

Reliable TCP mode: skipped because don’t find any newlly established TCP connections.

UnReliable mode: I do find an H.224 capability in both of these entities, since there is no OLC requests other than Audio, Video, and H.224 data.

Let’s suppose they are re-using the H.221 MLP data channel for both FECC and T.140 transmission.

4) H.224 protocol octet structure

H.224 protocol octet structure

5) H.224 -Standard Client ID Table

H.224 -Standard Client ID Table

3. H.224 data packets sending between TE60 and T800

I managed to extract the H.224 data packets from the PCAP file.

And they are like these:

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff

Explain the packet by the standard document’s description:

Buffer

Description

Class

7e 7e 7e Flag Flag
00 Upper DLCI Q.922 Address Header
86 Lower DLCI, 0x6 or 0x7 + EA
C0 UI Mode Q.922 Control Octet(s)
00 Upper Destination Terminal address Data Link Header
00 Lower Destination Terminal address
00 Upper Source Terminal address
00 Upper Source Terminal address
00 Standard Client ID
03 ES + BS
40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff Client data octet Client data octet

Comparing the extracted Standard Client ID with H.224 Standard Client ID Table, we can make out a conclusion for this packet: it’s a CME packet, not a T.140 packet.

Now, since we know how to identify the data type of H.224 data packets, we can judge all the H.224 data packet between TE60 and T800.

TE60 –> T800

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff

7e 7e 7e 00 86 c0 00 00 00 00 00 03 80 00 80 81 12 c8 7e 7e 7e ff

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 fb c0 c8 a8 bf 3f 3f 7f ff

7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 fb c0 c8 a8 bf 3f 3f 7f ff

T800 –> TE60

7e 7e 7e 00 8e c0 00 00 00 00 00 03 80 00 40 81 f7 00 00 5a 00 00 4c 50 3f 3f 3f 3f 3f 3f 16

7e 7e 7e 00 8e c0 00 00 00 00 00 03 40 00 81 68 a8 0f 92 07 cb 00 28 80 3d f1 ef cf cf cf cf cf cd

7e 7e 7e 00 8e c0 00 00 00 00 80 03 a0 08 0e 45 7e 7e 7e 7e 7e 7e

 

Among the listed packets, there’s only one packet not a CME packet, which Standard Client ID is 0x80.

According to T-REC-H.323-200002-S!AnnG!PDF-E.pdf, we should reverse the octet value by bit to get the real value, and the reversed real value would be 0x01, after check with the Standard Client ID, we know it’s a FECC packet, still not T.140.

 

God, I lost. Anyone can tell me how to get T.140 work on ZTE T800 and HUAWEI TE60?

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

An issue about HUAWEI TEx0 H.264 video capability calculating

Encounter a H.264 video capability issue while conferencing with HUAWEI TEx0 MT.
Both MTs(H800 and TEx0) have 1080P 60 fps H.264 video capability, but HUAWEI MT will send an OLC request with 1080P 30 fps when starting open the logical channel, while conferencing with Cisco MTs, this issue doesn’t happen.

H800 H.264 capabilityH.245 TCS from H800HUAWEI TEx0 H.264 capabilityH.245 TCS from TEx0OLC from HUAWEI TEx0H.245 OLC from HUAWEI TEx0

Checked the H.245 TCS of H800, found there was no CustomMaxFS value in it (only CustomMaxMBPS and CustomMaxBRandCPB),

  • H800 TCS: Level: 85, CustomMaxMBPS: 972 –> 1080P 60 fps
  • TEx0 TCS: Level: 71, CustomMaxMBPS: 983, CustomMaxFS: 32 –> 1080P 60 fps
  • OLC from TEx0: Level: 71, CustomMaxMBPS: 212, CustomMaxFS: 32 –> 1080P 30 fps

Conclusion:

HUAWEI TEx0 will use Level parameter only if there’s no CustomMaxFS.
In this case, we presented only H.264 Level, and CustomMaxMBPS, TEx0 will just ignore the CustomMaxMBPS parameter, that is to say it considered only the H.264 Level parameter, and the Level default capability is right 1080P 30 fps.

Solution:

Add CustomMaxFS parameter to H800’s TCS, everything works just fine.