Subject: [Megaco] Dublin Meeting Minutes

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 14 Nov 2001 16:17:00 -0500

I have excerpted the Dublin meeting minutes relating to Megaco/H.248 below.
I will place all documents mentioned in the Megaco FTP site.

3	Q.3/16 Infrastructure and Interoperability for Multimedia over
Packet Networks
3.1	Coordination
...
3.1.2	Discussion of Liaisons
3.1.2.1	AVD-2105: Rec. H.248 package definitions [ATM Forum]
This liaison was noted. There is related work in Megaco referenced in the
ATM Forum spec. This appears to be a profile describing the use of H.248 for
a particular application. The supplement will be updated to reflect this
liaison. 

...
3.2	Material for Implementers Guides
3.2.1	H.248
3.2.1.1	AVD-2126: H.248 Annex K Implementors' Guide Clarification [LM
Ericsson]
The proposal was accepted as written. The proposed text will be added to the
implementers guide.

3.2.1.2	AVD-2127: Proposed Implementors' Guide Additions [LM Ericsson]
·	Error code 410 for invalid root termination - add to IG.
·	Syntax specification to add OCTET STRING - add to IG.
·	Annex C properties: Comment that we probably need better
clarification about bit positioning within an octet (e.g., is a 3-bit item
placed in the low-order or high-order bits of the octet) - annex C already
describes bit ordering within an octet. Also need clarification about cases
where bits take more than 1 octet - but ASN.1 already handles byte ordering.
Comment that we also need clarification about value for Boolean - but
examples in H.248 are not actually coded as ASN.1 booleans. Add text as
proposed.
·	General ATM properties - add text as proposed.

Note that we should define which Annex C properties would appear in
local/remote descriptors, and which would appear in LocalControl. Note that
there was a contribution to the Tasmania meeting addressing this matter.

3.2.1.3	AVD-2128: H.248 Implementors Guide Draft [Editor]

·	Section 6.92 - text OK as shown. Eventually, we could benefit from
defining service change procedures more precisely.
·	Section 6.94 - to illustrate that these are examples, add references
to additional Recommendations (e.g., Q.764, Q.1902.4)
·	Comment that more definition is needed to define signal list.
Suggestion that interested folks meet to draft text to clarify. (Christian,
Tom, Terry)
·	Section 6.99 - comment that error could be more explicit (that
topology descriptor is not supported), but counter arguments that error
processing would identify that the error is with the topology descriptor.
Error descriptor can include text to identify unsupported descriptor (see
Annex L), so desired operation is already provided. Text will include a note
that the error descriptor should contain additional information.
·	Section 6.102 - difficult to precisely describe what a "signal" is
in H.248. Consider adding "as well as bearer-related signaling" to new text
under 7.1.11.

TD-28 is the Implementers Guide updated with material accepted at this
meeting.

3.2.1.4	AVD-2132: Proposed requirements for the H.248 Media Gateway resource
congestion handling package [BT]
Comments from the delegates included:
·	MG has no real concept of a "call". Equivalent would be context
creation and subsequent Adds. Throttling context creation is only way to
allow MG to control call rates.
·	New context does not necessarily mean that a new context indicates a
new call. Only MGC has true knowledge of "call".
·	We should only specify how MG supports E.412 & ACC.
·	Good argument for leaky-bucket, but problem needs to be solves in
MGC, not MG. Would have to know offered rate in this case.
·	Congestion control needs to account for ETS.
·	Need to recognize that MG can be many flavors, to support many
applications. Need to identify the application for which this is needed.
·	Package scope should indicate where this package would be used.

It was decided not to modify Annex M.2 as proposed in this contribution.
However, delegates feel that a new package is entirely reasonable to define
the operation described in this contribution. The scope of this new package
should define the application for its use. AVD-2132 will serve as the basis
for a new Annex M.rch.

3.2.1.5	AVD-2155: H.248 with Implementers Guide Incorporated [Editor]
AVD-2155 is the first draft of H.248 with the Implementers Guide
incorporated into the text. This document includes material from the
Implementers Guide that was approved at the Porto Seguro meeting. Note that
this document has no official status at this time.

3.2.1.6	AVD-2164: Corrections to H.248 Annex F [Editor]
The modifications requested in this contribution have already been included
in the Implementers Guide approved at the Porto Seguro meeting. However, one
minor change was noted (V.30V4 to V30V4). This minor modification will be
added to the Implementers Guide.

3.3	Work to Progress for Consent
3.3.2	H.248 Annex M.1
3.3.2.1	AVD-2119: H.248 Annex M.1, Advanced Audio Server Packages [Editor]
Delegates should note that work on Annex M.1 is nearing completion, so
immediate attention is suggested. 

Delegates had no specific comments on AVD-2119, although a concern was
raised regarding localization. Additional comments should be directed to the
email lists, and contributions will be welcomed at the next meeting (the
SG16 meeting in February). 

3.3.2.2	AVD-2171: H.248 Annex M.1: speaking digits according to national
requirements [France Telecom]
Comments from delegates:
1st issue: need to search for standard that allows additional selector
(variant). Could use 2 selectors (language + region), or find some standard.
SG2 (numbering, human factors) might have some ideas.
2nd issue: remove cadence subtype
2nd issue: could remove telno subtype, use capabilities to speak integers

To address the 2nd issue, there will be a separate telno type. Selectors
will handle localization. If explicit control is desired, one should not
embed a variable within a provisioned segment because the number of
subsegments are not known in advance.

TD-38 is a liaison to SG2 requesting their help in working localization
issues in Annex M.1.

3.3.2.3	AVD-2172: Open Issues In Draft H.248 Annex M.1 [Editor]
Issue 1: See AVD-2171.
Issue 2: There seems to be a real need to allow per-segment selector (e.g.,
to play an announcement in both English and Spanish). This means that the
syntax in section 2.2 will be pursued. Annex M.1 editor will also revise the
syntax for provisioned segments to be consistent.

3.3.3	H.248 V2

During the presentation of AVD-2155, discussion progressed to what should go
in V2. Comments from the attendees included:

·	Is it possible to publish an H.248-2001, not a version 2 (i.e., not
bumping the version number in the protocol syntax)? Recall that ITU does not
really have a version 2, because version 2 replaces version 1. Rapporteur
will check with TSB on this possibility.
·	There was an argument that the version number should be changed so
that implementers know that they are working with the corrected version. The
IETF would use a sub-version number (e.g., 1.1). The argument was repeated
that sub-version numbers don't matter because the protocol has changed
(whether a sub-version number or a new number, it's still a new identifier).
·	A maintenance release would work well with the IETF process.
·	Other orgs have indicated that they need V2 features (e.g., 3GPP and
SG11), so there is some argument for approving a V2 with at least some new
features.
·	Could look at a feature-by-feature addition for V2, rather than
everything that has already been accepted. Need to look at need + impact.
New features may negatively impact stability.

The issue of V2 content was addressed again on 1 November, with the
following comments:
·	Want more time to get bugs out before adding new features. Would
favor a maintenance release. V2 in October would be good timing.
·	Several features help in operation (e.g., service change features).
These enhance quality of network and improve stability. These are issues
carriers are worried about.
·	No argument that these features may be good or needed, but are they
needed in February? Can we wait until October? There is an April deadline in
3GPP.
·	Can we hold a conference call among ITU and IETF folks to try to
reach a consensus?

Since approval of V1, a number of proposals have been accepted by the
experts participating in Q.3. In some cases, recent proposals have been
accepted in principal with the understanding that minor corrections will be
made. All the functionality accepted since V1 would go into a V2 targeted
for February 2002. When the time comes to make a decision about approving
V2, features deemed unstable or destabilizing could be held back for a later
version.

3.3.3.1	AVD-2115: Topology enhancement in H.248 Version 2 [RadVision]
Comments from the delegates:
·	Possible to use existing means.
·	No, topology descriptor was added to create connection topologies
that aren't possible with stream descriptor. New package might be possible,
but this proposal more elegant.
·	Need to define error behavior for when "A topology descriptor SHALL
NOT include a combination of associations between two terminations (Ti,Tj)
with and without the optional StreamID field, to avoid undefined behavior."

The proposal is accepted for V2 as modified by TD-42. TD-42 shows the
updated proposal including text to describe explicit error behavior to
address the 3rd bullet above.

The proposed addition for the implementers guide is also accepted.

3.3.3.2	AVD-2120: Auditing Context Properties [LM Ericsson]
Changes to ABNF are to the previously proposed additions to V2, so are
backward compatible with V1.

Comments from the delegates:
·	Is the table needed? This is not quite the same as auditing a
termination because of the messages available. Table appears to be more
descriptive and concise. Leave table in.
·	Table appears to reflect a deviation from some principles of the
protocol by returning a union in the case of audit ALL (instead of returning
a separate response for each context). 
 
AVD-2120 will be accepted in principle, with the understanding that its
features and syntax can be modified through future contributions.

3.3.3.3	AVD-2122: H.248v2 Profile Handling [LM Ericsson]
Proposed addition to the Implementers Guide was accepted with no debate.

Need to include optional protocol items in profile description. The proposed
profile description and additional text for service change were accepted.

The proposed packages were accepted as the start of new work item for
profile packages, Annex M.profile.

3.3.3.4	AVD-2124: Additions to the H.248 Multiplex Descriptor [LM Ericsson]
This proposal was stimulated by a need identified in SG11 to specify circuit
multiplexing (Nx64, see AVD-2125).

Comments from the delegates:
·	Is Nx64 mux or single wideband ckt? If single, then more appropriate
to specify at local/remote descriptor level.
·	Two dimensions to multiplex problem: 1) ability to specify that n
ckts should be combined together, 2) ability to specify type of multiplex
for data over that pipe. Current mux descriptor does not provide enough
information to MG to establish H.320 or H.324 calls. Regardless of mux type,
we need the ability to define aggregation of DS0s. May want to deprecate mux
descriptor.
·	In ABNF, "other" is not defined.
·	Extend mux descriptor thru IANA registration.
·	Argument that this proposal breaks existing structure, so should
look for other means to provide desired functionality.

This concept was accepted in principle, but discussion highlighted a
disagreement about how multiplexing really works. The need to support
aggregation was acknowledged, but final resolution of this matter is subject
to further contributions. Contributions are also expected to provide more
detail about how to create a multiplex or bearer aggregate.

3.3.3.5	AVD-2131a: H.248 V2 [Editor]
A number of editorial changes from the last draft were noted.

TD-47 is the draft V2 including changes from this meeting. Delegates should
review this draft in detail and provide comments or proposals for the next
meeting.

3.3.3.6	AVD-2141a: H.248 Digit Collection Corrections and Enhancements
[Nortel]
There was concern that some of the proposed changes (such as the matching
rules) would not be compatible with V1 implementations. The proposal as a
whole is complex, so removal of individual features in the proposal that are
not backwards compatible may break entire proposal.

In TD-40, the proposal was restructured to identify parts that would not be
backward compatible. There was a lack of time to adequately review this
contribution, but we recognize that many of the items in the proposal need
attention. We will proceed as follows:
·	Separately identify items for the implementers guide and post these
to the megaco and SG16 lists
·	Separately identify items intended for V2 and post these to the
megaco and SG16 lists
·	The proposed extended DTMF detection package is accepted as a new
annex on the condition that the related material for V2 is accepted

Understanding that sufficient time is needed to review the entire proposal,
the material is accepted in principle, subject to further review and open to
contributions or counter-proposals.

3.3.3.7	AVD-2173: Implications Of Context Packages [Nortel]
Comments from delegates:
·	C. Groves believes sum of proposals addresses first 2 bullet points
needed for context properties (see section 7.1.19 in V2). AVD-2120 addresses
the 3rd bullet point. Would need some more detail to address 4th bullet
point,  but this is an issue with terminations as well.
·	Regarding matter of semantics, the same issue seems to exist with
terminations. All packages should be reviewed to maintain sanity, and this
holds for context properties as well as terminations. Some additional
forethought would help provide guidance on creation of context properties.
·	Should we require that every context property has an implicit
stream?

Delegates are requested to review the merit of context properties and submit
contributions addressing problems to the next meeting. Likewise, supporters
of adding context properties should provide contributions to add more detail
and address the issues raised in AVD-2173. At that time, a decision can be
made to include or omit context properties from V2.

3.3.4	MCU Decomposition
3.3.4.1	AVD-2102: MCU Decomposition [Polycom]
Much of this contribution has been discussed on the Megaco list. Other
groups (e.g., 3GPP) may be interested. 

There were no disagreements with the architecture and requirements presented
in this proposal. Might want to be bearer agnostic to support something like
AAL2. The general plan presented in this proposal was accepted for the work
going forward. Contributions are expected to progress the package work. A
decision to write a profile will be made at a later point as work
progresses.

...

3.4	New Material
3.4.7	New Annexes for H.248

3.4.7.1	AVD-2121: SDP attributes for package properties [LM Ericsson]
Comments from the delegates:
·	Should string name "pkgitem" reflect that it's for H.248?
·	Will this become a general tunnel for H.245 or similar media
descriptions? Just as with any part of a package definition, the use of
pkgitem will require review and consensus.

This proposal was accepted on the assumption that the "pkgitem" name would
be changed to better reflect that the name is for use with H.248/Megaco.
This new annex will be H.248 Annex N.

3.4.8	New Packages for H.248
3.4.8.1	AVD-2125: H.248 Package for Nx64K [LM Ericsson]
This concept was accepted in principle, and the need to support aggregation,
such as for Nx64k, was acknowledged. The direction of this work depends on
the disposition of the work related to AVD-2124.

3.4.8.2	AVD-2129: H.248 KeepAlive package proposal [Lucent]
Comments from delegates:
·	Characteristics should be read/write
·	Default value should be 0
·	Should be defined as a property on root, so "global" characteristic
is pointless.
·	Would event on MG be more appropriate? With property MGC must
maintain timer for each MG. There were objections to this idea on the Megaco
list. With messages coming anyway, would not require additional messages.

This proposal was accepted in principle, but the editor is expected to model
based on event reporting. Editor will also take other comments above into
consideration while drafting this package, currently named Annex M.ka. TD-44
is the updated keep-alive package.

3.4.8.3	AVD-2130: H.248 Line Test package proposal [Lucent]
This set of packages is under development in ATIS for tests specific to the
USA. It seems to make sense to develop these packages in the ITU since there
is base material for similar tests in other countries, and other tests could
be added. Q.3 will plan to pursue standardization of this set of packages.
The Q.3 rapporteur would appreciate early notification by any ITU delegates
of any objections to working on a package that initially is focused on
regional (i.e., USA) procedures.

AVD-2130 will be the basis for a new H.248 Annex M.lt.

3.4.8.4	AVD-2165: Package for Quality Alert Ceasing [LM Ericsson]
Might be useful to specify a second threshold so that the termination does
not continually oscillate between good and bad quality indications. Note
that the 2 bullets should be ANDed.

AVD-2165 was accepted as the basis for a new H.248 Annex M.qac.

3.4.8.5	H.248 in CableCom
AVD-2169: H.248 profile for controlling MG between cable networks and PSTN
[France Telecom]
AVD-2170: H.248 profile for Audio Servers on cable networks [France Telecom]
This was the first presentation of material to specify the use of H.248 in
the IP CableCom architecture (recall that SG9 had an action item to produce
an annex to a Recommendation to support H.248 in addition to TGCP). TD-39 is
a liaison that will be sent to SG9 through the TSB along with the documents.
TSB will be consulted on procedural matters regarding ownership of the
documents.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

_______________________________________________
Megaco mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/megaco