Based on the emails exchanged on the Megaco mailing list, this is how I have
addressed the issues from SG16 on the Megaco requirements draft
(draft-ietf-megaco-reqs-03.txt). Let me know of any comments.The new
requirements draft (-04) will be out this week.
(this msg has been posted to both the ITU SG16 mailing list as well as the
Megaco mailing list - please answer only to the Megaco mailing list.)
Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
> ----------
> From: Taylor, Tom-PT [CAR:5V00-I:EXCH]
> Sent: Wednesday, June 02, 1999 10:49 AM
> To: megaco(a)standards.nortelnetworks.com
> Subject: Proposed Changes To Requirements
>
> The following changes to our requirements were proposed by members of
> Study
> Group 16.
>
> ITU - Telecommunication Standardization Sector Temporary Document XX
> (WP2/16)
> STUDY GROUP 16
>
> Santiago, 18-28 May 1999
>
> Question(s): 14/16
>
> SOURCE*: Rapporteur Q. 14/16
>
> TITLE: Proposed Revisions To Megaco/H.GCP Requirements
> __________________
>
>
> ABSTRACT
>
> This document describes the revisions proposed to the Megaco/H.GCP
> requirements as documented in DC 16-286. IETF Working Group Megaco is
> asked
> to consider these for inclusion into the next draft of the Gateway Control
> protocol requirements document.
>
> PROPOSED REVISIONS
> Preliminary comment: it is unclear what the "Architecture" of the title
> refers to. [PTT: It refers to the functional architecture within which
> the
> protocol is supposed to operate.]
>
> Section 3 - Definitions: Suggest including "SG Function" and "MG Function"
> as defined terms. [PTT - they are already there. Looks like a title
> change
> is needed to make them obvious.]
>
"function"added to MG, MGC and SG definitions.
> Section 3 "Termination Class": This is quite unclear. What you appear to
> mean to say, from the examples in Chapter 11, is "Type of Bearer".
>
changed to "Type of Bearer".
> Section 4 -- Specific Functions ...: This Section does not seems relevant
> to
> a specification of protocol requirements. The concept of contexts and
> terminations is best handled in the protocol specification itself. In
> addition much of the material is of a vague and general nature and seems
> out
> of place in a specification. If it is decided to leave some of this here
> it should be pruned down to the essentials and the protocol connection
> model should be avoided. Maybe replace "termination" with "resource".
> Certainly get rid of "context".
>
"termination" changed to "resource", "context" removed.
> Section 4 , 2nd bullet list, 8th bullet: Remove "(Sigtran)" as it is not
> really related to the capability mentioned per se.
>
> General comment: It must be possible to extend the protocol to include
> manufacturer-specific information, perhaps identified by T.35 manufacturer
> code. At the same time, it must be possible for a given implementation
> not
> to support all features defined within the protocol.
> [PTT: extensibility is already a stated requirement - see section 8, item
> b.
> Identification of extensions can be done in various ways. The final
> protocol specification should indicate the minimal MG and MGC
> implementations, and of course should provide for reasonable behaviour for
> unimplemented features.]
>
> Section 5.1 -- Resource Reservation: add (c.) The media gateway is not
> required (or allowed) by the protocol to maintain a sense of future time:
> a
> reservation remains in effect until explicitly released by the MGC.
>
added
> Section 5.2 - Connection Requirements, Item (d): Suggest bringing "Support
> multiple media types ..." out as its own item, and make it stronger:
> support
> multimedia connections. Add "Support the range of options used in
> commonly
> available coders such as H.263."
>
> Section 5.2 (g.): Remove termination-context terminology, which
> anticipates
> the protocol document. Can simply say "Add or delete media streams during
> a
> call or session.", and "Add or subtract participants to a call or
> session."
> May want to state these as separate points.
>
ok
> Section 5.2 (h.): Use "call or session" rather than "context". This is
> not
> to say that the two expressions are equivalent, but only that the
> suggested
> rephrasing conveys the requirement without anticipating the protocol
> solution.
>
ok
> Section 5.2 (i.) Missing words: should read "... and which are blocked at
> a
> given point in time ...".
>
ok
> Section 5.2 (j.): Special case of item (a) and should be combined with
> that
> item.
>
ok
> Section 5.2 (l.): Could rephrase in less implementation-oriented terms:
> "Allow the MGC to specify that a given connection has higher priority than
> other connections."
>
ok
> Section 5.3 -- Media Transformations, Item (e): This seems to have a lot
> of
> problems. Replace with the following:
>
> Allow the MGC to specify that MF/DTMF be extracted and handled in the
> following ways:
> [Nancy - I assume the above should read "in ANY OF the following ways"]
> (1)encoded as part of the RTP stream
> (2)extracted and sent to the MGC
> (3)handled according to a script of instructions
> [Nancy - we need to add (4) - extracted and encoded in a separate RTP
> stream]
> In all cases, if the MF/DTMF is extracted, the MG must replace the tones
> with silence or comfort noise. Also, the option to have the MG not
> extract
> MF/DMTF must exist as well.
>
change made with my additions above.
> [PTT: the original text provides for extraction of the MF/DTMF and its
> onward transmission in a separate RTP stream. This is in anticipation
> that
> an RFC will eventually be created which supports such operation. Work on
> this has been moving (slowly) through MMUSIC.]
>
> Section 5.3 (g.) Is this requirement intended to allow for adaptation of
> ATM
> AAL5 to and from ATM AAL2, among possibly other things? It is so badly
> worded it is difficult to tell for sure. It needs clarification, and
> probably is covered already by 5.3(a).
>
5.3(g) reworded
> Section 5.3 (h.) Define "audio normalization level" further.
>
> Add Section 5.3 (i): Allow conversion to take plece between media types
> e.g
> text to speech and speech to text.
>
added
> Section 5.4 - Signal/Event Handling, Item (d): delete the word
> "signaalling"
> before events, making the requirement more general.
>
ok
> Section 5.4 (e): Redundant, covered by earlier items.
>
> Section 5.5 - QOS/COS, Item (b) Define what "the connection as a whole"
> is.
> The link between MGs? The entire user to user connection? Probably the
> former.
>
added "between MGs"
> Section 5.5 (d.) "... by flow direction ... " It is unclear what this
> means.
> It is also unclear how this requirement differs from requirement 5.5 (c).
>
5.5(d) removed (covered by 5.5(c))
> Add Section 5.5 (f): Allow the size and performance of jitter buffers on
> RTP
> channels to be specified at call set-up.
>
added ("at call setup" changed to "at connection setup")
> Section 5.6 - Test Capabilities, Item (c): After some discussion the
> conclusion here was that loopbacks and unspecified other test capabilities
> are not a Gateway Control protocol issue. They will be invoked by other
> means. Hence this item should be deleted.
>
No change - If a test is initiated by an ISUP message, then it needs to be
part of the protocol. This includes loopbacks and continuity tests.
[reference: Greene - Megaco/H.gcp conference call minutes, June 16/99]
> Section 5.7 - Accounting - Item (a): use a term other than "terminations",
> since the latter is specific to the protocol specification. Suggestion:
> "resources".
>
ok
> Section 5.8 - Signalling Control (General): The protocol for
> establishment
> of signaling backhaul channels should be part of this protocol, not "out
> of
> scope." Signalling could be viewed as another form of media from the
> point
> of view of the protocol.
>
No change - Establishment of a SIGTRAN backhaul is provisioning [reference:
Rosen, June 8/99, and June 9/99]
> Section 5.8 (b.) Calls for support of "national variations" of signaling.
> This creates a potential "homologation horror". The opposite requirements
> are suggested: "All national variations of signaling protocols that are
> channel associated are reported to the MGC in a uniform fashion that
> conceals the national varations."
>
No change: Reasons:
* Creating a uniform representation for all CAS protocols may prove
non-trivial.
* A uniform superset protocol for representing all CAS protocols, if
one could be created, would probably contain much that was not needed for
particular applications, hence MGCs and MGs would tend to implement subsets,
resulting in national variations anyway.
* Simplifying the MGC at the expense of the MG isn't necessarily the
right economic model in all applications.
[reference Ashworth, June 15/99]
> Section 5.8 (c): intent is unclear. Probably mean to say that support of
> signalling should not be such as to cause the transmission time between
> the
> MG and the MGC to become a critical element in meeting signalling timing
> constraints. More specifically, where responses to signalling events must
> occur in less than one second, the protocol should assume that these
> responses will be generated autonomously by the MG rather than via an
> MG-MGC-MG messaging sequence.
>
> Add Section 5.9 (d): The protocol shall not create a situation where the
> MGC
> and the MG must be homologated together as a mandatory requirement of
> using
> the protocol; i.e. it must be possible to optionally conceal signaling
> type
> variation from the MGC.
>
added, but as Brian Rosen says, the current protocol definition would fail
to meet this
requirement for CAS, since it only covers some CAS variants.[reference:
Rosen, June 8/99]
> Section 6.1 - Resource Status Management - Item (c): replace the word
> "contexts" with "connections".
>
ok
> Section 6.1 (d): "...must enumerate the names and quantities of available
> terminations..." Delete "quantities": terminations are instances, so
> there
> is only one of each. Also questionable whether the word "termination"
> should be used without qualification (e.g. circuit termination).
>
ok
> Section 6.1 (e.) Change "reasonable" to "reasonably".
>
ok
> Section 6.2 (c.) What are "network entities"? Either define exactly or
> remove.
>
network entities removed.
> Section 7.1 - Assurance of Control/Connectivity - Item (a): This was
> intended to be a summary of the section. Inserted as an item itself, it
> is
> redundant.
>
ok
> Section 7.2 - Resiliency: This whole section is covered by the previous
> one
> and is redundant. Another way of looking at it is that it provides
> implementation details to achieve the objectives of the previous section,
> by
> constraining the control models and specifying the recovery mechanisms.
>
7.2 a, b, f, g removed, the rest moved into 7.1.
> Section 7.3 - Error Control -- (b.) Define UPC events in more detail.
>
> Section 7.3 (c.) Needs rephrasing to make clear in what way this is a
> protocol requirement rather than an MG implementation issue. Also, should
> use more formal term than "shower".
>
"provide a mechanism to" replaced by "be able to"
> Section 7.4 MIB Requirements: Note that since the MGC/MG must look like
> an
> H.323 GW, it must, as a unit, support the MIBs in H.341, including the RTP
> MIB, etc. Mostly this burden falls on the MGC, but it seems there are two
> requirements:
>
> 1)The protocol must provide enough information to the MGC to allow it to
> support the MIBs in H.341.
>
Added the following to section 7.4:
The protocol must allow the MG to provide to the MGC all information the MGC
needs to provide in its MIB.
> 2)The presence of the MG MIB must be concealable in some fashion so that
> (optionally) the MG/MGC can look like an H.323 GW. This appears to
> require
> a bit of thought.
>
This comment is not understood - the MG MIB would not be visible in any way
as the H.341 MIB [reference: Rosen, June 8/99]
> Section 8 (c.) A suggested example of flexibility would be to allow the
> SGF
> (Signaling Agent Function) to reside in the Media GW Unit for H.323
> signaling.
>
..but we are talking out MG functions and MGC functions here. An example of
the flexibility required is for the MGC let the MG assign resources in some
implementations, while in others, the MGC may want to assign the resources
itself (this was added).
> Section 8.1 (b) and (c): These requirements for a MG to receive messages
> from more that one MGC threaten to make the protocol more complex that is
> really needed. Suggest removing these requirements.
>
No change - this requirement will stay [reference: Rosen, June 8/99, ...]
> Section 8.2 (General): The exact implication of mentioning the E.500
> series
> is unclear. There is a possible implication that the protocol must
> conform
> to all aspects of the E.500 series. Provide specific references to
> specific
> documents as appropriate. A formal reference should be added as well.
>
sentence with E.500 in it has been removed.
> Section 10: Add requirement that the protocol be able to pass through
> commonly-used firewalls.
>
Add 10(h) that it would be desireable for the protocol to be able to pass
through commonly-used firewalls.
> Section 11 (General): the expression "Termination Class" is used, but
> generally "bearer type" is what is meant and is a protocol-independent
> phrase.
>
ok
> Section 11 (Intro): add MultiMedia to Analogue and Restricted Capability
> Applications (H.324 terminals).
> Add the following two lines to Table 1:
> Multimedia H.323 H.323 multimedia IP,ATM
> Gateway and MCU
> Multimedia H.320 h.323 GW and MCU ISDN, SS7
>
ok
> Section 11.1.1: add the following items:
> k. H-channel (n x 64K) calls to/from the SCN.
> l. B channel aggregation protocols for creating high speed channels for
> multimedia over the SCN.
> m. Modem terminations and negotiations
>
ok
> Section 11.1.2 (c.) Make this required; not FFS. (reporting of codec
> re-negotation).
>
No change - this remains FFS, since there is no proposal on the table today
on how to do it.
> Section 11.1.2 (h.) "seperate RTP flow" for DTMF - shouldn't this be the
> same RTP flow as for voice?? What is meant by this?
>
11.1.2(h) is replaced by section 5.3(e)
> Add Section 11.1.2 (l) (required) The protocol shall allow for a request
> to
> initiate an H.323 call from the MGW (which implies the SG Function for
> H.323
> is in the Media GW Unit). It also shall allow for the Media GW Unit to
> report that arrival of such a call to the MGC.
> [PTT: We never got back to discussing this one, after noting the need to
> do
> so.]
>
> Section 11.1.3: Should say somewhere that H.323 Annex C operation is
> supported.
>
reference added to 11.1.3.3 Media Adaptation (i)
> Section 11.2.4: should be
> 11.2.4. Trunking/Access Gateway with text telephone access ports
> Support translation of modem text conversation to/from audio
>
ok
> Sections 11.2.7 (Analog GW) and 11.2.9 (ISDN GW): These sections should be
> removed as they are not really applications.
>
ok
> Section 11.2.10. Suggest changing the title to "MultiMedia GW" and
> generalizing. The need is to be able to tell the MG what protocol to use
> on
> the SCN side (H.320, H.324) and what protocol to use on the packet side
> (H.323) or ATM side (H.310, H.321). An implied requirement is that H.245
> to
> H.242 processing must take place in the MG due to timing constraints. This
> should be brought out explicitly
> Add:
> a) the gateway should support Bonding Bearer channel aggregation
> b) the gateway must support 2xB (and possibly higher rates) aggregation
> via
> H.221
> c) dynamically change the size of audio, video and data channels within
> the
> h.320 multiplex
> d) the gateway must react to changes in the H.320 multiplex on 20 msec
> boundaries.
> e) The gateway must support TCS4/IIS BAS commands
> f) That gateway must support detection and creation of DTMF tones.
> g) The gateway should support SNMP MIBS as specified in H.341
>
ok
> Section 11.2.10 (x.-new) It must be possible on a call by call basis to
> specify different applications. Thus, one call might be PSTN to PSTN under
> SS7 control, while the next might be ISDN/H.320 under SS7 control to
> H.323.
> This is only one example; the key requirement is that the protocol not
> prevent such applications.
>
added
> Section 11.2.11.: Web based and text based alternatives to IVR functions
> should be more strongly promoted, if not required. This is needed by deaf,
> hard-of-hearing and people from other language regions. And for all of us
> who are tired of the tedious IVR systems. Maybe also for fax users and
> multimedia users.
>
> Section 11.2.12: add
> 11.2.12 Multipoint Control Units
> The protocol shall support a mechanism to create multipoint conference of
> audio only and multimedia conferences in the MG.
> - audio mixing; mixing multiple audio streams into a new composite audio
> stream
> - audio switching; selection of incoming audio stream to be sent out to
> all
> conference participants.
> - video switching; selection of video stream to be sent out to all
> conference particiapants
> - lecture video mode; a video selection option where on video source is
> sent
> out to all conference users
> - multipoint of T.120 data conferencing
>
added
> A final thought:
> How are Mobile networks connected to the model? They may need to be
> separately handled.
>
> ____________________
>
>
> * Contact:
> Tom Taylor
> Tel: +1 613 736 0961
> Fax: +1 613 736 0961
> E-mail: taylor(a)nortelnetworks.com
>
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
