Subject: Cisco SG16: Annex E comments

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 20:17:37 -0500

Section:        E.1.3, E.3.3, E.5.3, E.7.3
Category:       Technical, Editorial
Issue:          The draft text does not follow the package format specified in
Section 12.1.4. More specifically, neither SignalType nor Duration is
specified.
Proposal:       It is recommended that SignalType and Duration are specified.

v13 Status:     OPEN. No text changed.

Section:        E.4
Category:       Editorial, Technical
Issue:          The draft text only specifies toneID's, not EventID's, thereby
violating the package format specified in Section 12.1.3.
Proposal:       It is recommended that eventIDs are defined for the DTMF tones as
well as the current toneIDs.

v13 Status:     OPEN. No relevant text changed.

Section:        E.4
Category:       Technical
Issue:          The draft text specifies that "Support of dA-dD is optional".
Having optional events in a package tends to defeat the purpose of packages
in the first place.
Proposal:       It is recommended that either support for the signals become
mandatory or they are provided in a separate package.

v13 Status:     OPEN. No relevant text changed.

Section:        E.6
Category:       Technical, Editorial
Issue:          The draft text only specifies toneID's, not EventID's, thereby
violating the package format specified in Section 12.1.3.
Proposal:       It is recommended that eventIDs are defined for the Call Progress
Tones as well as the current toneIDs.

v13 Status:     OPEN. No relevant text changed.

Section:        E.8
Category:       Technical
Issue:          The draft text specifies that the possible values for the signals
are "q724" and that the MG figures out whether a 2-wire or 4-wire
continuity test is to be performed on the trunk in question. First of all,
it is unclear how the MG determines precisely what continuity test variant
to perform unless it is assumed that the MG is provisioned with this
information, however this should not be a requirement. Secondly, national
variants of continuity test procedures exist, and considering the package
is a "basic continuity package" it should be possible to use this package
without requiring support for Q.724 continuity test.
Proposal:       It is recommended, that the possible test values are not
specified in this basic package, but that extension packages define this
packages, similarly to the "tone generator" and "tone detection" packages
defined in Annex E.1 and E.2

v13 Status:     OPEN. No relevant text changed.

Section:        E.9
Category:       Open Issue
Issue:          Cf. comment to Section 7.1.8 on "Local" and "Remote" as well as
ongoing list discussion, it is unclear what the status of this package
should be. Furthermore, it does not seem like the package supports
specification of asymmetric codecs. It is also not clear, how multiple
independent yet comprehensive codec specifications can be supported by the
package.
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.
Proposal:       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:     CLOSED ? Most of the package now removed. If the v13 solution
on Local/Remote is accepted, this particular issue seems to be closed.

Section:        E.11.1
Category:       Technical
Issue:          The draft text specifies that "silence suppression" is a property
of the DS0 package. However silence suppression relates to the encoding
method and as such should be a property of each packet based termination.
For example, if a three-way call is established with one DS0 termination,
and two RTP terminations, it is conceivable that one of the RTP
terminations would like to use silence suppression while the other would
not (or cannot for that matter as not all codecs support silence
suppression).
Proposal:       It is recommended that the "silence suppression" property is
moved from the DS0 package to the "network package"

v13 Status:     SEMI-OPEN. Silence suppression has been removed, but it has not
been added anywhere else (except for Annex C.1 which defines it as a
General Media Attribute).

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