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 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 . 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 . Melkild, Raju, Thomas expires May 1999 [Page 6] INTERNET DRAFT Inter-Gateway Signalling Protocol December 1998 +---------------------------------------------------------+ | | |---------------------------------------------------------| | : IGSP/1.0 | |---------------------------------------------------------| | From: | |---------------------------------------------------------| | [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 to indicate the start of the mixed protocol part. (In other words, a sequence of ASCII 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. 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 and is of the for- mat . 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: : / is described below. 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. is a globally unique identifier used between Media Gateway Con- trollers. 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 is encoded as an ASCII string with the value enclosed in quotes: "IGSP". 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 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 . is of the format . 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 | | | | [] | +---------------------------------------------------------------+ indicates the protocol type of the message and is an ASCII alphanumeric string. indicates the issuing organization and is an ASCII alphanumeric string. identifies the version of the protocol and is an ASCII alphanumeric string. is an ASCII integer identifying the length in bytes of the pro- tocol message. 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 +---------------------------------------------+ | | |---------------------------------------------| | SET O: IGSP/1.0 | |---------------------------------------------| | From: | |---------------------------------------------| | Resource: | |---------------------------------------------| | Encoding: ISUP Bellcore 1997 IAM | |---------------------------------------------| | Encoding: SDP IETF 0 | |---------------------------------------------| | | |---------------------------------------------| | 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. 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. +---------------------------------------------+ | | |---------------------------------------------| | ACK T: IGSP/1.0 | |---------------------------------------------| | From: | |---------------------------------------------| | 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. +---------------------------------------------+ | | |---------------------------------------------| | REJ T: IGSP/1.0 | |---------------------------------------------| | From: | +---------------------------------------------+ 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. +---------------------------------------------+ | | |---------------------------------------------| | PRG T: IGSP/1.0 | |---------------------------------------------| | From: | |---------------------------------------------| | 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 +---------------------------------------------+ | | |---------------------------------------------| | CON T: IGSP/1.0 | |---------------------------------------------| | From: | |---------------------------------------------| | 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. +----------------------------------------------+ | | |----------------------------------------------| | REL : IGSP/1.0 | |----------------------------------------------| | From: | |----------------------------------------------| | 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 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. +-----------------------------------------------+ | | |-----------------------------------------------| | CAR : IGSP/1.0 | |-----------------------------------------------| | From: | |-----------------------------------------------| | Encoding: ISUP Bellcore 1997 25 | |-----------------------------------------------| | 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 | | | | | |<--------------------| | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 | | | | | |<--------------------| | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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 | | | | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | | | | | | | | | | 1. SUS | | | | | |<--------------------| | | 2. CAR(SUS)| | | | | |<---------| | | | 3. SUS | | | | | |<--------------------| | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | | | | | | | | | | 4. RES | | | | | |<--------------------| | | 5. CAR(RES)| | | | | |<---------| | | | 6. RES | | | | | |<--------------------| | | | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- <> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 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", , 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]