INTERNET-DRAFT T. Johnson CAVNER / UNC-CH M. Yafchak NYSERNet March 2000 The ViDe Reference Model for Internet-extensible H.323 Communications Filename: draft-johnson-yafchak-vide-h323-reference-model-00.txt Expiration Date: September 30, 2000 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted but other documents at any time. It is in appropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (c) The Internet Society (date). All Rights Reserved. Abstract This paper discusses H.323 communication as it is being developed and implemented within the context of today's Internet (I1 and I2). As such it suggests a model that the authors believe can be developed using current thinking, protocols, and practices. It is also intended to support a vision for future communication development that will allow multi-mode communication to become more universally useful for end-users while becoming more sophisticated and reliable in its technological foundation. The authors see the concepts emerging within and around the development of the H.323 standard as some of the most promising today for enabling Internet-extensible multi-mode global communication. After a brief presentation of a communication model, several problems and concerns with the present state of H.323 communication are presented along with specific recommendations for changes in these areas. Several key foci serve as a foundation for the ideas presented herein. It should be understood throughout that the following are considered necessary: mobility of the service provided, security in using and in managing the service, scalability of the service, and the ability for IP network service providers to autonomously implement H.323 services without external control or involvement by PSTN operators. These foci necessitate that several key implementation areas be addressed: Johnson & Yafchak INTERNET-DRAFT Page 1 ViDe Reference Model for H.323 Communications March 2000 - Gatekeeper address resolution and naming schemes (alphanumeric alias naming as well as naming by numeric extension). - The use of H.323 metadata to provide smooth integration with other commonly used information systems (e.g., the World Wide Web). - Directory services and account management (user lookup, maintenance of user account information). - User and device authentication (including single-user and multi-user system authentication schema, E.164 authentication, and the ability to integrate user authentication with support for network transport/policy decisions). - Inter-zone gatekeeper communications, including suggestions towards a protocol to integrate with future policy-based networking and QoS offerings. - Administrative recommendations for more robust or special services to more fully align H.323 implementations with expected Internet-based performance. The paper is intended to provide encouragement and a focal point for discussion in all of these areas. The authors have included their contact information in Section 7: Authors' Addresses and welcome input from both the Internet and H.323 development communities. Table of Contents 1. Introduction 2. Communication Simplified 3. The Role of H.323 Communication 4. Key Implementation Issues 4.1 Underlying Design Goals 4.2 Gatekeeper Address Resolution and Naming Schemes 4.2.1 Alphanumeric Naming by Alias 4.2.2 Numeric Naming by Extension 4.3 H.323 Metadata 4.4 Directory Services and Account Management 4.4.1 External vs. Internal User Lookup 4.4.2 External Lookup - Conditions and Parameters 4.4.3 Internal Lookup - Conditions and Parameters 4.4.4 Maintenance of User Account Information 4.4.5 Availability and Functionality of Directory Services 4.5 Security 4.6 Authentication 4.6.1 User Authentication vs. Device Authentication 4.6.2 User Authentication and Network Transport/Policy Decisions 4.6.3 Gatekeeper Authentication 4.6.4 Multi-user Authentication 4.6.5 E.164 Authentication 4.6.6 Inter-zone Access to Gatekeeper Services 4.7 Policy-based networking and QoS 4.8 Administrative Recommendations for More Robust Services 4.8.1 H.323 Processes as Services and Daemons 4.8.2 Call Control, Logging, and Administration 4.8.3 General Addressing 4.8.4 Special Services 5. References 6. Security Considerations 7. Authors' Addresses 8. Copyright (C) The Internet Society (date). All Rights Reserved. Johnson & Yafchak INTERNET-DRAFT Page 2 ViDe Reference Model for H.323 Communications March 2000 1. Introduction This paper discusses H.323 communication as it is being developed and implemented within the context of today's Internet (I1 and I2). As such it suggests a model that the authors believe can be developed using current thinking, protocols, and practices. It is also intended to support a vision for future communication development that will allow multi-mode communication to become more universally useful for end-users while becoming more sophisticated and reliable in its technological foundation. The simple communication model outlined in the section directly below illustrates the latter. Subsequent sections detail known problems or concerns with the present state of H.323 communication (within the H.323 standard or within recent product implementations of that standard) and recommends changes in these areas. These sections are intended to provide an outline for the development of a working model that demonstrates the best current understanding of Internet-extensible H.323 communications. 2. Communication Simplified The future vision underlying this paper is based on a very simple communication model. Though communication can and does, in fact, take place between devices as well as humans, the proposed model concerns itself with messages where humans are the ultimate end-points. A sender then is assumed to be anyone who wishes to send a message to anyone else. A receiver is anyone who wishes to be open to the receipt of incoming messages. If we begin with this simple model, some basic tenets emerge: A) A sender's options for message content in the foreseeable future are data, voice, video, or some combination of those. To send this content, the sender ideally needs a single application that provides a universal, human- friendly, secure means of creating and packaging the message and reaching the desired recipient. B) A recipient has two options: "I'll take the message live", or "Leave it in my inbox" This would be applicable to email, voice mail, video mail, or, eventually, "combo-mail". These conditions exist today in our various messaging systems though not in any integrated form: Live Receipt Inbox ------------ ------------ Data messaging Talk, Chat, Instant Messaging Email Voice messaging Telephone Voice mail Answering machines Video messaging Video Conferencing "Video mail" [not implemented as of this writing] C) There should ideally be a single application that receives all incoming messages on behalf of the recipient and handles them according to the recipient's current availability status ("Live" or "Inbox"). The interface/application that allows the recipient to check the Inbox and "handle" the messages (e.g., view, reply, forward) should be the same one Johnson & Yafchak INTERNET-DRAFT Page 3 ViDe Reference Model for H.323 Communications March 2000 that enables the recipient to act as a sender. 3. The Role of H.323 Communication We see the concepts emerging within and around the development of the H.323 standard as some of the most promising today for enabling multi-mode global communication. True, there are many complex issues to be resolved and processes to be integrated in order to approach the simple model discussed above. However, there is great potential for convergence around H.323 as a specification capable of integrating the best we have come to expect from traditional telephony, video conferencing, and IP data communications. It is with an eye towards this that we present the sections below, outlining the issues and latest developments in several key areas and proposing immediate implementation changes to enable the design and development of a short-term working model for Internet-extensible H.323 communication. 4. Key Implementation Issues 4.1 Underlying Design Goals Several key issues drive the technical schemes suggested in the following sections. The first is the concept of mobility. A user should be able to move from her desktop computer to a conference room for a meeting, travel by automobile with cellular telephone access, dial in from home using an ISP and use a standard telephone without losing access to her communication services. Whatever services are subscribed to by the user should follow her as she moves throughout her day, including 'phone number', email, voicemail, videomail, conference calling, address book and other personalized features of her account. The availability and character of each service may change, being mitigated by the underlying network type from which each access is made. For example, a videomail message may be retrievable from a desktop h.323 station, but checking mail from a standard telephone should yield up the audio portion of the message. The second concept is that of security. The existence of mobility implies the availability of a reliable authentication scheme. Without reliable authentication, services cannot be billed for and costs recovered. As long as security remains unaddressed, h.323 services will continue to be 'toy' applications without a fundamental underlying business case behind them. This is the case with the current generation of h.323 products and deployments. The third concept is that of the scalability of services. Communication services must be scalable to all inhabitants of the earth, because any person is a potential user of the services. The existence of multiple private stratified or interlaced networks will not meet the fundamental criteria of any user being able to contact any other user. That said, it should be possible to construct virtual private networks if so desired. The concept of global scalability implies the existence of a unified, unique and mobile numbering scheme for all users. The fourth concept is that of scalability of specific implementations. It is desirable to put in place systems that will scale to very large numbers of users and be highly integrated with existing large-scale directory Johnson & Yafchak INTERNET-DRAFT Page 4 ViDe Reference Model for H.323 Communications March 2000 services, network policy servers and security systems. At the same time, network managers are unwilling to invest the huge sums of time and money to create totally integrated, large scale h.323 systems when they only have one hundred users on the network. What is needed are systems that can be implemented cost-effectively and in a 'standalone' fashion now, but that have 'hooks' into external services that allow for integration and scaling as the service grows. A final and important concept is that h.323 services should be able to be implemented autonomously by IP network service providers without external control or involvement by PSTN operators. Indeed, the primary reason why there is so much interest in h.323 today is not so much because it provides a rich new feature set, but because it is free from the heavy handed control of today's PSTN 4.2 Gatekeeper Address Resolution and Naming Schemes In keeping with the existing H.323 standard, there should be two forms of addressing supported. The first, extension, is a numeric address that is designed to maintain compatibility with the PSTN. The second, alias, is an alphanumeric address that is Internet-centric. The extension is meant to provide backward compatibility with PSTN terminals that are only capable of generating the 1,2,3,4,5,6,7,8,9,0,#,* symbol set. Both forms of addressing should be supported simultaneously on the h.323 network. It is anticipated that over time the extension address will no longer be necessary. The alias is the primary and preferred method of addressing on the Internet and should be used whenever possible. The primary feature of an h.323 naming scheme is that the IP address of the dialed gatekeeper is easily determined from the dialed address itself. The reasons for this are: * No central naming authority should 'dole out' addresses. A central authority undermines the autonomous nature of h.323. * The currently implemented static table, proxy and multicast gatekeeper address resolution schemes do not scale to a global level. Indeed, they do not scale to even the size of the current h.323 deployment. * Network service providers with existing operational IP networks should be able to immediately add remove or change h.323 zones without registering those changes. * IP addresses are unique. * IP addressing, coupled with DNS, already provides these capabilities at the network layer. 4.2.1 Alphanumeric Naming by Alias Aliases should be of the form user@gatekeeper.domain, where user represents the local alias of the user and gatekeeper.domain represents the DNS name of the gatekeeper to which that user is registered. When an originating gatekeeper receives a call setup request to a destination user@gatekeeper.domain, it first parses out gatekeeper.domain and resolves the IP address of that destination gatekeeper. The origination gatekeeper then signals the destination gatekeeper to establish a call to user in the destination gatekeeper's zone. It can be assumed that calls placed to user Johnson & Yafchak INTERNET-DRAFT Page 5 ViDe Reference Model for H.323 Communications March 2000 without the @gatekeeper.domain portion of the address are local calls to users within the home zone. All services on the network should be similarly named, i.e. service@gatekeeper.domain . In general, network operators will choose to align h.323 alias fields with user IDs on existing authentication systems. 4.2.2 Numeric Naming by Extension Numeric addresses should be of the form gatekeeper+extension, where gatekeeper is the fully expanded (including leading zeros and excluding periods) IP address of the gatekeeper to which the user extension is registered. For example, a gatekeeper with IP address 152.2.21.1 and a user in that zone of extension 962-4978 would be referred to as 1520020210019624978. In this way a gatekeeper originating a call to another zone can immediately parse out the IP address of the destination gatekeeper. It should be noted that numeric names do not support gatekeepers whose IP addresses are dynamically assigned. Neither does it support IP version 6, though it could be extended to do so. Because of these factors, the authors feel that a seamless alignment of h.323 addresses with E.164 addresses is not a useful design goal. Further, there is no useful mapping of gatekeepers to E.164 sub-address (e.g. area codes). Still, using this naming scheme, PSTN gateways can be built using v.25bis that give h.323 terminal end stations on the IP network E.164 style DNs from the PSTN. In this way, users can have an extension that looks exactly like an E.164 number to PSTN-originated calls creating the illusion that the IP 'phone' is actually a normal 'phone.' Users originating calls on the PSTN should never be concerned with the gatekeeper portion of the address unless they are dialing from the PSTN into a gateway and thence to a third zone for toll arbitrage purposes. Still, this scenario supports the creation of IVR (Interactive Voice Response) services that could prompt a user for the destination gatekeeper field for inter-zone dialing. In general, many user-friendly interfaces could be built on top of this architecture, including text-based menus that are downloaded to telephones with alphanumeric displays as well as voice- recognition-driven directories. Those interfaces are beyond the scope of this document but will be important components in the creation of successful products that bridge the PSTN and IP networks. 4.3 H.323 Metadata Multimedia Conferencing, MMC, should be defined as a metadata type to allow for embedding of h.323 transport services within other document types. A tag of the form mmc://johndoe@netcall.unc.edu should be used to signal web browsers, document editors and other applications that the h.323 application registered with the application or operating system should be invoked and a call placed to johndoe@netcall.unc.edu. In this way, web pages, including html-based directory services, can be built with links that activate calls to specific users. Services, such as mmc://mcu.netcall.unc.edu or mmc://voicegateway.netcall.unc.edu, can be linked in the same way. Johnson & Yafchak INTERNET-DRAFT Page 6 ViDe Reference Model for H.323 Communications March 2000 4.4 Directory Services and Account Management 4.4.1 External vs. Internal User Lookup In general, gatekeepers should not maintain private tables of users because this creates another set of user accounts that must be supported by the zone administrator. All information about users should be stored externally so that it is accessible not only by gatekeepers, but by other systems vital to the operation of the zone's core business, such as billing, directories, account information, status, etc. Relevant information for H.323 calls includes user ID, password and a list of services to which each user is subscribed. The gatekeeper does not retrieve information that is irrelevant to it, such as date of birth, social security number, etc. For the sake of this document, we will refer to the process of a gatekeeper querying these external systems as 'external user lookup.' However, a gatekeeper attempting to do an external user lookup during each call setup would introduce unacceptable delay into the call setup process. Therefore, it is suggested that the gatekeeper take the result of the external user lookup and store it in a local high performance database. It is not the responsibility of the gatekeeper to maintain this database in any way. The gatekeeper simply retrieves information from the database that is relevant to its operations. For instance, when a terminal end station places a call, the gatekeeper finds the user information, based on user ID, in the internal database. For the sake of this document, this process is referred to as 'internal user lookup.' For implementation efficiency, the internal database should be a separate application (i.e. not integrated with the gatekeeper) that uses the same query protocol (LDAP) as the external database. This facilitates the construction of small scale 'standalone gatekeepers' that allow network administrators to deploy small- scale non-integrated h.323 zones very cost effectively. 4.4.2 External Lookup - Conditions and Parameters External user lookup should happen whenever a terminal end station registers with the gatekeeper, either as a part of RAS or as an additional process added to the h.323 standard. This causes the gatekeeper to do an external user lookup on that user and move the information into the gatekeeper's internal database. Calls placed by the terminal end station are thus referenced against the internal database. This ensures that user lookup is very fast and not dependent on the speed of the external user database. It also helps to keep the size of the internal database low, since it only contains entries for users that are currently on the network. The gatekeeper should also have an administratively configurable refresh period that causes the gatekeeper to do an external lookup and update its internal database for each currently registered endpoint. If this refresh causes a condition that would effect the parameters of a call currently in progress, the decision of whether to disrupt the call immediately or have changes invoked after the call has been completed should be configurable on the part of the h.323 system administrator. A scenario where this feature would be used would be the case of an employee who moves from one department of a company to another, but never turns off (unregisters) her terminal end station. In this case, the privileges she had under the old Johnson & Yafchak INTERNET-DRAFT Page 7 ViDe Reference Model for H.323 Communications March 2000 department should be replaced with those of the new department for her account. Terminal end stations should also have a 're-registration' button that causes them to re-register with the gatekeeper and causes the gatekeeper to refresh its internal database with information from the external user database. Additionally, terminal end stations should have user-configurable time value in a personal preferences area that allows them to choose how often their terminal end stations periodically re-registers (useful values might include 60-600 seconds, now, and only on application startup). This ensures that the gatekeeper has access to reasonable up-to-date information about the status of a user's rights on the network. 4.4.3 Internal Lookup - Conditions and Parameters As an implementation issue, the gatekeeper's internal database should be capable of containing permanently defined users that are not accessible via the external user lookup function. This provides the gatekeeper vendor with a 'standalone gatekeeper' which is useful for smaller clients that have not yet implemented large-scale external user databases. It can also be used as a place to define exceptional users that are not in the external database, such as guests and system administrators. 4.4.4 Maintenance of User Account Information All changes to a user's account information, including their password and which services are available to them should be made from applications external to the h.323 network. For example, a student registration application might enable a certain multipoint call service right for all students currently enrolled in a specific class. The gatekeeper should have no knowledge of this. If that student tries to access that service, the gatekeeper will discover upon terminal end station registration whether or not that right is available for that student. Scheduling for h.323 resources should be built upon this model. A scheduling program should enable and disable specific rights in the external user database in real time. The gatekeeper will only allow use of requested services if they are enabled at that particular time for that particular user. The scheduling application is not related in any way to the gatekeeper. However, developers wishing to implement small 'standalone gatekeepers' could implement a basic scheduling package that accesses the internal database. Groups of users should be managed in this way as well. Group rights management is already a mature concept in directory services and authentication schema in place today. 4.4.5 Availability and Functionality of Directory Services The dynamic directory service scheme currently supported in h.323 and exemplified by Microsoft's Internet Locator Service is not a useful tool for extensible h.323 communications because it does not identify user zone information and thus cannot be used for dialing. Rather, directories should be web accessible lists of all users in a zone, regardless of whether or not they are online at the time. Johnson & Yafchak INTERNET-DRAFT Page 78 ViDe Reference Model for H.323 Communications March 2000 In general, a zone directory will be created by an external application that generates html from the external user database. However, vendors wishing to create small scale 'standalone gatekeepers' may wish to include a small web server as a part of their product that serves directory information from the internal user database. In this case, the internal user database should contain additional fields for personal information such as name, URL, address, etc. Directories should use the mmc://johndoe@netcall.unc.edu metadata as described above to provide 'clickable' connection from the directory. 4.5 Security All devices on the network should be protected with a user ID and password. This includes gatekeepers, gateways, and MCUs. It should not be possible to obtain http, telnet, SNMP or flash upgrade access to a device without a user ID and password. All security information should traverse the network in encrypted form. 4.6 Authentication 4.6.1 User Authentication vs. Device Authentication There is currently little agreement in the h.323 world about the fundamental mode of authentication. Some implementations take the 'telephone model' approach in which the actual physical instrument is the entity known to the network. In this model, access to and services available from a physical instrument are available to any person using that instrument, and all usage tracking is referenced against that instrument. The network does not know what human actually used the instrument. Security is thus controlled by limiting physical access to the device, for example by placing it in a locked office. Another approach is the 'Unix model' in which a user provides a user ID / password pair to assure their identity. In this model, the network does not care which physical computer is actually used to gain access. It is only concerned that the proper individual is granted access to their predetermined resources. The authors strongly favor this approach for h.323 communications. This approach provides a number of advantages to the end user. First, it is mobile, so users can access their account from their office machines, home computers, or mobile communication devices. Secondly, it creates a security model adequate to allow 'kiosk' access to the h.323 network. This is critical in public spaces such as classrooms, laboratories, conference rooms, reception areas, 'pay phones,' etc., where it is desirable to have h.323 communication capabilities that do not compromise the security of the network by providing 'wide open' access to the network in a public space. Additionally, because each user is uniquely identified on the network, their individual 'profile,' or set of subscribed services, is always available regardless of their physical location. 4.6.2 User Authentication and Network Transport/Policy Decisions In general, h.323 gatekeepers should not utilize physical location, i.e. IP address, in determining the identity of users and the availability of services to those users. Because dynamic IP address allocation is becoming Johnson & Yafchak INTERNET-DRAFT Page 9 ViDe Reference Model for H.323 Communications March 2000 more common and address spoofing is easy to accomplish, this approach provides little advantage. Rather, the network itself should mitigate the resources available to a given terminal end station. For example, if a user generally has access to 6-way multipoint calling by virtue of that service being defined in her account, she should have access to that service whether she is on a major fiber backbone, T1 line or wireless network. The gatekeeper should grant access to the service without regard for the network transport in play. The underlying network itself, however, using some form of policy based networking, will allow or disallow various types of connectivity based on physical location. For example, if the user connects in from a fiber backbone, she may access her 6-way service at 1 megabit per second. However, if she moves over to a location that is T1-connected, the network may only allow her access to 128 kilobits per second for her 6-way service. In this model, h.323 authentication is performed at the application layer on a per user basis, as in the 'Unix model.' At the network layer, access is granted based on physical connection, as in the 'telephone model.' By separating application and physical layer authentication in this way, h.323 gatekeepers can be developed and deployed without the unreasonable burden of their being aware of the underlying network transport. 4.6.3 Gatekeeper Authentication Users should authenticate themselves to the gatekeeper in the zone in which they are registered by transmitting an encrypted user ID (alias) and password to the gatekeeper. The gatekeeper will also record the IP address of the station that is requesting authentication. The gatekeeper will authenticate the user via the internal database (for standalone gatekeepers) or via a call to an external authentication server. Once the user is authenticated, the gatekeeper should allow calls from that terminal end station / IP address pair. Users should be de-authenticated whenever they unregister from the gatekeeper or after a timeout value has elapsed. This timeout value should be configurable on a per user basis by the zone administrator to be from 'this call only', to several days in order to allow for mobility between end stations and alignment with DHCP leases. Gatekeepers should support Pluggable Authentication Modules (PAM) to allow them to hook into existing authentication schemes in place, such as those built around kerberos, UNIX or Windows NT. The following functionality should be defined as a protocol and added to the h.323 standard: prompting for password, encrypted transmission, acknowledgment of authentication, acceptance of calls, rejecting of calls. Since not all terminal end stations will support this new standard, the authors suggest that gatekeepers provide alternate ways to accomplish authentication. One method is for the gatekeeper to provide a web interface that allows the user to authenticate. Another method is for the gatekeeper developer to provide a small application that can be given away to h.323 client developers or downloaded and installed on a client machine. This application could prompt the user for a ID/password pair and pass that information to the gatekeeper. The Johnson & Yafchak INTERNET-DRAFT Page 10 ViDe Reference Model for H.323 Communications March 2000 application could be standalone or called from the h.323 client application. This functionality also opens up the possibility for 'pay phone' services that require a credit card number to be entered along with the authentication information. 4.6.4 Multi-user Authentication H.323 terminal end stations should be multi-user profile aware when running in multi-user operating system environments. When a user logs onto a machine with a user ID and password, the h.323 client should present the user with an identification screen. The screen should allow the user to choose to accept the currently active user ID and password pair (default), or specify another one. This information should be saved so that subsequent logins to the machine do not require re-entry of this information. Whether or not to save password information should be left to the user. The actual authentication handshake should occur as described in the previous section. When an h.323 system handles authentication in this way, terminal end stations that are multi-user profile aware achieve true multi- user performance. Terminal end stations that are not multi-user profile aware, such as many of the current generation of end stations running under Windows 95, behave as 'telephone model' single user instruments. This is an acceptable tradeoff and allows integration of legacy h.323 clients. 4.6.5 E.164 Authentication Authentication for terminal end stations that do not support alphanumeric entry is extremely problematic. For example, a user dialing into a zone via gateway has no way to type in a user ID and password. That user's ultimate user ID and password are stored in a central authentication server and are almost certainly alphanumeric in nature. One possibility is for the gatekeeper to authenticate the user using an extension / PIN pair. The gatekeeper could use IVR to prompt the user for a PIN. In this case, the PINs would have to be stored in an external database, possibly via the LDAP directory server or in a completely dedicated PIN server. This represents functionality that is not part of the PSTN today. In return for the extra step of authenticating via a PIN, telephony end-users would be provided with an unprecedented level of secure and mobile network access. 4.6.6 Inter-zone Access to Gatekeeper Services There is currently a need for a zone to be able to offer access to certain services within the zone to users dialing into the zone from other zones. For example, a service provider might want to provide access to a specialized high-speed MCU farm or special rate PSTN gateway services. The subscribers to this service will not be in the same zone. It is unacceptable to allow the subscribers to register with the service provider's gatekeeper, since that violates the notion of network sovereignty. In order for a user registered in a home directory to use restricted services in a remote zone, the user should authenticate with the remote gatekeeper using the same authentication handshake described earlier for their home zone. The remote zone 'service provider' will of course not have the same access to authentication and directory services of the user's home zone, but will have to maintain their own database of users and Johnson & Yafchak INTERNET-DRAFT Page 11 ViDe Reference Model for H.323 Communications March 2000 groups. 4.7 Policy-based networking and QoS Whenever a gatekeeper completes call setup for a properly authenticated terminal end station, it should send information about the new call to the network so that the network can implement policies for that call. Specifically, the gatekeeper should send the following information: 1. Source IP address 1.1. Video stream IP port number 1.1.1. Policy requested (e.g. low latency 384 kb/s service) 1.2. Audio stream IP port number 1.2.1. Policy requested 1.3. T.120 stream IP port number 1.3.1. Policy requested 2. Destination IP address 2.1. Video stream IP port number 2.1.1. Policy requested 2.2. Audio stream IP port number 2.2.1. Policy requested 2.3. T.120 stream IP port number 2.3.1. Policy requested This information will be used by a policy enforcement server on the network to enable quality of service (QoS) mechanisms that will give appropriate QoS to the specific packet streams associated with this call. When the gatekeeper disconnects the call, it should send a corresponding message to the policy enforcement server that this call is no longer in place and the associated QoS path should be torn down. This messaging protocol should be standardized and incorporated into h.323 so that router and policy based networking vendors can begin to build support for this mechanism into their products. In general, today's h.323 gatekeeper is an example of a policy server, although it lacks the enforcement capabilities that a full-featured policy server would have. In that sense, the gatekeeper functions more as a 'policy requester' to the network and the network provides a 'policy enforcer' mechanism to carry out the policy. Gatekeepers are currently more mature discrete devices than are policy servers. In fact they represent one of the first instantiations policy servers. The authors see a convergence of gatekeepers and policy servers leading to a mature policy server that has h.323 awareness as one of its many components. 4.8 Administrative Recommendations for More Robust Services 4.8.1 H.323 Processes as Services and Daemons All h.323 functions should run continuously as processes on the host system, without requiring that any particular user be logged on. They should run as services (Windows NT) or daemons (UNIX) with the user Johnson & Yafchak INTERNET-DRAFT Page 12 ViDe Reference Model for H.323 Communications March 2000 interface being an external application to the core service itself. 4.8.2 Call Control, Logging, and Administration Active calls should be displayed in a sortable format within the h.323 gatekeeper. For example, it should be possible to see all calls attached to a particular MCU or MCU service grouped together. This would allow administrators to quickly determine which MCUs are in use to manually tear down multipoint calls for servicing. Other types of useful sort criteria include call registration, call duration, alias, extension and IP address. Call information should be automatically logged and stored as a text file. The period for logging (real time, daily, hourly, weekly, etc.) should be configurable by the administrator, as should the type and granularity of the elements (including error messages) to be included in the log. 4.8.3 General Addressing All h.323 IP addressing should be available using DNS or IP address per the network administrator's preference. Currently, the bulk of h.323 equipment on the market requires static IP addresses for configuration. This prevents service providers from switching over to standby services in the event of equipment failure and generally limits the flexibility service providers have in managing systems. 4.8.4 Special Services Gatekeepers should support several convenience features including a user- definable list of forwarding numbers. This facilitates scenarios such as, "If I don't answer, then forward my calls to my cell phone. If my cell phone does not answer, then forward the call to my voicemail." Voicemail/videomail systems should simply emulate h.323 terminal end stations with a unique alias/extension pair for each account. In this way, missed calls can be forwarded directly to a user mailbox. 5. References [1] ITU-T Recommendation H.323, "Packet-based multimedia communication systems", Adopted February 1998. [2] Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] Arango, M., Dugan, A., Elliott, I., Huitema, C., Pickett, S., "Media Gateway Control Protocol (MGCP)", RFC 2705, October 1999. [4] ITU-T Recommendation E.164, "The international public telecommunication numbering plan", Adopted May 1997. [5] Radhika, R., "Distributed Gatekeeper Architecture for H.323-Based Multimedia Telephony", Proceedings of the 24th Conference on Local Computer Networks, Institute of Electrical and Electronics Engineers, 1998. Johnson & Yafchak INTERNET-DRAFT Page 13 ViDe Reference Model for H.323 Communications March 2000 [6] Brown, A., "Telephone Number Mapping", Internet Draft, Informational, November 1999. 6. Security Considerations This document presents some actual and some conceptual guidelines intended to further discussion such that protocol development and device implementation within the area of Internet-extensible H.323 communication may be enabled. Security considerations are mentioned throughout but most specifically in sections 4.5, 4.7, and 4.8. However, the information contained herein is not intended to address security issues at the level of a new protocol or standards specification. This document also does not address encryption of data as it is transmitted within an H.323 communication or authenticated communication between H.323 devices. Security requirements in these areas would be the same as for other IP devices and are beyond the scope of this document. 7. Authors' Addresses Tyler Miller Johnson CAVNER Center for Advanced Video Network Engineering and Research CB# 3224 University of North Carolina Chapel Hill, NC 27599 Phone: +1 919.843.7004 Fax: +1 919.843.7008 Email: Tyler_Johnson@unc.edu Mary Fran Yafchak 1807 County Route 4 Central Square, NY 13036 Phone: +1 315.413.0345 X5236 Fax: +1 315.413.0346 Email: maryfran@nysernet.org 8. Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Johnson & Yafchak INTERNET-DRAFT Page 14 ViDe Reference Model for H.323 Communications March 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Filename: draft-johnson-yafchak-vide-h323-reference-model-00.txt Expiration Date: September 30, 2000