FW: Results from the ITU SG16 Berlin mtg
ngreene at NORTELNETWORKS.COM
Sun Aug 8 22:26:01 EDT 1999
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
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 M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene at nortelnetworks.com
> From: Greene, Nancy-M [CAR:5N10:EXCH]
> Sent: Sunday, August 08, 1999 10:20 PM
> To: 'megaco at 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
> 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
> If you have any trouble getting/reading these files, please let me know
> (ngreene at nortelnetworks.com).
> After discussion on the Megaco mailing list, the editors of Megaco/H.248
> (Brian Rosen (brosen at eng.fore.com) as the IETF editor, and John Segers
> (jsegers at 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 22.214.171.124: 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 126.96.36.199: 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 188.8.131.52: ***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 184.108.40.206: ***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 220.127.116.11: ***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 18.104.22.168: ***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 22.214.171.124: Re-added the sentence saying at least one level of
> embedding should be supported. (Why was it removed?)
> T8) Sectio 126.96.36.199: 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 188.8.131.52: Re-added some of the text in digitMapDescriptor on
> T10) After Section 184.108.40.206: Put/Delete removed - they are for future
> T11) Section 220.127.116.11, 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 18.104.22.168, 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
> T13) Section 6.4.1, 22.214.171.124,126.96.36.199, 188.8.131.52: 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, 184.108.40.206: 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 220.127.116.11: Context general - wording changes, still needs
> E8) Section 18.104.22.168 Change Audit to AuditValue just before Termination
> Dynamics section. A few other changes to paragraph describing muxing.
> E9) section 22.214.171.124, 126.96.36.199: 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
> E10) Section 188.8.131.52: Clarifications made to definition of "brief": "no
> timeout value is needed".
> E11) Section 6.3.3: Clarified text in Command API describing the syntax
> E12) Section 184.108.40.206: Add command - MediaDescriptor now marked as optional
> in the text.
> E13) section 220.127.116.11: Some clarifications made in the section on
> Termination Properties and Descriptors.
> E14) Section 18.104.22.168: Added section for templates, and marked it for
> further study.
> E15) Section 22.214.171.124: 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 126.96.36.199: LocalDescriptor - mode not defined well - sentence
> E17) Section 188.8.131.52: ***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).
> 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 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