Proposal for changes to CHAT protocols T.134 and T.140

Mark Duckworth Mark_Duckworth at
Fri Dec 19 09:41:52 EST 1997

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 when we have", but I didn't see any discussion on the
ITU-SG16 reflector.  I think we don't need in an H.323 environment,
for all the reasons Toby mentioned.

Mark Duckworth
duckworthm at

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



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


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}


More information about the sg16-avd mailing list