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@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@nortelnetworks.com
Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com