INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 INTERNET DRAFT Bob Bell Selsius Systems Title: draft-bell-ipdc-signaling-00.txt Date: August 1998 IPDC Device Management Protocol 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Device Signaling Transport protocol presented here, the media gateway can receive a signaling from a circuit switched network and deliver the signaling to a media gateway controller on an intervening IP network. The media gateway controller can also send signaling to a media gateway for delivery on a circuit switched network. Bell Expires February 1999 [Page 1] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 Table of Contents 1.0 Introduction 1.1 Background 2.0 Protocol Definition 2.1 Specification of Requirements 2.2 Messages 2.2.1 Native Mode Q.931 Signalling 2.2.2 Tunneled Mode Signalling 3.0 New AVP Values 3.1 Control Channel IPDC-Reference AVP 3.2 PDU Block AVP 3.3 Protocol Type AVP 4.0 Examples of usage 4.1 Native Q.931 Mode Signalling 4.2 Tunneled Mode Signalling 5.0 Security Considerations 6.0 Rights and Permissions 7.0 Acknowledgments 8.0 References 9.0 Authors Address 1.0 Introduction The messaging specification presented here is intended for use between a media gateway and a media gateway controller. The media gateway may be capable of acting as a voice over IP gateway, dialup modem access server, or circuit switch. Using the IP Signaling Transport (IPST) protocol within this document, the media gateway controller (MGC) can send messages to the media gateway to setup and clear connections within a media gateway (MG) or between media gateways. 1.1 Background This document is part of the IPST family of protocols. The IPDC protocols have been proposed as a protocol suite that can be used individually or together to perform connection control, media control, and signaling transport for environments where the MGC is separate from the MG itself. Please see the references section for a list of other IPDC documents. This document describes the commands and attribute value pairs that are necessary within the IP Signaling Transport (IPST) messaging set to allow the MGC to perform call and media control on the MG. This Bell Expires February 1999 [Page 2] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 control provides the ability for the MGC to setup, modify and clear connections within a MG. A MG may support multiple types of connections within itself and to other MGs or endpoints. These connections are based upon the specification of two MG entities or endpoints for each connection request. The IPDC base specification describes the format for the specification on these endpoints, This format may be seen in the definition of the IPDC-Reference AVP. The base document describes a set of references for device-based endpoints as well as "other entity types" for packet based endpoints. IPST provides a mechanism to transport call signaling information between the MGC and the MG in a stateless fashion relative to the +--------------------------------+ +----------------+ | | | | | +-----------+ +-+ +----------+ | | +----------+ | | | External | |I| |Q.931/IPST| | | |Q.931/IPST| | | | Signaling | |W| |Protocol | | | |Protocol | | <->| | Protocol | |F| |Stack | |<-->| |Stack | | | | Stack | | | | | | | | | | | +-----------+ +-+ +----------+ | | +----------+ | | | | | | Media Gateway | | Media Gateway | | | | Controller | | | | | +--------------------------------+ +----------------+ Figure 1-1 Native Q.931 Mode Signaling (IWF = Interworking Function) link. There are two modes of operation presented in this document. The first, styled as "Native Mode Q.931 Signaling" uses ITU-T Q.931 messages and Information Elements to convey signaling information to and from the associated MGC-MG pair. Figure 1-1 illustrates the structural requirements for native mode signaling. In this case, the MG terminates the external signaling protocol and passes only Bell Expires February 1999 [Page 3] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 indications to the MGC in the form of stateless Q.931 messages. The second, "styled as "Tunneled Signaling" provides transparent transport for external signaling through the MG and is terminated at the MGC. +------------------------+ +-------------------------+ | | | | |+-----------++---------+| |+---------++-++---------+| || Layer 2 ||Tunneled || ||Tunneled ||I||Layer 3 || || Signaling ||IPST || ||IPST ||W||Protocol || <->|| Protocol ||Protocol ||<-->||Protocol ||F||Stack || || Stack ||Stack || ||Stack || ||(eg Q931)|| |+-----------++---------+| |+---------++-++---------+| | | | | | Media Gateway | | Media Gateway | | | | Controller | | | | | +------------------------+ +-------------------------+ Figure 1-2 Tunneled Mode Signaling (IWF = Interworking Function) Figure 1-2 illustrates the structural requirements for the tunneled mode signaling. In this case, the MG terminates only the lower layers of the protocol stack. The higher layer signaling protocol is encapsulated into a tunneled message and passed upward to the MGC for processing. Both the protocol termination and the interworking function exist in the MGC. 2.0 Protocol Definition 2.1 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. Bell Expires February 1999 [Page 4] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 SHOULD This word, or the adjective "recommended", means there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 2.2 Messages This section describes the IPST commands that are described within this document. All IPST implementations that support the signaling transport extension MUST support one or the other of the following commands depending upon which mode of operation is active: Command Command Code Description ------- ------------ -------------------------------------- NATIVE 1800 (0x708) Transport native mode Q.931 signaling TUNNELED 1801 (0x709) Transparent transport of signaling protocol data units (Tunneling) An implementation MAY support both modes, although only one MAY be active at any time for a single circuit interface. IPST messages are constructed in the same way as any IPDC message, using a standard header followed by Attribute-Value pairs. The standard header and required AVP information may be found in the IPDC Base Document, reference [1]. In the case of Tunneled Signaling, a transaction consists of all messages exchanged between the MG and its associated MGC from the initial signaling connection until the connection is dropped. Its duration is effectively infinite. For Native Mode Q.931 Signaling, a transaction consists of the set of Q.931 messages related to a single call. The transaction begins with the transmission of a SETUP message and terminates with the transmission of a RELEASE COMPLETE message. 2.2.1 Native Mode Q.931 Signaling In Native mode signaling, the MG maintains an external signaling engine relative to the GSTN interface. Since state control is Bell Expires February 1999 [Page 5] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 accomplished by that function, the Native mode signaling need not be state driven. Events detected at the external signaling point are translated into Q.931 messages with their associated IEs. The Q.931 message is then encapsulated in a PDU Block AVP. This AVP contains the Q.931 message as data. The format of the Native Mode Signaling data is determined by the Q.931 message and is defined in ITU-T Recommendation Q.931, reference [2]. The single exception to the Q.931 signaling procedures as described in ITU-T Recommendation Q.931 is that call clearing is indicated by sending a RELEASE COMPLETE from the end initiating the call clearing to its peer. In addition to the PDU Block AVP, there may be other AVPs that are exchanged to provide information not available within the Q.931 message itself. The AVP content of the NATIVE message is presented below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Message Header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Diameter Command AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Native Mode Signaling Command Code | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Transaction Originator Host-Name AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Control Channel IPDC-Reference AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | PDU Block AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ AVP Code Bell Expires February 1999 [Page 6] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 256 DIAMETER-Command AVP Length The length of this attribute MUST be at exactly 12. AVP Flags The flag field MUST have bit one (Mandatory Support) set. Bit two (SS-Encrypted-Data), Bit three (PK-Encrypted-Data) and Bit four (Vendor-Specific-AVP) SHOULD NOT be set. Reserved The Reserved field MUST be set to zero (0). Command Code 1800 Native Mode Signaling Command Code Transaction Originator Host Name AVP The host name of the initiator of the transaction. This is a required parameter for all IPDC protocol messages. Control Channel IPDC-Reference AVP Required for all IPST messages, this AVP identifies the control channel within the media gateway upon which the native mode signaling PDU was received or upon which a native mode signaling PDU will be sent. PDU Block AVP Required for all IPST Native Mode messages, this AVP contains the Q.931 PDU in total. The format of the Transaction Originator Hostname is of type IPDC Reference, and the format is given in the IPDC Base Protocol Document, reference [1]. The Control Channel IPDC-Reference, and the PDU Block are both presented in the New AVP Values section of this document. 2.2.2 Tunneled Mode Signaling In the tunneled mode of signaling, the MG does not terminate the Bell Expires February 1999 [Page 7] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 signaling messaging. It may terminate the lower levels (such as Layer 2 in ISDN) but merely relays the received protocol data elements from the MGC to the GSTN and vice-versa. The format of the Tunneled message is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Message Header | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Diameter Command AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunneled Mode Signaling Command Code | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Transaction Originator Host-Name AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Control Channel IPDC-Reference AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Protocol Type AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | PDU Block AVP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ AVP Code 256 DIAMETER-Command AVP Length The length of this attribute MUST be at exactly 12. AVP Flags The flag field MUST have bit one (Mandatory Support) set. Bit two (SS-Encrypted-Data), Bit three (PK-Encrypted-Data) and Bit four (Vendor-Specific-AVP) SHOULD NOT be set. Bell Expires February 1999 [Page 8] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 Reserved The Reserved field MUST be set to zero (0). Command Code 1801 Tunneled Mode Signaling Command Code Transaction Originator Host Name AVP The host name of the initiator of the transaction. This is a required parameter for all IPDC protocol messages. Control Channel IPDC-Reference AVP Required for all IPST messages, this AVP identifies the control channel within the media gateway upon which the native mode signaling PDU was received or upon which a native mode signaling PDU will be sent. Protocol Type AVP Indicates the type of protocol being tunneled. If this field is not present then the protocol type is presumed to be Q.931. PDU Block AVP Required for all IPST Native Mode messages, this AVP contains the Q.931 PDU in total. The format of the Transaction Originator Hostname is of type IPDC Reference, and the format is given in the IPDC Base Protocol Document, reference [1]. The Control Channel IPDC-Reference, Protocol Type and the PDU Block AVPs are presented in the New AVP Values section of this document. 3.0 New AVP Values There are three new AVPs defined in this document. These are: AVP Name AVP Value Description ------------------ ------------ ---------------------------- Control Channel 1900 (0x76C) Identifies the control IPDC-Reference endpoint for GSTN signaling Bell Expires February 1999 [Page 9] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 PDU Block 1901 (0x76D) Contains the embedded protocol data elements Protocol Type 1902 (0x76E) Identified the type of signaling protocol being transported Each is addressed below. 3.1 Control Channel IPDC-Reference AVP This AVP provides the IPDC-Reference descriptor for the control channel associated with this signaling event. AVP Code 1900 Control Channel IPDC Reference AVP Length The length of this attribute MUST be at least 12 to accommodate 8 bytes of AVP header information plus a minimum 4 byte data field. The character coding of this attribute is likely to make this field considerably longer than 12. AVP Flags The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. Control Channel IPDC-Reference The Control Channel IPDC-Reference AVP is used to identify the signaling endpoint for GSTN gateway. The value of this field is of type IPDC Reference and the definition of this type may be found in the IPDC Base Protocol Document, reference [1]. 3.2 PDU Block AVP The PDU Block AVP encapsulates a signaling protocol data unit (PDU) for transmission from or to the MGC. AVP Code 1901 PDU Block AVP Length Bell Expires February 1999 [Page 10] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 The length of this attribute MUST be at least 12 to accommodate 8 bytes of AVP header information plus a minimum 4 byte data field. The actual encoding of this PDU Block may extend the length considerably beyond the 12 byte minimum. The PDU Block is padded in length to a multiple of 4 bytes. AVP Flags The flag field MUST have bit one (Mandatory Support) set. The flag field MUST not have bit four (Vendor Specific AVP) set. PDU Block Data This field contains the formatted protocol data unit for transport. If the Protocol Type AVP is present, this data field is encoded according to the rules specified for the designated protocol type. Otherwise, this data field is encoded as a simple Q.931 PDU. 3.3 Protocol Type AVP The Protocol Type AVP indicates the underlying signaling protocol to be used on to interpret the accompanying PDU Block AVP. AVP Code 1902 Protocol Type AVP Length The length of this attribute MUST be 12 to accommodate 8 bytes of AVP header information plus a 4 byte integer32 data field. AVP Flags The flag field MUST have bit one (Mandatory Support) set. The flag field MAY have bit four (Vendor Specific AVP) set. Protocol Type Value This field contains an integer-32 value corresponding to a signaling protocol type. The following table of values represents those protocol types currently defined. Value Protocol ---------- --------------- 0x00000001 ITU-T Q.931 0x00000002 ITU-T SS7 Bell Expires February 1999 [Page 11] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 0x00000003 National ISDN-1 0x00000004 National ISDN-2 0x00000005 Euro-ISDN 0x00000006 QSIG Additional protocol types may be assigned as needed. 4.0 Examples of Usage The following examples illustrate the usage of these two types of signaling. 4.1 Native Q.931 Mode Signaling This example is of a 4 wire analog trunk using a wink start procedure. The diagram in Figure 4-1 illustrates the message flow between the MG and the MGC as a result of signaling events at the MG- GSTN interface. MGC MG GSTN | | Incoming Seizure | | |<---------------------------| | | | | | Return Wink | | |--------------------------->| | | | | | Dialed Digit 1 | | |<---------------------------| | | Dialed Digit 2 | | |<---------------------------| | | Dialed Digit 3 | | |<---------------------------| | | Dialed Digit 4 | | |<---------------------------| | Native AVP (Setup) | | |<------------------------| | | Native AVP (Alerting) | | |------------------------>| | | Native AVP (Connect) | | |------------------------>| Return Seizure | | |--------------------------->| | | | |<---------------------------------------------------->| | Conversation | |<---------------------------------------------------->| Bell Expires February 1999 [Page 12] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 | | | | Native AVP (Rel Compl.) | | |------------------------>| Release Seizure | | |--------------------------->| | | | | | Seizure Release | | |<---------------------------| | | | Figure 4-1, 4-Wire Analog Trunk Incoming Call In the above example, the GSTN initiates an inbound call by seizing the trunk at the MG-GSTN interface. The MG returns a wink to indicate that it is ready to receive digits. The GSTN then sends 4 digits to the MG. Having all the digits needed, the MG sends a Native message with a PDU Block containing a Q.931 SETUP message with the dialed digits. As interworking occurs, the MCG sends a Native message with the PDU Block containing an ALERTING message, followed by a Native message with a PDU Block containing a CONNECT message. The CONNECT message may also contain the connection control AVPs to complete the RTP connections. The MG then returns seizure toward the GSTN to indicate that the distant station has answered. The users are now in conversation. To clear the call, the MCG sends a Native message with the PDU Block containing a RELEASE COMPLETE message. The MG responds by releasing seizure towards the GSTN. The GSTN releases seizure towards the MG and the call is complete. The diagram in Figure 4-2 illustrates the reverse operation in which the MGC initiates an outbound call on a 4-wire Analog Interface. MGC MG GSTN | Native AVP (SETUP) | Outgoing Seizure | |------------------------>|--------------------------->| | | | | | Return Wink | | |<---------------------------| | | | | | Dialed Digit 1 | | |--------------------------->| | | Dialed Digit 2 | | |--------------------------->| | | Dialed Digit n | | |--------------------------->| | Native AVP (Proceeding) | | |<------------------------| Return Seizure | Bell Expires February 1999 [Page 13] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 | Native AVP (Connect) |<---------------------------| |<------------------------| | | Native AVP (Connect Ack)| | |------------------------>| | |<---------------------------------------------------->| | Conversation | |<---------------------------------------------------->| | | | | | | | | Release Seizure | | Native AVP (Rel Compl.) |<---------------------------| |<------------------------| | | | Seizure Release | | |--------------------------->| | | | Figure 4-2 4-Wire Analog Trunk Outgoing Call In the above example, the MGC requests an outgoing call by sending a Native CMD with a PDU Block containing a SETUP message. If the trunk is to be used for "fast connect", this Native CMD MUST also contain the connection control AVPs needed to establish connections. In response to the SETUP, the MG seizes the outbound trunk and waits for "wink". Upon receiving "wink", the MG sends the supplied digits to the GSTN. At the completion of digit transmission, the MG returns a Native CMD with a PDU Block containing a CALL PROCEEDING message. When the distant end station answers, the GSTN sends a return seizure to the MG. The MG then sends a Native CMD with a PDU Block containing a CONNECT message to the MGC. If the connection control AVPs have not been sent already, the MGC sends a Native CMD with a PDU Block containing a CONNECT ACK message and the required connection control AVPs. The conversation is now active. In this example, the GSTN releases the call first by releasing seizure. The MG sends a PDU Block containing a RELEASE COMPLETE message to the MGC and releases seizure towards the GSTN. The call is now completed. 4.2 Tunneled Mode Signaling Tunneling Mode Signaling simply encapsulates the underlying signaling messages and sends them either to the MG or the MGC. The diagram in 4-3 illustrates this operation. The sequence is self-explanatory. The protocol type AVP contains the value 2 to indicate that the trunk is a National ISDN-1 trunk. MGC MG GSTN | Tunneled AVP (SETUP) | SETUP | |------------------------>|--------------------------->| Bell Expires February 1999 [Page 14] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 | | | | | CALL PROCEEDING | | Tunneled AVP (Proceedin)|<---------------------------| |<------------------------| | | Tunneled AVP (Alerting) | | |------------------------>| | | | ALERTING | | |--------------------------->| | IPCC RCON | | |------------------------>| | | IPCC ACON | | |<------------------------| | | Tunneled AVP (Connect) | | |------------------------>| CONNECT | | |--------------------------->| |<---------------------------------------------------->| | Conversation | |<---------------------------------------------------->| | | | | | | | | DISCONNECT | | Tunneled AVP (Disconn.) |<---------------------------| |<------------------------| | | IPCC RCR | | |------------------------>| | | IPCC ACR | | |<------------------------| | | Tunneled AVP (Release) | | |------------------------>| RELEASE | | |--------------------------->| | | RELEASE COMPLETE | | |<---------------------------| | Tunneled AVP (Rel. Comp)| | |<------------------------| | Figure 4-3, Tunneled Mode ISDN Signaling 5.0 Security Considerations Security considerations for these modes of signaling are addressed in the IP Device Control Base Protocol document, reference [1]. These issues are not addressed here. 6.0 Rights and Permissions The contributors to this document are listed in the author's address and acknowledgement sections of the document. All contributors to Bell Expires February 1999 [Page 15] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 this document and the organizations we represent grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to any party under the copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution. The contributors grant permission to reference the names and addresses of the contributors and of the organizations we represent. We agree that no information in the contribution is confidential and that the any party may freely disclose any information in the contribution. The contributors to this document believe that the organizations we represent have the authority to grant the rights stated herein. The contributors to this document will grant any party a perpetual, non- exclusive, royalty-free, world-wide right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification. The contributors represent that we have disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributors. The contributors do not represent that we personally know of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties. The contributors represent that there are no limits to the contributors' ability to make the grants, acknowledgments and agreements above that are reasonably and personally known to the contributors. 7.0 Acknowledgments The author wishes to acknowledge the following individuals for their contribution to the IP Signaling Control protocol: Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, Russ Dehlinger, Andrew Dugan, Ike Elliott, Cary FitzGerald, Jan Gronski, Tom Hess, Geoff Jordan, Tony Lam, Shawn Lewis, Dave Mazik, Pete O'Connell, Shyamal Prasad, Paul Richards, Dale Skran, Louise Spergel, Raj Srinivasan, Tom Taylor, Michael Thomas. 8.0 References [1] Taylor, "IP Device Control Base Protocol" [2] ITU-T, "Recommendation Q.931", March 1993 [3] Dugan, "IP Device Connection Control Protocol" Bell Expires February 1999 [Page 16] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998 Other references: Calhoun, Rubens, "DIAMETER Base Protocol". Internet-Draft, draft- calhoun-diameter-03.txt, May 1998. Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft, draft- calhoun-diameter-framework-00.txt, May 1998. Elliott, "IP Media Control Protocol", Internet-Draft, draft-elliott- ipdc-media-00.txt, August, 1998. Skran, "IP Device Control Framework" Pickett, "IP Device Management Protocol", Internet-Draft, draft- pickett-ipdc-management-00.txt, August, 1998 9.0 Author's Address Questions about this document can be directed to: Bob Bell Selsius Systems Inc. 640 N. Main St. Suite 2246 North Salt Lake, Utah 84054 Phone: 1-801-294-3034 Fax: 1-801-294-3023 Email: bbell@selsius.com Page - ii 5 August, 1998 Page - i 5 August, 1998 Bell Expires February 1999 [Page 17] INTERNET DRAFT IPDC Signaling Transport Protocol August 1998