[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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