Chair Tom Taylor - taylor@nortelnetworks.com Reported by Matt Holdrege - matt@ascend.com 170 people signed the blue sheet 1. Agenda Bashing Tom Taylor's first two slides presented a proposed agenda. (See his presentation, filename Agenda43.PDF.) David Oran (oran@cisco.com) objected to the item "Target Media Gateway Architecture", on the grounds that this would amount to prescribing Media Gateway implementations. It was agreed that there was no intention to specify implementation, and the architectural discussion would be curtailed if it appeared to be going in that direction. Subject to that provision, the agenda item was retained. 2. Review of the Charter Tom Taylor reviewed the proposed Megaco charter (see his presentation charts 3 and 4), touching on the architectural framework within which Megaco is to work, its deliverables, and the other groups with which Megaco should coordinate. Tom pointed out in particular that ITU-T Study Group 16 (Questions 13 and 14) is covering the same ground as Megaco, and expressed his personal interest in having Megaco and the ITU come to a common result. 3. Requirements 3.1 Presentations Francois Menard (fmenard@mediatrix.com) made an architectural presentation, the key point of which was that, taken in the aggregate, the components of a decomposed gateway (i.e. MG-MGC-SG) should appear to exterior elements exactly like a gateway all functional elements of which are implemented in the same physical unit. In particular, a single-unit SIP-to-circuit network gateway would have no need to implement the Media Gateway control protocol which Megaco is producing. There was rough consensus that making device control protocols work across service provider administrative domains was not a target. However, Ike Elliot (ike.elliott@Level3.com) and Henry Sinnreich (henry.sinnreich@mci.com) pointed out that it may need to work between a service provider and an enterprise domain. Scott Bradner summed up the basic requirement emerging from the discussion: that the protocol should operate across untrusted domains in secure fashion. Fernando Cuervo (cuervo@nortelnetworks.com) showed a diagram of a functional model of a gateway, taken from draft-cuervo-navdec-mg-arch-00.txt. The nature and role of endpoints in Fernando's model drew the bulk of comments and discussion, with some sense that Fernando's description was too vague. Tom Taylor said there is a requirement to pass incoming and outgoing streams to multiple endpoints within the Media Gateway. He gave as a specific example the requirement to associate wiretaps to some calls. David Oran said that he has a problem with a requirement that the media gateway controller must be able to ascertain that two endpoints are in the same box when constructing a control message. It was generally agreed that it was highly desirable that the protocol should be able to refer to network resources such as announcements in the same way regardless of their physical location. After more discussions, Scott Bradner said that we need to move on and assume only that endpoints are addressable in a simple sense. David Oran said that he objected to Fernando's entire functional diagram. There was general agreement that we want to know the minimum of information about the media gateway to design the protocol. Tom Taylor said that the important thing is that we recognize that it would be nice to have a protocol which would address entities in a functional fashion. 3.2 Clarification of Core Requirements Tom Taylor presented charts (final three charts of Agend43.PDF) summarizing core requirements and identifying extension items of work, according to work program proposals he made earlier on the list. As he pointed out, the charts were summaries of summaries, and intended to provoke discussion rather than be in any way definitive. The subsequent discussion made it clear that what the working group wished to create was a general protocol framework possibly amplified by profiles, within which all applications and all bearer types would fit. As a result, the attempt to distinguish core from extension work items was irrelevant at this time. Francois Menard specifically questioned whether the group would be wise to tackle all possible applications at once, and proposed instead that it should focus initially on trunking gateways. The clear consensus by show of hands was against this proposal, in favour of defining a protocol which would apply to all applications. A number of detailed points were noted en route to this general position. - Under the any-to-any requirement, Ike Elliot wanted to make sure that hairpin connections (i.e. circuit-to-circuit or packet-to-packet in a circuit-to-packet gateway) are supported. - Under the circuit requirements, it was stated that we should support Frame Relay and other bearer types not explicitly mentioned. - Under line signalling, it was asked if we need to take into account other types of signalling such as caller-id, key sets. Tom asked if these should be a core requirement or an extension. There was much discussion over what was a core requirement or an extension. Tom Taylor wanted to keep the core requirements small in order to make the task of getting an RFC out more realistic. David Oran said that the protocol must be able to support all signalling. Ike Elliott said that we should specify profiles. As long as we have extensible packages and mechanisms, we should be able to support any scheme. In general, the view was that the syntax related to signalling should be the same whether pertaining to lines or to trunks, and should be independent of the application. - Michael Ramalho (mramalho@notes.cc.bellcore.com) said we should design for a variety of control relationships between call agents of any media gateway from different vendors. The point was made that the real requirement being met by any control relationship is to assure reliability, availability, and security of the services being offered. - Under scalability requirements, it was mentioned that we need to support very highly scalable systems that exceed today's PSTN transit switches in size. Tom clarified that he had not meant that ITU Recommendation E.5xx should be listed in the Megaco Architecture and Requirements RFC, but instead that the numbers given in that Recommendation should be used as design targets (particularly to guard against specifying overly-stringent response times for the protocol). - Tom's slides listed media gateway proxies (i.e. MG-Intermediate Entity-MGC) as an extension work item. It was agreed that firewalls at least must be supported from the outset. Other forms of proxying require further discussion. The charter clearly says we are working to interconnect IP networks and circuit switched networks. This would exclude voice over FR or ATM. But if we work in an abstract sense the other solutions may be included. We will work with NASREQNG and AAA to make sure their requirements are understood when we describe the MEGACO requirements and architecture. 3.3 Signalling Backhaul Scott Petrack (temporarily Scott_Petrack@Vocaltec.com) made a presentation on signalling requirements and how RTP can be used to meet them (see slides if Scott gets around to providing them). No conclusions were drawn from the discussion of this presentation. Matt Holdrege pointed out that the ATM Forum is working on RTP over AAL5 with header compression. 4. Target Media Gateway Architecture This topic was effectively dealt with earlier, in the discussion of Fernando Cuervo's presentation, so the meeting moved on to the next topic. 5. Protocol and API Chia Li (chiali@lucent.com) presented two charts under the title "Toward network independent media processing. Media Device Control Protocol (MDCP)" (see slides in file mdcpietf.PDF). Chia was filling in for Paul Sijben (sijben@lucent.com) who couldn't be present. The charts dealt with the key motivations behind the proposal for MDCP (draft-sijben-megaco-mdcp-00.pdf) and the general approach taken in defining the protocol. No conclusions were drawn from the discussion following this presentation. In the interest of saving time if a consensus already existed, Tom Taylor asked for a show of hands of support for starting with MGCP (draft-huitema-MGCP-v0r1-01.txt) as the working group's protocol base point. There was no clear consensus to support MGCP at this stage. There were enough people in the room who preferred to review the requirements and architecture first. Michael Ramalho questioned the process of asking the room for consensus. Scott Bradner said that final decisions on reaching consensus cannot be taken at a meeting. However, it can be determined that we do not have consensus, so it was legitimate to ask the meeting if there was consensus. This result means that the discussion must be taken to the mailing list. Ike Elliott suggested that at least an editor could be appointed to provide an initial draft of a protocol document, to save time. Scott Bradner said that it is too early to appoint an editor of a standards track document since in normal IETF practice the editor(s) chosen will be the author(s) of the document which eventually attracts consensus as the baseline document. Nancy Greene (ngreene@nortelnetworks.com) and Michael Ramalho (mramalho@notes.cc.bellcore.com) are the proposed editors of the working group architecture and requirements document. A number of other people volunteered their services and a third editor may be appointed. Matt Holdrege made a plea to service providers to send input to Nancy and Michael. Members of the audience suggested that call flow descriptions would be useful, showing how the protocol would be used. Christian Huitema has already provided call flows in connection with MGCP (draft-huitema-mgcp-flows-00.txt) but it was noted that these are based on the specific structure of MGCP. People might wish to submit call flows based on differing assumptions. In any event, it was agreed that the requirements document should be separated from the call flow specifications document. The meeting was wound up at this point.