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
<draft-bell-ipdc-signaling-00.txt>
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