One document matched: draft-thomas-sigtran-igsp-00.txt
INTERNET DRAFT Keith Melkild
Category: Informational Venkatesh Raju
Title: draft-thomas-sigtran-igsp-00.txt Michael Thomas
Date: December 1998 Nortel Networks
An Inter-Gateway Signalling Protocol For VoIP Networks
<draft-thomas-sigtran-igsp-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes a protocol devised by Nortel Networks for call
signalling between gateway call processing entities in a public network
offering Voice over IP (VoIP) services and interworking with the
Switched Circuit Network (SCN). The protocol takes account of the
requirement to carry ISUP and other Switched Circuit Network protocols
across the network in a transparent fashion while also carrying informa-
tion uniquely required for call processing within the VoIP network. The
current draft applies only to calls using the VoIP network to pass from
one SCN to another, but the protocol may be extended to more general
application.
Table of Contents
Melkild, Raju, Thomas expires May 1999 [Page 1]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
1.0 Protocol Discussion
1.1 Introduction
1.2 Requirements
2.0 The Proposed Inter-Gateway Signalling Protocol
2.1 General Description
2.2 Mandatory Header
2.2.1 First Header Line
2.2.2 Second Header Line
2.2.3 Third Header Line
2.3 Common Message Parameters
2.3.1 Encoding Parameter
2.4 Message Types
2.4.1 SET (Setup Message)
2.4.1.1 Resource Parameter
2.4.2 ACK (Setup ACK) Message
2.4.3 REJ (Setup REJect) Message
2.4.4 PRG (Call PRoGress Message)
2.4.5 CON (Connect Message)
2.4.6 REL (RELease Message)
2.4.7 CAR (CARrier Message)
2.5 Encoding of the Mixed Protocol Part
2.5.1 SDP Encoding
2.5.2 ISUP Encoding
2.6 State Machines
2.7 Required SDP Embedding
2.8 Examples
2.8.1 Normal Call Setup
2.8.2 Normal Call Setup with Alternative Routing
2.8.3 Failed Call Setup Due To No Resources
2.8.4 Suspend and Resume
2.8.5 Continuity Testing
3.0 Transport Protocol Proposal
4.0 Intellectual Property
5.0 References
6.0 Authors' Addresses
Melkild, Raju, Thomas expires May 1999 [Page 2]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
1.0 Protocol Discussion
1.1 Introduction
Figure 1 shows a typical signalling configuration in a VoIP network.
The key distinctions are between gateway entities at the edge of the
network, centralized call processing entities such as H.323 Gatekeepers
performing Gatekeeper-routed signalling in the interior of the network,
and signalling endpoints such as H.323 clients in the interior of the
VoIP network.
As agreed in recent work on signalling architecture in the IETF [1], a
VoIP gateway may be decomposed into three functional components: the
Signalling Gateway, which performs a signalling mediation function; the
Media Gateway Controller, which is the call processing entity proper;
and the Media Gateway, which mediates the flow of mmedia streams between
the two networks. The protocol described in this document is intended
to operate between Media Gateway Controllers.
When a call originates or terminates in the switched network, the Media
Gateway Controller must deal with native signalling of that network. If
the call is transiting the VoIP network, so that it both originates and
terminates in the switched network, it will typically be necessary to
provide transparent passage of at least some of the switched network
signalling from one edge of the VoIP network to the other. This
requirement is additional to the use of the signalling by the VoIP net-
work itself.
On the other hand, VoIP network signalling requires more information
than switched network signalling protocols provide. As a specific exam-
ple, VoIP network signalling must include descriptions of media flows,
typically in terms of RTP-encapsulated packets. It must also include
information related to signalling management and routing, in the same
way that MTP3 includes such information in an SS7 network.
These requirements are explored in more detail in the next section. The
remainder of the document describes a protocol designed to meet them.
Melkild, Raju, Thomas expires May 1999 [Page 3]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------+ +---------+
SCN <----------> | SG | | SG | <----------> SCN
SS7/ISUP +---------+ +---------+ SS7/ISUP
Q.931 | | Q.931
QSIG +---------+ +---------+ QSIG
| MGC | <------> | MGC |
+---------+ MGC-MGC +---------+
\ / \
\ / \ H.323
\ TBD TBD / \
\ / \
+--------+ \ / +--------+
| VoIP | +---------+ | VoIP |
| Client |<--------->|H.323 GK | | Client |
+--------+ H.323 +---------+ +--------+
Figure 1: VoIP Network Signalling
1.2 Requirements
An inter-MGC signalling protocol must address the following:
- transport of sufficient information to derive a complete bill for
the call
- extensibility support. This includes aspects of version control as
well as vendor specific additions and optional parameters.
- routing support. Media Gateway Controllers may not have sufficient
resources to process calls and may need to reroute.
- support for regional ISUP standards such as Bellcore GR-394-CORE
consistent with carrier interconnection to end offices and tandems.
- transparent connection of ISUP. The switches connected to the VoIP
network should not be required to change as a result of network
interworking. Sufficient ISUP information must be conveyed across
the VoIP network to establish and release calls as well as support
in-call progress indications.
- support for carrying sufficient information to establish RTP media
streams between media gateways involved in a call
- transaction and call management. Sufficient information must be
provided to distinguish and manage individual calls.
Melkild, Raju, Thomas expires May 1999 [Page 4]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
The following are additional requirements that, although desirable, are
not the first priority for definition of an inter-gateway signalling
protocol. These requirements are important and need to be discussed as
the protocol design matures.
- support for re-establishment, replacement, or modification of an
RTP stream as requested by another Media Gateway Controller
- option to create services between Media Gateway Controllers outside
of PSTN protocols. Such services may include call redirection ser-
vices and referral services.
- support for additional PSTN access protocols (such as PRI), PSTN
agents (such as MF or lines), network devices (such as IVRs), and
so forth
- support for non-PSTN access protocols (e.g., SIP, H.323, or other
protocols).
It is expected that VoIP networks in their early stages will be inter-
connected to the PSTN in a manner consistent with how an interexchange
carrier connects to LECs: at both the access tandem and end office
level, using ISUP signalling. Carriage of direct dialed long distance
voice from an end office or access tandem where access is via ISUP,
through the VoIP network, and then to another end office or access tan-
dem where access is via ISUP, is considered to be the starting point for
design of an inter-gateway signalling protocol. Passing ISUP between
Media Gateway Controllers is a practical solution to the problem of
guaranteeing ISUP transparency across the network. Features and ser-
vices (such as call forwarding from a terminating Media Gateway Con-
troller) could be invoked via ISUP procedures within the VoIP network.
There are areas that need to be addressed within the protocol that are
beyond the scope of ISUP. Exchange of RTP endpoint information is a
fundamental requirement. Route advance within the Media Gateway Con-
troller network is required when a terminating Media Gateway Controller
does not have sufficient trunking resources to complete a call. To
indicate the RTP information and support rerouting requires additional
information outside the scope of traditional ISUP. The present proposal
is based on the idea of a wrapper protocol around ISUP to simplify the
transport of this additional information, support future extensibility,
and support the carriage of protocols other than ISUP.
The idea that services may be launched outside the scope of ISUP, for
example through inclusion of additional parameters or commands in the
wrapper protocol, is interesting and requires additional investigation.
It is beyond the scope of this initial proposal, but may be in line with
a general standards approach. The Session Initiation Protocol is
Melkild, Raju, Thomas expires May 1999 [Page 5]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
definitely a candidate as the wrapper protocol.
2.0 The Proposed Inter-Gateway Signalling Protocol
2.1 General Description
Media Gateway Controllers communicate via the inter-Media Gateway Con-
troller protocol. This protocol is basically a thin text wrapper around
a protocol specific payload. The initial protocol addresses ISUP. There
are two general parts of the protocol, a text header describing the pro-
tocol used to initiate transactions and describe transaction progress,
and a mixed part used to carry the various protocols used between Media
Gateway Controllers.
The general format of an inter Media Gateway Controller message is shown
below. It consists of at least three lines of text delimited by ASCII
carriage return and line feed. The first three lines are mandatory;
they are used to identify the source and destination Media Gateway Con-
trollers, the type of message and version, and transaction information.
The first line specifies the name of the destination Media Gateway Con-
troller. The second line is the IGSP request line and indicates the
message type, the global call id, and the IGSP protocol version. The
third line indicates the originating Media Gateway Controller. Other
optional "tag: value" lines may be present after the first three lines.
A tag line is defined by a brief ASCII string (from 1 to 32 characters)
in the ranges of alphanumeric characters with no whitespace followed by
a colon ':' (ASCII d58), a whitespace, and then by the value parameters;
it is terminated by ASCII <CR><LF>. All whitespace is assumed to be a
SPACE (ASCII d32) and only one space must be used. An ASCII alphanumeric
character is defined as one character in the following "" enclosed
string encoded as ASCII:
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
Note: Each entry in the table corresponds to a line delimited by
<CR><LF>.
Melkild, Raju, Thomas expires May 1999 [Page 6]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------------------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------------------|
| <MessageType> <DirectionIndicator>:<Call-ID> IGSP/1.0 |
|---------------------------------------------------------|
| From: <Source MGCName> |
|---------------------------------------------------------|
| [Message Specific Parameters] |
| |
|---------------------------------------------------------|
| (empty line) |
|---------------------------------------------------------|
| [start of mixed protocol part] |
| |
+---------------------------------------------------------+
The message specific parameters may consist of zero or more "tag: value"
lines which may be used as parameters specific to the message or common
Across all message types.
The mixed protocol part typically contains a protocol payload (such as
ISUP or Q.931) and an SDP payload in a distinct format. The format and
encoding of the mixed protocol part is discussed later. When a mixed
protocol part is present, it is preceded by an additional <CR><LF> to
indicate the start of the mixed protocol part. (In other words, a
sequence of ASCII <CR><LF><CR><LF> indicates the start of the mixed pro-
tocol part.)
Note that the brackets [] are not part of the protocol and are used to
denote optional contents.
<MGCName> is a ASCII text identifier from 1 to 64 characters used to
uniquely identify Media Gateway Controllers in the network and consists
of only alphanumeric characters and possibly zero or more instances of
the following: the "." character (ASCII d46), the "-" character (ASCII
d45), the "_" character (underscore, ASCII d95), or . "@" character
(d64). When a ".", "-", "_", or "@" are used, they must be preceded and
followed by at least one alphanumeric character.
2.2 Mandatory Header
2.2.1 First Header Line
The first line consists of the <Destination MGCName> and is of the for-
mat <MGCName>. <Destination MGCName> identifies the destination Media
Gateway Controller for the message.
Melkild, Raju, Thomas expires May 1999 [Page 7]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
2.2.2 Second Header Line
The second line indicates a message type, a transaction identifier, and
a message type identifier which identifies the inter-gateway signalling
protocol as below:
<MessageType> <DirectionIndicator>:<CallID> <ProtocolName>/<Version>
<MessageType> is described below.
<DirectionIndicator> indicates the source of the signalling message
relative to the direction of the call. Its value is either a single O
(ASCII d79) to indicate that the signalling message comes from the ori-
ginating Media Gateway Controller or T (ASCII d84) when it comes from
the terminating Media Gateway Controller.
<CallID> is a globally unique identifier used between Media Gateway Con-
trollers. <CallID> is an ASCII string from 1 to 64 characters consist-
ing of alphanumerics and may contain the "." (period, ASCII d46) charac-
ter, the "-" character (dash, ASCII d45), the "_" character (underscore,
ASCII d95), or . the "@" character (at-sign, ASCII d64). When a ".",
"-", "_", or "@" are used in the CallID, they must be preceded and fol-
lowed by at least one alphanumeric character.
The <ProtocolName> is encoded as an ASCII string with the value enclosed
in quotes: "IGSP".
<Version> is an identifier used to identify the protocol version. The
only valid identifier at this time is the ASCII quote enclosed string
"1.0".
The following are valid values for <MessageType> and are encoded as
ASCII strings as given in the table below under the MessageType column.
A brief description is provided of the purpose of each message and
whether its support is Required or Optional in the specification. These
message types and any message specific parameters are discussed later in
this document.
Melkild, Raju, Thomas expires May 1999 [Page 8]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+----------------------------------------------------------------+
| Message | Purpose | Required |
| Type | | /Optional |
|=========|==========================================|===========|
| SET | To initiate a call. Includes initial | Required |
| | call information (IAM contents) and an | |
| | SDP description of the RTP endpoint on | |
| | the originating gateway. | |
|---------|------------------------------------------|-----------|
| ACK | Acknowledges call initiation request. | Required |
| | Includes an SDP description of the RTP | |
| | endpoint on the terminating gateway. | |
|---------|------------------------------------------|-----------|
| REJ | Rejects call initiation request. For the| Required |
| | current draft, this message is issued by | |
| | the terminating Media Gateway Controller | |
| | when there are insufficient resources to | |
| | complete the call. | |
|---------|------------------------------------------|-----------|
| PRG | Conveys information about call progress | Required |
| | both before and after answer. | |
|---------|------------------------------------------|-----------|
| CON | Indicates successful answer. | Required |
|---------|------------------------------------------|-----------|
| REL | Indicates call release. | Required |
|---------|------------------------------------------|-----------|
| CAR | Used to carry a protocol specific | Required |
| | message not covered by SET, PRG, CON, | |
| | or REL. | |
+----------------------------------------------------------------+
2.2.3 Third Header Line
The third line indicates the sending Media Gateway Controller. The line
is encoded by a "From" tag followed by the <Source MGCName>. <Source
MGCName> is of the format <MGCName>.
2.3 Common Message Parameters
2.3.1 Encoding Parameter
The Encoding parameter is common to almost all messages. It indicates
the presence of a protocol specific payload in the mixed protocol part
of the message and indicates the type of protocol, the issuing organiza-
tion, and a version.
The format of the encoding parameter is as follows:
Melkild, Raju, Thomas expires May 1999 [Page 9]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------------------------------------------------------------+
| Tag | Value |
|===============|===============================================|
| Encoding | <Protocol> <Organization> <Version> <Length> |
| | [<MessageType>] |
+---------------------------------------------------------------+
<Protocol> indicates the protocol type of the message and is an ASCII
alphanumeric string.
<Organization> indicates the issuing organization and is an ASCII
alphanumeric string.
<Version> identifies the version of the protocol and is an ASCII
alphanumeric string.
<Length> is an ASCII integer identifying the length in bytes of the pro-
tocol message.
<MessageType> is an optional indicator used to indicate the message type
of the protocol message.
There are two valid protocol types in this draft, encoded as ASCII
strings as follows. Others may be added as necessary.
+------------------------------------------------+
| Protocol | Organization | Version |
|=============|===================|==============|
| SDP | IETF | 0 |
|-------------|-------------------|--------------|
| ISUP | Bellcore | 1997 |
+------------------------------------------------+
The order in which the Encoding parameters occur is significant. Proto-
col payloads are encoded in the mixed protocol part in the order in
which the Encoding parameters appear within the message. For example,
the SDP payload would occur before the ISUP payload in the following
sample message.
Melkild, Raju, Thomas expires May 1999 [Page 10]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------------------------------------------+
| eagle2.SanFrancisco |
|---------------------------------------------|
| PRG bear1.Colorado.5000 IGCSP/1.0 |
|---------------------------------------------|
| From: bear1.Colorado |
|---------------------------------------------|
| Encoding: SDP IETF 0 100 |
|---------------------------------------------|
| Encoding: ISUP Bellcore 1997 42 ACM |
|---------------------------------------------|
| |
|---------------------------------------------|
| SDP Part ... |
| |
|---------------------------------------------|
| ISUP Part ... |
| |
+---------------------------------------------+
The Encoding parameters occur as the last parameters in the text header.
The specific encoding of each protocol payload may be different. Encod-
ing rules for ISUP Bellcore 1997 and SDP are described later in the
document. The encoding rules are specific to this draft.
2.4 Message Types
Each section below describes the message types that are used for inter-
gateway signalling along with their associated message specific parame-
ters.
2.4.1 SET (Setup Message)
The Setup message is used to initiate a call between two Media Gateway
Controllers. It contains a distinct CallID, the route or trunk group
the destination Media Gateway Controller is to use, the IAM payload, and
an SDP payload describing the endpoint on the originating side of the
network. Below is the SET message format.
Melkild, Raju, Thomas expires May 1999 [Page 11]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------|
| SET O:<Call-ID> IGSP/1.0 |
|---------------------------------------------|
| From: <Source MGCName> |
|---------------------------------------------|
| Resource: <ResourceGroupName> |
|---------------------------------------------|
| Encoding: ISUP Bellcore 1997 <Length> IAM |
|---------------------------------------------|
| Encoding: SDP IETF 0 <Length> |
|---------------------------------------------|
| |
|---------------------------------------------|
| Initial Address Message Payload |
| |
|---------------------------------------------|
| SDP Payload |
| |
+---------------------------------------------+
The ISUP and SDP payloads are mandatory. An ISUP IAM is the only
allowed ISUP payload in the SET message. CallID is used throughout the
life of the call for subsequent messages. The life of the call is
defined from the receipt of the Setup message to the release of the call
(via the Release message) or rejection of the setup request (via the
Reject message).
The terminating Media Gateway Controller receiving a SET message must
respond with an ACK message to indicate successful processing or a REJ
message to indicate an unsuccessful setup attempt. Should a REJ message
be received by the originating Media Gateway Controller or no response
is received, it may route advance to select a new route as appropriate.
2.4.1.1 Resource Parameter
The Resource parameter is mandatory. The resource parameter indicates
the resource group name (a trunk group) the terminating Media Gateway
Controller is to use in order to route the call. <ResourceGroupName> is
an ASCII alphanumeric string possibly including a "." (ASCII d46), the
"-" character (dash, ASCII d45), the "_" character (underscore, ASCII
d95), or the "@" character (at-sign, ASCII d64) and is from 1 to 64
characters in length. ). When a ".", "-", "_", or "@" are used in the
ResourceGroupName, they must be preceded and followed by at least one
alphanumeric character.
Melkild, Raju, Thomas expires May 1999 [Page 12]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+----------------------------------------------------------------+
| Tag | Value |
===========|=====================================================|
| Resource | ResourceGroupName, a string used to identify the |
| | outgoing trunk group on the terminating Media |
| | Gateway Controller. |
+----------------------------------------------------------------+
2.4.2 ACK (Setup ACK) Message
The ACK message is used to indicate successful processing of the Setup
message. The ACK message must contain an SDP payload which indicates
the RTP endpoint on the terminating side of the network. Below is the
ACK message format.
+---------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------|
| ACK T:<Call-ID> IGSP/1.0 |
|---------------------------------------------|
| From: <Source MGCName> |
|---------------------------------------------|
| Encoding: SDP IETF 0 100 |
|---------------------------------------------|
| |
|---------------------------------------------|
| SDP Payload |
| |
+---------------------------------------------+
Multiple ACKs may be received until a PRG or CON message are received to
support reselection on glare conditions and continuity testing on the
terminating Media Gateway Controller. The originating Media Gateway
Controller updates the originating gateway as needed to reflect new con-
nection information.
2.4.3 REJ (Setup REJect) Message
The Setup Reject message is used to indicate unsuccessful processing of
the Setup attempt. A Setup may be unsuccessful at the terminating Media
Gateway Controller due to lack of gateway resources, Media Gateway Con-
troller resources, or other conditions.
It is possible that a REJ may be sent after an ACK in the event of glare
or continuity failure and no resources are available on the terminating
Media Gateway Controller. The originating Media Gateway Controller
Melkild, Raju, Thomas expires May 1999 [Page 13]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
would then route advance upon receipt of the REJ message.
No protocol payloads are carried within this message.
+---------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------|
| REJ T:<Call-ID> IGSP/1.0 |
|---------------------------------------------|
| From: <Source MGCName> |
+---------------------------------------------+
2.4.4 PRG (Call PRoGress Message)
The Call Progress message is used to indicate call progress conditions
both before and after the call is connected.
For ISUP, a PRoGgress message may carry an ISUP ACM or CPG message as
appropriate. In this draft, no SDP payloads would be carried.
+---------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------|
| PRG T:<Call-ID> IGSP/1.0 |
|---------------------------------------------|
| From: <Source MGCName> |
|---------------------------------------------|
| Encoding: Bellcore ISUP 1997 24 ACM |
|---------------------------------------------|
| |
|---------------------------------------------|
| Address Complete Message Payload |
| |
+---------------------------------------------+
2.4.5 CON (Connect Message)
The Connect message is used to indicate call answer or connect. An SDP
payload may be carried as appropriate.
For ISUP, an ANM message payload must be included.
Melkild, Raju, Thomas expires May 1999 [Page 14]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+---------------------------------------------+
| <Destination MGCName> |
|---------------------------------------------|
| CON T:<Call-ID> IGSP/1.0 |
|---------------------------------------------|
| From: <Source MGCName> |
|---------------------------------------------|
| Encoding: Bellcore ISUP 1997 30 ANM |
|---------------------------------------------|
| |
|---------------------------------------------|
| Answer Message Payload |
| |
+---------------------------------------------+
2.4.6 REL (RELease Message)
The Release message is used to indicate that the call should be
released. No SDP payloads are carried in this message.
If the cause of the release corresponds to an ISUP Release, then an ISUP
Release payload must be included such that cause information can be pro-
pagated as needed.
+----------------------------------------------+
| <Destination MGCName> |
|----------------------------------------------|
| REL <DirectionIndicator>:<Call-ID> IGSP/1.0 |
|----------------------------------------------|
| From: <Source MGCName> |
|----------------------------------------------|
| Encoding: Bellcore ISUP 1997 18 REL |
|----------------------------------------------|
| |
|----------------------------------------------|
| Release Message Payload |
| |
+----------------------------------------------+
2.4.7 CAR (CARrier Message)
The Carrier message is used to carry protocol specific messages that are
not covered under SET, PRG, CON, or REL. It may also be used to carry
an SDP payload if needed, but none is expected in this draft.
For ISUP, the messages include: Suspend, Resume, and Continuity. For
these ISUP messages, it is required that the <MessageType> of the
Melkild, Raju, Thomas expires May 1999 [Page 15]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
Encoding parameter be set as shown in the table of section 2.5.2.
Below is the format for the Carrier message.
+-----------------------------------------------+
| <Destination MGCName> |
|-----------------------------------------------|
| CAR <DirectionIndicator>:<Call-ID> IGSP/1.0 |
|-----------------------------------------------|
| From: <Source MGCName> |
|-----------------------------------------------|
| Encoding: ISUP Bellcore 1997 25 <MessageType> |
|-----------------------------------------------|
| Encoding: SDP IETF 0 75 |
|-----------------------------------------------|
| |
|-----------------------------------------------|
| ISUP Message Payload |
| |
|-----------------------------------------------|
| SDP Message Payload
| |
+-----------------------------------------------+
2.5 Encoding of the Mixed Protocol Part
In this draft, there are two portions of the mixed protocol part, an SDP
part and an ISUP part. As mentioned earlier, the order in which the
Encoding parameters occur is significant and indicates the order in
which payloads are encoded.
2.5.1 SDP Encoding
SDP payloads are encoded according to RFC 2327. For interoperability,
the RTP endpoints must be sufficiently identified.
The following is an example of an SDP payload for G.711 mu-law:
+--------------------------------+
| v=0 |
| c=IN IP4 47.100.40.54 |
| m=audio 3456 RTP/AVP 8 |
+--------------------------------+
2.5.2 ISUP Encoding
ISUP between Media Gateway Controllers is encoded in a tag-length-value
format and conveys the same content as GR-394-CORE Issue 2, December
Melkild, Raju, Thomas expires May 1999 [Page 16]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
1997 ISUP. It is basically a sequence of ISUP parameter name code-
length-value encoding which encapsulates ISUP parameter codes (as in
Appendix B of GR-394-Core Issue 2, December 1997, also GR-246-CORE,
T1.113.3 Issue 2, December 1997, Table 4) and the associated parameter
value in its native format. The message type is omitted from the ISUP
payload (but must be indicated in MessageType of the Encoding: parameter
in the text header). Pointers to the optional parts are not encoded.
The value of the MessageType field of the encoding parameter is set as
follows:
+----------------------------------------------------+
| ISUP Message | Value of MessageType |
|============================|=======================|
| Initial Address | IAM |
|----------------------------|-----------------------|
| Address Complete | ACM |
|----------------------------|-----------------------|
| Answer | ANM |
|----------------------------|-----------------------|
| Release | REL |
|----------------------------|-----------------------|
| Continuity | COT |
|----------------------------|-----------------------|
| Suspend | SUS |
|----------------------------|-----------------------|
| Resume | RES |
|----------------------------|-----------------------|
| Call Progress | CPG |
+----------------------------------------------------+
Each parameter name code serves as the tag value and is encoded as a
byte. The length is encoded as an unsigned byte with value ranging from
1 to 255. The parameter is encoded as per GR-394-CORE.
The order of parameters (and tags by reference) for a given ISUP message
is as appears in GR-394-CORE with the fixed mandatory part being encoded
first, followed by the variable length mandatory part, and then followed
by the optional part.
2.6 State Machines
It is worth noting the expected responses to given messages and a state
machine driven by them. The following details a simplified originating
Media Gateway Controller state machine. Idle is the initial state.
Melkild, Raju, Thomas expires May 1999 [Page 17]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+----------------+
-------------------->/ Idle \<----------------
| | \ / |
| | +----------------+ |
| REJ/route advance | |
| | route selected/send SET |
| | | |
| | +----------------+ |
| ------------/ Call Initiated \--------------->|
| \ / |
| +----------------+ |
| | |
REJ/route advance ACK/mdcx REL/dlcx
| | |
| +----------------+ |
---------------------/ Call Proceeding \--------------->|
\ /--------> |
+----------------+ | |
| | ACK/mdcx |
PRG | | |
| <-------------- |
+----------------+ |
/ Call Received \--------------->|
\ / |
+----------------+ |
| |
CON |
| |
+----------------+ |
/ Call Active \--------------->|
\ /
+----------------+
Figure 2: IGSP Originating State Machine
The terminating Media Gateway Controller simplified state diagram is as
follows. Again idle is the initial state.
Melkild, Raju, Thomas expires May 1999 [Page 18]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+----------------+
----------->/ Idle \<----------------
| \ / |
| +----------------+ |
no circuit/send REJ | |
| SET/select circuit |
| | |
| +----------------+ |
------------/ Call Initiated \--------------->|
--------------->\ / |
| +----------------+ |
| | |
glare or COT failure circuit selected/send ACK REL/send REL
/reselect circuit | |
| +----------------+ |
----------------/ Call Proceeding \--------------->|
\ /---------> |
+----------------+ | |
| | CPG/send PRG |
ACM/send PRG | | |
-------------- | <-------------- |
CPG/send PRG \ +----------------+ |
| / Call Delivered \--------------->|
--------------->\ / |
+----------------+ |
| |
ANM/send CON |
| |
+----------------+ |
/ Call Active \--------------->|
\ /
+----------------+
Figure 3: IGSP Terminating State Machine
2.7 Required SDP Embedding
The following details the required SDP embedding within a given message
type for this draft.
Melkild, Raju, Thomas expires May 1999 [Page 19]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+----------------------------------------------------------+
| Message | Embedded SDP Message |
|=========|================================================|
| SET | Describes RTP endpoint on originating gateway. |
|----------------------------------------------------------|
| ACK | Describes RTP endpoint on terminating gateway. |
|----------------------------------------------------------|
| REJ | No message allowed. |
|----------------------------------------------------------|
| PRG | No message allowed. |
|----------------------------------------------------------|
| CON | No message allowed. |
|----------------------------------------------------------|
| REL | No message allowed. |
|----------------------------------------------------------|
| CAR | No message allowed. |
+----------------------------------------------------------+
2.8 Examples
The following are examples of typical Media Gateway Controller interac-
tions.
2.8.1 Normal Call Setup
The diagram following represents a message flow for a successful call
from start to finish.
Melkild, Raju, Thomas expires May 1999 [Page 20]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
| | 1. IAM | | | |
|-------------------->| | | |
| 2. Allocate| | | |
| |<---------| | | |
| |Connection| | | |
| |--------->| | | |
| | 3.SET(IAM,SDP) | |
| | |--------->| | |
| | | 4. Allocate| |
| | | |--------->| |
| | | |Connection| |
| | | |<---------| |
| | 5. ACK(SDP)| | |
| | |<---------| | |
| |6. Modify | | | 7. IAM |
| |<---------| |-------------------->|
| |Connection| | | |
| |--------->| | | |
| | | | 8. ACM | |
| | | |<--------------------|
| | 9. PRG(ACM)| | |
| | |<---------| | |
| |10. Modify| | | |
| |<---------| | | |
| |Connection| | | |
| |--------->| | | |
| 11. ACM | | | | |
|<--------------------| | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<<Alerting>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Figure 4: Call Setup To Call Received/Delivered State
Melkild, Raju, Thomas expires May 1999 [Page 21]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
| | | | 12. ANM | |
| | | |<--------------------|
| | 13. CON(ANM)| | |
| | |<---------| | |
| 14. ANM | | | | |
|<--------------------| | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<<Talking>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Figure 5: Call Setup To Call Active State
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
| | 15. REL | | | |
|-------------------->| | | |
| | 16. REL(REL)| | |
| | |--------->| | |
| 17. Deallocate| | | 18. REL |
| |<---------| |-------------------->|
| |Connection| 19. Deallocate| |
| |--------->| |--------->| |
| | | |Connection| |
| | | |<---------| |
| 20. RLC | | | 21. RLC | |
|<--------------------| |<--------------------|
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Figure 6: Call Takedown
2.8.2 Normal Call Setup with Alternative Routing
The following represents a normal call setup where the terminating Media
Gateway Controller is unable to process the setup request and rejects
the setup request. The originating Media Gateway Controller selects as
appropriate an alternative Media Gateway Controller.
Melkild, Raju, Thomas expires May 1999 [Page 22]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC1 Term MGC2 Term MG SG
| | | | | | |
| | 1. IAM | | | | |
|------------------>| | | | |
| 2. Allocate| | | | |
| |<--------| | | | |
| Connection| | | | |
| |-------->| | | | |
| | 3.SET(IAM,SDP) | | |
| | |-------->| | | |
| | | 4. REJ | | | |
| | |<--------| | | |
| | | 5.SET(IAM,SDP) | | |
| | |------------------>| | |
| | | | 6. Allocate| |
| | | | |--------->| |
| | | | |Connection| |
| | | | |<---------| |
| | 7. ACK(SDP)| | | |
| | |<------------------| | |
| 9. Modify | | | | 8. IAM |
| |<--------| | |------------------->|
| Connection| | | | |
| |-------->| | | | |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
| = Call proceeds as in previous figures = |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
Figure 7: Normal Call Setup with Alternative Routing
2.8.3 Failed Call Setup Due To No Resources
It is possible that no Media Gateway Controller in the routing plan has
resources to handle the terminating side of the call. In this case, the
originating Media Gateway Controller must release the call.
Melkild, Raju, Thomas expires May 1999 [Page 23]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC1 Term MGC2 Term MG SG
| | | | | | |
| | 1. IAM | | | | |
|------------------>| | | | |
| 2. Allocate| | | | |
| |<--------| | | | |
| Connection| | | | |
| |-------->| | | | |
| | 3.SET(IAM,SDP) | | |
| | |-------->| | | |
| | | 4. REJ | | | |
| | |<--------| | | |
| | | 5.SET(IAM,SDP) | | |
| | |------------------>| | |
| | | 6. REJ | | | |
| | |<------------------| | |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
| = No setup attempts succeed, | = |
| = originating MGC releases call | = |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
| 7. Release | | | | |
| |<--------| | | | |
| Connection| | | | |
| |-------->| | | | |
| 8. REL (cause) | | | | |
|<------------------| | | | |
| | 9. RLC | | | | |
|------------------>| | | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Figure 8: Failed Call Setup Due To No Resources
2.8.4 Suspend and Resume
The following represents the behavior of suspend and resume.
Melkild, Raju, Thomas expires May 1999 [Page 24]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<<Talking>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| | | | | |
| | | | 1. SUS | |
| | | |<--------------------|
| | 2. CAR(SUS)| | |
| | |<---------| | |
| 3. SUS | | | | |
|<--------------------| | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<<Suspended>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| | | | | |
| | | | 4. RES | |
| | | |<--------------------|
| | 5. CAR(RES)| | |
| | |<---------| | |
| 6. RES | | | | |
|<--------------------| | | |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<<Talking>>
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Figure 9: Operation Of Suspend and Resume
2.8.5 Continuity Testing
There are two continuity scenarios: forward and backward. Note that
there is no continuity testing over the RTP connection between gateways.
The following is an example of forward continuity testing. The ter-
minating Media Gateway Controller is responsible for running continuity
tests in the forward direction.
Melkild, Raju, Thomas expires May 1999 [Page 25]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
| | 1. IAM | | | |
|-------------------->| | | |
| 2. Allocate| | | |
| |<---------| | | |
| |Connection| | | |
| |--------->| | | |
| | 3.SET(IAM,SDP) | |
| | |--------->| | |
| | | 4. Allocate| |
| | | |--------->| |
| | | |Connection| |
| | | |<---------| |
| | 5. ACK(SDP)| | |
| | |<---------| | |
| 6. Modify | 7. Allocate| |
| |<---------| |--------->| |
| |Connection| Connection (COT) |
| |--------->| |<---------| |
| | | | 8. IAM (w/COT) |
| | | |-------------------->|
| | | 9. Report COT |
| | | |<---------| |
| | | |ACK | |
| | | |--------->| |
| | | | 10. COT (success) |
| | | |-------------------->|
| | | 11. Deallocate |
| | | |--------->| |
| | | | Connection (COT) |
| | | |<---------| |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
| = Call proceeds as in figures 4 to 6 = |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
Figure 10: Operation Of Forward Continuity Testing
The following is an example of backward continuity testing. The ori-
ginating Media Gateway Controller runs backward continuity testing.
Melkild, Raju, Thomas expires May 1999 [Page 26]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
SG Orig MG Orig MGC Term MGC Term MG SG
| | | | | |
| 1. IAM (w/COT) | | | |
|-------------------->| | | |
| 2. Allocate| | | |
| |<---------| | | |
| |Connection| | | |
| |--------->| | | |
| | 3.SET(IAM,SDP) | |
| | |--------->| | |
| 4. Allocate| 5. Allocate| |
| |<---------| |--------->| |
| Connection (COT)| |Connection| |
| |--------->| |<---------| |
| | 6. ACK(SDP)| | |
| | |<---------| | |
| 8. COT (success) | | | 7. IAM |
|-------------------->| |-------------------->|
| | 9. CAR(COT)| | |
| 11. Deallocate |--------->| | 10. COT |
| |<---------| |-------------------->|
| Connection (COT)| | | |
| |--------->| | | |
| 12. Modify | | | |
| |<---------| | | |
| |Connection| | | |
| |--------->| | | |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
| = Call proceeds as in figures 4 to 6 = |
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |
Figure 11: Operation Of Backward Continuity Testing
3.0 Transport Protocol Proposal
An ordered guaranteed delivery scheme is required. TCP is proposed in
this draft, pending work in the sigtran working group.
The following represents the protocol stack for this transport:
Melkild, Raju, Thomas expires May 1999 [Page 27]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
+-------------------------------------------+
| IGSP |
| (IGSP PDU encoded as in 2.1) |
|-------------------------------------------|
| TPKT |
| (4 byte header to indicate packet length) |
|-------------------------------------------|
| TCP |
|-------------------------------------------|
| IP |
+-------------------------------------------+
The TPKT header is described in RFC 1006.
MGCNames are mapped to a host and port number and are preprovisioned. A
Media Gateway Controller which discovers that a connection is required
to another Media Gateway Controller attempts to connect and must main-
tain the connection indefinitely. In the event of glare (two Media
Gateway Controllers attempting to establish a socket simultaneously),
the Media Gateway Controller with the lower valued IP address yields and
closes its socket.
4.0 Intellectual Property
This document in part describes intellectual property claimed by Nortel
Networks (Northern Telecom). Nortel Networks is prepared to license
this intellectual property on a reasonable and non-discriminatory basis.
5.0 References
[1] F. Cuervo, N. Greene, et al, "SS7-Internet Interworking - Architec-
tural Framework", <draft-greene-ss7-arch-frame-01.txt>, July 1998,
work in progress.
Melkild, Raju, Thomas expires May 1999 [Page 28]
INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998
6.0 Authors' Addresses
Keith Melkild
Nortel Networks
2350 Lakeside Dr.
Richardson, Texas
melkild@NortelNetworks.com
Venkatesh Raju
Nortel Networks
2350 Lakeside Dr.
Richardson, Texas
orion@NortelNetworks.com
Michael Thomas
Nortel Networks
2350 Lakeside Dr.
Richardson, Texas
thomasmf@NortelNetworks.com
Melkild, Raju, Thomas expires May 1999 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-23 15:12:05 |