Internet DRAFT - draft-foster-mgcp-r2
draft-foster-mgcp-r2
Internet Engineering Task Force Kushanava Laha
Internet Draft Vikram Nair
Document: <draft-foster-mgcp-r2-00.txt> Hughes Software Systems
Category: Informational Bill Foster
Expires: April 2002 Cisco Systems
October 2001
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 2001
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 2001
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 2001
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 2001
* 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 2001
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 2001
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=<dig1><dig2> ... <dign>, where <digi>
is a digit from "0" to "9"
* Source number: sn=<dig1><dig2> ... <dign>, where <digi>
is a digit from "0" to "9"
* Caller Subscriber Category: sc=<subscriber-category> where
<subscriber-category> 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=<es-info> where <es-info>
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 2001
already been inserted
"ICRQ" - Call requires incoming echo suppressors
to be inserted
* Country Code Information: cc=<dig1>,<dig2>, ..., <dign>,
where <digi> is a digit from
"0" to "9"
* Discriminating Indicator: ds=<disc-ind>, where <disc-ind>
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=<nat-circ>, where <nat-circ>
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/r2addr(<reason>))
where <reason> 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 2001
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=<dig1><dig2> ... <dign>
* Termination Method: tm=<termination-method>
* Source number: sn=<dig1><dig2> ... <dign>
* Caller Subscriber Category: sc=<subscriber-category>
* Echo Suppression Information: es=<es-info>
* Country Code Information: cc=<dig1>,<dig2>, ..., <dign>
* Discriminating Indicator: ds=<disc-ind>
* Nature of the Circuit: nc=<nat-circ>
See the description of the "sup" signal for allowable parameter
values. The only exception is the termination method. The
<termination-method> 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=<dig1><dig2> ...
<dign>,tm=<termination-method>)
* Source number: sn(<dig1><dig2> ... <dign>)
Laha et al Informational [Page 9]
INTERNET DRAFT MGCP R2 CAS Package October 2001
* Caller Subscriber Category: sc(<subscriber-category>)
* Echo Suppression Information: es(<es-info>)
* Country Code Information: cc(<dig1>,<dig2>, ..., <dign>)
* Discriminating Indicator: ds(<disc-ind>)
* Nature of the Circuit: nc(<nat-circ>)
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 2001
O: r2/r2a(dn=<destination-number>,sn=<source-number>,...)
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=<source-number>,...)
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 2001
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/csf" 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(<destination-number>),sn(<source-number>),...)
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 2001
* a NTFY with "O: r2/csf(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 2001
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/csf" 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 2001
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 2001
"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 2001
"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 2001
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 2001
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 2001
/*---------------------------------------------------------------
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 2001
<-----------
"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 2001
---------------------------------------------------------------
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 2001
<-----------
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 (2001). 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 2001
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]
