Fwd: Rapporteur meeting in February 2003

OKUBO Sakae okubo at MXZ.MESH.NE.JP
Sun Dec 15 23:12:22 EST 2002

A new version of H.245 (version 9) was consented at the October Study
Group 16 meeting in Geneva. One official comment was submitted by Avaya
against H.245 V9 during the last call period.  According to ITU
procedures we need to resolve this issue and then have an "additional
review" (a second last call) before it can be considered approved.

The issue raised by Avaya concerned the use of encrypted media channels
for MoIP and included specific suggestions for additional ASN.1 items
and description in H.245 to support this.  The changes are not extensive.

 From the comment:

> Introduction
> As it now stands, version 9 of H.245 does not permit the specification
> of encryption of media channels using the new Modem-over-IP (MoIP)
> data types RedundancyEncoding, MultiplePayloadStream, and FECdata.
> Inasmuch as these types of channels can be subject to eavesdropping,
> and can carry the same information as other audio or data channels, it
> seems appropriate to provide the means to encrypt them.

The issue and suggested changes have been discussed by several of
parties involved with the MoIP work (Paul Jones, Cisco, Martin Euchner
and Sasha Ruditsky along with Bob Gilman from Avaya) and they support
the suggested changes.

As rapporteur, I am proposing that adopt the suggested changes and
submit the revised version for the Additional Review at the next review
period (I believe in January) unless there are objections from others.
Any discussion should be sent to the ITU-SG16 at mailbag.cps.intel.com
reflector.  I am including the tsg16q3 and tsg16wp2 lists in this
message so that all interested parties are aware of the process.  If I
do not see any objections by 17:00 UT a week from today, Dec 20, we will
proceed with the additional review of the text as revised.

For those with TIES logins, the Avaya comment document can be accessed at:

For any that may not, I will summarize the changes below:
1. Annex A (page 47)
Add the new data types RedundancyEncoding, MultiplePayloadStream, and
FECdata to H235Media.  This will permit the specification of encryption
for these data types in the same way it is specified for other media types.

As follows:
H235Media        ::=SEQUENCE
   mediaType    CHOICE
       nonStandard    NonStandardParameter,
       videoData    VideoCapability,          audioData    AudioCapability,
       data    DataApplicationCapability,
       redundancyEncoding    RedundancyEncoding,
       multiplePayloadStream    MultiplePayloadStream,
       fec        FECData

2. Annex B, Section B.3.1 (page 108)
Add a description of the use of H235Media in DataType to indicate that
the channel is to be encrypted.

As follows:
A dataType of h235Media is used to specify encryption of the logical
channel; the actual
data type is indicted within H235Media, along with the encryption
3. Annex B, Section B.3.1 (page 111)
Add a description of the use of redundancyEncoding for media encryption
when the dataType specifies multiple payload types within the channel.

As follows:
When encryption is specified for a channel carrying multiple payloads,
redundancy encoding using RFC 2198 is used to preserve the actual
payload types transmitted.  The Encapsulating payload type is set to the
value specified in the syncFlag field of the encryptionSync element.

Terry L Anderson                     tlatla at verizon.net
Voice: +1 908.766.4463          Mobile: +1 908.342.9595

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at lists.intel.com

More information about the sg16-avd mailing list