draft-04 vs. Results from Berlin

Nancy-M Greene ngreene at NORTELNETWORKS.COM
Thu Sep 30 14:38:50 EDT 1999


For each point raised at the ITU-T SG16 meeting in Berlin, I have put the
reference in the new Megaco/H.248 draft that covers it. This can be used to
determine how the current draft implements the desired change requested in
Berlin.

The Berlin draft is:
ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.doc
or
ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.zip

The draft-04 of Megaco/H.248 is:
ftp://standards.nortelnetworks.com/latest/megaco-h248_protocol.pdf,
or
ftp://standards.nortelnetworks.com/latest/draft-ietf-megaco-protocol-04.txt

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene at nortelnetworks.com

> Technical additions/changes/issues
> ----------------------------------------------------
> T1) Section 6.2.2.2: Intercept: added a topology descriptor as a context
> parameter, to allow operator intercept, wiretapping - satisfies the
> regulatory requirement of only allowing the tapping of one side. Also,
> removed InterceptToken from ABNF - this is done using context parameters
> instead. ***Need to review this topology descriptor proposal to see
> whether
> it works, and whether it could be covered already in another way, using
> the
> muxing descriptor for example.
>
see draft-04 7.1.16 Topology Descriptor

> T2) Section 6.2.3.3: TerminationIds - Changed  "arbitrary string" to
> "arbitrary schema" so it is not tied to a text encoding (there may be a
> better word). Note that there is NO special meaning about the / character.
> Added "In a text encoding of this protocol". Added sentence
> "TerminationIDs
> of physical Terminations are provisioned in the Media Gateway".
> Re-included
> text describing use of hierarchical terminationIds.
>
see draft-04 Section 6.2.2

> T3) Section 6.2.3.5: ***Make sure the parameter tables from the Santiago
> text go in an annex as parameters of one of the basic packages. These
> parameters would be included in the LocalDescriptor.
>
see draft-04 Annex D.

> T4) Section 6.2.3.5: ***There is still an issue with tx and rx descriptor
> names: when you do an add on the RTP termination, in the response you will
> get params for RxDescriptor (local information). BUT it is also a transmit
> descriptor. So, there is still a wish to call rxDescriptor the
> localDescriptor, and txDescriptor the remoteDescriptor. Note added.
>
In draft-04, the 3 descriptors a StreamDescriptor may have are now called
LocalControl, Local, and Remote.

> T5) Section 6.2.3.6: ***Issue with ROOT TerminationId - It seems a bit of
> a
> kludge to use a special ROOT terminationId to refer to the entire MG - can
> we make TerminationId optional in AuditValue, AuditCapability? then we
> would
> not need ROOT. Check effect to ServiceChange.
>
In draft-04 - ROOT left as is. Useful for applying commands to the
properties of the entire MG.

> T6) Section 6.3.2.11: ***Need to add a way to configure the level of
> embedding of signals/events descriptor, and MGC needs to be able to find
> out
> the level of embedding.
>
In draft-04, Embedding is explicitly limited to one level of embedding (see
end of 7.1.10).

> T7) Section 6.3.2.11: Re-added the sentence saying at least one level of
> embedding should be supported. (Why was it removed?)
>
In draft-04, sentence changed to say that only ONE level of embedding is
allowed (see end of 7.1.10).

> T8) Sectio 6.3.2.15: DigitMapDescriptor - Added a start timer, ***still
> need
> to add text for naming/use of transient digit maps. ***Also need to make
> sure that if the MG fails to load a digit map, event notification
> continues
> anyway.
>
see draft-04 Section 7.1.14  - are two *** points above covered in draft-04?

> T9) Section 6.3.2.15: Re-added some of the text in digitMapDescriptor on
> wildcarding.
>
see draft-04 section 7.1.14

> T10) After Section 6.3.3.8: Put/Delete removed - they are for future
> consideration.
>
ok

> T11) Section 6.3.2.10, 6.3.4, Annex A, B, C: Text vs binary: Annex A added
> for modified ASN.1 that describes the protocol syntax, Annex B for the
> ABNF,
> and the translation mechanism, and Annex C for the binary and the binary
> translation mechanism.
>
See draft-04 Annexes A, B, C.

> Agreements: ABNF remains normative. ASN.1 and compiler to compile into the
> ABNF already written,  will also be added as normative when they are
> available. Sentence added: " This compiler is a living tool that will
> likely
> be enhanced over time. To start, this tool should be tested to verify that
> syntax can be compiled to the ABNF defined below.
>
> It is expected that industry forums would define profile for use of H.248
> and this would include whether text vs binary is used, as well as which
> packages would be used, etc. In Section 6.3.4, sentences added: "MGCs
> should
> support both encoding formats. MGs may support both formats."
>
see draft-04 section 7.2.9 Generic Command Syntax: "The protocol can be
encoded in a binary format or in a text format.  MGCs should support both
encoding formats.  MGs may support both formats"


> T12) Section 6.3.2.10, Annex D: A new proposal has been added for native
> encoding of StreamDescriptors (SDP codepoint is still there). Changes made
> to ABNF, reference made to SDP RFC, and to native encoding. ***Media
> descriptor parameter and value tables put into Annex D -  this annex still
> needs work. ***Need to add in the sentence: "It is recommended that the
> native encoding method for stream descriptors be used when encoding is
> binary, and the SDP method be used when the protocol encoding is
> text-based."
>
See draft-04 - Annex D is not complete.

> T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify transaction
> semantics
> - changes to text and to ABNF (Annex B) made: removed the concept of
> rollback on transactions - the document did not define how you could roll
> back commands that actually cause physical changes on the MG, e.g.,
> sending
> of a signal, subtracting a termination from a context.
>
> It was decided that in fact, all a transaction does, is ensure that
> commands
> occur in a particular order, and that no commands after a command that
> fails, gets executed. In a TransactionAccept, need to say what a response
> is
> - added sentence on this. In a TransactionReject, the command that failed
> has error code, all the rest of the commands are not executed.
>
See draft-04 section 8.

> T14) Section 6.4.1: Transaction figure - renamed "action" to "contextId".
>
See draft-04 Figure 5, section 8

> T15) Section 6.5: ***An example use case for text telephony will be added
> (need to move all examples to an informative appendix).
>
Added in draft-04 - See last example in Annex G.

> T16) Section 6.6: Transport: Proposed text added - it does not change
> current transport functionality in draft-ietf-megaco-protocol-03.txt.
> ***Editorial changes to this section will be suggested.
>
Transport section is draft-04 Section 9; Transport using UDP and ALF is
Annex E, Transport using TCP is Annex F

> T17) Section 6.7: Security section - some clarifications to text added -
> you
> do not have to implement AH-in-Megaco/H.248 if you have IPSEC. Only ONE of
> the two schemes is used at one time - if IPSEC is on both MGC and MG, it
> is
> used, otherwise AH-in-Megaco/H.248 is used. Proposed text: "The MG need
> only
> support IPSEC if it is capable. Otherwise it must support
> AH-within-Megaco/H.248." ***Section too long, needs rewording.
>
see draft-04 Section 10. "Implementations of the MEGACO/H.248 protocol SHALL
implement IPsec where the underlying operating system supports IPsec.
Implementations of the MEGACO/H.248 protocol using IPv4 SHALL implement the
interim AH-within-MEGACO/H.248 scheme. However, this interim scheme SHALL
NOT be used when the underlying network layer supports IPsec. IPv6
Implementations are assumed to support IPsec and SHALL NOT use the
AH-within-MEGACO/H.248 interim scheme."

> T18) Section 6.7: *** Security: request clarification on how the MGC knows
> what the security mechanism is that the MG is using, and vice versa.
>
See draft-04 Section 10.

> T19) Section 7: Packages: a proposal for the writing of base packages,
> along
> with proposals for the base packages will be turned into an internet-draft
> and submitted for comment.
>
See draft-04 Section 12.

> T20) Section 7.2: Text added for IANA registration of packages. ***Text
> still needs work. Agreed that IANA is the place to register ALL packages.
> Suggestion that procedures should say that for ITU-T packages, we would
> standardize the first few characters of the package name, and that a
> public
> document describing the packages are not necessarily required.
>
See draft-04 Section 13.

> T21) Annex B: ***AuditCapabilities - need to allow multiple copies of
> descriptors to be returned. ABNF needs to be updated.
>
See draft-04 Annex B - ABNF allows multiple copies of descriptors.

> T22) Annex D, SDP: ***Need to be able to pass a QoS parameter to the MG.
> (Note: Place to define this would be in the Package that defines
> parameters
> to the LocalDescriptor. Also needed in SDP.)
>
SDP allows a bandwidth parameter - check SDP RFC.

> Editorial changes
> -------------------------
> E1) Section 1: Have an ITU scope, and an IETF scope. Text that is there is
> the ITU scope.
>
ok

> E2) Architecture: Change architecture section back to Santiago determined
> version of the text, and move it to H.323, instead of having it as an
> annex
> to H.248. If architecture is moved out, all definitions (section 3) that
> pertain to the architecture section and not the protocol, for example, GK,
> can be deleted.  (Note - there is still an issue of where the architecture
> section will live, but in any case, it will NOT be in the IETF version of
> the protocol).
>
ok - draft-04 has no architecture section.

> E3) ***Section 3: Add definition for stream, signal, event (not done yet).
>
see draft-04 Section 3: definition for stream, descriptor added. Still need
to remove defintions of GK, etc, that are no longer referenced in this
protocol document.

> E4) Requirements section (old section 6) is removed. No need to reference
> requirements doc in this document.
>
ok

> E5) Section 6.1:Removed  reference to "interface A".
>
ok

> E6) Section 6.2.1, 6.2.3.1: Terminations Basic Concepts, and Overview -
> some
> wording changes. For example, in the case of intercept for wiretapping, a
> third termination in a context does not make the context a conference
> bridge. Also conference replaced by association.
>
see draft-04 Section 6.2

> E7) ***Section 6.2.2.1: Context general - wording changes, still needs
> work.
>
see draft-04 Section 6.1

> E8) Section 6.2.3.1 Change Audit to AuditValue just before Termination
> Dynamics section. A few other changes to paragraph describing muxing.
>
ok, see end of draft-04 Section 6.2

> E9) section 6.2.3.5, 6.2.3.8: The "Support" columns in several tables have
> been removed (not relevant now). This makes it look like those entire
> tables
> have been changed - in fact it is just that a column has been removed.
>
ok

> E10) Section 6.3.2.12: Clarifications made to definition of "brief": "no
> timeout value is needed".
>
see draft-04 section 7.1.11

> E11) Section 6.3.3: Clarified text in Command API describing the syntax
> used.
>
ok

> E12) Section 6.3.3.1: Add command - MediaDescriptor now marked as optional
> in the text.
>
see draft-04 section 7.2.1

> E13) section 6.2.3.5: Some clarifications made in the section on
> Termination
> Properties and Descriptors.
>
        ok

> E14) Section 6.2.3.7: Added section for templates, and marked it for
> further
> study.
>
for further study sections removed in draft-04.

> E15) Section 6.2.3.8: Added section for scripting descriptors (marked for
> further study). Make sure we can add them later to the protocol, e.g. make
> sure it can be used as an alternative way of describing digit maps.
>
for further study sections removedin draft-04. Scripting can be added later
as a new parameter to commands called a ScriptingDescriptor.

> E16) Section 6.3.2.9: LocalDescriptor - mode not defined well - sentence
> removed.
>
Termination state defined in draft-04 Section 7.1.6 (test, in service, out
of service), Stream Mode in Section 7.1.8: "The allowed values for the mode
parameter are "send only" (sendonly), "receive only" (recvonly),
"send/receive" (sendrecv),  "inactive" (inactive), "loop back" (looback) and
"delete" (delete).  "Send" and "Receive" are with respect to the stream
within a termination, so that, for example, a stream set to mode=sendonly
can talk but it cannot listen.
Mode set to delete is used to remove a stream from a termination."

> E17) Section 6.3.2.11: ***Question: does loop in eventBuffer mean that
> event
> is returned each time it occurs without having to resend an
> EventsDescriptor
> - need to make text clearer.
>
see draft-04 Section  7.1.6   - is the text clearer now?: "2)
BufferedEventNotificationMode - specifies whether the Media Gateway is
expected to detect the requested event and notify the controller once (step
by step) or repeatedly".

> E18) Section 6.3.5: ***Need to renumber error codes (Need to discuss this
> -
> may be better to leave them with the numbering they have.)
>
- see draft-04 Section  7.3 - leave numbering as it is

> E19) Section 7.2: ***Verify that all places that require IANA registration
> in one place are grouped - error codes, packages, - (Events and signals do
> NOT need to be registered - they are defined in packages).
>
>
>
> Questions
> --------------
> Q1) What is the media type parameter of a termination? Is it in the stream
> descriptor? or is it at the termination level? In describing the
> muxDescriptor, it is stated that the media type of a termination included
> in
> a mux is set to mux...
>
erroneous text removed in draft-04 .

> Q2) Check semantics in embedded signals - what happens if one of the
> signals
> fails - is the next signal applied or is it an error?
>
check.

> Q3) Check that you can put two signals on a line and they are mixed.
>
> Q4) How does MGC to find out if MG supports digit maps? By just sending
> them, and the MG ignores them if it wants to?
> --------------
>
> Nancy
>
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene at nortelnetworks.com
>



More information about the sg16-avd mailing list