Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors

Tom-PT Taylor taylor at NORTELNETWORKS.COM
Thu Oct 25 16:10:05 EDT 2001


My apologies for the late delivery of this contribution.  For the moment I'm
locked out of the PictureTel server, so here's the text:

TITLE:	Implications Of Context Attribute Descriptors

___________________

Summary

This contribution is written to express concern over the proposed inclusion
of context attribute descriptors in H.248v2.  This innovation is seen upon
reflection as a major change in the H.248 protocol architecture, and
threatens the coherence of the protocol.
It is proposed as an alternative that we gain further experience by seeing
if it is possible to avoid the specification of new context properties while
solving the problems of MCU decomposition.  When we are satisfied that we
can enunciate clear criteria for adding properties to contexts as opposed to
terminations and further, that we are aware of all of the implications of
context properties for the protocol, we can proceed to update the protocol
accordingly.

1.   Introduction

H.248v1 defines three context properties: the Topology Descriptor, the
Emergency flag, and the Priority flag.  These additions were desirable, but
were made at a fairly late stage in the development of the protocol.  As a
result, the work was done in an ad hoc manner and  introduced irregularities
into the operation of the protocol.

Delayed Contribution 129 (Porto Seguro) proposed the introduction of a
context attributes descriptor to contain new context properties and to allow
addition of such properties in packages.  On the one hand, the present
contribution argues that this step, while desirable, does not go far enough
to assimilate context properties into the overall protocol structure.  On
the other hand, introduction of the ability to define context properties in
packages at this stage in the development of the protocol may cause
confusion and threaten protocol interoperability at a practical level.

2.   A Complete Implementation Of Context Properties

A complete implementation of context properties requires that the protocol
satisfy the following requirements:
·	there is a well-defined method for setting property values;
·	there is a well-defined method for modifying or clearing property
values;
·	there is a well-defined method for auditing values that have been
set on a context;
·	it would be highly desirable to have a method for determining what
context properties an MG supports.

Beyond these protocol matters come questions of semantics.  We must decide
whether the permissible properties of a context can depend on what media are
flowing in it, or on the properties of the terminations currently in the
context.  Since the active streams are a property of a context, we must
decide whether context properties can be associated with specific streams,
and if so, what syntax is used for the purpose.  There are undoubtedly other
issues which may come to light.

As a possibly controversial final step, it would seem desirable to
assimilate the existing context properties into the new syntactic structures
which would evolve.  With appropriate requirements for transitional
interworking, the existing syntax for topology and the emergency and
priority flags should be deprecated and counterparts should be defined
within the context attribute descriptor.

3.    Potential Confusion

The final point this contribution makes is that if we do not establish a
clear definition within the protocol specification of which properties
should be context attributes and which should be termination properties,
packages will inevitably be defined which solve the same problem with
differing mechanisms.  This will be unhelpful to achieving the
interoperability of different implementations.

4.   Conclusion and Proposal

Context attributes should be formalized only after careful study of all of
the issues.  In concrete terms, this contribution proposes either that the
generalization of context attributes should be left to H.248v3 or else that
H.248v2 be delayed beyond the proposed February 2002 target.

Tom Taylor
taylor at nortelnetworks.com
Ph. +1 613 736 0961 (ESN 396 1490)
 

_______________________________________________
Megaco mailing list
Megaco at ietf.org
http://www1.ietf.org/mailman/listinfo/megaco



More information about the sg16-avd mailing list