Subject: Cisco SG16: Local negotiation

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 19:46:54 -0500

Section:        7.1.8, second paragraph
Category:       Open Issue
Issue:          The draft text specifies that "Local is the capability of the local
MG and is typically sent from MG to MGC, and subsequently used as part of a
capability negotiation between two MGCs. Remote contains the parameters
describing the flows the remote MG will send/receive, is typically sent
from MGC to MG, and is the result of the capability negotiation". The
details of this negotiation as well as how it interacts with
LocalControlDescriptor and the network package defined in Annex E.9 is
unclear and needs further clarification. In particular, it is not clear:

*       that the specification adequately supports media streams with asymmetric
send and receive capabilities.
*       when negotiated media resources are reserved and they are available for use
It should be noted, that this particular issue has been the subject of much
debate on the IETF Megaco mailing list since the white contribution was
developed, and that at time of writing, no resolution had been found.
Discussion:             Given the fact, that solving this issue is at the heart of the
very purpose of the protocol, it is recommended that additional work to
develop a solution that satisfies the protocol requirements [1] in this
area is done.

v13 Status:             Modified. INADEQUATE. Above text has been removed and replaced
with extensive new text, incl. description of "Reserve" parameter in
Section 7.1.7 which provides for:
*       Return all alternatives supported and currently capable, and reserve
sufficient resources for any one of those.
*       Return one alternative, and reserve sufficient resources for that one.
In addition to these two options, a third option is proposed:
*       Return all alternatives supported and currently capable, but only reserve
sufficient resources for one alternative selected.
This will allow each endpoint to learn the capabilities of the other
without requiring that simultaneous support for each alternative. This may
be required when codecs (or other associated resources, e.g. external
resource reservation) can not be activated nearly instantaneously.
Also, how does this interwork with SIP, etc., i.e. other protocols that use
SDP ? For example, it does not seem to be legal to only support a subset of
the codecs listed in an "m=" line which is somewhat problematic.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------