I'm looking for comments on the enclosed proposal, which I would like to see incorporated into the T.134 and T.140 recommendations before decision in Geneva next month.
Also, a couple months ago Toby Nixon raised the issue "why do we need H.chat when we have T.chat?", but I didn't see any discussion on the ITU-SG16 reflector. I think we don't need H.chat in an H.323 environment, for all the reasons Toby mentioned.
Mark Duckworth duckworthm@pictel.com
1. Introduction
This document proposes specific modifications to T.134 and T.140. The intent is to clarify the usage of T.140 in the T.134 multipoint environment and to fix the ASN.1.
2. Proposed changes to T.140
There is no need to have the light and enhanced profiles in a multipoint session. Several enhanced commands are specifically not allowed in multipoint, and the other commands can be safely ignored, so the proposal is to eliminate the distinction between light and enhanced.
The entire text of section 9, profile and multipoint considerations, should be replaced with the following:
In point-to-point sessions, communication should be limited to what is supported in the highest common profile.
In multipoint sessions it is not desired that a single node with a low profile can dictate the level of the communication used.
Therefore the following principles shall be adopted:
In a point-to-point session, the highest common profile shall be used. ENHANCED is regarded higher than LIGHT.
In a multipoint session, there is no distinction between enhanced and light profiles. A multipoint terminal may send commands from the ENHANCED set of protocol elements. A multipoint terminal shall be capable of ignoring protocol elements it does not support.
The following protocol elements shall be sent only to a specific node and thus not used in multipoint sessions:
"Unsupported request", "Check status", "Status report", "Resynchronize", "Indicate ENHANCED profile".
All other protocol elements shall be distributed to all participants in the session.
A multipoint session includes any session in a multipoint capable environment (such as T.134), even if only two terminals are involved at a given time.
3. Proposed changes to T.134
3.1 CHAT Concepts
The description of the diagram in section 5.1, CHAT Concepts, is misleading. The second bullet item, which states "CHATE C acts as an MCU, distributing the CHATPDUs among the CHATEs" should be replaced with the following: "The MCS provider in the node with CHATE C acts as an MCU, distributing the CHATPDUs among the CHATEs".
3.2 Conducted mode operation
The behaviour of a T.134 APE should be restricted in a conducted mode conference. The following text should be added at the end of section 7, Use of GCC:
When a session is in conducted mode, a CHATE may be restricted from sending data, depending on the GCC conducted-mode permission mechanism. If the node is given GCC conducted-mode permission, then a CHATE may send any type of ChatPDU. If the node is not given GCC conducted-mode permission, then a CHATE shall not send any type of ChatPDU.
3.3 Non-standard extensions
Text should be added at the end of section 8.3, CHATPDU Formats:
A ChatPDU can contain non standard information using the chatNonStandardPDU choice. This uses the H221NonStandardIdentifier to allow an implementation to use non-standard information without conflicting with any other implementation's non-standard information. If a terminal receives a ChatNonStandardPDU it doesn't understand, it shall ignore the PDU.
3.4 ASN.1
Unused types are removed, and a non-standard PDU choice is added to allow proprietary extensions. The entire section 9.1, ASN.1 Definition, should be replaced with the following:
--|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- Begin CHAT Definitions -- -- The following base mode ASN.1 definitions are encoded using the BASIC -- ALIGNED variant of the Packed Encoding Rules of ITU-T Recommendation -- X.691. -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CHAT-PROTOCOL DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
-- NOTE: =============================================================== -- NOTE: All abstract types defined shall be exported -- NOTE: ===============================================================
-- H221NonStandardIdentifer -- Used to specify non-standard objects using H.221 numbering. -- The first four octets shall designate country code and -- manufacturer code, assigned as specified in -- Annex A/H.221 for NS-cap and NS-comm. H221NonStandardIdentifier ::= OCTET STRING (SIZE (4..255))
Key ::= CHOICE -- Identifier of a standard or non-standard object { object OBJECT IDENTIFIER, h221NonStandard H221NonStandardIdentifier }
-- NonStandardParameter -- Used to specify non-standard parameters. This includes a -- data field which may be used to fill in parameter values -- of the type indicated by the NonStandardIdentifier NonStandardParameter ::= SEQUENCE { key Key, value OCTET STRING OPTIONAL }
ChatString ::= GeneralString (SIZE (0..255)) -- Chat Protocol String
--|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- Begin CHATPDU Definitions -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| ChatentryPDU ::= SEQUENCE { chatString ChatString, ... }
ChatNonStandardPDU ::= SEQUENCE { nonStandardTransaction NonStandardParameter, ... }
ChatPDU ::= CHOICE { chatentryPDU ChatentryPDU, chatNonStandardPDU ChatNonStandardPDU, ... }
--|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| -- -- End CHAT Definitions -- --|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| --||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
END
3.5 Object Identifier
Typographic errors in the object identifier should be fixed, so it conforms to Recommendation X.680.
The object identifier in Annex C is given as:
{itu recommendation T.134 version 1}
This should be replaced with:
{itu-t recommendation t 134 version(0) 1}
END