INTERNET DRAFT IPDC Connection Control Protocol August 1998
INTERNET DRAFT Andrew Dugan
Level 3 Communications
Title: draft-dugan-ipdc-connection-00.txt Date: August 1998
IPDC
Connection Control Protocol
<draft-dugan-ipdc-connection-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 Connection Control protocol presented here,
the media gateway controller can setup, modify and teardown
connections within or between media gateways.
Dugan Expires February 1999 [Page 1]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Table of Contents
1.0 INTRODUCTION
1.1 BACKGROUND
1.2 SPECIFICATION OF REQUIREMENTS
2.0 MESSAGES
2.1 RCON - REQUEST CONNECTION
2.2 ACON - ACCEPT CONNECTION
2.3 MCON - MODIFY CONNECTION
2.4 AMCN - ACCEPT MODIFY CONNECTION
2.5 RCR - RELEASE CONNECTION REQUEST
2.6 ACR - RELEASE CONNECTION COMPLETED
3.0 AVP VALUES
3.1 BEARER CAPABILITY AVP
3.2 CAUSE CODE AVP
3.3 CONNECTION DIRECTION AVP
3.4 CONNECTION ID AVP
3.5 DYNAMIC PAYLOAD TYPE AVP
3.6 ENDPOINT 1 IPDC-RESOURCE
3.7 ENDPOINT 2 IPDC-RESOURCE
3.8 QOS AVP
3.9 RADIUS - CALLED PHONE NUMBER
3.10 RADIUS - CALLING PARTY NUMBER AVP
3.11 REQUESTED PRIORITY AVP
3.12 SESSION KEY AVP
3.13 STATISTICS REQUEST AVP
3.14 STATISTICS REPORT AVP
4.0 PROTOCOL DEFINITION
4.1 LOOPBACK CONNECTION
5.0 SECURITY CONSIDERATIONS
6.0 RIGHTS AND PERMISSIONS
7.0 ACKNOWLEDGMENTS
8.0 REFERENCES
9.0 AUTHOR'S ADDRESS
1.0 Introduction
The protocol 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 Connection Control
protocol within this document, the controller entity can send
messages to the media gateway to setup and teardown connections
within an media gateway or between media gateways.
1.1 Background
This protocol is part of the IP Device Control (IPDC) family of
Dugan Expires February 1999 [Page 2]
INTERNET DRAFT IPDC Device Management Protocol August 1998
protocols. The IPDC protocols have been proposed as a protocol suite
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 .
Please see the references section for other IPDC documents.
This document describes the commands and attribute value pairs that
are necessary within the IPDC protocol to allow the media gateway
controller to perform call and media control on the media gateway.
This control provides the ability for the service control logic to
setup, modify and teardown connections within the media gateway.
A media gateway may support multiple types of connections within
itself and to other media gateways. These connections are based upon
the specification of two media gateway entities or endpoints for each
connection request. The IPDC base specification describes the format
for the specification of 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. The following
endpoint types and corresponding reference types are supported within
the IPCC command set.
GSTN: This endpoint specifies a channel that interconnects the
media gateway with a channel on the GSTN. Entity type: access-
termintion or trunk-termination
RTP: This endpoint specifies IP addresses and ports to support an
RTP connection between the media gateway and RTP ports on another
device. Entity type: RTP-port
H.323: This endpoint specifies the H.323 address of another device
that is capable of receiving an H.323 connection from the media
gateway. Entitiy type: H.323-spec
SIP: This endpoint specifies the SIP address of another device
that is capable of receiving using SIP to establish a connection
from the media gateway: Entity type: SIP-spec
ATM: (for further study). Entity type: type ATM-spec
Modem: The modem endpoint specifies an internal media gateway
resource that may be used for terminating modem calls. Entity
type: modem
Playback: The playback endpoint specifies an internal media
gateway resource that may be used for streaming audio out on the
other endpoint involved in the connection. Entity type: stream-
Dugan Expires February 1999 [Page 3]
INTERNET DRAFT IPDC Device Management Protocol August 1998
source
Record: The record endpoint specifies an internal media gateway
resource that may be used for collecting and storing streaming
audio coming from the other endpoint involved in the
connection. Entity type: stream-recorder
Conference: The conference endpoint specifies an internal media
gateway resource that may be used for terminating the call to an
audio bridge. Entity type: conf-port
Fax: The fax endpoint specifies an internal media gateway resource
that may be used for collecting or forwarding faxes. Entity type:
Fax-port
Other Internal Device: Media gateways will have other resources
that do not have currently assigned reference types. This port
type is a generic placeholder for these types of devices. Entity
type: Device
It is important to note that the IPDC Connection Control
specification is limited to the establishment of connections between
endpoints and is not a protocol for controlling the services on those
endpoints. For example, if the protocol is used to establish a
connection between a GSTN port and a conference resource, the
protocol does not provide any mechanisms for controlling such things
as authentication and admission of callers to a conference, control
of which media streams are played out on which ports, etc.
Similarly, if the connection is to a fax endpoint, the protocol does
not provide the commands to instruct the device to collect a fax and
store it in a particular mailbox or to transmit a specific fax out
the other port in the connection. The control interfaces for
instructing the server to perform its application function are
expected to be provided by an interface that is outside the scope of
IPDC.
Using the endpoint types allowed in the call control commands it is
possible to establish connections between any two types of endpoints.
It is also to establish connections between endpoints of the same
type.
1.2 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
Dugan Expires February 1999 [Page 4]
INTERNET DRAFT IPDC Device Management Protocol August 1998
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
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 inter-operate
with another implementation which does include the option.
2.0 Messages
This section describes the IPCC commands that are described within
this document. All IPCC implementations that support the connection
control extension MUST support all of the following commands:
Command Command Code DESCRIPTION
-------------------------------------------------------------------------
RCON 1200 Request Connection between two
endpoints
ACON 1201 Accept Connection
MCON 1202 Modify Connection
AMCN 1203 Accept modify connection
RCR 1204 Release channel request
ACR 1205 Release channel complete
2.1 RCON - Request Connection
The RCON command is sent from the controller to the media gateway to
request a connection between two endpoints.
The table below identifies the AVPs that may be used with the RCON
command. Because there are a number of different types of endpoints
types that may be used within the RCON command, and some of the AVPs
may be used with some types of connections and not others, the table
includes an indication of which endpoints may use each of the AVPs.
This indication includes a definition of whether the AVP is required
with the use of that endpoint or whether the AVP may be optionally
included under some circumstances. Generally, if the parameter may be
optionally included, the Notes column of the table describes the
conditions under which it may be used.
AVP Type R/O Notes
-----------------------------------------------------------------
Dugan Expires February 1999 [Page 5]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Command R-All Required on all IPDC commands.
Host-IP-Address R-All Required on all IPDC commands.
Endpoint1 IPDC-Reference R-All Specifies the first endpoint
in this connection.
Endpoint2 IPDC-Reference R-All Specifies the second endpoint
in this connection.
Connection Direction R-All Specifies whether this
connection should be
established as bi-directional
or uni-directional.
Dynamic Payload Type R-RTP Specifies the payload type for
RTP connections as defined in
H.235.
Session Key O-RTP Specifies the session key for
RTP connections as defined in
H.235.
Bearer Capability R-All Identifies whether this is a
voice of the Channel (BCC)
or data call.
Radius - Called R-Modem Used only for authentication
Phone number on modem termination calls.
This information must be passed
from the access device to any
authentication servers being
used for modem terminations.
Radius - Calling R-Modem
Party number
Requested Priority O-All Required only for priority
calls. If set to forced, the
media gateway will attempt to
connect the call even if it
requires the tear-down of an
existing non-priority call.
Statistics Request O-All Indicates whether statistics
should be collected on this
call and identifies the
statistics group(s) to be
collected.
QoS O-H.323 Used for networks where
O-RTP Quality of Service controls
O-SIP are available.
Event Script O-All The script is an ASCII text
string of variable length,
formatted according to the
scripting language defined by
the script type parameter.
Script Type O-All This parameter specifies the
script type used in the event
Dugan Expires February 1999 [Page 6]
INTERNET DRAFT IPDC Device Management Protocol August 1998
script. The script type
presented in this document
is script type 1, and is the
default if this parameter
is not specified
Symbol Set O-All The symbol set used in the
script may be specified as
well. The symbol set defined
in this document is symbol set
1, and is the default if this
parameter is not specified.
Maximum Buffer Size O-All If parameter is not specified,
default buffer size is 512
bytes.
Table 1 - RCON AVPs
2.2 ACON - Accept Connection
The media gateway as a successful response to an RCON message sends
the ACON message. If the RCON message fails, the media gateway would
have sent a message reject (MRJ) response. The source and
destination endpoints are optional to handle the case where the media
gateway manages and allocates its own endpoints. If the media
gateway selects the endpoint for a connection the media gateway MUST
return the endpoint address in the ACON. The media gateway allocates
its own endpoints in cases where the RCON message uses a wildcard or
group designator as a source or destination endpoint.
AVP Type R/O Notes
-------------------------------------------------------------------
Command R-All Required on all IPDC commands.
Host-IP-Address R-All Required on all IPDC commands.
Connection ID R-All Required for all call control
messages.
Endpoint 1 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP.
Endpoint 2 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP.
Table - 2 ACON AVPS
2.3 MCON - Modify Connection
The MCON command allows the media gateway controller to change
parameters or endpoints for a connection. With the use of an existing
connection ID, any AVP specified within the MCON message will be
interpreted as a request to change the setting for that AVP within
Dugan Expires February 1999 [Page 7]
INTERNET DRAFT IPDC Device Management Protocol August 1998
the call.
AVP Type R/O Notes
---------------------------------------------------------------------
Command R-All Required on all IPDC commands
Host-IP-Address R-All Required on all IPDC commands
Connection ID R-All Required for all call control
messages
Endpoint 1 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP.
Endpoint 2 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP.
Connection Direction O-All Specifies whether this
connection
should be established as
bi-directional or uni-directional
Dynamic Payload Type O-RTP Specifies the payload type for
RTP connections as defined in
H.235.
Session Key O-RTP Specifies the session key for RTP
connections as defined in H.235.
QOS O-H.323 Used for packet networks where
O-RTP Quality of Service controls are
O-SIP available.
Statistics Request O-All Indicates whether statistics
should be collected on this
call and identifies the
statistics group(s) to be
collected.
Event Script O-All ASCII text string formatted
according to the scripting
language defined by the script
type parameter.
Script Type O-All This parameter specifies the
script type used in the event
script. The script type
presented in this document is
script type 1, and is the default
if this parameter is not
specified.
Symbol Set O-All The symbol set used in the script
may be specified as well. The
symbol set defined in this
document is symbol set 1, and is
the default if this parameter
is not specified.
Maximum Buffer Size O-All If parameter is not specified,
default buffer size is 512 bytes.
Dugan Expires February 1999 [Page 8]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Table 3 - MCON AVPs
2.4 AMCN - Accept Modify Connection
This command is sent in response to an MCON. Since the MCON command
is also a request to query the state of a connection, all AVPs within
the response are required if they are applicable to the connection
type.
AVP Type R/O Notes
------------------------------------------------------------------
Command R-All Required on all IPDC commands
Host-IP-Address R-All Required on all IPDC commands
Connection ID R-All Required for all call control
messages
Endpoint 1 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP.
This AVP as well as the
endpoint 2 are optional because
they MUST only be returned when
the MCON request contained
wildcards or groups identifiers
and the ACON responds with the
allocated references.
Endpoint 2 IPDC-Reference O-All See the IPDC base specification
for a description of this AVP
Table 4 - AMCN AVPs
2.5 RCR - Release Connection request
This command is sent from the media gateway controller to request the
media gateway to tear-down a connection and free any allocated
resources for that connection.
AVP Type R/O Notes
----------------------------------------------------------------
Command R-All Required on all IPDC commands.
Host-IP-Address R-All Required on all IPDC commands
Connection ID R-All Required for all call control
messages
Cause code R-All
Table 5 - RCR AVPs
2.6 ACR - Release Connection completed
This command is sent in response to a request to release a
connection. The message contains a number of statistical AVPs that
Dugan Expires February 1999 [Page 9]
INTERNET DRAFT IPDC Device Management Protocol August 1998
are required in for packet connections.
AVP Type R/O Notes
-----------------------------------------------------------------
Command R-All Required on all IPDC commands.
Host-IP-Address R-All Required on all IPDC commands
Connection ID R-All Required on all call control
messages
Packet Statistics O-H.323 This AVP contains RTP
O-RTP statistics for packet based
O-SIP connections.
Table 6 - ACR AVPs
3.0 AVP Values
This section will define the new AVPs that are applicable to the
commands described within this document. Some of the base AVPs such
as command and host-IP-address are defined in the IPDC base
specification document, others such as event type, script type,
symbol set and buffer size are defined in the IPMC specification
document [4].
3.1 Bearer Capability AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bearer Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1301 Bearer Capability
AVP Length
The length of this attribute MUST be 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.
Dugan Expires February 1999 [Page 10]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Bearer Capability
The Bearer Capability is used for data connections to specify the
type of connection expected on the GSTN side of the media gateway.
The encoding is the same as the octet "Information Transfer
Capability" from the User Service Information parameter from ANSI
T1.113.3. The following bearer types have been defied:
Voice Call 0
64K Data Call 8
56K Data Call 9
Modem Call (3.1K audio) 16
The bearer capability field is of type Interger32
3.2 Cause Code AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1302 Cause Code
AVP Length
The length of this attribute MUST be at least 16 to accommodate 8
bytes of AVP header information plus a 4 byte cause code type and
a 4 byte cause code
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Cause Code Type
The cause code is used for release of connections in order to
indicate the reason why a connection is being torn down. The AVP
Dugan Expires February 1999 [Page 11]
INTERNET DRAFT IPDC Device Management Protocol August 1998
is made up of two values. The first value is contained in the
first 4 bytes and indicates the type of cause code contained in
the next field. Values for this attribute may be:
1 ISDN
Other values reserved for future use
The cause code values indicates the reason why a connection is
being torn down. Values for this attribute may be:
A one byte value. For ISDN cause codes, the encoding is defined in
ANSI T1.113.3, using the CCITT coding standard. The following is a
list of ISDN cause codes values is for reference only:
1 Unassigned (unallocated) number
2 No route to specified transit network
3 No route to destination
6 Channel unacceptable
7 Call awarded and being delivered in
an established channel
16 Normal call clearing
17 User busy
18 No user responding
19 No answer from user (user alerted)
21 Call rejected
22 Number changed
26 Non-selected user clearing
27 Destination out of order
28 Invalid number format (incomplete number)
29 Facility rejected
30 Response to status enquiry
31 Normal, unspecified
34 No circuit/channel available
38 Network out of order
41 Temporary failure
42 Switching system congestion (gateway controller,
media gateway, IP network)
43 Access information discarded
44 Requested circuit/channel not available
47 Resource unavailable, unspecified
50 Requested facility not subscribed
57 Bearer capability not authorized
58 Bearer capability not presently available
63 Service or option not available
65 Bearer capability not implemented
66 Channel type not implemented
69 Requested facility not implemented
70 Only restricted digital information bearer
capability is available
Dugan Expires February 1999 [Page 12]
INTERNET DRAFT IPDC Device Management Protocol August 1998
79 Service or option not implemented, unspecified
81 Invalid call reference value
82 Identified channel does not exist
83 A suspended call identity exists but this call
identity does not
84 Call identity in use
85 No call suspended
86 Call having the requested call identity has been cleared
88 Incompatible destination
91 Invalid transit network selection
95 Invalid message, unspecified
96 Mandatory information element is missing
97 Message type non-existent or not implemented
98 Message not compatible with call state, message type
non-existent/implemented
99 Information element non-existent or not implemented
100 Invalid information element contents
101 Message not compatible with call state
102 Recovery on time expiry
111 Protocol error, unspecified
127 Interworking, unspecified
3.3 Connection Direction AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1303 Connection Direction
AVP Length
The length of this attribute MUST be 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.
Connection Direction
Dugan Expires February 1999 [Page 13]
INTERNET DRAFT IPDC Device Management Protocol August 1998
The Connection Direction AVP supports the capability to establish
a one-way or two way connection with the RCON or MCON commands.
The values for this attribute may be
1 = Uni-directional connection from endpoint 1 to endpoint 2
2 = Uni-directional connection from endpoint 2 to endpoint 1
3 = Bi-directional connection
3.4 Connection ID AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1304 Connection ID
AVP Length
The length of this attribute MUST be 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.
Connection ID
The connection ID is used for all connection related messages
within IPDC. It must remain the same for all messages exchanged
for the same connection. The data is a 4 byte value that is
assigned by the media gateway for each connection established by
the gateway. The connection ID is returned to the media gateway
controller in the ACON response to each RCON request.
The value of the Connection ID attribute should be assigned by the
media gateway such that it is guaranteed to be unique within that
media gateway for a long period of time. The recommended method of
assigning Connection Ids is to use monotonically increasing
numbers that are continuous across reboot. If it is not possible
to maintain consistency across reboot, the media gateway may also
Dugan Expires February 1999 [Page 14]
INTERNET DRAFT IPDC Device Management Protocol August 1998
generate a random number to begin the sequence again.
The Connection ID field is of type integer32
3.5 Dynamic Payload Type AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Type . . .
+-+-+-+-+-+-+-+-+-+-+-+-
AVP Code
1305 Dynamic Payload Type
AVP Length
The length of this is variable.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Payload Type
The Dynamic Payload Type is an optional attribute for all
connections that used the RTP endpoint type. The value of this
field takes on a value as defined in H.235.
The Dynamic Payload Type field is of type data.
3.6 Endpoint 1 IPDC-Resource
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Type Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 1 Entity name . . .
Dugan Expires February 1999 [Page 15]
INTERNET DRAFT IPDC Device Management Protocol August 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1306 Endpoint 1 IPDC-Resource
AVP Length
This is a variable length field.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Entity Type Code
This field identifies the type of endpoint address specified in
the Endpoint 1 field of this AVP. The allowable values are:
ACCESS_TERMINATION 5
TRUNK_TERMINATION 6
DEVICE 8
MODEM 9
CONFERENCE_PORT 10
FAX_PORT 11
STREAM_SOURCE 12
STREAM_RECORDER 13
RTP_PORT 14
ATM_SPEC 15
H323_SPEC 16
SIP_SPEC 17
Endpoint 1 Entity Name
The Endpoint 1 IPDC-Resource AVP is used to identify the source
endpoint for a connection. The value of this field is of type
IPDC_Resource and the definition of this type may be found in the
IPDC base document. For each of the allowable Entity Code Types
for this AVP, the base document provides a description of how to
populate the entity name field.
This AVP is of data type data.
3.7 Endpoint 2 IPDC-Resource
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
Dugan Expires February 1999 [Page 16]
INTERNET DRAFT IPDC Device Management Protocol August 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Type Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 2 Entity name . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1307 Endpoint 2 IPDC-Resource
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.
Entity Type Code
in 6 This field identifies the type of endpoint address specified in
the Endpoint 2 field of this AVP. The allowable values are:
ACCESS_TERMINATION 5
TRUNK_TERMINATION 6
DEVICE 8
MODEM 9
CONFERENCE_PORT 10
FAX_PORT 11
STREAM_SOURCE 12
STREAM_RECORDER 13
RTP_PORT 14
ATM_SPEC 15
H323_SPEC 16
SIP_SPEC 17
Endpoint 2 IPDC-Resource
The Endpoint 2 IPDC-Resource AVP is used to identify the
Destination endpoint for a connection.. The value of this field is
Dugan Expires February 1999 [Page 17]
INTERNET DRAFT IPDC Device Management Protocol August 1998
of type IPDC_Resource and the definition of this type may be found
in the IPDC base document. For each of the allowable Entity Code
Types for this AVP, the base document provides a description of
how to populate the entity name field.
3.8 QOS AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QOS value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1308 QOS
AVP Length
The length of this attribute is variable, but it must be at least
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.
QOS
The QOS AVP is used on packet based connections to specify the
Quality of Service type and value that should be used when
establishing the connection. This attribute may only be used when
the packet network supports the specified Quality of Service
Mechanism.
The AVP is made up of two fields. The first is a type indicator
which may have the following values:
0x00000001 MPLS
0x00000002 ToS bits
0x00000003 ATM
Dugan Expires February 1999 [Page 18]
INTERNET DRAFT IPDC Device Management Protocol August 1998
The second is QOS and specifies the Quality of Service value that
should be used when establishing the connection. This attribute
coupled with the QOS Type completes the definition of how the
media gateway should setup the connection. This attribute may only
be used when the packet network supports the specified Quality of
Service Mechanism.
The following QOS values may be specified with this attribute.
For MPLS 4 byte, network defined, MPLS tag
For ToS 1 byte (4 bits used, big-Endian) as defined in RFC
1349
0x00000008 Minimize delay
0x00000004 Maximize throughput
0x00000002 Maximize reliability
0x00000001 Minimize monetary cost
0x00000000 Normal service
For ATM
0x00000001 Constant bit rate
0x00000002 Real-Time variable bit rate
0x00000003 Non-Real-Time variable bit rate
0x00000004 Available bit rate
0x00000005 Unspecified bit rate
3.9 Radius - Called Phone Number
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Called Phone number . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-
AVP Code
1309 Radius - Called Phone Number
AVP Length
The length of this attribute is variable.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
Dugan Expires February 1999 [Page 19]
INTERNET DRAFT IPDC Device Management Protocol August 1998
The flag field MUST not have bit four (Vendor Specific AVP) set.
Called Phone Number
The Radius - Called Phone Number is used for data connections to
provide some of the information necessary to authenticate the
caller. This information may be used in a query to a RADUIS
server to provide additional information about the service being
accessed. It is important to note that this attribute is not
intended for use for anything other than passing the value to
Radius for user authentication.
The Radius - Called Phone Number field is of type String with a
minimum length of 1.
3.10 Radius - Calling Party Number AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Calling Party Number . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-
AVP Code
1301 Radius - Calling Party Number
AVP Length
The length of this attribute MUST be at least 9 to accommodate 8
bytes of AVP header and at least one digit for calling party
number
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Calling party Number
The Radius - Calling Party Number is used for data connections to
provide some of the information necessary to authenticate the
caller. This information may be used in a query to a RADUIS
server to provide additional verification of the calling party.
Dugan Expires February 1999 [Page 20]
INTERNET DRAFT IPDC Device Management Protocol August 1998
The Radius - Calling Party Number field is of type String and may
have a variable length including a zero length (not present).
3.11 Requested Priority AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1311 Request Priority
AVP Length
The length of this attribute MUST be at exactly 12 to accommodate
8 bytes of AVP header information plus a 4 byte indication of
whether this is a priority call.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Requested Priority
The Requested Priority AVP is used to indicate to the media
gateway that this is a priority. This requires that the media
gateway allocate any necessary internal resources for the
establishment of the connection even if it requires the teardown
of an existing non-priority connection. This implies that the
media gateway must know which of its current connections are
priority connections and which connections are candidates for
arbitrary selection as one that may be torn down.
The Request Priority field is of type Interger32.
3.12 Session Key AVP
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
Dugan Expires February 1999 [Page 21]
INTERNET DRAFT IPDC Device Management Protocol August 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1312 Session Key
AVP Length
The length of this attribute is variable.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Session Key
The Session Key is an optional attribute for all connections that
use the RTP endpoint type. This field is used to specify
encryption information and takes on a value as defined in H.235.
The Session Key field is of type integer 32.
3.13 Statistics Request AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o o o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
Dugan Expires February 1999 [Page 22]
INTERNET DRAFT IPDC Device Management Protocol August 1998
1313 Statistics Request
AVP Length
The length of this attribute MUST be at least 12 to accommodate 8
bytes of AVP header information plus at minimum a single
statistics group ID.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Statistics Group ID
The Statistics request AVP is used to request the collection and
reporting of statistics for a call. The data field(s) of this AVP
contain one or more group IDs that represent statistics groups
that should be collected. Currently only one statistics group has
been identified. This group collects statistics for RTP based
connections.
1 Packet statistics group ID
Other values may be used for extensions to the protocol or vendor
specific statistics groups.
Statistics collected based upon this request are generated and
sent to the media gateway controller at the end of the call for
which they were collected.
3.14 Statistics Report AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio packets dropped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio packets sent and received |
Dugan Expires February 1999 [Page 23]
INTERNET DRAFT IPDC Device Management Protocol August 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio bytes sent and received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio bytes received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of audio bytes dropped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling packets sent and received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling packets received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling packets dropped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling bytes sent and received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling bytes received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of signaling bytes dropped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Average Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1314 Statistics Report
AVP Length
The length of this attribute MUST be at least 16 to accommodate 8
bytes of header, a group ID and at least one statistic.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
The flag field MUST not have bit four (Vendor Specific AVP) set.
Connection Packet Statistics
This AVP is used to report statistics about the a particular
statistics group that was associated with a connection. The
example AVP format shown above is the only statistics group
currently defined. This group collects statistics about the RTP
session associated with a connection. The packet statistics group
contains 13 four byte values that hold the following information
elements
Number of audio packets sent and received:The total number of
packets of audio data sent and received on the RTP connection
Dugan Expires February 1999 [Page 24]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Number of audio packets received: The number of packets of audio
data that were received by the media gateway during on the RTP
connection.
Number of audio packets dropped: The number of packets of audio
data that were lost during the RTP connection
Number of audio bytes sent and received: The total number of bytes
of audio data sent and received on the RTP connection
Number of audio bytes received: The number of bytes of audio data
received during on the RTP connection.
Number of audio bytes dropped: The number of bytes of audio data
that was lost during the RTP connection
Number of signaling packets sent and received: The number of RTCP
packets sent and received by an media gateway during and RTCP
connection
Number of signaling packets received: The number of RTCP packets
received by the access server during a connection
Number of signaling packets dropped The number of RTCP packets
lost during an RTCP connection
Number of signaling bytes sent and received: The number of RTCP
bytes sent and received during an RTCP connection
Number of signaling bytes received: The number of RTCP bytes
received during by an media gateway during a connection
Number of signaling bytes dropped: The number of RTCP bytes
dropped during an RTCP connection
Estimated average latency: Estimated latency between the two
endpoints in an RTP connection. RFP 1889 for a description on how
to measure estimated average latency.
Inter-arrival jitter: Estimated measurement of the variation in
packet latency between two endpoints in an RTP connection. See RFP
1889 for a description on how to measure inter-arrival jitter.
4.0 Protocol Definition
This section describes how to establish any unusual or confusing
connection types within the IPCC protocol. The only connection type
Dugan Expires February 1999 [Page 25]
INTERNET DRAFT IPDC Device Management Protocol August 1998
currently described within this section is the loopback. Others may
be described as they are identified as being difficult to understand.
4.1 Loopback Connection
The IPCC message set may be used to establish may types of
connections, one such connection that may not be obvious from the
message definitions above is the ability to establish a loopback
connection. Two types of loopbacks may be established in the context
of this protocol.
The first type of loopback may be used to perform continuity testing
on the GSTN network. This is the traditional loopback connection
that would be used to perform a continuity test as required for SS7
ISUP. This may be established by simply specifying the same GSTN
reference channel value for both Endpoint 1 and Endpoint 2. The
media gateway will establish a loopback connection on that channel.
The second type of loopback exists within the IP network and may be
used to verify connectivity or measure performance statistics. The
mechanisms to perform these types of tests are outside the scope of
the is protocol, but the ability to establish this type of connection
is not. This type of connection may be established by taking an RTP
connection and looping it back on itself. To do this, the following
types of values may be specified for Endpoint 1 and Endpoint 2 for a
connection.
Endpoint 1 reference: /rtp-term/134.37.41.2:3056/-
Endpoint 2 reference: /rtp-term/-/134.37.45.4/
In this example, the receive RTP port is specified for Endpoint 1 and
the transmit port is specified for Endpoint 2. This in effect
establishes a one-way connection that takes RTP packets in on
endpoint 1 and transmits them out on endpoint 2. The address
specification for the transmit side of Endpoint 2 should be set to
the IP address and port of the far-end device that will be performing
the loopback tests.
5.0 Security Considerations
Security issues are not discussed in this memo. The security
mechanisms recommended are those specified in [3].
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
Dugan Expires February 1999 [Page 26]
INTERNET DRAFT IPDC Device Management 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 represent that the organizations we
represent jointly own any intellectual property associated with this
document. 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 Call Control protocol:
Ascend Communications Inc. Ilya Akramovich
Selsius Systems Bob Bell
Tekelec Dan Brendes
3Com Corporation Peter Chung
3Com Corporation Russ Dehlinger
Level 3 Communications Isaac Elliott
Cisco Systems, Inc. Cary Fitzgerald
Cisco Systems, Inc. Jan Gronski
Stratus Computer, Inc. Tom Hess
Dugan Expires February 1999 [Page 27]
INTERNET DRAFT IPDC Device Management Protocol August 1998
Level 3 Communications Geoff Jordan
Ascend Communications, Inc. Tony Lam
Xcom Technologies Shawn Lewis
Ascend Communications, Inc. Dave Mazik
Vertical Networks Alan Mikhak
Alcatel Telecom Pete O'Connell
Vertical Networks Scott Pickett
Ericsson Shyamal Prasad
3Com Corporation Paul Richards
Ascend Communications, Inc. Dale Skran
Lucent Technologies Louise Spergel
Lucent Technologies Raj Srinivasan
Nortel Tom Taylor
Nortel Michael Thomas
8 References
[1] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, draft-
calhoun-diameter-03.txt, May 1998
[2] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft,draft-
calhoun-diameter-framework-00.txt, May 1998
[3] Taylor, "IP Device Control Base Protocol",
[4] Elliott, "IP Media Control Protocol",
[5] Skran, "IP Device Control Framework"
[6] Pickett,Mikhak, "IP Device Management Protocol"
[7] Bell, "IP Signaling Protocol"
9 Author's Address
Questions about this memo can be directed to:
Andrew Dugan
Level 3 Communications
1450 Infinite Drive
Louisville, CO 80027
Phone: 1-303-926-3429
Fax: 1-303-926-3406
Email: andrew.dugan@L3.com
Dugan Expires February 1999 [Page 28]
INTERNET DRAFT IPDC Device Management Protocol August 1998