Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-bidulock-sigtran-isua-04

Description: Request For Comments

You can download source copies of the file as follows:

draft-bidulock-sigtran-isua-04.txt in text format.
draft-bidulock-sigtran-isua-04.ps in ps format.
draft-bidulock-sigtran-isua-04.pdf in pdf format.

Listed below is the contents of file draft-bidulock-sigtran-isua-04.txt.




Network Working Group                                     Brian Bidulock
INTERNET-DRAFT                                       OpenSS7 Corporation
Intended status: PROPOSED STANDARD                      February 3, 2007

Expires in August 2007

                     SS7 ISUP-User Adaptation Layer
                                 (ISUA)
                  <draft-bidulock-sigtran-isua-04.txt>

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

    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".

    The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

    This Internet-Draft will expire in August 2007.

Copyright

    Copyright (C) The IETF Trust (2007).

Abstract

    This document defines a protocol for the transport of any SS7 ISUP-
  User signalling (e.g, Call Control) over IP using the Stream Control
  Transport Protocol [SCTP].  The protocol should be modular and
  symmetric, to allow it to work in diverse architectures, such as a
  Signalling Gateway and IP Signalling End-point architecture.  Protocol
  elements are added to allow seamless operation between peers in the
  SS7 and IP domains.

B. Bidulock                    Version 0.4                        Page 1

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

Contents

    A complete table of contents, list of illustrations, list of tables
  and document change history appear at the end of this document.

1.  Introduction

    This draft defines a protocol for the transport of SS7 ISUP [Q.761],
  [T1.113] Users (i.e, Call Control) signalling messages over IP using
  the Stream Control Transmission Protocol (SCTP) [SCTP].  This protocol
  would be used between a Signalling Gateway (SG) and Signalling End-
  point located in an IP network.  Additionally, the protocol can be
  used to transport SS7 ISUP users between two signalling end-points
  located within an IP network.

1.1.  Scope

    There is on-going integration of SCN networks and IP networks.
  Network service providers are designing all IP architectures that
  include support for SS7 signalling protocols.  IP provides an
  effective way to transport user data and for operators to expand their
  networks and build new services.  In these networks, there is a need
  for interworking between the SS7 and IP domains [RFC2719].

    This document details the delivery of Call Control messages over IP
  between two signalling end-points.  Consideration is given for the
  transport from an SS7 Signalling Gateway (SG) to an IP signalling node
  (such as an IP-resident Database) as described in the Framework
  Architecture for Signalling Transport [RFC2719] This protocol can also
  support transport of Call Control messages between two end-points
  wholly contained within and IP network.

  The delivery mechanism addresses the following criteria:

   + Support for transfer of ISUP messages (Call Control)
   + Support for the seamless operation of Call Control protocol peers.
   + Support for the management of SCTP transport associations between
     an SG and one ore more IP-based signalling nodes.
   + Support for distributed IP-based signalling nodes.
   + Support for the asynchronous reporting of status changes to
     management.

1.2.  Abbreviations and Terminology

1.2.1.  Abbreviations

      ANSI -- American National Standards Institute.
      API  -- Application Programming Interface.
      AS   -- Application Server.
      ASP  -- Application Server Process.

B. Bidulock                    Version 0.4                        Page 2

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      BLA  -- Blocking Acknowledgement.
      BLO  -- Blocking Request.
      CA   -- Certificate Authority.
      CC   -- Call Control.
      CCR  -- Continuity Check Request.
      CGBA -- Circuit Group Blocking Acknowledgement.
      CGB  -- Circuit Group Blocking Request.
      CGUA -- Circuit Group Unblocking Acknowledgement.
      CGU  -- Circuit Group Unblocking Request.
      CMF  -- Circuit Mapping Function.
      COT  -- Continuity Test.
      CP   -- Call Processing.
      CQM  -- Circuit Group Query Request.
      CQR  -- Circuit Group Query Response.
      CTP  -- Common Transport Protocol.
      ETSI -- European Telecommunication Standards Institute.
      GRS  -- Group Reset.
      HLR  -- Home Location Register.
      IANA -- Internet Assigned Numbers Authority.
      IETF -- Internet Engineering Task Force.
      IP   -- Internet Protocol.
      IPSP -- IP Signalling Point.
      ISDN -- Integrated Services Digital Network.
      ISO  -- International Standards Organization.
      ISUA -- SS7 ISUP-User Adaptation Layer.
      ISUP -- ISDN User Part.
      ITU  -- International Telecommunications Union.
      L1   -- Layer 1.
      LM   -- Layer Management.
      LPA  -- Loop Back Acknowledgement.
      MGC  -- Media Gateway Controller.
      MTP2 -- MTP Level 2.
      MTP3 -- MTP Level 3.
      MTP  -- Message Transfer Part.
      NA   -- Network Appearance.
      NIF  -- Network Interworking Function.
      PSTN -- Public Switched Telephone Network.
      RC   -- Routing Context.
      RFC  -- Request For Comments.
      RK   -- Routing Key.
      RKM  -- Routing Key Management.
      RSC  -- Reset Circuit.
      SCN  -- Switch Circuit Network.
      SCP  -- Service Control Point.
      SCTP -- Stream Control Transmission Protocol.
      SG   -- Signalling Gateway.
      SGP  -- Signalling Gateway Process.
      SS7  -- Signalling System No. 7.
      SSP  -- Service Switching Point.
      STP  -- Signalling Transfer Point.
      TLI  -- Transport Layer Interface.
      TLS  -- Transport Layer Security.

B. Bidulock                    Version 0.4                        Page 3

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      TLV  -- Tag-Length-Value.
      UBA  -- Unblocking Acknowledgement.
      UBL  -- Unblocking Request.
      VPN  -- Virtual Private Network.
      XTI  -- X/Open Transport Interface.

1.2.2.  Terminology

  Application Server (AS) - a logical entity serving a specific Routing
      Key.  An example of an Application Server is a virtual database
      element handling all HLR or SCP transactions for a particular SS7
      Signalling Point.  The AS contains a set of one or more unique
      Application Server Processes, of which one or more is normally
      actively processing traffic.  There is a one-to-one relationship
      between an Application Server and a Routing Key.

  Application Server Process (ASP) - a process instance of an
      Application Server.  An Application Server Process serves as an
      active, backup, load-share or broadcast process of an Application
      Server (e.g, part of a distributed signalling node or database
      element).  Examples of ASPs are MGCs, IP SCPs, or IP HLRs.  An ASP
      contains an SCTP end-point and may be configured to process
      traffic within more that one Application Server.

  Association - refers to an SCTP association [SCTP].  The association
      provides the transport for the delivery of ISUP protocol data
      units and ISUA layer peer messages.

  Call Control - The layer above the ISDN User Part in the SS7 protocol
      stack that exchanges primitives with the ISUP provider.  Call
      Control has two major functional blocks: Call Processing and
      Circuit Supervision.  Unlike other layers of the SS7 stack, ISUP
      does not have individual "Users" or ISUP-SAPs.  A single Call
      Control entity is responsible for controlling both ISUP and other
      switch signalling stacks at the Application Layer of the ISO
      7-layer model.  for

  Call Processing] - Call Processing is a major functional block of both
      ISUP and Call Control which is responsible for signalling and
      controlling the state of calls (as opposed to circuits).

  Circuit Supervision] - Circuit Supervision is a major functional block
      of both ISUP and Call Control which is responsible for signalling
      and controlling the state of circuits (as opposed to calls).

  Fail-over - the capability to reroute signalling traffic as required
      to an alternate Application Server Process, or group of ASPs,
      within an Application Server in the event of failure or
      unavailability of a currently used Application Server Process.
      Fail-over may apply upon the return to service of a previously
      unavailable Application Server Process.

B. Bidulock                    Version 0.4                        Page 4

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Host - the computing platform that the process (SGP, ASP or IPSP) is
      running on.

  IP Server Process (IPSP) - a process instance of an IP-based
      application.  An IPSP is essentially the same as an ASP, except
      that it uses ISUA in a point-to-point fashion.

  ISDN User Part (ISUP) - The Integrated Services Digital Network (ISDN)
      User Part [Q.761], [T1.113] of the SS7 protocol.

  Layer Management (LM) - a nodal function that handles the inputs and
      outputs between the ISUA layer and a local management entity.

  Message Transfer Part (MTP) - The Message Transfer Part [Q.701],
      [T1.111] of the SS7 protocol.

  Nodal Interworking Function (NIF) - an implementation dependent
      interworking function present at a Signalling Gateway that
      interworks primitives and procedures between the ISUP and ISUA
      layers in the SG.

  Network Appearance (NA) - a value that identifies the SS7 network
      context of a Routing Key.  The Network Appearance value is of
      significance only within an administrative domain; it is
      coordinated between the SG and ASP.

  Network Byte Order - the ordering of bytes most-significant-byte
      first, also referred to as Big Endian.

  Routing Context (RC) - a value that uniquely identifies a Routing Key
      and an Application Server.  Routing Context values are either
      configured using a configuration management interface, or by using
      the Routing Key Management (RKM) messages and procedures defined
      for ISUA.

  Routing Key (RK) - describes a set of SS7 parameters and parameter
      values that uniquely define the range of signalling traffic to be
      handled by a particular Application Server.

  Signalling Gateway (SG) - a signalling agent that exchanges SCN native
      signalling at the edge of the IP network [RFC2719].  An SG appears
      to the SS7 network as an SS7 Signalling Point.  An SG contains a
      set of one or more Signalling Gateway Processes, of which one or
      more is normally actively processing traffic.  When an SG contains
      more than one SGP, the SG is a logical entity and the contained
      SGPs are assumed to be coordinated into a single management view
      both toward the SS7 network and toward the supported Application
      Servers.

  Signalling Gateway Process (SGP) - a process instance of a Signalling
      Gateway.  It serves as an active, backup, load-sharing or
      broadcast process of a Signalling Gateway.

B. Bidulock                    Version 0.4                        Page 5

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Stream - an SCTP stream; a unidirectional logical channel established
      from one SCTP endpoint to another associated SCTP endpoint, within
      which all user messages are delivered in sequence, except for
      those submitted to the unordered delivery service.

  Circuit Mapping Function (CMF) - an implementation dependent function
      that is responsible for resolving the address and application
      context presented in the incoming ISUA message to the correct SCTP
      association and Routing Context for the desired application.  The
      CMF MAY use routing context or routing key information as
      selection criteria for the appropriate SCTP association.

  Transport Address - an address that serves as a source or destination
      for the unreliable packet transport service used by SCTP.  In IP
      networks, a transport address is defined by the combination of IP
      address and an SCTP port number <1>.

1.3.  ISUA Overview

1.3.1.  Signalling Transport Architecture

    The framework architecture that has been defined for SCN signalling
  transport over IP [RFC2719] uses multiple components, including an IP
  transport protocol, a signalling common transport protocol and an
  adaptation module to support the services expected by a particular SCN
  signalling protocol from its underlying protocol layer.

    In general terms, the ISUA architecture can be modeled as a peer-to-
  peer architecture.  The first section considers the SS7-to-IP
  interworking architectures for ISUP call control.  For this case, it
  is assumed that the ASP initiates the establishment of the SCTP
  association with the SG.

1.3.2.  Protocol Architecture for Call Control

    In this architecture (illustrated in Figure 1), the ISUP and ISUA
  layers interface in the SG.  A Nodal Interworking Function (NIF)
  provides for interworking between the ISUP and ISUA layers and
  provides for the transfer of the call processing as well as circuit
  supervision messages.

B. Bidulock                    Version 0.4                        Page 6

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

          .........         ...............        .........
          :       :         :             :        :       :
          :  SEP  :   SS7   :             :   IP   :       :
          :   or  :.........:     SG      :........:  ASP  :
          :  STP  :         :             :        :       :
          :.......:         :.............:        :.......:
           _______           _____________          _______
          |       |         |             |        |       |
          |  CC   |         |     NIF     |        |  CC   |
          |-------|         |------ ------|        |-------|
          | ISUP  |         | ISUP | ISUA |        | ISUA  |
          |-------|         |------|------|        |-------|
          | MTP3  |         | MTP3 |      |        |       |
          |-------|         |------| SCTP |        | SCTP  |
          | MTP2  |         | MTP2 |      |        |       |
          |-------|         |------|------|        |-------|
          |  L1   |         |  L1  |  IP  |        |  IP   |
          |_______|         |______|______|        |_______|
              |                |       |               |
              |________________|       |_______________|

                 CC  - Call Control
                 STP - SS7 Signaling Transfer Point
                 NIF - Nodal Interworking Function

                      Figure 1.  Protocol Architecture

1.3.3.  All IP Architecture

    This architecture, illustrated in Figure 2, can be used to carry a
  protocol which uses the transport services of ISUP, but is contained
  within an IP network.  This allows extra flexibility in developing
  networks, especially when interaction between legacy signalling is not
  needed.  The architecture removes the need for a signalling gateway
  function.

B. Bidulock                    Version 0.4                        Page 7

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

                   ........        ........
                   :      :   IP   :      :
                   :  AS  :........:  AS  :
                   :      :        :      :
                   :......:        :......:
                    ______          ______
                   |      |        |      |
                   |  AP  |        |  AP  |
                   |------|        |------|
                   | ISUA |        | ISUA |
                   |------|        |------|
                   | SCTP |        | SCTP |
                   |------|        |------|
                   |  IP  |        |  IP  |
                   |______|        |______|
                      |                |
                      |________________|

           AP - Application Protocol (e.g. - Call Control)

                       Figure 2.  All IP Architecture

1.3.4.  ASP Fail-over Model and Terminology

    The ISUA protocol supports ASP fail-over functions to support a high
  availability of transaction processing capability.

    An Application Server can be considered as a list of all ASPs
  configured or registered to handled Call Control messages within a
  certain range of routing information, or within a certain set of
  transaction dialogues, known as a `Routing Key.'  One or more ASPs in
  the list may normally be active to handle traffic, while others may be
  inactive but available in the event of failure or unavailability of
  the active ASPs.

    For operational considerations, see Appendix A.

1.3.5.  Services Provided by the ISUA Layer

1.3.5.1.  Support for the transport of Call Control Messages

    The ISUA supports the transfer of Call Control messages.  The ISUA
  layer at the SG and the ASP support the seamless transport of user
  messages between the SG and the ASP.

1.3.5.1.1.  ISUP Call Control Support

    Depending on the specific implementation of Call Control supported,
  the ISUA shall support Call Control transparently.  Call Control
  consists of two major functional blocks:

B. Bidulock                    Version 0.4                        Page 8

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    Call Processing is responsible for signalling and control of calls
  (as opposed to circuits).  Call processing functions move a call
  through its life-cycle by providing the following functions:

   + call setup,
   + call suspend/resume,
   + call release,
   + call exception handling.

    Circuit Supervision is responsible for signalling and control of
  circuits (as opposed to calls).  Circuit supervision functions affect
  the management state of circuits and provides the following functions:

   + circuit testing,
   + circuit reset,
   + circuit blocking and unblocking due to hardware failure and
     recovery events,
   + circuit blocking and unblocking maintenance action,
   + circuit state query.

1.3.5.2.  Native Management Functions

    The ISUA layer provides the capability to indicate errors associated
  with the ISUA protocol messages and to provide notification to local
  circuit management and the remote peer as necessary.

1.3.5.3.  Interworking with Circuit Supervision Functions

    The ISUA layer provides interworking with Circuit Supervision
  functions at the SG for seamless inter-operation between the SCN
  network and the IP network.  ISUA provides the following circuit
  supervision functions:

   + Provides an indication or accpets a request to perform a continuity
     check on a circuit.
   + Provides an indication or accepts a request to reset a circuit or
     circuit group.
   + Provides an indication or accepts a request to block a circuit or
     circuit group.
   + Provides an indication or accepts a request to unblock a circuit or
     circuit group.
   + Provides an indication or accepts a request to query a circuit or
     circuit group.

    The interworking with ISUP circuit supervision messages consists of
  CCNT, CCNA, CREP, CRSC, CBLO, CBLA, CUBL, CUBA, CQRY and CQRA messages
  on receipt of circuit supervision events to the appropriate ASPs.  The
  primitives in Table 1 are sent between the ISUP and ISUA circuit
  supervision functions in the SG to trigger events in the IP and SS7
  domain.

B. Bidulock                    Version 0.4                        Page 9

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

           Table 1. Mapping of Circuit Supervision Primitives

 +---------------------------+---------------------------+------------+
 |           Name            |          Message          |    ISUA    |
 +--------------+------------+-------------+-------------+ Cc't Supv. |
 | Generic <2>  | Specific   | ITU-T Q.764 | ANSI T1.113 |  Message   |
 +--------------+------------+-------------+-------------+------------+
 |CONT RECHECK  | Request    |     CCR     |     CCR     |    CCNT    |
 |              | Indication |             |             |            |
 |              +------------+-------------+-------------+------------+
 |              | Response   |      -      |     LPA     |    CCNA    |
 |              | Confirm    |             |             |            |
 +--------------+------------+-------------+-------------+------------+
 |CONT REPORT   | Request    |     COT     |     COT     |    CREP    |
 |              | Indication |             |             |            |
 +--------------+------------+-------------+-------------+------------+
 |RESET         | Request    |  RSC, GRS   |  RSC, GRS   |    CRSC    |
 |              +------------+-------------+-------------+------------+
 |              | Confirm    |  RLC, GRA   |  RLC, GRA   |    CRSA    |
 +--------------+------------+-------------+-------------+------------+
 |BLOCKING      | Request    |  BLO, CGB   |  BLO, CGB   |    CBLO    |
 |              | Indication |             |             |            |
 |              +------------+-------------+-------------+------------+
 |              | Response   |  BLA, CGBA  |  BLA, CGBA  |    CBLA    |
 |              | Confirm    |             |             |            |
 +--------------+------------+-------------+-------------+------------+
 |UNBLOCKING    | Request    |  UBL, CGU   |  UBL, CGU   |    CUBL    |
 |              | Indication |             |             |            |
 |              +------------+-------------+-------------+------------+
 |              | Response   |  UBA, CGUA  |  UBA, CGUA  |    CUBA    |
 |              | Confirm    |             |             |            |
 +--------------+------------+-------------+-------------+------------+
 |CCT GRP QUERY | Request    |     CQM     |     CQM     |    CQRY    |
 |              | Indication |             |             |            |
 |              +------------+-------------+-------------+------------+
 |              | Response   |     CQR     |     CQR     |    CQRA    |
 |              | Confirm    |             |             |            |
 +--------------+------------+-------------+-------------+------------+

    The ISUA layer provides transparent passing of circuit reset,
  blocking and query primitives (RESET, BLOCKING, UNBLOCKING, CCT GROUP
  QUERY) as provided for in ITU-T Q.724 [Q.724] Q.764 [Q.764], and ANSI
  T1.113 [T1.113].

1.3.5.4.  Support for the Management of SCTP Associations

    The ISUA layer at the SGP maintains the availability state of all
  configured remote ASPs, to manage the SCTP Associations and the
  traffic between ISUA peers.  As well, the active/inactive and
  congestion state of remote ASPs is maintained.

B. Bidulock                    Version 0.4                       Page 10

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    The ISUA layer MAY be instructed by local management to establish an
  SCTP association to a peer ISUA node.  This can be achieved using the
  M-SCTP_ESTABLISH primitives to request, indicate and confirm the
  establishment of an SCTP association with a peer ISUA node.  To avoid
  redundant SCTP associations between two ISUA peers, one side (client)
  SHOULD be designated to establish the SCTP association, or ISUA
  configuration information maintained to detect redundant associations
  (e.g, via knowledge of the expected local and remote SCTP endpoint
  addresses).

    Local management MAY request from the ISUA layer the status of the
  underlying SCTP associations using the M-SCTP_STATUS request and
  confirm primitives.  Also, the ISUA MAY autonomously inform local
  management of the reason for the release of an SCTP association,
  determined either locally within the ISUA layer or by a primitive from
  the SCTP.

    Also, the ISUA layer MAY inform the local management of the change
  in status of an ASP or AS.  This MAY be achieved using the M-
  ASP_STATUS request or M-AS_STATUS request primitives.

1.4.  Functional Areas

1.4.1.  Circuit Identifiers, Routing Contexts and Routing Keys

1.4.1.1.  Overview

    The mapping of ISUP messages into calls between the SGP and the
  Application Servers is determined by Circuit Identifiers, Routing Keys
  and their associated Routing Contexts.

    A Routing Key is essentially a set of ISUP parameters used to direct
  ISUP messages; whereas, the Routing Context parameter is a 4-byte
  value (unsigned integer) that is associated to that Routing Key in a
  one-to-one relationship.  The Routing Context therefore can be viewed
  as an index into a sending node's Circuit Mapping Function tables
  containing the Routing Key entries.

    Possible ISUP address/routing information that comprise a Routing
  Key entry includes, for example, a local and remote Point Code, and a
  Circuit Identification Code or Call Control specific information such
  as Circuit Group or Trunk Group Identifiers.  The particular
  information used to define a ISUA Routing Key is application and
  network dependent, and none of the above examples are requirements for
  ISUA.

    An Application Server Process (ASP) may be configured to process
  signalling traffic related to more than one Application Server (AS),
  over a single SCTP Association.  ASP Active (ASPAC) and ASP Inactive
  (ASPIA) management messages (see Section 3) use the Routing Context to
  discriminate signalling traffic to be started or stopped.  At an ASP,
  the Routing Context parameter uniquely identifies the range of
  signalling traffic associated with each Application Server that the

B. Bidulock                    Version 0.4                       Page 11

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  ASP is configured to receive.

1.4.1.2.  Routing Key Limitations

    Routing Keys SHOULD be unique in the sense that each received ISUP
  message SHOULD have a full or partial match to a single routing
  result.  It is not necessary for the parameter range values within a
  particular Routing Key to be continuous.  For example, an AS could be
  configured to support call processing for multiple ranges of circuits
  that are not represented by contiguous Circuit Identification Codes.

1.4.1.3.  Managing Routing Context and Routing Keys

    There are two ways to provision a Routing Key at an SGP.  A Routing
  Key may be configured statically using an implementation dependent
  management interface, or dynamically managed using the the ISUA
  Routing Key registration procedures.

    When using a management interface to configure Routing Keys, the
  Circuit Mapping Function within the SGP is not limited to the set of
  parameters defined in this document.  Other implementation dependent
  distribution algorithms may be used.

1.4.1.4.  Circuit Mapping Function

    To perform its addressing and relaying capabilities, the ISUA makes
  use of an Circuit Mapping Function (CMF).  This function is considered
  part of ISUA, but the way it is realized is left implementation or
  deployment dependent (local tables, database, etc.)

    The CMF is invoked when a message is received at the incoming
  interface.  The CMF is responsible for resolving the Circuit
  Identification Code (CIC) and any necessary ISUP message parameters
  presented in the incoming ISUP message to SCTP associations and
  destinations within the IP network.  The CMF will select the key
  information available.  The Routing Keys reference an Application
  Server, which will normally have one or more ASPs processing
  transactions for the AS.  The availability and status of the ASPs is
  handled by ISUA ASP management messages.

    Possible SS7 routing information that comprise a Routing Key entry
  includes, for example, ISUP Circuit Identification Code (CIC), Range
  and Status parameters.

    It is expected that the routing keys will be provisioned via a MIB,
  dynamic registration or an external process, such as a database.

1.4.1.4.1.  Circuit Mapping at the SG

    To direct messages received from the SS7 network to the appropriate
  IP destination, the SGP must perform a circuit mapping function using
  information from the received ISUP message.

B. Bidulock                    Version 0.4                       Page 12

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    To support this circuit mapping, the SGP might, for example,
  maintain the equivalent of a network address translation table,
  mapping incoming ISUP message information to an Application Server for
  a particular application and set of transactions.  This could be
  accomplished by comparing the circuit identification code and range
  and status portions of the incoming ISUP message to currently defined
  Routing Keys in the SGP.  These Routing Keys could in turn map
  directly to an Application Server that is enabled by one or more ASPs.
  These ASPs proxy dynamic status information regarding their
  availability, call handling capabilities and congestion to the SGP
  using various management messages defined in the ISUA protocol.

    The list of ASPs in the AS is assumed to be dynamic, taking into
  account the availability, call handling capability and congestion
  status of the individual ASPs in the list, as well as configuration
  changes and possible fail-over mechanisms.

    Normally, one or more ASPs are active in the AS (i.e, currently
  processing calls) but in certain failure and transition cases it is
  possible that there may not be an active ASP available.  The SGP will
  buffer the message destined for this AS for a time T(r) or until an
  ASP becomes available.  When no ASP becomes available before expiry of
  T(r), the SGP will flush the buffered messages and initiate the
  appropriate ISUP call clearing procedures.

    If there is no match for an incoming message, a default treatment
  MAY be specified.  Possible solutions are to provide a default
  Application Server to direct all unallocated call processing and
  circuit supervision messages to a (set of) default ASP(s), or to drop
  the messages and provide a notification to management.  The treatment
  of unallocated circuits is implementation dependent.

1.4.1.4.2.  Circuit Mapping at the ASP

    To direct messages to the SS7 network, the ASP MAY perform a circuit
  mapping to choose the proper SGP for the given message.  This is
  accomplished by observing the Circuit Identification Code, Range and
  Status, and other elements of the outgoing message, SS7 network
  status, SGP availability, and Routing Context configuration tables.

    A Signalling Gateway may be composed of one or more SGPs.  There is,
  however, no ISUA messaging to manage the status of an SGP.  Whenever
  an SCTP association to an SGP exists, it is assumed to be available.
  Also, every SGP of one SG communicating with one ASP regarding one AS
  provides identical call control to this ASP.

    In general, an ASP routes responses to the SGP that it received
  messages from; within the routing context which it is currently active
  and receiving transactions.  The routing context itself is used by the
  ASP to select the SGP.

B. Bidulock                    Version 0.4                       Page 13

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

1.4.1.5.  Signalling Gateway SS7 Layers

    The SG is responsible for terminating up to the Call Control of the
  SS7 protocol, and offering an IP-based extension to its users.

    From an SS7 perspective, it is expected that the Signalling Gateway
  transmits and receives ISUP messages to and from the SS7 Network over
  standard SS7 network interfaces, using the services of the MTP [Q.704]
  to provide transport of the messages.

    Note that it is also possible for the MTP services to be provided
  using the services of the MTP-User Adaptation Layer (M3UA) [M3UA].

    The ISUP-SAP through which ISUA at the SG obtains its services could
  reside at a Signalling Transfer Point (STP) or Signalling End Point
  (SEP) [Q.701].

1.4.1.6.  SS7 and ISUA Interworking at the SG

    The SGP provides a functional interworking of transport functions
  between the SS7 network and the IP network by also supporting the ISUA
  adaptation layer.  It allows the ISUP application to exchange call
  control messages with an IP-based Application Server Process where the
  peer Call Control protocol layer exists.

    To perform ISUP circuit supervision, it is required that the Call
  Control protocols at ASPs receive indications of circuit state, as
  well as call state as they would be expected by an SS7 ISUP
  application.  To accomplish this, the RESET, BLOCKING, UNBLOCKING and
  CCT GROUP QUERY primitives received at the ISUP upper layer interface
  at the SG need to be propagated to the remote Call Control lower layer
  interface at the ASP.

    ISUP call processing and circuit supervision messages (such as BLO,
  BLA, CGB, CGBA) received from the SS7 network MUST NOT be
  encapsulated.  The SG MUST terminate these messages and generate ISUA
  message as appropriate.

1.4.1.7.  Application Server

    A cluster of Application Servers is responsible for providing the
  overall support for one ore more SS7 upper layers.  From an ISUP
  standpoint, Call Control provides complete support for the upper layer
  service for given Circuits or Trunk Groups.  As an example, Call
  Control could provide complete support for Central Office Call Control
  for a given point code.

1.4.1.8.  SCTP Stream Mapping

    The ISUA supports SCTP streams.  The SG and AS need to maintain a
  list of SCTP and Call Control for mapping purposes.  Call Control
  requiring sequenced message transfer need to be sent over a stream
  using sequenced delivery.

B. Bidulock                    Version 0.4                       Page 14

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    ISUA SHOULD NOT use stream 0 for ISUA circuit supervision messages.
  It is OPTIONAL that sequence delivery be used to preserve the order of
  circuit supervision message delivery.

    All ISUA Circuit Supervision (CS) messages MAY select unordered
  delivery, depending on the requirements of Call Control.  Normally one
  stream is used to send ISUA Circuit Supervision (CS) messages between
  peers, regardless of Application Server.

    All Call Processing (CP) messages MUST be sent using ordered
  delivery.  All Call Processing (CP) messages relating to the same call
  MUST be sent on the same stream as other Call Processing (CP) messages
  relating to the same call.  The stream selected is based upon the Call
  Reference given by the Call Control over the primitive interface and
  other traffic information available to the SGP or ASP.

1.4.2.  Redundancy Models

1.4.2.1.  Application Server Redundancy

    All CSET and Circuit Supervision (CS) messages (e.g, SETUP, RESET,
  BLOCKING) which match a provisioned Routing Key at an SGP are mapped
  to an Application Server.

    The Application Server is the set of all ASPs associated with a
  specific Routing Key.  Each ASP in this set may be active, inactive or
  unavailable.  Active ASPs handle traffic; inactive ASPs might be used
  when active ASPs become unavailable.

    The fail-over model supports an "n+k" redundancy model, where "n"
  ASPs is the minimum number of redundant ASPs required to handle
  traffic and "k" ASPs are available to take over for a failed or
  available ASP.  A "1+1" active/backup redundancy is a subset of this
  model.  A simplex "1+0" model is also supported as a subset, with no
  ASP redundancy.

1.4.3.  Flow Control

    Local Management at an ASP may wish to stop traffic across an SCTP
  association to temporarily remove the association from service or to
  perform testing and maintenance activity.  The function could
  optionally be used to control the start of traffic onto a newly
  available SCTP association.

1.4.4.   Congestion Management

    The ISUA layer is informed of local and IP network congestion by
  means of an implementation-dependent function (e.g, an implementation-
  dependent indication from the SCTP of IP network congestion).

    At an ASP or IPSP, the ISUA layer indicates congestion to local Call
  Control by means of an appropriate ISUP primitive, as per current ISUP
  procedures, to invoke appropriate upper layer responses.  When an SG

B. Bidulock                    Version 0.4                       Page 15

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  determines that the transport of SS7 messages is encountering
  congestion, the SG might trigger SS7 Congestion messages to
  originating SS7 nodes, per the congestion procedures of the relevant
  ISUP [T1.113], [Q.764] or MTP [T1.111], [Q.704] standard.  (The
  triggering of SS7 Management messages from an SG is an implementation-
  dependent function.)

1.5.  Definition of ISUA Boundaries

    ISUA has three protocol boundaries: an upper boundary between ISUA
  and Call Control; a lower boundary between ISUA and SCTP; and a layer
  management boundary between ISUA and the Layer Management Function.
  Figure 3 illustrates the ISUA protocol boundaries.

                      ...........
                      :   CC    :
                      :.........:  Layer
            Upper Boundary :       Management
                       ____:____   Boundary   ............
                      |   ISUA  |.............:    LM    :
                      |_________|             :..........:
            Lower Boundary :
                      .....:.....
                      :   SCTP  :
                      :.........:

                    Figure 3.  ISUA Protocol Boundaries

1.5.1.  Definition of Upper Boundary

    The primitives and messages listed in Table 2 are provided between
  the ISUA and Call Control in support of Call Control [Q.761],
  [T1.113].
               Table 2. Mapping of Call Control Primitives

    +-------------+------------+---------------+---------------+------+
    |Generic      | Specific   |  ITU-T Q.764  |  ANSI T1.113  | ISUA |
    |Name         | Name       |    Message    |    Message    | Msg  |
    +-------------+------------+---------------+---------------+------+
    |Call Setup Messages                                              |
    +-------------+------------+---------------+---------------+------+
    |SETUP        | Request    |      IAM      |      IAM      | CSET |
    |             | Indication |               |               |      |
    |             +------------+---------------+---------------+------+
    |             | Response   |   ANM, CON    |      ANM      | CCON |
    |             | Confirm    |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |MORE INFO    | Request    |       -       |       -       | CMOR |
    +-------------+------------+---------------+---------------+------+

B. Bidulock                    Version 0.4                       Page 16

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    +-------------+------------+---------------+---------------+------+
    |Generic      | Specific   |  ITU-T Q.764  |  ANSI T1.113  | ISUA |
    |Name         | Name       |    Message    |    Message    | Msg  |
    +-------------+------------+---------------+---------------+------+
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |TIMEOUT      | Indication |       -       |       -       | CTOT |
    +-------------+------------+---------------+---------------+------+
    |INFO         | Request    |      SAM      |      SAM      | CINF |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |PROC         | Request    |   ACM, CPG    |   ACM, CPG    | CPRO |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |ALERT        | Request    |   ACM, CPG    |   ACM, CPG    | CALR |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |PROG         | Request    |   ACM, CPG    |   ACM, CPG    | CPRG |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |Call Established Messages                                        |
    +-------------+------------+---------------+---------------+------+
    |SUSPEND      | Request    |      SUS      |      SUS      | CSUS |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |RESUME       | Request    |      RES      |      RES      | CRES |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |Call Termination Messages                                        |
    +-------------+------------+---------------+---------------+------+
    |REATTEMPT    | Indication |       -       |       -       | CREA |
    +-------------+------------+---------------+---------------+------+
    |CALL FAILURE | Indication | RST, REL, RLC | RST, REL, RLC | CERR |
    +-------------+------------+---------------+---------------+------+
    |IBI          | Request    |   ACM, CPG    |   ACM, CPG    | CIBI |
    |             | Indication |               |               |      |
    +-------------+------------+---------------+---------------+------+
    |RELEASE      | Request    |      REL      |      REL      | CREL |
    |             | Indication |               |               |      |
    |             +------------+---------------+---------------+------+
    |             | Response   |   REL, RLC    |   REL, RLC    | CRLC |
    |             | Confirm    |               |               |      |
    +-------------+------------+---------------+---------------+------+

1.5.2.  Definition of Boundary between ISUA and Layer Management

  M-SCTP_ESTABLISH request
  Direction: LM->ISUA
  Purpose:   LM request ASP to establish an SCTP association with its
             peer.

B. Bidulock                    Version 0.4                       Page 17

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  M-SCTP_ESTABLISH confirm
  Direction: ISUA -> LM
  Purpose:   ASP confirms to LM that it has established an SCTP
             association with its peer.

  M-SCTP_ESTABLISH indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that a remote ASP has established an SCTP
             association.

  M-SCTP_RELEASE request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to release an SCTP association with its
             peer.

  M-SCTP_RELEASE confirm
  Direction: ISUA -> LM
  Purpose:   ASP confirms to LM that it has released SCTP association
             with its peer.

  M-SCTP_RELEASE indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that a remote ASP has released an SCTP
             Association or the SCTP association has failed.

  M-SCTP RESTART indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that an SCTP restart indication has been
             received.

  M-SCTP_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of an SCTP
             association.

  M-SCTP_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA responds with the status of an SCTP association.

  M-SCTP_STATUS indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports the status of an SCTP association.

  M-ASP_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of a local or
             remote ASP.

  M-ASP_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA reports status of local or remote ASP.

B. Bidulock                    Version 0.4                       Page 18

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  M-AS_STATUS request
  Direction: LM -> ISUA
  Purpose:   LM requests ISUA to report the status of an AS.

  M-AS_STATUS confirm
  Direction: ISUA -> LM
  Purpose:   ISUA reports the status of an AS.

  M-NOTIFY indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that it has received a Notify (NTFY) message
             from its peer.

  M-ERROR indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that it has received an Error (ERR) message
             from its peer or that a local operation has been
             unsuccessful.

  M-ASP_UP request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to start its operation and send an ASP Up
             (ASPUP) message to its peer.

  M-ASP_UP confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that is has received an ASP UP Ack (ASPUP
             ACK) message from its peer.  T} ; ls l1lw(5.7i).  M-
             ASP_UP indication Direction:;ISUA -> LM Purpose:;T{ ISUA
             reports it has successfully processed an incoming ASP Up
             (ASPUP) message from its peer.

  M-ASP_DOWN request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to stop its operation and send an ASP
             Down (ASPDN) message to its peer.

  M-ASP_DOWN confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that is has received an ASP Down Ack (ASPDN
             ACK) message from its peer.

  M-ASP_DOWN indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Down (ASPDN) message from its peer, or the SCTP
             association has been lost or reset.

  M-ASP_ACTIVE request
  Direction: LM -> ISUA

B. Bidulock                    Version 0.4                       Page 19

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Purpose:   LM requests ASP to send an ASP Active (ASPAC) message to
             its peer.

  M-ASP_ACTIVE confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that is has received an ASP Active Ack (ASPAC
             ACK) message from its peer.

  M-ASP_ACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Active (ASPAC) message from its peer.

  M-ASP_INACTIVE request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to send an ASP Inactive (ASPIA) message
             to its peer.

  M-ASP_INACTIVE confirm
  Direction: LM -> ISUA
  Purpose:   ASP reports that is has received an ASP Inactive Ack
             (ASPIA ACK) message from its peer.

  M-ASP_INACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports it has successfully processed an incoming
             ASP Inactive (ASPIA) message from its peer.

  M-AS_ACTIVE indication
  Direction: ISUA -> LM
  Purpose:   ISUA reports that an AS has moved to the AS-ACTIVE state.

  M-AS_INACTIVE indication
  Direction: ISUA -> LM
  Purpose:   UA reports that an AS has moved to the AS-INACTIVE state.

  M-AS_DOWN indication
  Direction: ISUA -> LM
  Purpose:   UA reports that an AS has moved to the AS-DOWN state.

    If the ISUA layer supports dynamic registration of Routing Key, the
  layer MAY support the following additional primitives:

  M-RK_REG request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to register RK(s) with its peer by
             sending Registration Request (REG REQ) message

  M-RK_REG confirm

B. Bidulock                    Version 0.4                       Page 20

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Direction: ISUA -> LM
  Purpose:   ASP reports that it has received Registration Response
             (REG RSP) message with registration status as successful
             from its peer.

  M-RK_REG indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that it has successfully processed an
             incoming Registration Request (REG REQ) message.

  M-RK_DEREG request
  Direction: LM -> ISUA
  Purpose:   LM requests ASP to deregister RK(s) with its peer by
             sending Deregistration Request (DEREG REQ) message.

  M-RK_DEREG confirm
  Direction: ISUA -> LM
  Purpose:   ASP reports that it has received Deregistration Request
             (DEREG REQ) message with deregistration status as
             successful from its peer.

  M-RK_DEREG indication
  Direction: ISUA -> LM
  Purpose:   ISUA informs LM that it has successfully processed an
             incoming Deregistration Request (DEREG REQ) message from
             its peer.

1.5.3.  Definition of the Lower Boundary

  The upper layer primitives provided by the SCTP are provided in the
  SCTP specification "Stream Control Transmission Protocol (SCTP)"
  [SCTP].

Notes for Section 1

  <1>  IMPLEMENTATION NOTE:-  Only one SCTP port may be defined for
       each endpoint, but each SCTP endpoint may have multiple IP
       addresses [SCTP].

2.  Conventions

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

  In this document, the following conventions are used to describe how a
  parameter is used in the message:

B. Bidulock                    Version 0.4                       Page 21

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    Mandatory     The parameter MUST be present in the message.  A
                  message listing a parameter as Mandatory without
                  containing such a parameter is is incorrectly
                  formatted.

    Conditional   The parameter SHOULD be present in the message
                  under the conditions specified.  A message listing
                  a parameter as Conditional without containing such
                  a parameter under the conditions specified is
                  incorrectly formatted.

    Optional      The parameter MAY be present in the message as
                  specified.  A message listing a parameter as
                  Optional without containing such a parameter is
                  correctly formatted.

3.  Protocol Elements

    The general message format includes a Common Message Header together
  with a list of zero or more parameters as defined by the Message Type.

    For forward compatibility, all Message Types MAY have attached
  parameters even if none are specified in this version.

3.1.  Common Message Header

    The protocol messages for the ISUP-User Adaptation Protocol (ISUA)
  require a message structure that contains a version, message type,
  message length and message contents:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Version    |   Reserved    | Message Class | Message Type  |
    +---------------+---------------+---------------+---------------+
    |                        Message Length                         |
    +---------------------------------------------------------------+
    |                         Message Data                          |

  Notes:

   + This message header is common among all signalling protocol
     adaptation layers.
   + The 'data' portion of ISUA messages SHALL contain zero or more ISUA
     parameters, and SHALL NOT contain an encapsulated ISUP message.
   + All fields in the ISUA message MUST be transmitted in the network
     byte order, unless otherwise stated.
   + The Reserved field SHALL be coded zero by the sender of the message
     and SHALL be ignored by the receiver of the message.

B. Bidulock                    Version 0.4                       Page 22

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

3.1.1.  ISUA Protocol Version

  Version: 8-bits (unsigned integer)

    The Version field of the Common Message Header contains the version
    of the ISUA adaptation layer.  The supported versions are:

        1 - ISUA Version 1.0

3.1.2.  Message Classes

  Message Class: 8-bits (unsigned integer)

    The Message Class field of the Common Message Header contains the
    class of the message.  The supported classes are as follows:

        0        Management (MGMT) Message
        7        Reserved for Other Signalling Adaptation Layers
        2        Reserved for Other Signalling Adaptation Layers
        3        ASP State Maintenance (ASPSM) Messages
        4        ASP Traffic Maintenance (ASPTM) Messages
        5        Reserved for Other Signalling Adaptation Layers
        6        Reserved for Other Signalling Adaptation Layers
        7        Reserved for Other Signalling Adaptation Layers
        8        Reserved for Other Signalling Adaptation Layers
        9        Routing key Management (RKM) Messages
       10        ISUA Call Processing (CP) Messages
       11        ISUA Circuit Supervision (CS) Messages
       12 - 127  Reserved by the IETF
      128 - 255  Reserved for IETF-Defined Message Class Extensions

3.1.3.  Message Types

  Message Type: 8-bits (unsigned integer)

    The Message Type field of the Common Message Header contains the
    type of message within a message class.  The supported types of
    messages within the supported classes are as follows:

    Management (MGMT) Messages
      0         Error (ERR)
      1         Notify (NTFY)
      2 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Application Server Process State Maintenance (ASPSM) Messages

B. Bidulock                    Version 0.4                       Page 23

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      0         Reserved
      1         ASP Up (UP)
      2         ASP Down (DOWN)
      3         Heartbeat (BEAT)
      4         ASP Up Ack (UP ACK)
      5         ASP Down Ack (DOWN ACK)
      6         Heartbeat Ack (BEAT ACK)
      7 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Application Server Process Traffic Maintenance (ASPTM) Messages
      0         Reserved
      1         ASP Active (ASPAC)
      2         ASP Inactive (ASPIA)
      3         ASP Active Ack (ASPAC ACK)
      4         ASP Inactive Ack (ASPIA ACK)
      5 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    Routing Key Management (RKM) Messages
      0         Reserved
      1         Registration Request (REG REQ)
      2         Registration Response (REG RSP)
      3         Deregistration Request (DEREG REQ)
      4         Deregistration Response (DEREG RSP)
      5 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    ISUA Call Processing (CP) Messages
      0         Reserved
      1         Setup (CSET)
      2         More Information (CMOR)
      3         Timeout (CTOT)
      4         Information (CINF)
      5         Proceeding (CPRO)
      6         Alerting (CALR)
      7         Progress (CPRG)
      8         Connect (CCON)
      9         Suspend (CSUS)
     10         Resume (CRES)
     11         Reattempt (CREA)
     12         Failure (CERR)
     13         In Band Information (CIBI)
     14         Release (CREL)
     15         Release Complete (CRLC)
     16 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

    ISUA Circuit Supervision (CS) Messages
      0         Reserved
      1         Continuity Check (CCNT)
      2         Loop Back (CLBK)

B. Bidulock                    Version 0.4                       Page 24

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      3         Report (CREP)
      4         Reset (CRSC)
      5         Reset Acknowledgement (CRSA)
      6         Block (CBLO)
      7         Block Acknowledgement (CBLA)
      8         Unblock (CUBL)
      9         Unblock Acknowledgement (CUBA)
     10         Query (CQRY)
     11         Query Acknowledgement (CQRA)
     12 -  127  Reserved by the IETF
    128 -  255  Reserved for IETF-Defined Message Class Extensions

3.1.4.  Message Length

  Message Length: 32-bits (unsigned integer)

    The Message Length field of the Common Message Header defines the
    length of the message in octets, including the header.

3.1.5.  Tag-Length-Value Format

    ISUA messages consist of a Common Message Header followed by zero or
  more parameters, as defined by the message type.  The Tag-Length-Value
  (TLV) parameters contained in a message are defined in a Tag-Length-
  Value format as shown below <1>.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Parameter Tag        |       Parameter Length        |
    +-------------------------------+-------------------------------+
    \                                                               \
    /                       Parameter Value                         /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Parameter Tag: 16-bits (unsigned integer)

    The Parameter Tag field is a 16-bit identifier of the type of
    parameter.  It takes a value of 0 to 65534.

  Parameter Length: 16-bits (unsigned integer)

    The Parameter Length field contains the size of the parameter in
    bytes, including the Parameter Tag, Parameter Length, and Parameter
    Value fields.  The Parameter Length does not include any padding
    bytes.  However, composite parameters will contain all padding
    bytes, since all parameters contained within this composite
    parameter will considered multiples of 4 bytes.

B. Bidulock                    Version 0.4                       Page 25

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Parameter Value: variable-length

    The Parameter Value field contains the actual information to be
    transferred in the parameter.  The total length of a parameter
    (including Tag, Parameter Length and Value fields) MUST be a
    multiple of 4 bytes.  If the length of the parameter is not a
    multiple of 4 bytes, the sender MUST pad the Parameter at the end
    (i.e., after the Parameter Value field) with all zero bytes.  The
    length of the padding MUST NOT be included in the parameter length
    field.  A sender SHOULD NOT pad with more than 3 bytes.  The
    receiver MUST ignore the padding bytes.

3.2.  ISUA Message Header

    In addition to the Common Message Header, a specific message header
  is included for ISUA messages.  The ISUA message header will
  immediately follow the Common Message Header in ISUA Call Processing
  (CP) and Circuit Supervision (CS) messages.

  The ISUA Message Header is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Routing Context                        |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0013          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Correlation Id                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ISUA Message header can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      Correlation Id              Conditional   *2

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context MUST be present in the ISUA Message
          Header.  The Routing Context SHOULD always be placed in the
          ISUA Message Header.  When the Routing Context is present in
          the ISUA Message Header it SHOULD be placed first in the
          header because the context of the Correlation Id depends on
          the Routing Context.

  Note 2: Under some circumstances, the Correlation Id parameter MUST be
          included in the ISUA Message Header.  See sections "3.9.9 -

B. Bidulock                    Version 0.4                       Page 26

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

          Correlation Id" and "4.3.4.3 - ASP Active Procedures".

3.3.  ISUA Call Processing (CP) Messages

    The following section describes the ISUA Call Processing (CP)
  messages and parameter contents.  The general message format includes
  a Common Message Header, the ISUA Message Header and the CP Message
  Header, together with a list of zero or more parameters as defined by
  the Message Type.  For forward compatibility, all Message Types MAY
  have optional attached parameters in addition to the message headers.

  These messages are ISUA Call Processing (CP) messages:

              ISUA Call Processing (CP) Messages
      ----------------------------------------------------
      Message Name                 Message Type   Section
      ----------------------------------------------------
      CP Header                                   3.3.1
      Setup                 CSET         1        3.3.2
      More Information      CMOR         2        3.3.3
      Timeout               CTOT         3        3.3.4
      Information           CINF         4        3.3.5
      Proceeding            CPRO         5        3.3.6
      Alerting              CALR         6        3.3.7
      Progress              CPRG         7        3.3.8
      Connect               CCON         8        3.3.9
      Suspend               CSUS         9        3.3.10
      Resume                CRES        10        3.3.11
      Reattempt             CREA        11        3.3.12
      Failure               CERR        12        3.3.13
      In Band Information   CIBI        13        3.3.14
      Release               CREL        14        3.3.15
      Release Complete      CRLC        15        3.3.16
      ----------------------------------------------------

3.3.1.  CP Message Header

    In addition to the Common Message Header and ISUA Message Header, a
  specific message header is included for ISUA Call Processing (CP)
  messages.  The CP Message Header will immediately follow the ISUA
  Message header in these messages.

  The CP Message Header is formatted as follows:

B. Bidulock                    Version 0.4                       Page 27

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0520          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Circuit Id                          |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0501          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Call Reference                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CP Message Header contains the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Id                  Conditional   *1
      Call Reference              Conditional   *2

  Note 1: The Circuit Id MUST be placed in the ISUA CP Message Header
          for all CP messages sent from the SGP to the ASP, and is
          OPTIONAL in the ISUA CP Message Header for all CP messages
          sent from the ASP to the SGP for which a Circuit Id was
          assigend to the call by the SGP before the message was sent.
          If Circuit Id was not assigned by the SGP before the ASP sends
          a CP message, the ASP MAY include the Circuit Id parameter for
          simplicity, but it MUST then be coded zero (0).  CP messages
          for which a Circuit Id has not been assigned by the SGP
          include only the Setup (CSET) request message sent from the
          ASP to the SGP.

  Note 2: The Call Reference MUST be placed in the ISUA CP Message
          Header for all CP messages sent from ASP to the SGP, and is
          OPTIONAL in the ISUA CP Message Header for all CP messages
          sent from the SGP to the ASP for which a Call Reference was
          assigned to the call by the ASP before the message was sent.
          If Call Reference was not assigned by the ASP before the SGP
          sends a CP message, the SGP MAY include the Call Reference
          parameter for simplicity, but it MUST then be coded zero (0).
          CP messages for which a Call Reference has not been assigned
          by the ASP include only the Setup (CSET) indication message
          sent from the SGP to the ASP.

3.3.2.  Setup (CSET)

    The Setup (CSET) Request message is sent from an ASP to an SG or
  IPSP to initiate an outgoing ISUP call setup.  The CSET Indication
  message is sent from an SGP to an ASP to indicate an incoming ISUP
  call setup.

B. Bidulock                    Version 0.4                       Page 28

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    The CSET message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Setup' (Request, Indication) primitive and the ITU-T and
  ANSI ISUP `IAM' message [T1.113], [Q.763].

  The CSET message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0502          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Call Type                           |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0503          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Call Flags                          |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0504          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Called Party Number                     /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CSET message can contain the following parameters:

      Parameters
      -------------------------------------------
      Call Type                   Mandatory
      Call Flags                  Mandatory
      Called Party Number         Mandatory
      Optional Parameters         Optional    *1

  Note 1: Although the Optional Parameters are optional in the CSET
          message, the specific ISUP variant and network policy in which
          the implementation is operating could require that the
          implementation always place specific parameters in the
          Optional Parameters parameter.  An example of this would be
          the Charge Number of GR-394 networks.

3.3.3.  More Information (CMOR)

    The More Information (CMOR) message is sent from an SGP to an ASP to
  request additional address information for an outgoing ISUP call

B. Bidulock                    Version 0.4                       Page 29

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  setup.

    The CMOR message does not correspond to a Call Control primitive or
  ISUP message.

    The COMR message has no message-type-specific parameters beyond the
  CP Message Header.

3.3.4.  Timeout (CTOT)

    The Timeout (CTOT) message is sent from an SGP to an ASP to indicate
  that the SG has timed out while waiting for additional address
  information.

    The CTOT message does not correspond to a Call Control primitive or
  ISUP message.

    The CTOT message has no message-type-specific parameters beyond the
  CP Message Header.

3.3.5.  Information (CINF)

    The Information (CINF) message is sent from an ASP to an SGP to
  provide additional address information for an outgoing ISUP call
  setup.  The CINF message is sent from an SGP to an ASP to provide
  additional address information for an incoming ISUP call setup.

    The CINF message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Info' primitive and the ITU-T and ANSI ISUP `SAM'
  message [T1.113], [Q.763].

  The CINF message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0505          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                        Subsequent Number                      /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CINF message can contain the following parameters:

B. Bidulock                    Version 0.4                       Page 30

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Parameters
      ------------------------------------------
      Subsequent Number           Mandatory
      Optional Parameters         Optional

  Note 1:

3.3.6.  Proceeding (CPRO)

    The Proceeding (CPRO) message is sent from an ASP to an SG to
  indicate that an outgoing call setup is proceeding.  The CPRO message
  is sent from an SGP to an ASP to indicate that an incoming call setup
  is proceeding.

    The CPRO message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Proceeding' primitive and the ITU-T and ANSI ISUP `ACM' and `CPG'
  message [T1.113], [Q.763].

  The CPRO message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0508          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Proceeding Flags                       |
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CPRO message can contain the following parameters:

      Parameters
      -------------------------------------------
      Proceeding Flags            Mandatory
      Optional Parameters         Optional
                                              *1

  Note 1:

3.3.7.  Alerting (CALR)

    The Alerting (CALR) message is sent from an ASP to an SG to indicate
  that the terminating access on a incoming call setup is being alerted.
  The CALR message is sent from an SGP to an ASP to indicate that the

B. Bidulock                    Version 0.4                       Page 31

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  terminating access on an outgoing call setup is being alerted.

    The CALR message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Alerting' primitive and the ITU-T and ANSI `IAM' message [T1.113],
  [Q.763].

  The CALR message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CALR message can contain the following parameters:

        Parameters
        ------------------------------------------
        Optional Parameters         Optional
                                               *1

  Note 1:

3.3.8.  Progress (CPRG)

    The Progress (CPRG) message is sent from an ASP to an SG to indicate
  that an incoming call setup is in progress.  The CPRG message is sent
  from an SGP to an ASP to indicate that an outgoing call setup is in
  progress.

    The CPRG message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Progress' primitive and the ITU-T and ANSI ISUP `ACM' and `CPG'
  message [T1.113], [Q.763].

  The CPRG message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 32

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0509          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Progress Event                         |
    +-------------------------------+-------------------------------+
    |         Tag = 0x050A          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Progress Flags                         |
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CPRG message can contain the following parameters:

      Parameters
      -------------------------------------------
      Progress Event              Mandatory
      Progress Flags              Mandatory
      Optional Parameters         Optional
                                              *1

  Note 1:

3.3.9.  Connect (CCON)

    The Connect (CCON) message is sent from an ASP to an SG to indicate
  that an incoming ISUP call has been connected.  The CCON message is
  sent from an SGP to an ASP to indicate that an outgoing ISUP call has
  ben connected.

    The CCON message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Setup' (Response and Confirmation) primitive and the
  ITU-T `ANM' and `CON' and ANSI `ANM' message [T1.113], [Q.763].

  The CCON message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 33

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CCON message can contain the following parameters:

      Parameters
      ------------------------------------------
      Optional Parameters         Optional
                                             *1

  Note 1:

3.3.10.  Suspend (CSUS)

    The Suspend (CSUS) message is sent from the ASP to an SG or from the
  SGP to the ASP to indicate that an established call has been
  suspended.

    The CSUS message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Suspend' primitive and the ITU-T and ANSI `SUS' message
  [T1.113], [Q.763].

  The CSUS message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050B          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                     Suspend/Resume Flags                      |
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CSUS message can contain the following parameters:

B. Bidulock                    Version 0.4                       Page 34

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Parameters
      ------------------------------------------
      Suspend/Resume Flags        Mandatory
      Optional Parameters         Optional

  Note 1:

3.3.11.  Resume (CRES)

    The Resume (CRES) message is sent from the ASP to an SG or from the
  SGP to the ASP to indicate that a previously suspended established
  call has been resumed.

    The CRES message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Resume' primitive and the ITU-T and ANSI `RES' message
  [T1.113], [Q.763].

  The CRES message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050B          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                     Suspend/Resume Flags                      |
    +-------------------------------+-------------------------------+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CRES message can contain the following parameters:

      Parameters
      ------------------------------------------
      Suspend/Resume Flags        Mandatory
      Optional Parameters         Optional

  Note 1:

3.3.12.  Reattempt (CREA)

    The Reattempt (CREA) Indication message is sent from an SGP to an
  ASP to indicate that a call attempt on a circuit should be reattempted
  on an alternate circuit.

B. Bidulock                    Version 0.4                       Page 35

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    If the ASP selected the outgoing circuit in the corresponding CSET,
  then the ASP is responsible for selecting another circuit and issuing
  a new CSET message.  If the ASP did not select the outgoing circuit in
  the corresponding CSET message, then the SGP is responsible for
  performing an automatic reattempt on a new circuit or subsequently
  indicating call failure with a CERR message.

    The CREA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Reattempt' primitive and does not correspond to an ISUP
  message.

  The CREA message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0506          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Reattempt Reason                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CREA message can contain the following parameters:

      Parameters
      ------------------------------------------
      Reattempt Reason            Mandatory

3.3.13.  Failure (CERR)

    The Failure (CERR) message is sent from an ASP to an SG to indicate
  the failure of an incoming call setup.  The CERR message is sent from
  an SGP to an ASP to indicate the failure of an outgoing call setup.

    The CERR message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Failure `Call Failure' primitive and the ITU-T and ANSI `RST,'
  `REL' and `RLC' message [T1.113], [Q.763].

  The CERR message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050C          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        Failure Reason                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CERR message can contain the following parameters:

B. Bidulock                    Version 0.4                       Page 36

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Parameters
      -------------------------------------------
      Failure Reason              Mandatory
                                              *1

  Note 1:

3.3.14.  In Band Information (CIBI)

    The In Band Information (CIBI) message is sent from an ASP to an SG
  to indicate that in band information is now available for an incoming
  call.  The CIBI message is sent from an SGP to an ASP to indicate that
  in band information is now available for an outgoing call.

    The CIBI message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Setup `In Band Information' primitive and the ITU-T and ANSI
  `ACM' and `CPG' message [T1.113], [Q.763].

  The CIBI message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050E          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Optional Parameters                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CIBI message can contain the following parameters:

      Parameters
      ------------------------------------------
      Optional Parameters         Optional
                                             *1

3.3.15.  Release (CREL)

    The Release (CREL) message is sent from an ASP to an SG or from the
  SGP to an ASP to release a call during the setup or established phase.

    The CREL message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Release' (Request, Indication) primitive and the ITU-T
  and ANSI `REL' message [T1.113], [Q.763].

  The CREL message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 37

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050D          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                             Cause                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CREL message can contain the following parameters:

      Parameters
      ------------------------------------------
      Cause                       Mandatory

3.3.16.  Release Complete (CRLC)

    The Release Complete (CRLC) message is sent from an ASP to an SG or
  from an SGP to an ASP to confrim the release of a call.

    The CRLC message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Release' (Response, Confirmation) primitive and the ITU-
  T and ANSI `REL' and `RLC' message [T1.113], [Q.763].

  The CRLC message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x050D          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                             Cause                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CRLC message can contain the following parameters:

      Parameters
      ------------------------------------------
      Cause                       Mandatory

3.4.  ISUA Circuit Supervision (CS) Messaegs

    ISUA Circuit Supervision (CS) Messages are used to convey circuit
  management information to Call Control.  Theses messages correspond to
  specific RESET, BLOCKING, UNBLOCKING and CCT GROUP QUERY primitives.
  The general message format includes a Common Message Header, the ISUA
  Message Header, and the CS Message Header, together with a list of
  zero or more parameters as defined by the Message Type.  For forward
  compatibility, all Message Types MAY have optional attached parameters

B. Bidulock                    Version 0.4                       Page 38

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  in addition to the message headers.

  These messages are ISUA Circuit Supervision (CS) Messages:

              ISUA Circuit Supervision (CS) Messages
      --------------------------------------------------------
      Message Name                     Message Type   Section
      --------------------------------------------------------
      CS Header                                       3.4.1
      Continuity Check          CCNT        6         3.4.2
      Loop Back                 CLBK        7         3.4.3
      Report                    CREP        8         3.4.4
      Reset                     CRSC        1         3.4.5
      Reset Acknowledgement     CRSA        2         3.4.6
      Block                     CBLO        3         3.4.7
      Block Acknowledgement     CBLA        4         3.4.8
      Unblock                   CUBL        5         3.4.9
      Unblock Acknowledgement   CUBA        6         3.4.10
      Query                     CQRY        7         3.4.11
      Query Acknowledgement     CQRA        8         3.4.12
      --------------------------------------------------------

3.4.1.  CS Message Header

    In addition the the Common Message Header and ISUA Message Header, a
  specific message header is included for ISUA Circuit Supervision (CS)
  messages.  The CS Message Header will immediately follow the ISUA
  Message Header in these messages.

  The CS Message Header is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0520          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Circuit Id                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CS Message Header contains the following parameters:

      Parameters
      ------------------------------------------
      Circuit Id                  Mandatory

3.4.2.  Continuity Check (CCNT)

    The Continuity Check (CCNT) message is sent from an ASP to an SGP to
  request an continuity check on a specified circuit.  The CCNT message

B. Bidulock                    Version 0.4                       Page 39

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  is sent from an SGP to an ASP to indicate an a continuity check
  request on the specified circuit.

    The CCNT message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Continuity Recheck' (Request) primitive and the ITU-T
  and ANSI ISUP `CCR' message [T1.113], [Q.763].

    The CCNT message has no message-type-specific parameters beyond the
  CS Message Header.

3.4.3.  Loop Back (CLBK)

    The Loop Back (CLBK) message is sent from an ASP to an SGP to
  indicate that a loop back has been established on the local end of the
  specified circuit.  The CLBK message is sent from an ASP to an SGP to
  indicate that a loop back has been establish on the remote end of the
  specified circuit.

    The CLBK message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  Call Control `Continuity Recheck' (Confirmation) primitive and the
  ITU-T and ANSI ISUP `LPA' message [T1.113], [Q.763].

    The CLBK message has no message-type-specific parameters beyond the
  CS Message Header.

3.4.4.  Report (CREP)

    The Report (CREP) Request message is sent from an ASP to SG or from
  an SGP to an ASP to indicate the success or failure of a continuity
  test operation on the specified circuit.

    The CREP message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Continuity Report' primitive and the ITU-T and ANSI ISUP `COT'
  message [T1.113], [Q.763].

  The CREP message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0507          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Check Result                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CREP message can contain the following parameters:

      Parameters
      ------------------------------------------

B. Bidulock                    Version 0.4                       Page 40

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Check Result                Mandatory

3.4.5.  Reset (CRSC)

    The Reset (CRSC) message is sent from an ASP to an SG to request the
  reset of the specified circuit(s).  The CRSC message is sent from the
  SGP to an ASP to indicate the reset reset of the specified circuit(s).

    The CRSC message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Reset' (Request) primitive and the ITU-T and ANSI ISUP `RSC' and
  `GRS' message [T1.113], [Q.763].

  The CRSC message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CRSC message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CRSC message corresponds to the `GRS' message.  When the
          Circuit Range is not present in the message, the CRSC message
          corresponds to the `RSC' message.

3.4.6.  Reset Acknowledgement (CRSA)

    The Reset Acknowledgement (CRSA) message is sent from an SGP to an
  ASP to confirm the reset of the specified circuit(s).

    The CRSA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `Reset' (Confirmation) primitive and the ITU-T and ANSI ISUP `RLC' and
  'GRA' message.

  The CRSA message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 41

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CRSA message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CRSA message corresponds to the `GRA' message and the
          Circuit Range parameter SHOULD match the corresponding
          parameter in the CRSC request message.  When the Circuit Range
          is not present in the message, the CRSA message corresponds to
          the `RLC' message.

3.4.7.  Block (CBLO)

    The CBLO Request message is sent from an ASP to an SG or IPSP to
  perform a blocking request.  The CBLO Indication message is sent from
  the SGP to an ASP to indicate the blocking indication.

    The CBLO message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `BLOCKING' primitive and the ITU-T and ANSI `BLO' and `CGB' message.

  The CBLO message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CBLO message can contain the following parameters:

B. Bidulock                    Version 0.4                       Page 42

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CBLO message corresponds to the `CGB' message.  When the
          Circuit Range is not present in the message, the CBLO message
          corresponds to the `BLO' message.

3.4.8.  Block Acknowledgement (CBLA)

    The Block Acknowledgement (CBLA) Request message is sent from an ASP
  to an SG or IPSP to perform a blocking response.  The CBLA Indication
  message is sent from the SGP to an ASP to indicate the blocking
  confirmation.

    The CBLA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `BLOCKING' primitive and the ITU-T and ANSI `BLA' and `CGBA' message.

  The CBLA message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CBLA message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CBLA message corresponds to the `CGBA' message and the
          Circuit Range parameter SHOULD match the corresponding
          parameter in the CBLO request message.  When the Circuit Range
          is not present in the message, the CBLA message corresponds to
          the `BLA' message.

3.4.9.  Unblock (CUBL)

    The Unblock (CUBL) Request message is sent from an ASP to an SG or
  IPSP to perform a unblocking request.  The CUBL Indication message is
  sent from the SGP to an ASP to indicate the unblocking indication.

B. Bidulock                    Version 0.4                       Page 43

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    The CUBL message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `UNBLOCKING' primitive and the ITU-T and ANSI `UBL' and `CGU' message.

  The CUBL message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CUBL message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CUBL message corresponds to the `CGU' message.  When the
          Circuit Range is not present in the message, the CUBL message
          corresponds to the `UBL' message.

3.4.10.  Unblock Acknowledgement (CUBA)

    The Unblock Acknowledgement (CUBA) Request message is sent from an
  ASP to an SG or IPSP to perform a unblocking response.  The CUBA
  Indication message is sent from the SGP to an ASP to indicate the
  unblocking confirmation.

    The CUBA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `UNBLOCKING' primitive and the ITU-T and ANSI `UBA' and `CGUA'
  message.

  The CUBA message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 44

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The CUBA message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Circuit Range               Conditional   *1

  Note 1: When the Circuit Range parameter is included in the message,
          the CUBA message corresponds to the `CGUA' message and the
          Circuit Range parameter SHOULD match the corresponding
          parameter in the CUBL request message.  When the Circuit Range
          is not present in the message, the CUBA message corresponds to
          the `UBA' message.

3.4.11.  Query (CQRY)

    The Query (CQRY) Request message is sent from an ASP to an SG or
  IPSP to perform a query request.  The CQRY Indication message is sent
  from the SGP to an ASP to indicate the query indication.

    The CQRY message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `CCT GROUP QUERY' primitive and the ITU-T and ANSI `CQM' message.

  The CQRY message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0523          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Range                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CQRY message can contain the following parameters:

      Parameters
      ------------------------------------------
      Circuit Range               Mandatory   1

3.4.12.  Query Acknowledgement (CQRA)

    The Query Acknowledgement (CQRA) Request message is sent from an ASP
  to an SG or IPSP to perform a query response.  The CQRA Indication
  message is sent from the SGP to an ASP to indicate the query
  confirmation.

    The CQRA message corresponds to the ITU-T [Q.764] and ANSI [T1.113]
  `CCT GROUP QUERY' primitive and the ITU-T and ANSI `CQMA' message.

B. Bidulock                    Version 0.4                       Page 45

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The CQRA message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x05XX          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Circuit Status                       /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The CQRA message can contain the following parameters:

      Parameters
      -------------------------------------------
      Circuit Status              Mandatory   *1

  Note 1: The Circuit Status parameter SHOULD contain a circuit status
          for each of the circuit identifiers present in the
          corresponding CQRY message.

3.5.  Application Server Process State Maintenance (ASPSM) Messages

3.5.1.  ASP Up (UP)

    The ASP Up (UP) message is used to indicate to a remote ISUA peer
  that the Adaptation layer is up and running.

  The ASP UP message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0011          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        ASP Identifier                         |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASP UP message can contain the following parameters:

B. Bidulock                    Version 0.4                       Page 46

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Parameters
      ---------------------------------------------
      ASP Identifier              Conditional   *1
      Info String                 Optional

  Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot identify
          the ASP by pre-configured address/port number information
          (e.g, where an ASP is resident on a Host using dynamic
          address/port number assignment).

3.5.2.  ASP Up Ack (UP ACK)

    The ASP Up Ack (UP ACK) message is used to acknowledge an ASP UP
  message received from a remote ISUA peer.

  The ASP UP ACK message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASP UP ACK message can contain the following parameters:

      Parameters
      -----------------------------------------
      Info String                 Optional

3.5.3.  ASP Down (DOWN)

    The ASP Down (DOWN) message is used to indicate to a remote ISUA
  peer that the adaptation layer is not running.

  The ASP DOWN message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 47

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The ASP DOWN message can contain the following parameters:

      Parameters
      -----------------------------------------
      Info String                 Optional

3.5.4.  ASP Down Ack (DOWN ACK)

    The ASP Down Ack (DOWN ACK) message is used to acknowledge an ASP
  DOWN message received from a remote ISUA peer.

  The ASP DOWN ACK message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASP DOWN ACK message can contain the following parameters:

      Parameters
      -----------------------------------------
      Info String                 Optional

  Note:
       The ASP DOWN ACK message will always be sent to acknowledge an
       ASP DOWN message.

3.5.5.  Heartbeat (BEAT)

    The Heartbeat (BEAT) message is optionally used to ensure that the
  ISUA peers are still available to each other.

  The BEAT message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0009          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Heartbeat Data                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 48

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The BEAT message can contain the following parameters:

      Parameters
      -----------------------------------------
      Heartbeat Data              Optional

3.5.6.  Heartbeat Ack (BEAT ACK)

    The Heartbeat ACK (BEAT ACK) message is sent in response to a BEAT
  message.  A peer MUST send a BEAT ACK in response to a BEAT message.
  It includes all the parameters of the received BEAT message, without
  any change.

  The BEAT ACK message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0009          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Heartbeat Data                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The BEAT ACK message can contain the following parameters:

      Parameters
      -----------------------------------------
      Heartbeat Data              Optional

3.6.  Application Server Process Traffic Maintenance (ASPTM) Messages

3.6.1.  ASP Active (ASPAC)

    The ASP Active (ASPAC) message is sent by an ASP to indicate to a
  remote ISUA peer that it is Active and ready to process signalling
  traffic for a particular Application Server.

  The ASPAC message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 49

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Routing Context                         /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x000B          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                       Traffic Mode Type                       |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASPAC message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      Traffic Mode Type           Optional      *2
      Info String                 Optional

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context associated with the AS whose
          activation is being requested MUST be placed in the ASPAC
          message.

  Note 2: The Traffic Mode Type parameter is not necessary in the ASPAC
          message when both peers are aware of the traffic mode of the
          AS by configuration or registration.

3.6.2.  ASP Active Ack (ASPAC ACK)

    The ASP Active Ack (ASPAC) Ack message is used to acknowledge an
  ASPAC message received from a remote ISUA peer.

  The ASPAC ACK message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 50

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Routing Context                         /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x000B          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                       Traffic Mode Type                       |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASPAC ACK message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      Traffic Mode Type           Optional
      Info String                 Optional

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context associated with the AS whose
          activation is being acknowledged MUST be placed in the ASPAC
          ACK message.

3.6.3.  ASP Inactive (ASPIA)

    The ASP Inactive (ASPIA) message is sent by an ASP to indicate to a
  remote ISUA peer that it is no longer processing signalling traffic
  within a particular Application Server.

  The ASPIA message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 51

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Routing Context                         /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          INFO String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASPIA message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      INFO String                 Optional

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context associated with the AS whose
          deactivation is being requested MUST be placed in the ASPIA
          message.

3.6.4.  ASP Inactive Ack (ASPIA ACK)

    The ASP Inactive Ack (ASPIA ACK) message is used to acknowledge an
  ASPIA message received from a remote ISUA peer.

  The ASPIA message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Routing Context                         /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          INFO String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 52

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The ASPIA message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Routing Context             Conditional   *1
      INFO String                 Optional

  Note 1: When an ASP is registered or configured for multiple AS with
          an SG, the Routing Context associated with the AS whose
          deactivation is being acknowledged MUST be placed in the ASPIA
          ACK message.

3.7.  Management (MGMT) Messages

3.7.1.  Error (ERR)

    The Error (ERR) message is used by a ISUA peer to indicate an error
  situation.  ERR messages MUST NOT be generated in response to other
  ERR messages.

  The ERR message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 53

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000C          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                          Error Code                           |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0521          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                       Network Appearance                      |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Routing Context                       /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0520          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Circuit Id                          |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0501          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Call Reference                        |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0007          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Diagnostic Info                       /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ERR message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Error Code                  Mandatory
      Routing Context             Conditional   *1
      Call Reference              Conditional   *2
      Circuit Id                  Conditional   *3
      Network Appearance          Conditional   *4
      Diagnostic Info             Conditional   *5

  Note 1: When the Error Code is "Invalid Routing Context," the Routing
          Context parameter MUST contain the invalid routing context
          value(s).

  Note 2: When the Error Code is "Call Reference Unknown," the Call
          Reference parameter MUST contain the call reference for which
          status is unknown or unauthorized.

B. Bidulock                    Version 0.4                       Page 54

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Note 3: When the Error Code is "Circuit Status Unknown," the Circuit
          Id parameter MUST contain the circuit for which status is
          unknown or unauthorized.

  Note 4: When the Error Code is "Invalid Network Appearance," the
          Network Appearance parameter MUST contains the invalid network
          appearance value.

  Note 5: The Diagnostic Info parameter SHOULD contain at least the
          first 40 bytes of the message that caused the ERR message to
          be sent.

3.7.2.  Notify (NTFY)

    The Notify message is used to provide an autonomous indication of
  ISUA events at an SG or IPSP to an ASP.

  The NTFY message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000D          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Status                              |
    +-------------------------------+-------------------------------+
    |         Tag = 0x0011          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        ASP Identifier                         |
    +-------------------------------+-------------------------------
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                       Routing Context                         /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The NTFY message can contain the following parameters:

      Parameters
      ---------------------------------------------
      Status                      Mandatory
      ASP Identifier              Conditional   *1

B. Bidulock                    Version 0.4                       Page 55

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Routing Context             Conditional   *2
      Info String                 Optional

  Note 1: ASP Identifier MUST be used where the IPSP/SGP cannot identify
          the ASP by pre-configured address/port number information
          (e.g, where an ASP is resident on a Host using dynamic
          address/port number assignment) and the Status parameter is
          set to "Alternate ASP Active" or "ASP Failure".

  Note 2: When an ASP is registered or configured for multiple AS with
          an SG, to identify the Application Server, the Routing Context
          associated with the AS whose state is being notified MUST be
          placed in the NTFY message when the Status parameter is set to
          "AS_State_Change".

3.8.  Routing Key Management (RKM) Messages

    Routing Key Management (RKM) messages are used to manage the Routing
  Keys that are used by an SG to direct traffic toward an Application
  Server.

3.8.1.  Registration Request (REG REQ)

    The Registration Request (REG REQ) message is sent by an ASP to
  indicate to a remote ISUA peer that it wishes to register one or more
  given Routing Keys with the remote peer.  Typically, an ASP would send
  this message to an SGP, and expects to receive a REG RSP message in
  return with an associated Routing Context value.

  The REG REQ message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0522          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Routing Key 1                        /
    \                                                               \
    +-------------------------------+-------------------------------+
    \                                                               \
    /                              ...                              /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0522          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Routing Key n                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 56

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The REG REQ message can contain the following parameters:

      Parameters
      -------------------------------------------
      Routing Key                 Mandatory   *1

  Note 1: One or more Routing Key parameters MAY be included in a single
          REG REQ message.  Whereas it is OPTIONAL for an implementation
          to be able to generate a REG REQ message with more than one
          Routing Key parameter, it is REQUIRED that the implementation
          be able to receive multiple Routing Key parameters in a single
          REG REQ message.

3.8.2.  Registration Response (REG RSP)

    The Registration Response (REG RSP) message is sent by an SG to an
  ASP to indicate the result of a previous REG REQ from an ASP.  When
  successful, the REG RSP message contains the Routing Context assigned
  to the one or more Routing Keys that were presented in the REG REQ
  message.

  The REG RSP message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0014          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                     Registration Result 1                     /
    \                                                               \
    +-------------------------------+-------------------------------+
    \                                                               \
    /                              ...                              /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0014          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                     Registration Result n                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The REG RSP message can contain the following parameters:

      Parameters
      -------------------------------------------
      Registration Result         Mandatory   *1

B. Bidulock                    Version 0.4                       Page 57

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Note 1: REG RSP message.  Whereas it is OPTIONAL for an implementation
          to be able to generate a REG RSP message with more than one
          Routing Key parameter, it is REQUIRED that the implementation
          be able to receive multiple Routing Key parameters in a single
          REG RSP message.

3.8.3.  Deregistration Request (DEREG REQ)

    The Deregistration Request (DEREG REQ) message is sent by an ASP to
  indicate to a remote ISUA peer that it wishes to deregister a given
  Routing Key as identified by the given Routing Context.  Typically, an
  ASP would send this message to an SGP, and expects to receive a DEREG
  RSP message in return with the associated Routing Context value.

  The DEREG REQ message is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                        Routing Context                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The DEREG REQ message contains the following parameters:

      Parameters
      -------------------------------------------
      Routing Context             Mandatory   *1

  Note 1: One or more Routing Context values MAY be included in the
          Routing Context parameter.  Whereas it is OPTIONAL for an
          implementation to be able to generate a DEREG REQ message with
          multiple Routing Context values in the Routing Context
          parameter, it is REQUIRED that an implementation be able to
          receive multiple Routing Context values in the Routing Context
          parameter of the DEREG REQ message.

3.8.4.  Deregistration Response (DEREG RSP)

    The Deregistration Response (DEREG RSP) message is used as a
  response to the DEREG REQ message from a remote ISUA peer.

  The DEREG REQ message is formatted as follows:

B. Bidulock                    Version 0.4                       Page 58

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0015          |            Length = 12        |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                   Deregistration Result 1                     /
    \                                                               \
    +-------------------------------+-------------------------------+
    \                                                               \
    /                              ...                              /
    \                                                               \
    +-------------------------------+-------------------------------+
    |         Tag = 0x0015          |            Length = 12        |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                   Deregistration Result n                     /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The DEREG REQ message contains the following parameters:

      Parameters
      -------------------------------------------
      Deregistration Result       Mandatory   *1

  Note 1: One or more Deregistration Result parameters MAY be included
          in one DEREG RSP message.  Whereas it is OPTIONAL for an
          implementation to be able to generate a DEREG RSP message with
          multiple Deregistration Result parameters, it is REQUIRED that
          an implementation be able to receive multiple Deregistration
          Result parameters in a single DEREG RSP message.

3.9.  Common Parameters

  These TLV parameters are common across the different adaptation
  layers:

      Parameter Name                Parameter ID   Section
      -----------------------------------------------------
      Reserved                         0x0000         -
      Not used in ISUA                 0x0001         -
      Not used in ISUA                 0x0002         -
      Not used in ISUA                 0x0003         -
      Info String                      0x0004      3.9.1
      Not used in ISUA                 0x0005         -
      Routing Context                  0x0006      3.9.2
      Diagnostic Info                  0x0007      3.9.3

B. Bidulock                    Version 0.4                       Page 59

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

      Not used in ISUA                 0x0008         -
      Heartbeat Data                   0x0009      3.9.4
      Not used in ISUA                 0x000A         -
      Traffic Mode Type                0x000B      3.9.5
      Error Code                       0x000C      3.9.6
      Status                           0x000D      3.9.7
      Not used in ISUA                 0x000E         -
      Not used in ISUA                 0x000F         -
      Not used in ISUA                 0x0010         -
      ASP Identifier                   0x0011      3.9.8
      Not used in ISUA                 0x0012         -
      Correlation Id                   0x0013      3.9.9
      Registration Result              0x0014      3.9.10
      Deregistration Result            0x0015      3.9.11
      Registration Status              0x0016      3.9.12
      Deregistration Status            0x0017      3.9.13
      Local Routing Key Identifier     0x0018      3.9.14

3.9.1.  Info String

    The Info String parameter is optionally included in all MGMT, ASPSM
  and ASPTM messages to provide additional debugging or diagnostic
  information.

  The Info String parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0004          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                          Info String                          /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Info String parameter contains the following fields:

  Info String field: variable (ASCII string)

    The Info String field can carry any meaningful UTF-8 [STD63]
    character string along with the message.  Length of the Info String
    field is from 0 to 255 characters.  No procedures are presently
    identified for its use but implementations may use the Info String
    for debugging purposes.

3.9.2.  Routing Context

    The Routing Context parameter is included in all ISUA CP and CS
  messages as well as in MGMT, ASPTM, ASPSM that reference one or more

B. Bidulock                    Version 0.4                       Page 60

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Application Servers.  The Routing Context parameter is used to
  uniquely identify an Application Server and Routing Key within an
  association between an SGP and ASP.

  The Routing Context parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0006          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                      Routing Context(s)                       /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Routing Context parameter can contain the following fields:

  Routing Context field: list of 32-bit (unsigned integer)

    The Routing Context field contains (a list of) 32-bit unsigned
    integers indexing the Application Server traffic that the sending
    ASP is configured or registered to receive.  There is one-to-one
    relationship between a Routing Context value, an SG Routing Key and
    an Application Server <2>.  If the Routing Context parameter is
    present, it SHOULD be the first parameter in the message as it
    defines the format and/or interpretation of the parameters
    containing a PC or SSN value.

3.9.3.  Diagnostic Information

    The Diagnostic Info parameter is used in the MGMT )Error (ERR)
  message to provide additional information concerning the message that
  generated an ERR message reply.  The Diagnostic Info parameter SHOULD
  contain at least the first 40 bytes of the message that generated the
  error.

  The Diagnostic Info parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0007          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Diagnostic Info                       /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Diagnostic Info parameter contains the following fields:

B. Bidulock                    Version 0.4                       Page 61

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Diagnostic Info field: variable length (bytes)

    The Diagnostic Info field can contain any information germane to the
    error condition, to assist in the identification of the error
    condition.  The Diagnostic Info SHOULD be the first 40 bytes of the
    offending message.

3.9.4.  Heartbeat Data

    The Heartbeat Data parameter is used in the BEAT and BEAT ACK
  messages and contains whatever information the sender of the BEAT
  message chooses to include.  Some uses for the Heartbeat Data
  parameter are described in Section 4.

  The Heartbeat Data parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0009          |            Length             |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    \                                                               \
    /                         Heartbeat Data                        /
    \                                                               \
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Heartbeat Data parameter contains the following fields:

  Heartbeat Data field: variable length (opaque)

    The sending node defines the Heartbeat Data field contents.  It may
    include a Heartbeat Sequence Number or Time-stamp, or other
    implementation specific details.  The receiver of a Heartbeat (BEAT)
    message does not process this field as it is only of significance to
    the sender.  The receiver MUST echo the content of the Heartbeat
    Data in a BEAT ACK message.  The data field can be used to store
    information in the Heartbeat (BEAT) message useful to the sending
    node (e.g. the data field can contain a time stamp, a sequence
    number, etc.).

3.9.5.  Traffic Mode Type

    The Traffic Mode Type parameter indicates the fail-over and traffic
  distribution algorithm and procedures that will be used for an
  Application Server Process serving an Application Server.  Each
  Application Server has associated with it only one Traffic Mode Type.

  The Traffic Mode Type parameter is formatted as follows:

B. Bidulock                    Version 0.4                       Page 62

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000B          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                       Traffic Mode Type                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Traffic Mode Type parameter contains the following fields:

  Traffic Mode Type field: 32-bits (unsigned integer)

    The Traffic Mode Type field identifies the traffic mode of operation
    of an ASP within an AS.  The valid values for the Traffic Mode Type
    field are as follows:

        1   Override
        2   Load-share
        3   Broadcast

    Within a Routing Context, Override, Load-share Types and Broadcast
    cannot be mixed.  The Override value indicates that the ASP is
    operating in Override mode, and that when the ASP becomes active for
    the Application Server, it will take over all traffic for the AS
    (i.e, primary/back-up operation), overriding any currently active
    ASP in the AS.  In Load-share mode, when the ASP becomes active for
    the AS, the ASP will share in the traffic distribution with any
    other active ASPs.  In Broadcast mode, when the ASP becomes active
    for the AS, the ASP will receive the same traffic as any other
    active ASPs.

3.9.6.  Error Code

    The Error Code parameter is used in the Error (ERR) message to
  indicate the reason that the ERR message was generated and, along with
  the other parameters in the ERR message, help to locate the problem
  that generated the error condition.

  The Error Code parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000C          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                          Error Code                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

B. Bidulock                    Version 0.4                       Page 63

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The Error Code parameter contains the following fields:

  Error Code field: 32-bit (unsigned integer)

    The Error Code field indicates the reason for the Error Message.
    The Error Code field value can be one of the following values:

         1   Invalid Version
         3   Unsupported Message Class
         4   Unsupported Message Type
         5   Unsupported Traffic Handling Mode
         6   Unexpected Message
         7   Protocol Error
         9   Invalid Stream Identifier
        13   Refused - Management Blocking
        14   ASP Identifier Required
        15   Invalid ASP Identifier
        17   Invalid Parameter Value
        18   Parameter Field Error
        19   Unexpected Parameter
        21   Invalid Network Appearance
        22   Missing Parameter
        23   Routing Key Change Refused
        25   Invalid Routing Context
        26   No Configured AS for ASP
        34   Circuit Status Unknown
        35   Call Reference Status Unknown

    The "Invalid Version" error is sent if a message was received with
  an invalid or unsupported version.  The ERR message contains the
  supported version in the Common header.  The ERR message could
  optionally provide the supported version in the Diagnostic parameter.

    The "Unsupported Message Class" error is sent if a message with an
  unexpected or unsupported Message Class is received.

    The "Unsupported Message Type" error is sent if a message with an
  unexpected or unsupported Message Type is received.

    The "Unsupported Traffic Handling Mode" error is sent by a SGP if an
  ASP sends an ASP Active (ASPAC) message with an unsupported Traffic
  Mode Type or a Traffic Mode Type that is inconsistent with the
  presently configured mode for the Application Server.  An example
  would be a case in which the SGP did not support load-sharing.

    The "Unexpected Message" error MAY be sent if a defined and
  recognized message is received that is not expected in the current
  state (in some cases the ASP may optionally silently discard the
  message and not send an ERR message).  For example, silent discard is
  used by an ASP if it received a ISUA CP message from an SGP while it
  was in the ASP-INACTIVE state.  If the Unexpected message contained

B. Bidulock                    Version 0.4                       Page 64

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Routing Context(s), the Routing Context(s) SHOULD be included in the
  ERR message.

    The "Protocol Error" error is sent for any protocol anomaly (i.e.,
  reception of a parameter that is syntactically correct but unexpected
  in the current situation.

    The "Invalid Stream Identifier" error is sent if a message is
  received on an unexpected SCTP stream (e.g, a Management message was
  received on a stream other than "0", or a ISUA CP message was received
  on stream "0").

    The "Refused - Management Blocking" error is sent when an ASP Up
  (ASPUP) or ASP Active (ASPAC) message is received and the request is
  refused for management reasons (e.g, management lockout").  If this
  error is in response to an ASP Active (ASPAC) message, the Routing
  Context(s) in the ASP Active (ASPAC) message SHOULD be included in the
  ERR message.

    The "ASP Identifier Required" is sent by a SGP in response to an ASP
  Up (ASPUP) message which does not contain an ASP Identifier parameter
  when the SGP requires one.  The ASP SHOULD resend the ASP Up (ASPUP)
  message with an ASP Identifier.

    The "Invalid ASP Identifier" is send by a SGP in response to an ASP
  Up (ASPUP) message with an invalid (i.e., non-unique) ASP Identifier.

    The "Invalid Parameter Value" error is sent if a message is received
  with an invalid parameter value (e.g, a DUPU message was received with
  a Mask value other than "0").

    The "Parameter Field Error" would be sent if a message is received
  with a parameter having a wrong length field.

    The "Unexpected Parameter" error would be sent if a message contains
  an invalid parameter.

    The "Invalid Network Appearance" error is sent by a SGP if an ASP
  sends a message with an invalid (not configured) Network Appearance
  value.  For this error, the invalid (not configured) Network
  Appearance MUST be included in the Network Appearance parameter in the
  ERR message.

    The "Missing Parameter" error is sent if a mandatory parameter was
  not included in a message.

    The "Routing Key Change Refused" error is sent when an SG refuses a
  change in the Routing Key parameters.

    The "Invalid Routing Context" error is sent if a message is received
  from a peer with an invalid (not configured) Routing Context value, or
  if a message is received from a peer without a Routing Context
  parameter and it is not known by configuration data which Application

B. Bidulock                    Version 0.4                       Page 65

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Servers are referenced.  For this error, the invalid Routing
  Context(s) MUST be included in the ERR message.

    The "No Configured AS for ASP" error is sent if a message is
  received from a peer without a Routing Context parameter and it is not
  known by configuration data which Application Servers are referenced.

    The "Circuit Status Unknown" Error MAY be sent it a CQRY is receive
  at an SG inquiring of the status of a circuit or circuits and the SG
  does not wish to provide the status (e.g. the sender is not authorized
  to know the status).  For this error, the invalid or unauthorized
  Circuit Id MUST be included along with any Network Appearance or
  Routing Context associated with the Circuit Id from the CQRY message.

    The "Call Reference Status Unknown" Error MAY be sent it a CQRY is
  receive at an SG inquiring of the status of a circuit or circuits and
  the SG does not wish to provide the status (e.g. the sender is not
  authorized to know the status).  For this error, the invalid or
  unauthorized Call ReferenceFR MUST be included along with any Network
  Appearance or Routing Context associated with the Call Reference from
  the CQRY message.

3.9.7.  Status

    The Status parameter identifies the type of the status that is being
  notified in a Notify (NTFY) message and the Status ID.

  The Status parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x000D          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |         Status Type           |            Status ID          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Status parameter contains the following fields:

  Status Type field: 16-bits (unsigned integer)

    The valid values for Status Type field are as follows:

        1   Application Server state change (AS_State_Change)
        2   Other

  Status ID field: 16-bits (unsigned integer)

    The Status ID parameter contains more detailed information for the
    notification, based on the value of the Status Type.

B. Bidulock                    Version 0.4                       Page 66

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    (1)   If the Status Type is "AS_State_Change", then the Status ID
          values are as follows:

              1   reserved
              2   Application Server Inactive (AS-Inactive)
              3   Application Server Active (AS-Active)
              4   Application Server Pending (AS-Pending)

     These notifications are sent from an SGP to an ASP upon a change in
     status of a particular Application Server.  The value reflects the
     new state of the Application Server.

    (2)   If the Status Type is "Other", then the following Status
          Information values are defined:

              1   Insufficient ASP resources active in AS
              2   Alternate ASP Active
              3   ASP failure

     These notifications are not based on the SGP reporting the state
     change of an ASP or AS.  In the Insufficient ASP Resources case,
     the SGP is indicating to an "Inactive" ASP(s) in the AS that
     another ASP is required to handle the load of the AS (Load-sharing
     mode or Broadcast mode).  For the Alternate ASP Active case, an ASP
     is informed when an alternate ASP transitions to the ASP-Active
     state in Override mode.

3.9.8.  ASP Identifier

  The ASP Identifier parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0011          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                        ASP Identifier                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The ASP Identifier parameter contains the following fields:

  ASP Identifier field: 32-bits (unsigned integer)

    The ASP Identifier field contains a unique value that is locally
    significant among the ASPs that support an AS.  The SGP should save
    the ASP Identifier to be used, if necessary, with the Notify (NTFY)
    message (see Section 3.7.2).

B. Bidulock                    Version 0.4                       Page 67

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

3.9.9.  Correlation Id

    The Correlation Id parameter is used to tag messages sent to an ASP
  in a Broadcast group as well as during fail-over.

  The Correlation Id parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0013          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Correlation Id                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Correlation Id parameter can contain the following fields:

  Correlation Id field: 32-bits (unsigned integer)

    The Correlation Id field contains a Correlation Id.  The Correlation
    Id is a 32-bit identifier that is attached to the ISUA Message
    Header to indicate to a newly entering ASP in a Broadcast AS where
    in the traffic flow of ISUA messages the ASP is joining.  It is
    attached to the ISUA Message Header of the first CP message sent to
    an ASP by an SG after sending an ASP Active Ack or otherwise
    starting traffic to an ASP.  The Correlation Id is only significant
    within a Routing Context <3>.

3.9.10.  Registration Result

    The Registration Result parameter is used to indicate the result of
  a successful or unsuccessful registration operation for a specific
  Routing Key.

  The Registration Result parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0014          |             Length            |
    +-------------------------------+-------------------------------+
    |                  Local Routing Key Identifier                 |
    +---------------------------------------------------------------+
    |                       Registration Status                     |
    +---------------------------------------------------------------+
    |                         Routing Context                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Registration Result parameter can contain the following fields:

B. Bidulock                    Version 0.4                       Page 68

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Local Routing Key Identifier: TLV

    The Local Routing Key Identifier field is mandatory in the
    Registration Result parameter.  The Local Routing Key Identifier
    field contains the same TLV formatted parameter value as found in
    the corresponding Routing Key parameter in the Registration Request
    (REG REQ) message.

  Registration Status: TLV

    The Registration Status field is mandatory in the Registration
    Result parameter.  The Registration Status field indicates the
    success or reason for failure of the corresponding registration
    request.  For details on the format of the Registration Status
    parameter, see Section 3.9.12.

  Routing Context: TLV

    The Routing Context field is mandatory in the Registration Result
    parameter.  The Routing Context field contains the TLV formatted
    Routing Context parameter for the associated Routing Key if the
    registration was successful.  If the registration was not
    successful, it is set to zero (0).

3.9.11.  Deregistration Result

    The Deregistration Result parameter is used to indicate the result
  of a successful or unsuccessful deregistration operation for a
  specific Routing Key.

  The Deregistration Result parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0015          |             Length            |
    +-------------------------------+-------------------------------+
    |                         Routing Context                       |
    +---------------------------------------------------------------+
    |                      Deregistration Status                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Deregistration Result parameter can contain the following fields:

  Routing Context: TLV

    The Routing Context field is mandatory in the Deregistration Result
    parameter.  The Routing Context field contains the same TLV
    formatted Routing Context parameter as found in the corresponding
    Deregistration Request (DEREG REQ) message.

B. Bidulock                    Version 0.4                       Page 69

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  Deregistration Status: TLV

    The Deregistration Status field is mandatory in the Deregistration
    Result parameter.  The Deregistration Status field indicates the
    success or reason for failure of the corresponding deregistration
    request.  For details on the format of the Deregistration Status
    parameter, see Section 3.9.13.

3.9.12.  Registration Status

    The Registration Status parameter is used to indicate the success or
  failure of a registration operation.

  The Registration Status parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0016          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                       Registration Status                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Registration Status parameter can contain the following fields:

  Registration Status: 32-bits (unsigned integer)

    The Registration Status field indicates the success or the reason
    for failure of a registration request.

    Its values can be:

         0   Successfully Registered
         1   Error - Unknown
         2   Error - Invalid Circuit Identifier
         3   Error - Invalid Network Appearance
         4   Error - Invalid Routing Key
         5   Error - Permission Denied
         6   Error - Cannot Support Unique Routing
         7   Error - Routing Key not Currently Provisioned
         8   Error - Insufficient Resources
         9   Error - Unsupported RK parameter Field
        10   Error - Unsupported/Invalid Traffic Mode Type
        11   Error - Routing Context Registration Refused

3.9.13.  Deregistration Status

    The Deregistration Status parameter is used to indicate the success
  or failure of a deregistration operation.

B. Bidulock                    Version 0.4                       Page 70

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

  The Deregistration Status parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0017          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                      Deregistration Status                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Deregistration Status parameter can contain the following fields:

  Deregistration Status: 32-bits (unsigned integer)

    The Deregistration Status field indicates the success or the reason
    for failure of a deregistration request.

    Its values can be:

        0   Successfully Deregistered
        1   Error - Unknown
        2   Error - Invalid Routing Context
        3   Error - Permission Denied
        4   Error - Not Registered
        5   Error - ASP Currently Active for Routing Context

3.9.14.  Local Routing Key Identifier

    The Local Routing Key Identifier parameter is used for correlating
  the Routing Key parameter in a specific Registration Request (REG REQ)
  message with the Registration Result parameter in the corresponding
  Registration Response (REG RSP) message.

  The Local Routing Key Identifier parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0018          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                  Local Routing Key Identifier                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Local Routing Key Identifier parameter can contain the following
  fields:

  Local Routing Key Identifier: 32-bits (unsigned integer)

B. Bidulock                    Version 0.4                       Page 71

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

    The Local Routing Key Identifier value is assigned by the ASP and is
    used to correlate the response in a Registration Response (REG RSP)
    message with the original registration request from the Registration
    Request (REG REQ) message.  The Local Routing Key Identifier value
    must remain unique until the REG RSP message is received.

3.10.  ISUA-Specific parameters

  These TLV parameters are specific to the ISUA protocol:

               Parameters used in CP Messages
        ----------------------------------------------
        Parameter Name        Parameter ID   Section
        ----------------------------------------------
        Call Reference           0x0501     3.10.1.1
        Call Type                0x0502     3.10.1.2
        Call Flags               0x0503     3.10.1.3
        Called Party Number      0x0504     3.10.1.4
        Subsequent Number        0x0505     3.10.1.5
        Reattempt Reason         0x0506     3.10.1.6
        Check Result             0x0507     3.10.1.7
        Proceeding Flags         0x0508     3.10.1.8
        Progress Event           0x0509     3.10.1.9
        Progress Flags           0x050A     3.10.1.10
        Suspend/Resume Flags     0x050B     3.10.1.11
        Failure Reason           0x050C     3.10.1.12
        Cause                    0x050D     3.10.1.13
        Optional Parameters      0x050E     3.10.1.14
        ----------------------------------------------

            Parameters used in CS Messages
        ---------------------------------------
        Parameter Name  Parameter ID  Section
        ---------------------------------------
        Circuit Status     0x0510     3.10.2.1
        ---------------------------------------

                     Other Parameters
        -------------------------------------------
        Parameter Name      Parameter ID  Section
        -------------------------------------------
        Circuit Id             0x0520     3.10.3.1
        Network Appearance     0x0521     3.10.3.2
        Routing Key            0x0522     3.10.3.3
        Circuit Range          0x0523     3.10.3.4
        Local Point Code       0x0524     3.10.3.5
        Remote Point Code      0x0525     3.10.3.5
        -------------------------------------------

B. Bidulock                    Version 0.4                       Page 72

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

3.10.1.  Parameters used in CP Messages

3.10.1.1.  Call Reference

    The Call Reference parameter is used in the ISUA Message Header to
  identify the call within the Application Server indicated by the
  Routing Context (also in the ISUA Message Header).

  The Call Reference parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0501          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                         Call Reference                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Call Reference parameter contains the following fields:

  Call Reference field: 32-bits (unsigned integer)

    The Call Reference field contains an identifier that is used both at
    the SG and the ASP to identify a call within an Application Server.
    The Call Reference value must be unique within the scope of a given
    Application Server and Routing Context.

    For a given AS and Routing Context, either the SG or the ASP is
    responsible for assigning Call Reference, but not both.

3.10.1.2.  Call Type

  The Call Type parameter is formatted as follows:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Tag = 0x0502          |            Length = 8         |
    +- - - - - - - - - - - - - - - -+- - - - - - - - - - - - - - - -+
    |                           Call Type                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The Call Type parameter contains the following fields:

  Call Type field: 32-bits (unsigned integer)

    The Call Type field can take on the following values:

B. Bidulock                    Version 0.4                       Page 73

Internet Draft       SS7 ISUP-User Adaptation Layer     February 3, 2007

        0   Speech
        1   64 kbit/s unrestricted digital information
        2   3.1 kHZ audio
        3   64 kbit/s preferred
        4   2 x 64 kb