Internet Engineering Task Force TBD WG Internet Draft Authors: draft-sinnreich-sigdevctrl-00.txt Henry Sinnreich, November 1998 MCI Worldcom Expires: April 1998 Francois Menard, Mediatrix Telecom Service Requirements for Internet Telephony Signaling and Device Control Protocols STATUS OF THIS MEMO This document is an Internet-Draft. 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 by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), unnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Sinnreich, Menard Expires April 1999 [PAGE 1] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols ABSTRACT This memorandum discusses the requirements for telephony signaling and device control over the Internet from the perspective of meeting the needs of Internet service providers (ISPs) and telecom carriers wishing to provide Internet services that include telephony. The requirements apply equally to various Internet telephony and non-Internet telephony devices. For the purpose of this Internet draft, the notion of telephony is broadened to include control of other types of streaming media sessions, such as RTSP based media server device control. Rather than severely restricting the device control framework to a particular set of devices, such as IP telephony gateways and telephony network access servers, this Internet draft presents requirements that are broad enough to satisfy the needs of any device that is expected to provide telephony and related services on the Internet. Sinnreich, Menard Expires April 1999 [PAGE 2] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols Table of Contents 1. Introduction ............................................... 4 2. IP Telephony in the Internet Context ....................... 6 3. Telephony Signaling ........................................ 7 3.1. Tunneling of telephony signaling over the Internet........ 7 3.2. Common Denominator Signaling over the Internet ........... 7 4. Telephony Devices .......................................... 9 5. Telephony Device Control and Signaling Requirements........ 11 6. Internet Requirements ..................................... 12 6.1. Transport ............................................... 12 6.2. DTMF Signaling Issues ................................... 12 6.3. Security ................................................ 13 6.3.1.Network Level Security ................................. 13 6.3.2.User Level Security .................................... 14 6.4. Network Management ...................................... 14 7. Using Internet and Web State of the Art ................... 14 7.1. Policy and Accounting ................................... 15 7.2. Migrating from SDP to XML ............................... 15 7.3. Scalability of Call Processing Syntaxes ................. 16 8. Concluding Remarks ........................................ 16 9. Authors Address ........................................... 16 10. COPYRIGHT ................................................ 17 11. References ............................................... 18 Sinnreich, Menard Expires April 1999 [PAGE 3] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 1. Introduction This draft discusses the requirements for telephony signaling and device control over the Internet from the perspective of meeting the needs of Internet service providers (ISP's) and telecom carriers wishing to provide Internet services that include telephony. The advent of Internet Telephony has recently generated significant work in transposing the functionality of telephony signaling and of various telephony devices onto IP networks and onto the public Internet. Telephony on the Internet can be considered a logical subset of Internet multimedia developed with the Internet Conferencing Architecture [1]. An alternative is the ITU H.323 multimedia conferencing architecture for packet networks [2]. The IP Telephony to PSTN Gateway type of device has attracted most of the attention, generating a significant number of contributions to the IETF with the objective to establish a standards framework. This interest has led to the significant efforts on telephony signaling transport and device control [3], [4], [5]. As a result of recent work and discussions on mailing lists, there is now a better understanding of the requirements for IP telephony to PSTN gateways. There are however many other known telephony devices besides the IP telephony gateway. New ones are also emerging in the IP domain. It is the objective of this Internet Draft to translate the requirements for telephony signaling and device control from the telephony world of the Public circuit Switched Telephone Network (PSTN) to generic requirements for the Internet and the World Wide Web. One of the principal requirements for such an IP telephony device control framework is that it should be independent from a particular call control model. Current attempts, and to this date, there has been a significant number of them, at developing a protocol suitable IP telephony device control have mainly focused on device control that is heavily tied to a master/slave call control model. One can only observe that such an approach severely limits the capacity of a multitude of other Internet hosts to perform device control. By contrast, of particular interest to service providers, is the capability on implementing distributed control models, such as required for example when outsourcing certain network services, such as in virtual private networks. Distributed models are native to the Internet and need Sinnreich, Menard Expires April 1999 [PAGE 4] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols also to be ported to IP telephony. Finally, the service model, control model and architecture may be different for IP telephony gateways (1) integrated into a telephony switch, (2) being part of a cable network or (3) an all IP oriented services network. It has been well indicated by those interested in deploying Internet Telephony services in a traditional manner similar to the way that telephony has evolved on the GSTN, that the capacity of the network operator to enforce certain services is a key requirement for deployment. Unfortunately, this conflicts with the need of intelligent Internet Telephony endpoints to make decisions by themselves, without requiring that the network be aware of them. We are beginning to see differences in IETF proposals between an Internet telephony architecture based on SDP [6], RTP, [7], [8], SIP [9], RTSP [10] and SNMP [11] versus centrally controlled architectures such as: MGCP [5] under the Call Agent Call Control, or H.323 Gatekeeper-Routed Call Control, model. This document aims to focus attention back to the distributed Internet model. The authors believe that telephony signaling and device control over the Internet mandates the development of a generic architecture capable of accommodating the needs of both distributed and centralized call control models. The authors believe that it would be counterproductive limit the architecture of a device control protocol to centralized call control environments. We propose instead the deployment of Internet protocols that are generic and extensible enough to satisfy the requirements of both centralized and distributed call control architectures. The authors believe that it is technically feasible to develop and deploy protocols generic enough to control all these devices using existing technologies. More specifically, the extendable Framework provided by the eXtended Markup Language (XML) [12], the Session Initiation Protocol (SIP) and the Simple Network Management Protocol (SNMP) can be used to meet the requirement stated above. Throughout this architecture, media streaming will be done with the Real Time Protocol and the Real Time Control Protocol. Keeping this in perspective will keep the complexity of RTP-endpoints basic device control to a minimum. Sinnreich, Menard Expires April 1999 [PAGE 5] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 2. IP Telephony in the Internet Context Voice for Internet Telephony can be more than the plain point to point 3.1 kHz PSTN/ISDN audio stream that everyone is used to. Internet Telephony allows this voice stream to be associated with video and other types of media, such as mail, chat, whiteboards, etc., in various applications, that may not necessarily be associated with conventional telephone service. The voice media of Internet Telephony is therefore only a subset of a larger class of Internet media, and the telephony service is a subset of many other Internet services. The successful integration of telephony on the Internet requires the use of the same set of controls - protocols - both on global scale, and across multiple applications and services. Current predictions show than even when telephony traffic will migrate to a large extent on the Internet, it will represent a very small part of the overall traffic, thus not justifying the building of a separate infrastructure with significantly different protocols. The Internet Conferencing Architecture is a framework for a series of applications using various media for conferencing. There are several parts of the Internet Conferencing Architecture that are applicable for telephony, such as the Real Time Protocol (RTP) for the packetized transport of media streams, the Session Initiation Protocol (SIP) for signaling and the Real Time Streaming Protocol (RTSP) for audio/video client server play-out control. World Wide Web technology, such as URL's, HTTP, XML and SMIL [13] are a complementary framework for IP telephony, that solves many hard problems encountered in PSTN/ISDN telephony, such as addressing and service creation. We recommend in this draft to use the protocols of the Internet architecture and the World Wide Web for the full integration of Internet Telephony with all other existing Internet and Web Multimedia services for voice, video and data. This includes other aspects, such as security, policies, service levels, etc. Sinnreich, Menard Expires April 1999 [PAGE 6] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 3. Telephony Signaling IP Telephony Signaling must encompass all the capabilities of such diverse signaling categories as T1/E1 channel associated signaling, ISDN signaling and SS7 signaling in its various regional flavors and industry implementations. End-to-end signaling can be accomplished in several ways. 3.1. Tunneling of telephony signaling over the Internet This has the advantage of simplicity, but is not suitable when there are different types of signaling flavors at the endpoints on the IP network, when for example: o The tunnel stretches between two countries with different regional flavors of SS7, or o There is an SS7 point at one boundary of the IP network and an ISDN signaling end point at the other, o PSTN endpoint needs to connect to an IP host. Tunneling may also have some transport issues, such as balancing between the need for small delay vs. the use of TCP for reliable signaling. Finally, establishing secure tunnels and QoS between various devices may require additional operational resources. Tunneling may therefore be applicable in a limited context, but presents problems as a general method for signaling transport. 3.2. Common Denominator Signaling over the Internet The use of a common denominator signaling over the Internet, such as SIP, will allow the connection with other non-telephony devices and will also serve as a translator between telephony signaling options. In the case of SIP, the additional security features of SIP do not require operational resources for every new set of endpoints. However the translation of telephony signaling into SIP require the mapping of protocols, such as the mapping of SS7 ISUP to SIP [14]. The large number of signaling flavors in telecom networks raises a number of issues. One situation occurs when a call originating on PSTN is signaled via ISUP to a Gateway on the Internet, then signaled back to ISUP at another Gateway on the Internet, then terminated back to PSTN. The problem is that many ISUP parameters not necessarily required for signaling in the Internet may be needed to correctly handle Sinnreich, Menard Expires April 1999 [PAGE 7] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols the call at the destination. This is compounded by the many varieties of ISUP in general use. Two possible options can be considered: 1. Transport (tunnel) the telephony network protocol data unchanged over the Internet through another media session, while letting the telephony edge devices (i.e. gateways) take care of all issues relating to ensuring the interface to the telephone network is correct, such as proper DTMF timing, circuit/trunk selection and other considerations. The protocol for transporting this data transparently and in real time can be RTP, but as for fax data, such a protocol has far more features than required. 2. Map telephony protocol data (of which there are many varieties) to some sort of meta-data description (such as an XML DTD for telephony network protocol data), which would provide the basis for translations. Then carry this data description in a protocol over this Internet. The first proposal keeps the Internet Telephony Signaling using SIP simple, but could make the gateways very complex as they may be held responsible for interpreting "alien" telephony network protocol data, if there are divergent terminations such as in different countries, or SS7 and ISDN. The second proposal may require significant development work, but provides much simpler gateways, as only a single, locally applicable translation need be understood by each gateway. The second proposal also has the benefit of exposing telephony network protocol data for the benefit of Internet applications through an interface that is familiar for Internet applications. One could imagine, as an example, a Q.773 TCAP transaction exposed as an XML DTD sent along with a SIP INVITE as opposed to an X.209 ASN.1, BER-encoded, MIME-encoded, TCAP attachment sent along with a SIP INVITE. The addition of another media stream along with a SIP session keeps Internet Telephony signaling protocols unchanged as the telephony network protocol data is sent transparently. The second option involves translating from a local variant of the telephony network protocol to a meta-data description common format that is understood by both the ingress gateway and the egress gateway. Sinnreich, Menard Expires April 1999 [PAGE 8] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols Note: The issue of multiple telephony signaling flavors is independent of the "protocol in the middle", and applies equally to H.323. >From the Internet perspective, Internet telephony signaling must meet all the requirements for Internet addressing, transport, security and service level support. Such capabilities are not existent in the telephone network. Other such capabilities include the signaling of the RTP packet options (how many voice frames in the RTP packet), header compression data, and RTP multiplex data. Other Internet specific signaling requirements are Unicast/Multicast, Quality of Service, Policy Framework [15] and Internet Accounting data as part of AAA. The last items are of special interest for service providers. Also of interest for Internet service providers is to keep the Internet free of telecom network signaling details that the Internet does not need to be burdened with. The Internet clearly does not need to know about the PSTN inter-machine trunks, their numbers, their timers, etc. Given the complexity and variety of telecom signaling implementations, a top system design priority is not to carry this unnecessary burden over to the Internet. A good example of arcane and inconsistent signaling across the globe is in-band DTMF signaling to various PSTN telephony devices. Here the alpha-numeric information is encoded in analog DTMF signals, encoded in PCM, and ideally encoded in RTP packets. Though the information is mostly one single alpha-numeric digit, the encoding adds difficult timing requirements on the signaling receiver, that have no meaning to the alpha-numeric information to be transmitted. Clearly none of this should be part of any Internet signaling standard. 4. Telephony Devices As mentioned, the IP telephony gateway has enjoyed considerable attention in the form of proposals for the gateway architecture, signaling and device control. There are various schemes to place the functionality of IP telephony gateways in functional components, such as the signaling gateway, the media gateway controller and the media conversion gateway. Please see [4] for such functional placements. Sinnreich, Menard Expires April 1999 [PAGE 9] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols In either schema, a large number of distributed media gateways must be controlled from a small number of signaling gateways and gateway controllers, or from a centrally located "Intelligent Network" server. That is, the various control schemas have to be fully network enabled as when an ISP installs a number of media gateways in another country, they have to be under the "control" of a single or small number of gateway controllers. It is not desirable to install extra control networks for new services, such as IP telephony. Even when sharing a control network with other services, additional security is desirable. Therefore the protocols for gateway control should be full size Internet strength, that is deal with addressing, transport, security and QoS. Full size Internet protocols are however not required when all the components of an IP telephony gateway are packaged within one single box or on a dedicated, secure high-speed LAN. In such instances, no interoperability across the network is required and for these applications no network standards are required either. >From the perspective of SIP, the aggregation of call control, media control, media gateway and signaling gateway functions into a single entity, forms a single SIP client. Therefore, SGCP, MGCP, IPDC or other efforts are helpful designing the inside of the SIP client, and do not change the Internet architecture that we describe in this Internet Draft. There are other telephony devices that also require signaling and device control. More specifically, below is a relevant list of devices that are expected to be part of any comprehensive deployment of Internet telephony. This list is not meant to preclude other devices, which are limited only by imagination. This list is simply provided to let everyone consider the work required developing 23 or more different protocols to control the following 23 or more devices: 1. Announcement Server 2. Automatic Call Distributor 3. Call Agent 4. IP Telephone 5. IP Telephony Appliance 6. IP Telephony Gateway 7. RTP Multiplexer 8. Interactive Voice Response Systems 9. Voice Web Browser 10. Key System 11. MBONE Appliances 12. Network Access Server Sinnreich, Menard Expires April 1999 [PAGE 10] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 13. Pay Phone 14. LAN PBX 15. Routers 16. RTP Mixer 17. RTSP Media Server 18. Service Control Point 19. Signaling Gateway 20. SIP Server 21. Telephone Switch 22. Voice Recognition and Synthesis system 23. Web Kiosk x.-y. Talking Car or Talking Home Security System. 5. Telephony Device Control and Signaling Requirements In the circuit switched telephone network, signaling for telephony devices and their control does in general not require device specific protocols, though for some applications, richer signaling such as SS7 for call centers is more desirable. This property must be ported to Internet Telephony devices. New telephony devices on the Internet may also require either signaling, or at least new capability exchange such as specifying the parameters of an RTP Multiplexer or control of an RTSP Server. But for those devices, which need to be controlled, there are sets of requirements that now become evident: 1. The Control protocol must be agnostic about the call control model, whether distributed or centralized 2. The Control protocol should be simple, yet extensible 3. The Control protocol design should keep in mind what is being done in the IETF Authentication, Authorization and Accounting (AAA) work [16]. Earlier proposals, such as IPDC, already take this into account. 4. The Control protocol(s) must reuse as much of existing protocols, such as SNMPv3 and others, as possible. There needs to be an analysis of what cannot be performed with SNMP before the work can even be assigned working-group status. 5. The Control protocol should be first specified as meta-data grammar using XML if possible. 6. This Control meta-data grammar has to be protocol-independent if possible, and vice-versa. 7. Only as a last resort should new port numbers be required outside of RTP, SIP, RTSP and SNMP, so as to keep firewall requirements down. 8. It is very possible that no Internet wide protocol will be needed in the end. That is, only a meta-data grammar Sinnreich, Menard Expires April 1999 [PAGE 11] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols for telephony device control will emerge. This meta-data grammar can thus be sent using SIP event notification or rendered available through SNMP MIBs. 9. Ultimately, someone could say that developing this meta-data grammar is similar to developing an SNMPv3 MIB for telephony devices, therefore such a grammar would actually meet the goals envisaged for telephony device control. 6. Internet Requirements There are two options when providing telephony services over the Internet: 1. Provide the equivalent of telecom telephony services. This will be the 1st step and it is mandatory, for the successful introduction of any IP telephony service. 2. Make IP telephony part of a rich, integrated portfolio of Internet and Web based services. This is required to keep an IP telephony service alive and competitive. For option 2, a number of generic requirements have to be satisfied. We provide here only a very short overview, given the complexity for each of the individual topics. 6.1. Transport Transport (tunneling) of telephony network signaling over the Internet should use, as far as it is possible, existing mechanisms, such as SIP, RTP, UDP & TCP and avoid duplication of functions such as retransmissions and packet re-ordering. If new transport protocols for signaling are proposed, a reasonably compelling case should be made for the new protocol. 6.2. DTMF Signaling Issues The use of the Internet for placing telephone calls often mandates the use of low-bit rate voice compression algorithms. Because of the nature of certain voice-compression algorithms, Dual Tones Multiple Frequency (DTMF, i.e. the well known 0123456789*#ABCD tones) information cannot be sent across the compressed audio channel without corruption. One of the contentious issues raised recently is the transport of DTMF information as a media stream parallel to the audio stream. The standards bodies seem to have stayed quiet on the DTMF transport issues until recent discussions on the IETF mailing lists. Sinnreich, Menard Expires April 1999 [PAGE 12] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols In the GSTN, DTMF is in-band signaling. In H.323, as part of the VoIP Implementors Agreement 1.0, the VoIP Forum agreed to transport DTMF information using the H.245 UserInputIndication function to get around the fact that G.723.1 does not transport DTMF tones properly. SGCP introduced a method based on digit collection in the actual PSTN gateway or in residential gateways, at the edge of the network. The fact of the matter is that until DTMF in-band signaling is treated as in-band information on the same basis as the voice information, the solution will not be acceptable to control PSTN devices which rely on precise DTMF length/duration. Thus Internet Telephony to PSTN gateways will ideally be able to relay the length/duration information as reliably as possible. Clearly, intelligent IP telephony end-points have the capability of collecting this length, and such information can then be carried across the Internet. However, multiple Internet Telephony Gateways in tandem gathering DTMF length/duration information across PSTN interfaces will introduce severe timing problems. The gathering of DTMF length/duration and the expression of such information through a protocol grammar are evidently far from ideal for the reasons stated above. However, from the perspective of a modern architecture, when the end-to-end media stream is incapable of transmitting DTMF information, it is more scalable and easier to send the DTMF information as events than through a parallel RTP media stream. In our opinion, to carry DTMF digit length duration information correctly in an end-to-end manner, DTMF has to be carried over RTP as proposed in the RTP DTMF [17] draft. When this is not a requirement, then DTMF information is better sent as events. 6.3. Security 6.3.1. Network Level Security To avoid multiple private control networks, signaling and device control participants have to use secure mechanisms both for authentication and for message exchange, using as appropriate either the transport layer [18] or network layer [19] security protocols. Sinnreich, Menard Expires April 1999 [PAGE 13] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 6.3.2. User Level Security User level authentication should be based on the emerging IETF architecture for Authentication, Authorization and Accounting [20]. 6.4. Network Management Use existing protocols and the SNMP v3 framework. 7. Using Internet and Web State of the Art Internet technology is a fast moving target. When designing protocols for IP telephony, we have to separate what can be accomplished short term, using more mature Internet standards, versus emerging standards that are still under development. We will look in this section at emerging Internet standards that will affect Internet telephony, and where the Internet telephony community in its turn will have to provide input to meet telephony requirements. A top priority for service providers is the rapid deployment of new services. Possible options are: A. Static standards option o Centralized service control and no change in network elements, o Proprietary implementation, o Wait for new standard version before launching a new interoperable/global service. B. Or make use of W3C tools such as SIP 'Require', or XML for device control and signaling o Dynamic extensions for new methods, o Self describing tags, o Fast rollout of either proprietary or open new services and features. It is of interest to note two approaches for the fast rollout of new services. A. Services and feature rollout using centralized servers, such as in the telecom IN/AIN model. This approach works quite well as long as no interaction between different services, such as voice and e-mail are required. It is possible only when no changes are required to the network elements (features embedded in PSTN switches). Sinnreich, Menard Expires April 1999 [PAGE 14] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols Web based feature rollout using SIP "Require" or XML, where the protocol extensions are used for dynamic use of new features. 7.1. Policy and Accounting The rollout of IP telephony services is tied to the notion of who has access to what services and network resources [21]. Signaling and IP telephony devices will have to carry and enforce policies regarding certain services and user access privileges. The multiple types of devices which must work together across even a single domain to achieve the desired policy can include hosts (clients and servers), routers, firewalls, bandwidth brokers, subnet bandwidth managers, network access servers, and policy servers, to name just a few. As a result, telephony signaling and device control has to support generic Internet policy administration and distribution. 7.2. Migrating from SDP to XML Actual Internet Telephony signaling protocols, such as SIP, SGCP and MGCP rely heavily on extending the use of the Session Description Protocol (SDP). The authors believe that the use of SDP, as a way to speed the time to market of these protocols, is done at the expense of using the full potential of Web-based tools. A paper from W3C presented at the 42nd IETF by Philipp Hoschka of W3C [22], proposes as a graceful migration from SDP to XML-based meta-data description, an implementation of SDP using SMIL syntax. Furthermore, recently, all references to SDP as a mandatory element of SIP implementations MUST have been removed from the SIP draft for this reason, among others. Finally, migrating to XML in this architecture for meta-data description, permits to introduce the notion of the call setup protocol transmitting the settlement information. Internet payment systems will also accommodate the needs of telecommunications providers, while unifying the architecture of electronic commerce on telecommunication networks. XML provides thus the basis for a common API across the web for servers, data bases, etc., and also for telephony devices. It will allow to link Internet telephony directly to business processes. Sinnreich, Menard Expires April 1999 [PAGE 15] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 7.3. Scalability of Call Processing Syntaxes As it has been suggested by Masataka Ohta [23], it scales much better to let humans beyond distributed endpoints make decisions based on natural language than to try to express natural language rules using mere computer semantics. However, for basic set of functions, it may be feasible to develop a few sets of XML tags. 8. Concluding Remarks IP telephony signaling and device control represents two opportunities: o Re-engineering the telephony system, and o Absorbing telephony into the Internet. It can be seen from the above, that this implies getting rid of PSTN telephony complexity that is irrelevant to the Internet, but also that absorbing telephony into the Internet is a complex development. 9. Authors Address Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA E-mail: henry.sinnreich@mci.com Francois Menard Mediatrix Telecom, Inc. 4229 Garlock St. Sherbrooke, Quebec J1L 2C8 Canada E-mail: fmenard@mediatrix.com Sinnreich, Menard Expires April 1999 [PAGE 16] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 10. COPYRIGHT Copyright (C) The Internet Society 1998. 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. 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. INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols Sinnreich, Menard Expires April 1999 [PAGE 18] Sinnreich, Menard Expires April 1999 [PAGE 17] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols 11. References [1] The Internet Multimedia Conferencing Architecture by Mark Handley, Jon Crowcroft, Carsten Bormann, Joerg Ott (Internet-draft, Sept 1997) at http://north.east.isi.edu/~mjh/papers.html [2] ITU-T Recommendation H.323: Packet-Based Multimedia Communications Systems, Geneva, February 1998, http://www.itu.ch [3] Bi-Directional Session Setup Extension to Diameter by Nancy Greene and F.Cuervo. Internet draft, July 1998. http://ietf.org/internet-drafts/draft-greene-diameter-ss7- session-00.txt [4] SS7-Internet Interworking - Architectural Framework by F. Cuervo, N. Greene, M. Holdredge, L. Ong and C. Huitema, IETF draft, July 1998 at http://ietf.org/internet-drafts/draft-greene- ss7-arch-frame-01.txt [5] Media Gateway Control Protocol (MGCP) by M. Arango, A Dugan, I. Elliott, C. Huitema, S. Picket. Internet Draft, October 1998. ftp://ftp.bellcore.com/pub/huitema/papers/draft-huitema-mgcp- v0r1-00.txt [6] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Nov 1997. [7] RTP: A Transport Protocol for Real-Time Applications by H. Schlzrinne, S. Casner, R. Frederick, V. Jacobson. RFC 1889 at http://info.internet.isi.edu/in-notes/rfc/files/rfc1889.txt [8] RTP Profile for Audio and Video Conferences with Minimal Control by H. Schulzrinne, Internet draft, August 7, 1998. At http://ietf.org/internet-drafts/draft-ietf-avt-profile-new-03.txt [9] SIP: Session Initiation Protocol by Mark Handley, Henning Schulzrinne, Eve Schooler and Jonathan Rosenberg at http://ietf.org/internet-drafts/draft-ietf-mmusic-sip-09.txt [10] Schulzrinne, Lanphier 'Real Time Streaming Protocol (RTSP)' RFC 2326, Internet Engineering Task Force, April 1998. [11] SNMP v3. Home page at http://www.ietf.org/html.charters/snmpv3-charter.html [12] Frequently Asked Questions about the Extensible Markup Language, W3C white paper, October 1998. http://www.ucc.ie/xml/ [13] W3C Architecture Domain: Audio, Video and Synchronized Multimedia. http://w3c.org/AudioVideo/ [14] Mapping between ISUP and SIP. Private communication by H. Schulzrinne and R. Kang [15] Policy Framework BOF at the 42nd IETF ftp://ftp.ietf.org/ietf/98aug/policy-agenda-98aug.txt Sinnreich, Menard Expires April 1999 [PAGE 18] INTERNET DRAFT NOVEMBER 1998 Service Requirements for Internet Telephony Signaling and Device Control Protocols [16] Authentication, Authorization, and Accounting BOF at the 42nd IETF. http://ietf.org/meetings/wg_agendas_chic.html [17] RTP Payload for DTMF Digits by H. Schulzrinne, IETF Draft, July 1998. http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/ draft-i/draft-ietf-avt-dtmf-00.txt [18] IETF Transport Layer Security Working Group, home page, July 1998. http://www.ietf.org/html.charters/tls-charter.html [19] IP Security Protocol (ipsec) Working Group home page, July 1998. http://www.ietf.org/html.charters/ipsec-charter.html [20] DIAMETER: Policy and Accounting Extension for SIP by P. Pan, H. Schulzrinne and P. Calhoun, IETF draft, July 1998. http://search.ietf.org/internet-drafts/draft-pan-diameter-sip.txt [21] "Terminology for describing network policy and services", IETF draft by John Strassner and Ed Ellesson http://www.ietf.org/internet-drafts/draft-strassner-policy-terms-00.txt [22] Integrating SDP Functionality Into SMIL by Philipp Hoschka, IETF Draft, August 1998, http://search.ietf.org/internet-drafts/ draft-hoschka-smilsdp-01.txt [23] Nothing Other Than A Simple Internet Phone (NOTASIP) by Masataka Ohta and Kenji Fujikawa, IETF Draft, 1998, http://search.ietf.org/internet-drafts/draft-ohta-notasip02.txt Sinnreich, Menard Expires April 1999 [PAGE 19]