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@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@nortelnetworks.com