III. Evaluation of Gateway Development
Each organization addressed the various aspects of gateway development - technicality, practicality, perceived necessity - to varying degrees in the meeting discussion and also responded directly to the following questions in post-meeting reports to SURA:
- Discuss your organization's views on the *technical feasibility* of developing an Mbone-H.323 conferencing gateway, both "generically" and with respect to the specific applications that were presented in the meeting. If you have particular insights into difficult and/or critical development issues, please include those.
- Discuss your organization's views on the *necessity and/or practicality* of developing the gateway(s) described above.
- Describe what your organization may be willing/capable of doing to "gateway" these technologies to each other, including your willingness to consider collaborative projects (if so, of what type?).
Excerpts of the direct responses are included below, followed by a summary on each point from SURA. This summary is based upon reflection during and after meeting discussion as well as a review of all reported responses.
On the Technical Feasibility of Gateway Development
From the AccessGrid -
"As we discussed, there is more to the Access Grid than Mbone technology. The large numbers of streams we use make interoperability more difficult than simply transcoding streams. There must be a way for H.323 users to dynamically limit the streams they will be receiving. Since we have 4 video streams per one audio stream, using the classic voice-activates-video may not make sense. These issues must be addressed in any gateway discussion.
We also use our home grown version of distributed PowerPoint which delivers high fidelity presentations to all sites with excellent slide change synchronization. This and other tools under development would need to be integrated somehow into the H.323 environment.
During the meeting we learned quite a bit about the complexity of H.323 networks, with the gateways and MCUs. It is not at all clear to me how our Virtual Venue system of organizing meetings and persistent meeting spaces maps into the h.323 phone-call model. I think a lot of the setup and connecting would have to be done by hand. Oh yes, we are mostly open source and want to keep things that way. Any solution that we contribute to must be distributable as part of our open source model."
From RADVision -
"During the presentation, RADVision realized that there isn't any real large implementation of the Mbone network. We learned that groups and organization are using the Mbone tools to build Mbone applications [but] we think that those applications are not specific to the Mbone itself. We believe that those tools can be integrated into H.323.
Technical notes specifically from Orit Levin, RADVision's Director of Product Management and also ITU-T Editor of Annex O for "Work on Internet Technologies Complimentary to H.323":
"The most straightforward and up-to-date architecture would consist of 'media server' or 'media processors' whose job would be FAST processing of RTP streams, their possible re-routing, mixing, switching. These "media processors" would be controlled from the Management/Call Control/Application Servers by standard protocols, e.g., MEGACO (H.248) or MGCP. The Management Servers themselves (detached from the Media itself) would vary from "just" configurable proprietary applications (with Web interfaces) to Mbone applications to H.323 Gatekeepers and SIP stateful proxies, enabling dynamic call establishment with capabilities negotiation. Such a Call Signaling/Management Server would be a perfect place for provisioning of both the Conference Services and the mapping of different Call Signaling approaches that may be supported by the participating endpoints...More then ever, I don't believe in a low level automatic Call Signaling Gateway - between H.323 and SIP or between H.323 and Mbone or between SIP and Mbone). I do believe that, for an Application Server using the 'third party control model', the problem of combining a call between or among end points of different call signaling type is relatively a 'trivial' issue."
From VRVS -
"Basically, everything is possible. It is just a question of resources and time. Since we already developed a Mbone/H.323 gateway embedded in our VRVS system, I would say that it is technically possible. However, a lot of development issues have been faced and others have been fixed. Here are some insights on the four main ones:
- Only G.711 audio coding is possible with Mbone tools (Rat/Vat) in order to have the possibility of exchanging audio with an H.323 node. Mbone tools don't support G.722, G.728, etc. One would need a general transcoding piece of software in order to have all the audio coding possible.
- H.323 nodes can only display one video [window] at a time [as opposed] to the Mbone tools (Vic). It is absolutely necessary to have a piece of software that sends only one video to the H.323 node (from the speaker or any kind of video [source]).
- H.263 video encoding is not yet fully implemented in the Mbone tools so the gateway will not support an H.323 node sending H.263 video streams.
- Communication bandwidth set-up is different between [the] Mbone [tools] and H.323. You just adjust bandwidth dynamically using vic (up to 3 Mbps) [as opposed] to the call bandwidth set-up (128k, 256, 384k, etc.) used with H.323. This can cause some asymmetric communication."
From ViDe -
"We observed a bit of 'apples and oranges' problem: the Access Grid is mainly a technology for immersive, multi-location environments and its multicast transport is an 'implementation detail'.
Asking if it possible to reduce 20 video/audio streams into any kind of single stream overlooks the main purpose of their project. Anyone tackling an H.323-Access Grid gateway would need a clear definition of the problem they are trying to solve, and we are not convinced that one would want to attempt stuffing the entire 18' wide Access Grid environment onto a PC screen.
We were very interested to hear that none of the developers were very keen on T.120 technology as a reliable base for data sharing, and we plan to explore some of the suggested alternative directions.
Everyone at the meeting agreed that the VRVS solution was 'elegant'. The VRVS backbone was designed as a series of VRVS servers that are networked in order to bridge (tunnel) sections of network where there no IP multicast support exists. This was a practical architectural departure from the 'no server' multicast model, and this design happens to work well for incorporating H.323 users by the addition of a call setup server. The VRVS design handles the case where an H.323 client wishes to connect into the VRVS backbone. RADVision mentioned some preliminary investigations into a "gateway" that would allow a single IP multicast client to connect into an H.323 conference through a gatekeeper.
What ViDe took away from the conference was that it would be "not difficult" to handle a single multicast user coming into a gatekeeper, or a single H.323 user coming into a VRVS multicast server. Perhaps handling end users one-by-one would solve the problem of unattached islands of
video conferencing end-users. Technology to connect a multicast backbone such as VRVS with an H.323 "backbone" such as ViDeNet would go beyond this approach, and we believe that two types of gateways would be required: one for multicast coming into an H.323 world, and one for H.323 coming into a type of multicast world. It should be noted that the VRVS world is a subset of the IP multicast world, in that native IP multicast employs no servers at all; to introduce multicast servers into the mix is changing the native IP multicast architecture.
ViDe observes that open source H.323 is critical to the success of any effort to create a multicast-H.323 gateway and strongly advocates the Open H.323 effort. We expect that commercial H.323/SIP communications systems will develop rapidly and we believe commercial vendors should focus on the value they add to standards-based systems, rather than attempts to capture the standard."
Summary Observations from SURA -
It appears that at least limited functionality gateways can be developed between H.323 and specific Mbone tool based conferencing implementations. "Full-featured" gateways from an application point of view - those that smoothly offer all features of one technologies "user experience" for sharing with the others - would present many technical challenges. Several areas of difficulty in gateway development are described above and others can be suggested:
- Support for multiple audio/video algorithms and the attendant transcoding
- H.323 being IP multicast aware and capable
- Establishment of sessions (announcement of availability vs. "dialing" vs. continuous presence)
- Accommodation of varying multipoint models (centralized vs. decentralized control)
- How to manage/select multiple views or determine appropriate levels of participation for "space limited" (individual use) endpoints
- Lip sync
- Integration of H.323 Supplementary Services (e.g., "hold", "transfer", "forwarding" for sessions)
- Coordinated support for expansion of optional codecs (e.g., MPEG)
Since the Mbone tool based implementations are not bound to any standard for describing how sessions are established, maintained, etc, there is more freedom on that side for gateway innovation. It is highly likely that "flexing" an H.323-compliant implementation to share full functionality with either of the existing Mbone tool based implementations discussed here would result in some violation of the H.323 standard. This is speaking strictly from the point of view of trying to bridge/duplicate the technical underpinnings of how each implementation's functionality and features are enabled today.
If one considers the concept of a "gateway" at the level of the functionality that a user sees and what that user can then do, changes in the technical underpinnings could result in a greater likelihood of gateway success. In addition, though RADVision was just being introduced to both the AccessGrid and VRVS at this meeting, it was their observation in conversations surrounding the meeting that the user functionality of the Mbone-based implementations could likely be duplicated with an H.323 implementation. This application does not exist today, reflecting the gap between what the standard defines and/or allows and what product developers have yet to produce for the marketplace.
On the Practicality/Necessity of Gateway Development & the Potential for Collaboration
From the AccessGrid -
"Because our resources are so thin and since our research here targets group oriented collaboration and we are working with others installing AG nodes, we don't feel a strong necessity to work on developing this gateway. We do believe such a gateway would be beneficial to both communities and encourage the development of it."
"We learned that Phillipe [the VRVS] has figured out a way to bridge H.323 and Mbone streams. We are interested in that technology as an enabler for solving some of the other above mentioned interoperability problems. The problem is that this work is not open source and we don't see how it can be integrated into our work. Nevertheless, if someone knowledgeable about using this work with H.323 systems wants to experiment with connecting into an AG session, we'd like to try that. Beyond that, we are also willing to try experiments on our own to see if we can duplicate the bridging [that the VRVS] is doing. If we can show that, we would have a project that someone could work on to develop a full function open source bridge."
From RADVision -
"As described before we believe that there isn't a need for an Mbone to H.323 gateway. The main reason [is that] no one uses the Mbone network as a multicast network...As a company, we would work with each one of the groups if [each side realizes] that there is a business case to work together."
"Technically we believe that we can build an Mbone gateway. But since it is not really needed, we believe that the right approach is to work with individual groups and try to find a solution to [fit] their application."
From VRVS -
"Since we found that it is critical in our application community (world-wide, distributed and using both technologies), the necessity to develop this gateway arose one year ago. Today, we have reached the point where we have a way to have both technologies working together. But there is still work to be performed."
"Our organization is capable of doing this gateway. More work has to be done especially in doing the transcoding of different Audio and Video compressions. Current resources and priorities will limit us to having only a basic gateway (H.261, G.711) and [using it] with VRVS. We are certainly willing to collaborate in some project trying to build the missing pieces as explained above but not to the detriment of current VRVS development and production. It could only be done with additional resources."
From ViDe -
"Because of the different technologies, different histories and cultures of the end-user communities, and past lack of interoperability, ViDe finds it difficult to predict who would really need or want to use a multicast/H.323 gateway, but we already appreciate the desire for a single end-user with one kind of technology on their desktop to be able to participate in videoconferences that happen to take place in the other type of technology.
ViDe is strongly committed to exploring ways of effectively informing our constituents of the range of options, differences, and compatibilities between the various conferencing solutions. If there were a VRVS/H.323 freely available to ViDeNet, ViDe would use it; we would expect VRVS and/or the H.323 developer to support development of such a gateway. If there were an IP Multicast/H.323 gateway available to ViDeNet, ViDe would use it; we believe that it would be appropriate for anyone seeking to do this to go after research dollars (SURA/NSF/private) to fund its development."
Summary Observations from SURA -
Universally, "vanilla" gateway development is outside the scope of current work for each of these organizations and could not be undertaken without the application of additional resources. No one tried to dispute or conceal this fact but all expressed their appreciation at being part of the meeting and their willingness to collaborate further if the resources (and, in some cases, a specifically defined need) could be identified. In addition to this, during the meeting and through conversations that surrounded the meeting, there were several conversations between different pairings of the organizations that were present, seeking to learn more about specific aspects of the other's work and contemplating further discussion. We hope that this is a sign that SURA's first goal - that of raising awareness of each other and each other's work - was met.
![[Top]](go_top_b.gif)
IV. Conclusion
What has become obvious (or more obvious) throughout the exploration of an Mbone-H.323 gateway is the simple fact that the conceptual communication model and desired scope adopted by any given developer ultimately determines their implementation, including "look and feel", functionality and features, and integration of technology components. The AccessGrid and the VRVS are each specific implementations built towards specific purposes and target audiences. The evolution of each is likely to be a balance between the vision of the developers and response to specific user demand as the "target audience" becomes the "user community". ITU H.323 is not a specific implementation but rather the description for international multimedia over IP capability. As such, the definition of even seemingly small functionality has to remain mindful of "fitting in" with the larger scope of interoperability.
These differences in scope and motivational drivers produce interesting and significant differences in how each organization is likely to approach and also value collaborative development. Whereas the AccessGrid and VRVS may have more technical flexibility in what they could develop or how they might develop it, development is directed and channeled by specific project goals and targeted user demand. H.323 standards developers are not targeting particular user groups or even particular products; they are specifying guidelines that will enable a wide variety of compliant products to inter-operate with each other. Collaborative endeavors would be less guided or restricted in terms of implementation characteristics (what users are being targeted or particular features that are desired) than by how that implementation can be achieved.
Currently, the level of activity that each of these organizations is putting towards exploration and/or development of Mbone-H.323 gateways (which may be none at this time) is fully in keeping with their own project/business objectives and scope. This is expected and understandable. Yet, all of them did indicate their willingness to participate in further discussion and possible collaborative projects in this area if the need can be demonstrated and additional resources applied. This is good news for those who believe that further gateway work is necessary. However, it also means that gateway proponents will need to develop both the plan and the required resource pool for this development and also most likely need to drive the process.
V. Recommended Next Steps
Through this meeting, we have had significant affirmation of both the technical feasibility of developing a gateway (or gateways) and also the willingness of leaders in each technology area to work together. However, the degree of urgency and necessity for developing such a gateway remains unclear. The logical next step for SURA (and others with interest in the possible bridging of Mbone tool-based applications and H.323 video conferencing) is to undertake closer investigation in order to evaluate: 1) what communities would benefit from the existence of a gateway, and 2) what the specific benefits would be. Questions for this investigation include:
What is the existing and potential overlap between the user communities for each of these technologies? This question is best approached through identification of the current and intended user base for AccessGrid and VRVS deployment within the SURA region matched to an assessment of current and intended H.323 deployment within those identified user communities. Due to the fact that both the AccessGrid and VRVS have functionality that is either dependent on or enhanced via IP multicast, this survey should also attempt to measure the extent of and plans for multicast deployment for those user communities and the networks that interconnect them.
What is the desire/demand for gateway capability on the part of the overlapping user communities identified above? This question should be approached through a survey that considers institutional plans for implementation as well as direct end user acceptance and intent. The survey should also identify varying conceptions of what a gateway would look like and what functionality it might provide.
What resources would be required (time, money, expertise) to develop a gateway application and/or service that would be useful to the SURA community? In order to answer this question, a more detailed technical definition of the end product is required. This definition is highly dependent on information gained from answering the two questions above. Once the question of "who wants what?" is clear, relevant developers should be brought together again to prepare an outline for development and an estimate of the cost.
Appendix A: SURA Mbone-H.323 Gateway meeting attendee list
September 27, 2000, William Young Library, University of Kentucky
