Internet Engineering Task Force Kushanava Laha Internet Draft Vikram Nair Document: Hughes Software Systems Category: Informational Bill Foster Cisco Systems October 2002 MGCP R2 CAS Package Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 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. 1. Abstract This document describes an MGCP package for R2 CAS signaling. 2. Conventions used in this document 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 RFC-2119. Laha et al Informational [Page 1] INTERNET DRAFT MGCP R2 CAS Package October 2002 3. Introduction Signaling System R2 is used for international/national signaling for both automatic and semiautomatic inter-working. It allows for rapid call set-up by providing sufficient signals in both directions to permit the transmission of numerical and other information relating to the called and calling subscriber lines and to increase routing facilities. The forward and backward compelled register signaling sequence for exchanging call setup control information shall be executed in the Media Gateway (MG). Signaling System R2 defines several numbered (digit) and enumerated (non-digit) components of the call set-up control information. The numbered call setup-up control information components considered in this document are the destination number, source number and country code. The enumerated call set-up control information components considered are echo suppression information, calling subscriber category, discriminating indicator, nature of circuit, subscriber line status and congestion information. Of these, the numbered components and the following enumerated components - echo suppression information, calling subscriber category, discriminating indicator and nature of circuit, are collectively termed address parameters as they collectively convey the complete address information required for call set-up in Signaling system R2. They are also the components required at the minimum by the outgoing MG in order to start the compelling action. In order to handle time sensitive issues governing the compelling sequence and to keep the Call Agent transparent of implementation specific compelling at the MG, the following simple guidelines have been observed while defining the package: * All numbered address parameters are exchanged as complete digit strings between the MG and Media Gateway Controller/Call Agent (MGC) containing all the digits i.e. there is no digit by digit reporting or signaling of numbered address parameters between the MG and Call Agent. * The outgoing MG is supplied with all the address parameters before it starts outpulsing the compelling sequence. In fact the Call Agent provides a "call setup" signal to the outgoing MG with all the necessary (address and other) parameters. * The MG behaving as an incoming R2 end, compels and collect all the address parameters as per the provisioned compelling sequence when the "call setup" event is requested. Flexibility in the package allows for the Call Agent to solicit specific parameters. Signals and events related to only basic R2 signaling operation for automatic or semi-automatic inter-working, have been considered in the R2 package. Variants of R2 signaling may define new supervisory (line) and call set-up control (register) signals to introduce features such as re-answering, trunk offering, re-ring, operator break-in etc, to name a few. As there is no single standard mechanism to implement such features (they vary from country to country), they have not been considered in this package. However it is possible to Laha et al Informational [Page 2] INTERNET DRAFT MGCP R2 CAS Package October 2002 realize such features on the MGCP interface, by defining additional signals and events in other packages. 4. Assumptions a. As shown in the diagram below, the MG shall be connected to an R2 exchange for R2 compelled signaling, peer MG for media transport and Call Agent (MGC) for exchanging R2 signaling information using MGCP with R2 package. +-----+ +--MGCP--| MGC |--MGCP--+ | +-----+ | | | (~~~~~~) +--+--+ +--+--+ (~~~~~~) ( PSTN )====R2=====| MG1 |------RTP--------| MG2 |====R2=====( PSTN ) (~~~~~~) +-----+ +-----+ (~~~~~~) [Incoming MG] [Outgoing MG] [Call origination] [Call Termination] Incoming - Outgoing convention This draft uses the following convention for incoming / outgoing MG * Incoming MG: The R2 exchange initiates the call signaling towards the MG. * Outgoing MG: The MG initiates the call signaling towards the R2 exchange. Hence as shown in the figure above, MG1 is an incoming MG and MG2 is an outgoing MG. b. Signaling system R2 can be used for analog (one-way operation) or digital transmission systems (one-way or both-ways operations). The call agent (MGC) should be transparent with respect to the transmission details at the physical layer. The MG is therefore assumed to be provisioned with the actual signaling frequencies for inter-register signaling (2-out-of-n in-band multi frequency code with forward and backward compelled signaling) along with their properties such as amplitude, tone duration, cadence etc and also their logical significance. All timers that dictate the inter-register compelling actions are also assumed to be provisioned in the MG. The SF, E&M (for analog) and "abcd" bits (for digital) line signaling parameters generated at the physical layer, along with their logical significance are also assumed to be provisioned at the MG. c. The end-of-digit sequence for the called party on an incoming call to an endpoint may be recognized either by the "end of pulsing" compelled forward register signal or based on the digit map. The use of the digit map also takes care of situations where identification of end of digit sequence is through length Laha et al Informational [Page 3] INTERNET DRAFT MGCP R2 CAS Package October 2002 determination or timeout mechanisms. The calling party number shall be compelled till the occurrence of maximum length of calling party number or timeout (specified as configuration) or the occurrence of end of pulsing. The MG is assumed to be provisioned with a list of possible country codes. The MG shall compel the country code digits based on this provisioned information. d. The MGC and MG, supporting signaling System R2 on the PSTN side, provides signaling and media inter-working between two very different types of signaling systems and networks. It is therefore assumed that the MG shall either originate or terminate R2 signaling (acting as a true inter-working unit between the PSTN and packet network both in terms of signaling and media) depending on whether it emulates the outgoing or incoming end in the signal path. Under tandem operation, therefore, the MG converts end-to-end R2 signaling to link-by- link signaling and does not allow R2 register signals to pass through it as tones. 5. R2 CAS package Package Name: R2 Package Version: 0 5.1. MGCP Configuration Parameters The following MG configuration parameters are specific to the R2 CAS package. * Clear back signal validation time: Specifies the minimum duration for which the MG, if behaving as an outgoing end, validates the "Clear-back" signal initiated by the other end (incoming end). * Source number length: Indicates that the calling party digits can be up to a maximum length as specified by the parameter value. Thus calling party digits are collected up to a maximum of this value or end of pulsing indicator. * Source number timeout: Indicates that calling party digits are to be collected till timeout of this timer value. The MG shall stop compelling source number and consider collection of source number to be complete either on expiry of this timer or when the source number length criterion is matched or on receipt of end of pulsing. * Subscriber line status flag: Specifies whether the MG, behaving as an incoming end, and after reporting all the address parameters to the MGC, waits or does not wait for the called subscriber line status information to be signaled by MGC before terminating the compelling action. * Trunk direction: Specifies whether the R2 endpoint is an incoming, outgoing or bothway trunk circuit. Laha et al Informational [Page 4] INTERNET DRAFT MGCP R2 CAS Package October 2002 * Seize signal validation time: Specifies the minimum duration that the "seizing" signal must persist in order to be reported as an event. * Start dialing timeout : Specifies the timer for the receipt of the "start dialing" signal. * Answer timeout: Specifies the timer for the receipt of the "answer" signal. * Answer signal validation time: Specifies the minimum duration that the "answer" signal must persist for it to be reported as an event. * clear signal validation time: Specifies the minimum duration for which the gateway, if behaving as an incoming end, validates the "clear- forward" signal (or on-hook). * Country codes: A list of possible country codes is provisioned in the gateway. 5.2. Events and Signals The following codes are used to identify events and signals for the "R2" package: Table 1 "" Package Events and Signals ------------------------------------------------------------------ |Code|Description |Event|Signal Duration | |------------------------------------------------------------------| |ans |Call Answer | S | BR | | bl |Block | S | BR | | cb |Clear Back | S | BR | | cf |Clear Forward | S | BR | |ubl |Unblock | S | BR | |cng |Congestion | - | BR | |r2f |R2 CAS Failure | x | - | |sls |Subscriber Line Status | x | BR | |sup |Call Setup | - | TO Variable | | oc |Operation Complete | x | - | | of |Operation Fail | x | - | |sz |Seizure | S | - | |r2a |Accumulated Info. | x | - | |dn |Destination Number | x | - | |sn |Source Number | x | - | |sc |Subscriber Category | x | - | |es |Echo Suppression Info. | x | - | |cc |Country Code | x | - | |ds |Discriminating Ind. | x | - | |nc |Nature of Circuit | x | - | ------------------------------------------------------------------ Note that none of these events are defined as persistent. If persistent events are desired for certain events, the persistent Laha et al Informational [Page 5] INTERNET DRAFT MGCP R2 CAS Package October 2002 event parameter in the base ("B") package in [2] should be used (if supported). Call Answer (ans): Supervisory signal indicating that the call has been answered. Block (bl): This signal is used to supply a steady blocked condition on the endpoint. When requested as an event, it is used to indicate a blocked condition to the Call Agent. Unblock (ubl): This signal can be used to release a previously blocked condition (caused by the "r2/bl" signal). As an it event indicates that a previously blocked condition has become unblocked. Clear Back (cb): This event corresponds to R2 "clear back" line signaling. Clear Forward (cf): This event corresponds to R2 "clear forward" line signaling. Congestion (cng): This signal applies the network congestion compelled R2 signal on an endpoint. R2 Failure (r2f): Reports general failure or abnormal line and register signaling conditions. If reported, the reason for failure is reported as a parameter with one of the following possible values: "CNG" - Congestion: Encountered Network congestion. "BLK" - Blocked: Encountered engaged condition on the "idle" endpoint such that the MGC should not attempt a call on this endpoint until the un-engaged ("unblocked") condition is restored. If reported on an already "seized" endpoint, indicates a failure condition for which the controlling MGC is expected to back-off and retry on a new endpoint, propagate the congestion condition backwards and/or clear the call on this endpoint (depending on the call state at MGC). "EAD" - Error in address specification: The address information specified by the MGC is incomplete or inappropriate with respect to the compelling sequence provisioned in the outgoing MG current signaling state. "BAD" - Bad Signal Request: The package signal (supervisory line signal) requested by MGC for application is inappropriate with respect to the line signaling state at MG. The request is not being honored by MG with no impact on the current signaling state. "DSZ" - Dual Seizure: Encountered dual seizure (or glare) condition, indicating that the MGC requested "seizure" ("r2/sup") at the same time as an incoming seizure occurred. Subscriber Line Status (sls): This provides line condition information associated with the called subscriber. When requested as Laha et al Informational [Page 6] INTERNET DRAFT MGCP R2 CAS Package October 2002 a signal and when reported as an event, a parameter indicating the subscriber line status is included with one of the following possible values: "UN" - Unallocated number "SLB" - Subscriber line busy "SLFC" - Subscriber line free, charge "SLFNOC" - Subscriber line free, no charge "SOO" - Subscriber out of order "SIT" - Send special information tone "NK" - Subscriber status not known, set-up speech path Call Setup (sup): Outgoing call setup with the following parameters. When requested as a signal, a seizure is provided on the line and when the seizure is acknowledged, the gateway begins compelling action for the parameters provided. Parameters are provided as a comma-separated list as indicated below (order of the parameters is not important): * Destination number: dn= ... , where is a digit from "0" to "9" * Source number: sn= ... , where is a digit from "0" to "9" * Caller Subscriber Category: sc= where can have one of the values: "NNPS" - Non-priority subscriber (National Working) "NPRS" - Priority subscriber (National Working) "NMNT" - Maintenance equipment (National working) "NOPR" - Operator call (National Working) "NDT" - Data transmission (National working) "ISOPR" - Subscriber or operator without forward transfer facility (International working) "IOPRF" - Operator with forward transfer facility (International working) "IDT" - Data transmission (International working) "IPRS" - Priority subscriber (International working) * Echo Suppression Information: es= where can have one of the following values: "OGRQ" - Call requires echo suppressors and outgoing half-echo suppressor has to be inserted "NRQ" - Call may not require any echo suppressor "OGINS" - Call requires echo suppressors and outgoing half-echo suppressor has Laha et al Informational [Page 7] INTERNET DRAFT MGCP R2 CAS Package October 2002 already been inserted "ICRQ" - Call requires incoming echo suppressors to be inserted * Country Code Information: cc=,, ..., , where is a digit from "0" to "9" * Discriminating Indicator: ds=, where is one of the values: "DISC" - Discriminating digit for automatic working "FR" - Language digit French "EN" - Language digit English "GR" - Language digit German "RU" - Language digit Russian "SP" - Language digit Spanish "OT" - Language digit Other "TCI" - Call by automatic test equipment * Nature of the Circuit: nc=, where can have one of the values: "INC" - Satellite link included "NOI" - Satellite link not included Operation Complete (oc): This event is supported in accordance with its default definition (i.e. reports completion of a TO signal). In this case, the only TO signal is this package is the "sup" signal. Hence, this event can be used to indicate when call setup (outpulsing) is completed. Operation Fail (of): In general, the operation failure event may be generated when the endpoint was asked to apply one or several signals of type TO on the endpoint, and one or more of those signals failed prior to timing out. In this package, the only TO signal is the "sup" signal used for doing a call setup. The failure report carries with it as a parameter the name of the signal that failed. In the case of the sup signal, general reasons are also supplied w.r.t. call setup (in addition to the r2 specific reasons indicated for the r2f event) O: r2/of(r2/sup,)) where can be any one of: "ULS" - Unexpected line signal "LTO" - Line signal timeout "RTO" - Register signal timeout "SME" - Protocol State machine malfunction "SDO" - Start Dialing Timeout "ANO" - Answer Timeout "ADR" - Error during outpulsing Note that when the operation failure event is requested, it cannot be parameterized with any event parameters. Laha et al Informational [Page 8] INTERNET DRAFT MGCP R2 CAS Package October 2002 Seizure (sz): Event indicating that an incoming seizure has occurred. Accumulated R2 Information (r2a): When this event is requested, all of the address information as well as country code etc. is accumulated before reporting this event. The format of the parameters is the same as that for the "sup" signal: * Destination number: dn= ... * Termination Method: tm= * Source number: sn= ... * Caller Subscriber Category: sc= * Echo Suppression Information: es= * Country Code Information: cc=,, ..., * Discriminating Indicator: ds= * Nature of the Circuit: nc= See the description of the "sup" signal for allowable parameter values. The only exception is the termination method. The can have one of the following values: "UM" - Unambiguous Match or "perfect" match as described in section 2.1.5 of [2]. "NM" - No match or "impossible match" as described in section 2.1.5 of [2]. "PM" - end of signaling received (along with a partial match) Note that the digit map symbol "T" indicates timer expiry for compelled register signaling. In the case of a mismatch (including one due to timer expiry), the resulting mismatched digit string is included the destination number parameter. If the mismatch is caused by a timer expiry, then of course the digit string will be terminated by the "T" digit map symbol. If the digit map is not available when a request for "r2a" or "dn" is made, error 519 must be returned. Rather than waiting for all of the information to be accumulated, the Call Agent may request that the information as separate events. In that case, each piece of information will be reported separately as it occurs. None of the following events can be requested in conjunction with the "r2a" event (else an error will be reported with response code XXX). These separately reported events are as follows: * Destination number: dn(nu= ... ,tm=) * Source number: sn( ... ) Laha et al Informational [Page 9] INTERNET DRAFT MGCP R2 CAS Package October 2002 * Caller Subscriber Category: sc() * Echo Suppression Information: es() * Country Code Information: cc(,, ..., ) * Discriminating Indicator: ds() * Nature of the Circuit: nc() Allowable values for parameters are the same as for the "r2a" event. 6. Procedures 6.1. Procedures for exchanging supervisory signals This section attempts to capture the procedures involved in using the R2 package signals and events for exchanging the supervisory signals in signaling System R2 between the Call Agent and MG under normal signaling operations. Incoming Call Setup ------------------- When an endpoint in the MG is not involved in a call, it is in the "idle" state. The Call Agent has two choices: 1. Make a request for the r2a event which will accumulate all of the R2 information before reporting e.g.: RQNT ... ... R: r2/r2a,r2/r2f,r2/bl,r2/sz In the case of digital trunk, when an incoming seizure occurs, the gateway will automatically respond with a "seizure acknowledge" (in the analogue case, there is no seizure acknowledge required). Compelled signaling will be then be initiated immediately. If the Call Agent requested event "r2/sz", then the seizure event would be be notified as soon as the seizure occurs. Note: in this case and if in step-by-step mode, the Call Agent would have to send another RQNT before being notified about the "r2a" event. If the "Q:" parameter is set to "loop" or if the "sz" event was not requested, then this extra RQNT would not be required (however, requesting the "sz" event is recommended as part of the glare mitigation strategy). As soon as all the information is available that was requested in the event parameters, the "r2/r2a" event will be notified to the Call Agent e.g.: NTFY ... ... Laha et al Informational [Page 10] INTERNET DRAFT MGCP R2 CAS Package October 2002 O: r2/r2a(dn=,sn=,...) 2. Alternatively the Call Agent may ask to be told about R2 information as separate events than waiting until it all accumulates e.g.: RQNT ... ... Q:loop R: r2/dn,r2/sn,r2/sc,r2/es,r2/cc,r2/ds,r2/nc,r2/r2f,r2/bl,r2/sz In this case, as soon as "r2/z" is reported, the gateway will report individual notifies for each piece of information whenever it is available. Outgoing Call Setup ------------------- An outgoing call setup request is done with the "r2/sup" signal. When sent as a signal request to the gateway, the gateway sends a "seizure". In the case of a digital trunk it then waits for a "seizure acknowledge". It then starts outpulsing the address and other parameters supplied with the signal. Example - it may be done as an embedded RQNT in a CRCX like: CRCX ... ... S: r2/sup(dn=destination-number>,sn=,...) R: r2/of,r2/r2f,r2/ans,r2/oc If there is an error due to a "start dialing timeout" (i.e. the seizure acknowledge takes too long) or other error in trying to outpulse, the gateway will send a NTFY with "O: r2/of(r2/sup(...)) or r2/r2f(...), indicating the reason for the error. If outpulsing completes properly, then the operation complete event will be notified if it was requested(i.e. NTFY with "O:r2/oc(r2/sup)"). Call Answer ----------- "r2/ans" is reported as an event from the outgoing MG to the Call Agent when the "answer" line signal is detected. The Call Agent then uses "r2/ans" as a signal to instruct the incoming MG to transmit the "answer" line signal to the incoming end. Call Clearing ------------- The "r2/cb" signal can be used to generate a "clear-back" line signal on an incoming R2 trunk while "r2/cf" can be used to generate a "clear-forward" line signal on an outgoing R2 trunk. Similarly, these events can be requested in order to report these R2 line-signaling events on these events. Note that the release and release-guard sequence defined by signaling System R2 shall be locally executed at Laha et al Informational [Page 11] INTERNET DRAFT MGCP R2 CAS Package October 2002 the MG at the time of call clearing and such procedures shall be transparent to the Call Agent Blocking/Unblocking ------------------- Signaling System R2 defines supervisory signals to render an "idle" R2 endpoint (trunk) to "blocked" state. The Call Agent applies the "r2/blk" signal to the MG on an incoming interface in "idle" state to prevent any incoming "seizure" of the circuit. On an outgoing interface, the MG is able to report the blocking condition to its controlling Call Agent via the "r2/bl" event. If the controlling Call Agent of the outgoing MG attempts to "seize" a "blocked" endpoint, the outgoing MG shall report a failure to the MGC (filling up "Bad Signal Request" as the value of the error code parameter for the "r2/r2f event). Signaling System R2 similarly defines supervisory signals to render a "blocked" R2 endpoint (trunk) to "unblocked"/"idle" state. The Call Agent applies the "r2/ubl" signal to the MG on an incoming interface in "blocked" state to render it to "idle". On an outgoing interface, a request for the "r2/ubl" event can be used to report when the trunk becomes unblocked (or idle) so that it is available for future calls. Glare Mitigation ---------------- Glare (or more popularly known as "dual seizure") arises when an outgoing call setup request occurs simultaneous with an incoming seizure of a both-way R2 trunk. Glare can occur at either the MG to R2 interface or at the MGC-MG interface. If the gateway is able to recognize the glare condition early enough, it may respond immediately with reason code "800" to the "r2/sup(...)" signal request. Otherwise, it will notify (if requested) with an "r2/r2f(dsz)" event. In the case where the glare occurred at the MGC-MG interface, it may be possible for the incoming call to continue, (i.e. report the "r2/sz" event if requested). In order to reduce the glare "window" it is recommended that the Call Agent request to be notified about the "r2/sz" signal when setting up a trunk for an incoming call. This allows the Call Agent to be aware of an incoming call setup "in-progress" as soon as possible. To allow an incoming call to proceed in the case where glare occurred at the MGC-MG interface, it makes sense to request both the "r2/sz" and "r2/r2a" (or individual information) events, even when requesting an "r2/sup" signal i.e.: S: r2/sup(dn(),sn(),...) R: r2/of/r2/r2f,r2/ans,r2/sz,r2/r2a If this was done with "Q:loop" set, then in the case of an MG-MGC glare condition, the Call Agent might see: Laha et al Informational [Page 12] INTERNET DRAFT MGCP R2 CAS Package October 2002 * a NTFY with "O: r2/r2f(dsz)" * a NTFY with "O: r2/sz" * and a NTFY with "O: r2/r2a(...) indicating the incoming call has completed. Failure/Abnormal conditions --------------------------- Failure or abnormal conditions at the MG during supervisory signal exchange shall be reported through the "r2/of" and "r2/r2f" events to the MGC. It is advised that the MGC request the "r2/r2f" event when either setting up for an incoming or outgoing call. However, "r2/of" is only valid for the "r2/sup" TO signal. 6.2 Procedures for exchanging call set-up control information The "r2/r2a" (or alternative "r2/dn", r2/sn", etc.) events and "r2/sup" signal is used for passing (address and other) r2 parameters between the Call Agent and the MG. Digit sequence termination at incoming MG ----------------------------------------- Address parameters calling party number, called party number and country code shall be compelled and the event completion criteria for each parameter shall be decided upon the conditions / procedures mentioned in the table below: Address Parameter Completion criteria ----------------- ------------------- Called Party Number The MG shall collect called party number digit string until the occurrence of any one of the events mentioned below: * end of pulsing * maximum length of called party digits, perfect match or mismatch as specified by the digit map. * timeout of called party timer. The calling party timer shall be started the moment called party number compelling starts. {BF: how - unless T is especially defined} Calling Party Number The MG shall collect calling party number digit string until the occurrence of any one of the events mentioned below: * end of pulsing * maximum length of calling party digits * timeout of calling party timer. The calling party timer shall be started the moment calling party number compelling starts. Laha et al Informational [Page 13] INTERNET DRAFT MGCP R2 CAS Package October 2002 Country Code MG shall collect country code digits based on provisioned list of country codes. Termination of Compelling Sequence ---------------------------------- After an incoming MG has reported the "r2/r2a" (or alternative information) event(s) to its controlling MGC, the latter shall route the call based on the call set-up control information supplied. Depending on the value of the provisioned "subscriber line status flag", the incoming MG shall either terminate the compelled signaling sequence or wait for the outcome of the routing status to be signaled by the MGC. In the event of this second option, the MGC shall indicate back to the incoming MG either the Called subscriber line status ("r2/sls" signal) or the "r2/cng" signal (if the MGC encountered network congestion). Similarly, an MG behaving as an outgoing end shall wait for the called subscriber line status information. This shall be reported as the "r2/sls" event to the controlling MGC. If the outgoing MG receives congestion information instead, it shall be reported as "r2/r2f" event to MGC with Error code parameter set to Congestion ("CNG"). 6.3 Call flows for Incoming Call A digital trunk type is assumed at the physical interface level. The ladder diagrams attempt to capture the typical usage of the package signals and events and they are indicative in nature. Here the MG is behaving as an incoming end and the MG and MGC are assumed to be placed such that they together form the last incoming R2 register (transit gateway) in the signaling path beyond which international inter-working call signaling protocols start. Detailed parameters in events and signals are not shown --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- < --------- RQNT Q: loop R: r2/r2a,r2/r2f,r2/bl,r2/sz -----------> "seizing" <----------- "seizure acknowledged" -----------> NTFY O: r2/sz /*---------------------------------------------------------------- Laha et al Informational [Page 14] INTERNET DRAFT MGCP R2 CAS Package October 2002 Compelling action starts with the R2 outgoing end transmitting the country code indicator. The MG compels the country code digits and collects them till a match is found with one of the entries in its provisioned database. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- -----------> "Country Code Indicator, no echo suppressor required" <----------- "send next digit" -----------> "Country code (first digit)=9" <----------- "send next digit" -----------> "Country code (last digit)=1" /*------------------------------------------------------------------- MG solicits the language/discriminating digit information from the R2 end, as per compelling action defined in the MG. ------------------------------------------------------------------- */ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- <----------- "send language or discriminating digit" -----------> "discriminating digit=0" /*---------------------------------------------------------------- The MG solicits the called party number information from the R2 end, as per compelling action defined in the MG. ------------------------------------------------------------------- */ <----------- Laha et al Informational [Page 15] INTERNET DRAFT MGCP R2 CAS Package October 2002 "send next (called party number) digit" -----------> "Called party no. (1st digit)=0" <----------- "send next digit" -----------> "Called party no. (next digit)=0" <----------- "send next digit" { Remaining Called party number exchanged through compelling } -----------> "Called party no. (last digit)=6" /*---------------------------------------------------------------- MG solicits the calling party category information from the R2 end, as per compelling action defined in the MG. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- <----------- "send calling party category" -----------> "Calling party category = Non priority subscriber" /*---------------------------------------------------------------- The MG solicits the calling party number information from the R2 end, as per compelling action defined in the MG. ----------------------------------------------------------------*/ <----------- "send calling party number " -----------> "Calling party no. (1st digit)=6" <----------- Laha et al Informational [Page 16] INTERNET DRAFT MGCP R2 CAS Package October 2002 "send next (calling party number)digit" -----------> "Calling party no. (next digit)=8" <----------- "send next (calling party number)digit" { Remaining Called party number exchanged through compelling } -----------> "Calling party no. (last digit)=7" /*---------------------------------------------------------------- MG has no further address parameters to compel. The "r2a" event is reported to MGC with all collected address values as parameters. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- ------------> NTFY O: r2/r2a (es="NRQ", cc="91", ds="DISC", dn="00...6", sc="NP", sn="68...7") /*---------------------------------------------------------------- MGC has set the "subscriber line status flag" to "wait" so that MG waits for subscriber line status information signaled from the MGC, before terminating the compelling action. MG sends a dummy backward signal to complete the compelling sequence soliciting further digits. R2 outgoing end has no further digits to send. ----------------------------------------------------------------*/ <----------- "send next digit" /*---------------------------------------------------------------- Based on the received address information, MGC routes the call. However the subscriber line status is not known to MGC and the same information is signaled to MG. ----------------------------------------------------------------*/ <----------- RQNT Laha et al Informational [Page 17] INTERNET DRAFT MGCP R2 CAS Package October 2002 S: r2/sls(nk) /*---------------------------------------------------------------- MG terminates the compelling sequence by signaling the R2 end to set up the speech path (pulsed signal). R2 registers are deallocated at both ends} ----------------------------------------------------------------*/ <----------- "address complete, setup speechpath" /*---------------------------------------------------------------- Compelling action ends. Called Subscriber answers. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- <----------- RQNT S: r2/ans <----------- "answer" ================================================================ Media ================================================================ /*---------------------------------------------------------------- Outgoing R2 end clears the call. ----------------------------------------------------------------*/ -----------> "clear forward" -----------> NTFY O: r2/cf /*---------------------------------------------------------------- MG executes the release guard sequence locally. ----------------------------------------------------------------*/ <----------- "released" /*---------------------------------------------------------------- MGC brings back the endpoint to default state. ----------------------------------------------------------------*/ <----------- RQNT R: r2/sz,r2/r2a, Laha et al Informational [Page 18] INTERNET DRAFT MGCP R2 CAS Package October 2002 r2/r2f 6.4. Call flows for Outgoing Call A digital trunk type is assumed at the physical interface level. The ladder diagrams attempt to capture the typical usage of the package signals and events and they are indicative in nature. Here the MG is behaving as an outgoing end and the MG and MGC are assumed to be placed such that they together form the first outgoing R2 register in the signaling path beyond which R2 call signaling protocols start. --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- < --------- RQNT S: r2/sup(...) R: r2/or/r2/r2f,r2/sls <----------- "seizing" -----------> "seizure acknowledged" /*---------------------------------------------------------------- Compelling action starts with outgoing MG transmitting the Country Code indicator and the R2 end compelling the rest of the country code digits. ---------------------------------------------------------------*/ <----------- "Country Code Indicator, no echo suppressor required" -----------> "send next digit" <----------- "Country code (first digit)=9" -----------> "send next digit" <----------- "Country code (last digit)=1" Laha et al Informational [Page 19] INTERNET DRAFT MGCP R2 CAS Package October 2002 /*--------------------------------------------------------------- R2 end solicits the language/discriminating digit information from the MG. -----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- -----------> "send language or discriminating digit" <----------- "discriminating digit=0" /*---------------------------------------------------------------- R2 end solicits the called party number information from the MG. ---------------------------------------------------------------*/ -----------> "send next (called party number) digit" <----------- "Called party no. (1st digit)=0" -----------> "send next digit" <----------- "Called party no. (next digit)=0" -----------> "send next digit" { Remaining Called party number exchanged through compelling } <----------- "Called party no. (last digit)=6" /*---------------------------------------------------------------- R2 end solicits the calling party category information from the MG. ----------------------------------------------------------------*/ -----------> "send calling party category" Laha et al Informational [Page 20] INTERNET DRAFT MGCP R2 CAS Package October 2002 <----------- "Calling party category = Non priority subscriber" /*---------------------------------------------------------------- R2 end solicits the calling party number information from the MG. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- -----------> "send calling party number " <----------- "Calling party no. (1st digit)=6" -----------> "send next (calling party number)digit" <----------- "Calling party no. (next digit)=8" -----------> "send next (calling party number)digit" { Remaining Called party number exchanged through compelling } <----------- "Calling party no. (last digit)=7" /*---------------------------------------------------------------- R2 end terminates the compelling sequence by signaling the MG with the called destination status. R2 registers are deallocated at both ends. ----------------------------------------------------------------*/ ----------> "address complete, wait for called destination status" Laha et al Informational [Page 21] INTERNET DRAFT MGCP R2 CAS Package October 2002 --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- <----------- "Calling party category = Non priority subscriber" ----------> "subscriber line free, charge" -----------> Notify O: r2/sls(SLFC) /*---------------------------------------------------------------- MGC sets events for having answer reported. ----------------------------------------------------------------*/ <----------- RQNT Q: loop R: r2/ans,r2/r2f,r2/cb /*---------------------------------------------------------------- R2 end sends answer signal to MG. MG reports answer event to MGC. ----------------------------------------------------------------*/ -----------> "answer" -----------> NTFY O: r2/ans ================================================================ Media ================================================================ /*---------------------------------------------------------------- Incoming R2 end clears the call. ----------------------------------------------------------------*/ -----------> "clear back" -----------> NTFY O: r2/cb /*---------------------------------------------------------------- MGC brings the termination back to default handling. ----------------------------------------------------------------*/ --------------------------------------------------------------- R2 MG MGC --------------------------------------------------------------- Laha et al Informational [Page 22] INTERNET DRAFT MGCP R2 CAS Package October 2002 <----------- RQNT S: r2/cf R: r2/sz,r2/r2f,r2/r2a /*---------------------------------------------------------------- MG executes the release guard sequence locally. ----------------------------------------------------------------*/ <----------- "clear forward" -----------> "released" 7. References [1] Specifications of Signaling System R2, Q.400 to Q.490, Blue Book, CCITT [2] Arango et al, Media Gateway Control Protocol (MGCP)Version 1.0bis, draft-andreasen-mgcp-rfc2705bis-01.txt 8. Author's Addresses Kushanava Laha Hughes Software Systems, Ltd. Gurgaon,Haryana,India. 122015. Ph: (91)-11-6346666.Ext-2226 Email: klaha@hss.hns.com. Vikram Nair Hughes Software Systems, Ltd. Gurgaon,Haryana,India. 122015. Ph: (91)-11-6346666.Ex-2349 Email: vnair@hss.hns.com Bill Foster Email: bfoster@cisco.com 9. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published Laha et al Informational [Page 23] INTERNET DRAFT MGCP R2 CAS Package October 2002 and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Laha et al Informational [Page 24]