I've uploaded to the nortel ftp site (see URL below) TD-44, with diff marks
against TD-8 (which is the file referenced in the internet-draft
<draft-ietf-megaco-protocol-03.txt>), and made the following summary of the
changes made in Berlin. If any of you think I have mis-represented the
outcome, or if I have forgotten anything, please speak up on the Megaco
mailing list.
I hope that with a few days discussion, we will have a draft that both the
IETF and the ITU agree on, and can move towards going for Last Call.
Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
----------
From: Greene, Nancy-M [CAR:5N10:EXCH]
Sent: Sunday, August 08, 1999 10:20 PM
To: 'megaco@standards.nortelnetworks.com'
Subject: Results from the ITU SG16 Berlin mtg
ITU-T SG16 Q12-14 held a Rapporteurs' meeting in Berlin Aug 2-6/99. They
reviewed the current draft of the Megaco/H.248 protocol contained in
<draft-ietf-megaco-protocol-03.txt>, and produced a document containing
all changes they propose to make.
Much of the text as it appears in <draft-ietf-megaco-protocol-03.txt> has
been accepted. All the suggested additions and clarifications need
discussion on the Megaco mailing list in order to continue the ITU/IETF
cooperation, and to get the protocol ready for Megaco WG last call.
This document was accepted by SG16 in Berlin as the current draft of
H.248. The document is available at
ftp://standards.nortelnetworks.com/megaco/docs/Wash99 - with filenames
MegacoH248v9Chgs.doc
MegacoH248v9Chgs.pdf
MegacoH248v9Chgsdoc.zip
MegacoH248v9Chgspdf.zip
The Word document has diff marks against MegacoHGCPv9itu.doc, and NOTE
that the itu macro is on - switch it to the ietf macro to see the ietf
text.
If you have any trouble getting/reading these files, please let me know
(ngreene@nortelnetworks.com).
After discussion on the Megaco mailing list, the editors of Megaco/H.248
(Brian Rosen (brosen@eng.fore.com) as the IETF editor, and John Segers
(jsegers@lucent.com) as the ITU-T editor) will incorporate appropriate
changes and then (I expect) issue it as a new internet-draft.
****IF ANY POINTS NEED DISCUSSION, please send each
****point in a separate email, and, if applicable, propose
****exact text changes you would make.
Below is a summary of these changes, technical and editorial, as well as a
few questions. Points marked with "***" require work.
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.
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.
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.
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.
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.
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.
T7) Section 6.3.2.11: Re-added the sentence saying at least one level of
embedding should be supported. (Why was it removed?)
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.
T9) Section 6.3.2.15: Re-added some of the text in digitMapDescriptor on
wildcarding.
T10) After Section 6.3.3.8: Put/Delete removed - they are for future
consideration.
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.
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."
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."
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.
T14) Section 6.4.1: Transaction figure - renamed "action" to "contextId".
T15) Section 6.5: ***An example use case for text telephony will be added
(need to move all examples to an informative appendix).
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.
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.
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.
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.
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.
T21) Annex B: ***AuditCapabilities - need to allow multiple copies of
descriptors to be returned. ABNF needs to be updated.
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.)
Editorial changes
-------------------------
E1) Section 1: Have an ITU scope, and an IETF scope. Text that is there is
the ITU scope.
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).
E3) ***Section 3: Add definition for stream, signal, event (not done yet).
E4) Requirements section (old section 6) is removed. No need to reference
requirements doc in this document.
E5) Section 6.1:Removed reference to "interface A".
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.
E7) ***Section 6.2.2.1: Context general - wording changes, still needs
work.
E8) Section 6.2.3.1 Change Audit to AuditValue just before Termination
Dynamics section. A few other changes to paragraph describing muxing.
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.
E10) Section 6.3.2.12: Clarifications made to definition of "brief": "no
timeout value is needed".
E11) Section 6.3.3: Clarified text in Command API describing the syntax
used.
E12) Section 6.3.3.1: Add command - MediaDescriptor now marked as optional
in the text.
E13) section 6.2.3.5: Some clarifications made in the section on
Termination Properties and Descriptors.
E14) Section 6.2.3.7: Added section for templates, and marked it for
further study.
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.
E16) Section 6.3.2.9: LocalDescriptor - mode not defined well - sentence
removed.
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.
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.)
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...
Q2) Check semantics in embedded signals - what happens if one of the
signals fails - is the next signal applied or is it an error?
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@nortelnetworks.com