An issue when collaborating with HUAWEI VP9650 with H.460

TE40 caller :, E.164: 02510000
TE40 caller :,  E.164: 02510000
H600 callee :,  E.164: 654320

Pcap file was captured on H600 side.

All exchanged signaling commands between H600 and VP9650:
…Twenty seconds later…
–>ReleaseComplete, DRQ

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

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.

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.


1. T.140 related standard documents





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:




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?

A common bug of HD3 series terminals

An issue of call establishment delay when conferencing with Polycom MCU RMX2000

The situation was

1. Meeting entities
1). Polycom MCU: Polycom RMX 2000, version ID: 8.3.0
2). Kedacom HD3 H600 SP4

2. Call scenario
HD3 joined a multi-point conference with RMX2000.
1) All the H.225 and H.245 processes were OK.
2) OLC request from both side returned with ACK.
3) The audio packets could be captured right after the OLC ACK.
4) The video packets from HD3 sent right after got the OLC ACK from the MCU.
5) HD3 could not receive any video packets from the MCU.
6) HD3 waiting for a terminalYouAreSeeing conferenceIndication from the MCU to switch the status to InConf…
7) 20 seconds later we finally got the terminalYouAreSeeing indication. Along with the terminalYouAreSeeing, we got the video.

Seems the MCU was waiting for a command to switch its status to an established-mode.
But we just don’t know what it is, even after tested lot’s of MTs from Polycom, Tendburg, HUAWEI, ZTE, which all of them just working fine.

What we got is only that it must be a HD3’s bug.

After a long long times comparison with the pcap file, the only difference was the H.224 channel.
We did not open the H.224(FECC) channel together with the audio, video and H.239 channel, this caused the RMX2000 to wait 20 seconds to send the terminalYouAreSeeing indication.
It’s a yet-another-long-existing bug, we survived a long time, but today we finally ran into the consequence.

PCAP file: a-common-bug-of-hd3-series-terminals.pcap

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

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

1c. Huawei TE40’s tokenOID
ProductId: TEx0, versionId: Release

“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:


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.
2b. DES 56 bit CBC(Voice encryption using DES in CBC mode and 512-bit DH-group):

2.16.840. – id-aes128-ECB
2.16.840. – id-aes128-CBC
2.16.840. – id-aes128-OFB
2.16.840. – id-aes128-CFB
2.16.840. – id-aes128-GCM
2.16.840. – id-aes-CCM
2.16.840. – id-aes192-ECB
2.16.840. – id-aes192-CBC
2.16.840. – id-aes192-OFB
2.16.840. – id-aes192-CFB
2.16.840. – id-aes192-GCM
2.16.840. – id-aes192-CCM
2.16.840. – id-aes256-ECB
2.16.840. – id-aes256-CBC
2.16.840. – id-aes256-OFB
2.16.840. – id-aes256-CFB
2.16.840. – id-aes256-GCM
2.16.840. – id-aes256-CCM

Source :

About DH key exchange:
3. Diffie-Hellman,
4. rfc3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),
5. Huawei VP9650(which claims having AES256 supported):

OLC process rule of Avaya MCU 5110

1. Both H800 and Avaya MCU 5110 support up to H.264 1080P video.
2. Avaya MCU supports 720P video when conferencing with Avaya endpoints(XT1000)
3. H800 Called by(Or calling to) Avaya(RADVision) MCU 5110, the opened video channel can only max to 4CIF.
Continue reading “OLC process rule of Avaya MCU 5110”

Patent: Data transmission method for video conferencing and video conferencing systems

I submitted a patent paper, Data transmission method for video conferencing and video conferencing systems, to my parent agent early at Sep, 2014.

It is a patent with H.460 involved, origin from the V5.0 platform system.

But did not get any feedback until the Chinese New Year of 2015.

And after a few days of discussion and revision, finally got it finished. So, yes, the efficiency of patent agent could also be great once they decided to start.

Here is the Patent Application No. 201510096936.3

About alias: H.323 ID

Days earlier, ran into an issue which was H.323 ID related when conferencing with CISCO and LIFESIZE endpoints.

Normally we got used to set the H.323 ID with any charactors we want. But seems some manufacturors like CISCO and
LIFESIZE don’t think it appropriate, because they are adapting some rules in the naming of H.323 ID.

Here was the issue:
When trying to start a call, if the peer endpoint’s H.323 ID is named with {DIGIT}.{DIGIT}, such as 123.456, both CISCO’s and LIFESIZE’ endpoints will not to send ARQ to the registered GK to start the call.

The first thought was DOT is not allowed in H.323 ID to CISCO and LIFESIZE, then made more tries with different combinations, turned out an H.323 ID with {ALPHA}.{DIGIT} just worked fine.

Then turned to the ITU/T H.323 series of documents, trying to find a detail naming rule for H.323 ID, but got no luck but a simple description:

The H.323 ID consists of a string of ISO/IEC 10646 characters as defined in Rec. ITU-T H.225.0. It
may be a user name, conference name, e-mail name, or other identifier.

To my understanding of this phrase, DOT should not be an invalid character, but why this happened???

BTW: Tested HUAWEI(TEx0) and POLYCOM(PVX8.0.2) endpoints,  a H.323 ID named with {DIGIT}.{DIGIT} rule is allowed to them.

[H.323] TCS negotiation rule of HUAWEI

Encountered a capability negotiation issue when conferencing with a HUAWEI terminal.

It happened in a dual stream(H.239) capability negotiation.

1. According to the H.245 TCS, both terminal have 1080P 60 fps capability.
2. The band width setting was extreme low.
3. HUAWEI sent a OLC request with 4CIF H.264 video.

Continue reading “[H.323] TCS negotiation rule of HUAWEI”

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


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.


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


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