SIP323 BOF Minutes (report by Dave Walker) On Monday, March 27, the SIP323 BOF was held at IETF-47 with the goal of determining how and where SIP-H.323 interworking should be investigated and developed. The co-chairs of the BOF were Joon Maeng (VTEL) and Dave Walker (SS8 Networks). These minutes were recorded by Dave Walker (and I accept full responsability for all errors of transcription). The proposed agenda was: 1. Agenda bashing (5 min) 2. Motivation (5 min) 3. Requirements (10 min) 4. Coordination with other groups (10 min) 5. Proposed charter (5 min) 6. Discussion (20 min) 7. Wrap-up (5 min) Introduction and Motivation (slides: Intro+Motivation.ppt) After the traditional agenda bashing, Joon presented slides outlining the motivation for investigating interworking. The essence of this is that there are already many H.323 products available and deployed, and that in order to accelerate introduction of SIP products, it is necessary that it be possible to establish calls between the two systems. The signalling is different, but similar from a high level, and the media streaming is the same, so what is needed is a form of signalling gateway. It was pointed out that documenting how the interworking should be done is intended as an aid to interoperability. The claim was made that the IETF is the appropriate place for this work, as there is very limited SIP expertise in the ITU (home of H.323), and in fact significant H.323 expertise. The presentation suggested that a new Working Group should be chartered. Jonathan Rosenberg pointed out that since the same people who are involved in the SIP WG would likely also be involved with any new SIP-H.323 WG, there was no significant advantage to having a new WG. Requirements (slides: Requirements.ppt) Then Dave Walker presented slides proposing a set of requirements that the group should address. This proposal was apparently based on an emerging consensus on the sip-h323 mailing list, where these issues are being discussed. The solution should be procedurally compliant with H.323 version 2, and with RFC 2543. This would not necessarily result in the gateway being a fully compliant H.323 endpoint or SIP UA. Four configurations were illustrated, with the H.323 Gatekeeper and SIP proxy server being optionally present. The development was proposed as a two phase effort. The first phase would be limited to "Basic Call", and the second phase would add "Services" support. This is a reflection of current market needs. It was mentioned that it will be difficult, if not impossible to correctly map all of the supplementary services. There was some question as to why addressing was considered as a requirement, since we will have ENUM and a variety of mapping techniques that have been described in the three interworking documents published to date. The answer was that there is not complete consistency between all proposed approaches, and that part of the investigation will be to ensure that the proposed solution works under all conditions. There was some consideration given to the fact that some form of common call identifier may be required to correlate call records between call legs on different sides of the gateway. RadVision/ITU-T (slides: rvsn-itu.ppt) Orit Levin (RadVision) presented another view of interworking issues and requirements. This presentation made clear that H.323 could utilize a variety of protocols that have been or are being defined in the IETF. It then proposed SIP-H.323 interworking requirements in four categories: topology, services, data capabilities, protocol versions. These suggestions were very similar to what Dave had shown. During this presentation, Dave Oran pointed out that TRIP is a routing protocol, and not intended for services location (as was indicated on one of the slides). A question was raised about how SIP extensions and H.323 annexes should be included. This interesting point will be subject of discussion among interested parties as work progresses. Dave Oran questioned the omission of any mention of QoS support. Henry Sinnreich suggested that our immediate needs are to support managed networks, so that QoS could be considered after phase 1. Dave Wang agreed with the need for QoS, especially as data types are increaasingly mixed, but said that we need to wait for QoS support to actually be present in networks. IMTC aHit! and ETSI TIPHON (slides: IMTC-aHIT!.ppt) (slides: TIPHON.ppt) Dave Wang (Nuera) presented the requirements that have been determined by the IMTC Applications over Harmonized IP Telephony (aHIT!) Activity Group. After a brief introduction to the role played by IMTC, the presentation listed several applications that go beyond the level of interworking that is proposed for development in the IETF, such as billing and AAA, fax over IP, Internet Call Waiting, and conferencing. The requirements that were proposed by aHit for basic call, including protocol versions and call scenarios, were in accordance with what was proposed by Dave Walker in his presentation (due to prior discussions with members of the aHIT! AG). Dave emphasized that security will be an issue, regardless of whether each side of the signalling gateway is in a separate domain or if the gateway is entirely within a single domain. He also pointed out that a common model will use clearing houses for correlation between domains. Dave also presented a view from ETSI TIPHON. Although the work on SIP-H.323 interworking is quite early in TIPHON, the presentation made it clear that the architectural models that are being used in that group are intended to be protocol agnostic. Dave emphasized the feelings from both IMTC and ETSI that we all should work together to share the work, and not overlap efforts. Objectives (slides: Objectives+Milestones.ppt) The final presentation was made by Dave Walker who proposed that the IETF should develop 4 documents: interworking requirements, a Phase 1 spec, a Phase 2 spec, and a MIB (if required). The requirements document would be informational, with the others being standards track. A fairly aggressive schedule was then proposed, with requirements done by August, and Phase 1 completed by September. General Discussion Following this presentation, general discussion ensued. It was pointed out that the term Signalling Gateway is inappropriate, and that Interworking Function (IWF) is preferred. Brian Rosen indicated that since we're only talking about a single box, whose externally visible protocols are already defined standards, there is no need to define any new interoperability requirements. Christian Groves brought up the example of SIP-ISUP interworking which is currently being developed in the IETF. Jonathan Rosenberg suggested that one, or several informational RFCs would be adequate. He also proposed that OSP could solve the call identifier problem. Scott Petrack raised the point that it would be difficult to map security measures from one side to another considering that they're poorly understood even within a single signalling domain. Dave Oran voiced a concern that if a SIP-H.323 interworking was standardized, it might prove an impediment to further development of the SIP protocol and extensions since they might break the defined interworking. Dave Walker replied that this shouldn't be the case since the interworking is to be SIP compliant, so any thing that breaks the interworking would also break other forms of SIP device. Tom Taylor mentioned that it should be up to implementors to provide predictability of services, not to an interworking function. Jonathan wasn't even sure that predicatability of services was more important that the ability to differentiate products. Henry Sinnreich felt that services shouldn't be standardized - protocols should be, since we don't want to stifle competition. He felt that at this point, it may be to early for standardization, and that implementors should be left free to implement and innovate. At this point (actually earlier), Scott Bradner had had enough, and moved the session to a conclusion. He felt that there didn't seem to be a great deal fo support for a new Working Group. There was support for documenting implementation experience, although not necessarily as a Working Group activity. He also voiced a concern that an interworking standardization would put pressure on SIP. The conclusion was that a new draft should be put together, to be published as an informational RFC, or less likely as a BCP RFC. This document must include an architecture and requirements description. If subsequent development gives rise to issues that cannot be resolved some other way, another BOF could be held.