Fwd: AAP Comments during last call on H245v9

13 Dec 2002

      """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
This is to forward Mr. Anderson's announcement, which should have
been distributed through this reflector but looks not having gone
through. Please also note that you can find the mentioned Avaya's
comments in Word form at the following place:
http://standard.pictel.com/ftp/avc-site/0210_Gen/lc1_H245_Avaya.zip
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
...
Date: Fri, 13 Dec 2002 18:20:24 -0500
From: Terry L Anderson tlatla@verizon.net
X-Accept-Language: en-us, en
To: ITU SG-16 ITU-SG16@mailbag.cps.intel.com, tsg16q3@itu.int,tsgwp2@itu.int
Subject: AAP Comments during last call on H245v9
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at
out002.verizon.net from [138.89.124.43] at Fri, 13 Dec 2002 17:20:35
-0600
X-OriginalArrivalTime: 13 Dec 2002 23:15:45.0551 (UTC)
FILETIME=[908EF9F0:01C2A2FD]
Sender: owner-tsg16q3@itu.int
Reply-To: Terry L Anderson tlatla@verizon.net
X-Biglobe-VirusCheck: Sat, 14 Dec 2002 08:21:17 +0900
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@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:
   http://www.itu.int/itudoc/itu-t/aap/sg16aap/recaap/h245v9/lcc/index.html
For any that may not, I will summarize the changes below:

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
{
   encryptionAuthenticationAndIntegrity
EncryptionAuthenticationAndIntegrity,
   mediaType    CHOICE
   {
       nonStandard    NonStandardParameter,
       videoData    VideoCapability,
       audioData    AudioCapability,
       data    DataApplicationCapability,
       ...,
       redundancyEncoding    RedundancyEncoding,
       multiplePayloadStream    MultiplePayloadStream,
       fec        FECData
   },
...
}

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
specification.

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@verizon.net
Voice: +1 908.766.4463         Mobile: +1 908.342.9595
http://www.gti.net/tla

--
Best regards,
OKUBO Sakae
e-mail: okubo@giti.waseda.ac.jp
*******************************************************************
YRP Office
Global Information and Telecommunication Institute (GITI)
Waseda University
   YRP Ichibankan 312                           Tel: +81 468 47 5406
   3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken  Fax: +81 468 47 5413
   239-0847 Japan
GITI Headquarter
   29-7 Waseda University Bldg.                 Tel: +81 3 5286 3831
   1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo      Fax: +81 3 5286 3832
   169-0051 Japan
*******************************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@lists.intel.com

OKUBO Sakae

--

tags (0)

participants (1)