| NCI | 9022 | 1 OCTET | Nature of Connection |
| | | | Indicators |
| Reference: ITU Recommendation Q.763 |
| Bits 8 7 6 5 4 3 2 1 |
| |
| Bits 2 1 Satellite Indicator |
| 0 0 no satellite circuit in the connection |
| 0 1 one satellite circuit in the connection |
| 1 0 two satellite circuits in the connection |
| 1 1 spare
| |
| Bits 4 3 Continuity check indicator |
| 0 0 continuity check not required |
| 0 1 continuity check required on this circuit |
| 1 0 continuity check performed on a previous circuit |
| 1 1 spare |
| |
| Bits 5 Echo control device indicator |
| 0 outgoing echo control device not included |
| 1 outgoing echo control device included |
| |
| Bits 8 7 6 Spare |
+--------------------------------------------------------------------+
C.10 AAL5 Properties
+----------------+---------+-----------------+-----------------------+
| PropertyID | Property| Type | Value |
| | Tag | | |
+----------------+---------+-----------------+-----------------------+
| FMSDU | A001 | 32 bit integer | Forward Maximum CPCS-|
| | | | SDU Size: |
| Reference: ITU Recommendation Q.2931 |
| Maximum CPCS-SDU size sent in the direction from the calling |
| user to the called user. |
+----------------+---------+-----------------+-----------------------+
| BMSDU | A002 | 32 bit integer | Backwards Maximum |
| | | | CPCS-SDU Size |
| Reference: ITU Recommendation Q.2931 |
| Maximum CPCS-SDU size sent in the direction from the called user|
| to the calling user. |
+----------------+---------+-----------------+-----------------------+
| SSCS | See | See table C.7 | See table C.7 |
| | table | | |
| | C.7 | | |
| Additional values: |
| VPI/VCI |
+--------------------------------------------------------------------+
C.11 SDP Equivalents
+----------------+---------+-----------------+-----------------------+
| PropertyID | Property| Type | Value |
| | Tag | | |
+----------------+---------+-----------------+-----------------------+
| SDP_V | B001 | STRING | Protocol Version |
+----------------+---------+-----------------+-----------------------+
| SDP_O | B002 | STRING | Owner/creator and |
| | | | session ID |
+----------------+---------+-----------------+-----------------------+
| SDP_S | B003 | STRING | Sesson name |
+----------------+---------+-----------------+-----------------------+
| SDP_I | B004 | STRING | Session identifier |
+----------------+---------+-----------------+-----------------------+
| SDP_U | B005 | STRING | URI of descriptor |
+----------------+---------+-----------------+-----------------------+
| SDC_E | B006 | STRING | email address |
+----------------+---------+-----------------+-----------------------+
| SDP_P | B007 | STRING | phone number |
+----------------+---------+-----------------+-----------------------+
| SDP_C | B008 | STRING | Connection information|
+----------------+---------+-----------------+-----------------------+
| SDP_B | B009 | STRING | Bandwidth Information |
+----------------+---------+-----------------+-----------------------+
| SDP_Z | B00A | STRING | time zone adjustment |
+----------------+---------+-----------------+-----------------------+
| SDP_K | B00B | STRING | Encryption Key |
+----------------+---------+-----------------+-----------------------+
| SDP_A | B00C | STRING | Zero or more session |
+----------------+---------+-----------------+-----------------------+
| SDP_T | B00D | STRING | Active Session Time |
+----------------+---------+-----------------+-----------------------+
| SDP_R | B00E | STRING | Zero or more repeat |
+----------------+---------+-----------------+-----------------------+
| |
| Reference in all cases: IETF RFC2327, "Session Description |
| Protocol" |
+--------------------------------------------------------------------+
C.12 H.245
+----------------+---------+--------------+--------------------------+
| PropertyID | Property| Type | Value |
| | Tag | | |
+----------------+---------+--------------+--------------------------+
| OLC | C001 | octet string | The value of H.245 |
| | | | OpenLogicalChannel |
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| OLCack | C002 | octet string | The value of H.245 |
| | | | OpenLogicalChannelAck |
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| OLCcnf | C003 | octet string | The value of H.245 |
| | | | OpenLogicalChannelConfirm|
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| OLCrej | C004 | octet string | The value of H.245 |
| | | | OpenLogicalChannelReject |
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| CLC | C005 | octet string | The value of H.245 |
| | | | CloseLogicalChannel |
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| CLCack | C006 | octet string | The value of H.245 |
| | | | CloseLogicalChannelAck |
| | | | structure. |
+----------------+---------+--------------+--------------------------+
| Reference in all cases: ITU-T Recommendation H.245 |
+----------------+---------+--------------+--------------------------+
ANNEX D TRANSPORT OVER IP (NORMATIVE)
D.1 Transport over IP/UDP using Application Level Framing
Protocol messages defined in this document may be transmitted over
UDP. When no port is provided by the peer (see section 7.2.8),
commands should be sent to the default port number, 2944 for text-
encoded operation or 2945 for binary-encoded operation. Responses
must be sent to the address and port from which the corresponding
commands were sent.
Implementors using IP/UDP with ALF should be aware of the
restrictions of the MTU on the maximum message size.
D.1.1 Providing At-Most-Once Functionality
Messages, being carried over UDP, may be subject to losses. In the
absence of a timely response, commands are repeated. Most commands
are not idempotent. The state of the MG would become unpredictable
if, for example, Add commands were executed several times. The
transmission procedures shall thus provide an "At- Most-Once"
functionality.
Peer protocol entities are expected to keep in memory a list of the
responses that they sent to recent transactions and a list of the
transactions that are currently outstanding. The transaction
identifier of each incoming message is compared to the transaction
identifiers of the recent responses sent to the same MId. If a match
is found, the entity does not execute the transaction, but simply
repeats the response. If no match is found, the message will be
compared to the list of currently outstanding transactions. If a
match is found in that list, indicating a duplicate transaction, the
entity does not execute the transaction (see section D.1.4 for
procedures on sending TransactionPending).
The procedure uses a long timer value, noted LONG-TIMER in the
following. The timer should be set larger than the maximum duration
of a transaction, which should take into account the maximum number
of repetitions, the maximum value of the repetition timer and the
maximum propagation delay of a packet in the network. A suggested
value is 30 seconds.
The copy of the responses may be destroyed either LONG-TIMER seconds
after the response is issued, or when the entity receives a
confirmation that the response has been received, through the
"Response Acknowledgement parameter". For transactions that are
acknowledged through this parameter, the entity shall keep a copy of
the transaction-id for LONG-TIMER seconds after the response is
issued, in order to detect and ignore duplicate copies of the
transaction request that could be produced by the network.
D.1.2 Transaction identifiers and three-way handshake
D.1.2.1 Transaction identifiers
Transaction identifiers are 32 bit integer numbers. A Media Gateway
Controller may decide to use a specific number space for each of the
MGs that they manage, or to use the same number space for all MGs
that belong to some arbitrary group. MGCs may decide to share the
load of managing a large MG between several independent processes.
These processes will share the same transaction number space. There
are multiple possible implementations of this sharing, such as
having a centralized allocation of transaction identifiers, or pre-
allocating non-overlapping ranges of identifiers to different
processes. The implementations shall guarantee that unique
transaction identifiers are allocated to all transactions that
originate from a logical MGC (identical mId). MGs can simply detect
duplicate transactions by looking at the transaction identifier and
mId only.
D.1.2.2 Three-way handshake
The TransactionResponse Acknowledgement parameter can be found in
any message. It carries a set of "confirmed transaction-id ranges".
Entities may choose to delete the copies of the responses to
transactions whose id is included in "confirmed transaction-id
ranges" received in the transaction response messages. They should
silently discard further commands when the transaction-id falls
within these ranges.
The "confirmed transaction-id ranges" values shall not be used if
more than LONG-TIMER seconds have elapsed since the MG issued its
last response to that MGC, or when a MG resumes operation. In this
situation, transactions should be accepted and processed, without
any test on the transaction-id.
Messages that carry the "Transaction Response Acknowledgement"
parameter may be transmitted in any order. The entity shall retain
the "confirmed transaction-id ranges" received for LONG-TIMER
seconds.
In the binary encoding, if only the firstAck is present in a
response acknowledgement (see Annex A.2), only one transaction is
acknowledged. If both firstAck and lastAck are present, then the
range of transactions from firstAck to lastAck is acknowledged. In
the text encoding, a horizontal dash is used to indicate a range of
transactions being acknowledged (see Annex B.2).
D.1.3 Computing retransmission timers
It is the responsibility of the requesting entity to provide
suitable time outs for all outstanding transactions, and to retry
transactions when time outs have been exceeded. Furthermore, when
repeated transactions fail to be acknowledged, it is the
responsibility of the requesting entity to seek redundant services
and/or clear existing or pending connections. Implementations SHALL
ensure that the algorithm used to calculate retransmission timing
performs an exponentially increasing backoff of the retransmission
timeout for each retransmission or repetition after the first one.
The specification purposely avoids specifying any value for the
retransmission timers. These values are typically network dependent.
The retransmission timers should normally estimate the timer value
by measuring the time spent between the sending of a command and the
return of a response.
Note - One possibility is to use the algorithm implemented in TCP-
IP, which uses two variables:
* The average acknowledgement delay, AAD, estimated through an
exponentially smoothed average of the observed delays.
* The average deviation, ADEV, estimated through an exponentially
smoothed average of the absolute value of the difference between
the observed delay and the current average. The retransmission
timer, in TCP, is set to the sum of the average delay plus N times
the average deviation. The maximum value of the timer should
however be bounded for the protocol defined in this document, in
order to guarantee that no repeated packet would be received by
the gateways after LONG-TIMER seconds. A suggested maximum value
is 4 seconds.
After any retransmission, the entity SHOULD do the following:
* It should double the estimated value of the average delay, AAD
* It should compute a random value, uniformly distributed between
0.5 AAD and AAD
* It should set the retransmission timer to the sum of that random
value and N times the average deviation.
This procedure has two effects. Because it includes an exponentially
increasing component, it will automatically slow down the stream of
messages in case of congestion. Because it includes a random
component, it will break the potential synchronization between
notifications triggered by the same external event.
D.1.4 Provisional responses
Executing some transactions may require a long time. Long execution
times may interact with the timer based retransmission procedure.
This may result either in an inordinate number of retransmissions,
or in timer values that become too long to be efficient. Entities
that can predict that a transaction will require a long execution
time may send a provisional response, "Transaction Pending". They
SHOULD send this response if they receive a repetition of a
transaction that is still being executed.
Entities that receive a Transaction Pending shall switch to a
different repetition timer for repeating requests. The root
termination has a property (ProvisionalResponseTimerValue), which
can be set to the requested maximum number of milliseconds between
receipt of a command and transmission of the TransactionPending
response. Upon receipt of a final response following receipt of
provisional responses, an immediate confirmation shall be sent, and
normal repetition timers shall be used thereafter. An entity that
sends a provisional response, SHALL include the immAckRequired field
in the ensuing final response, indicating that an immediate
confirmation is expected. Receipt of a Transaction Pending after
receipt of a reply shall be ignored.
D.1.5 Repeating Requests, Responses and Acknowledgements
The protocol is organized as a set of transactions, each of which is
composed request and a response, commonly referred to as an
acknowledgement. The protocol messages, being carried over UDP, may
be subject to losses. In the absence of a timely response,
transactions are repeated. Entities are expected to keep in memory a
list of the responses that they sent to recent transactions, i.e. a
list of all the responses they sent over the last LONG-TIMER
seconds, and a list of the transactions that are currently being
executed.
The repetition mechanism is used to guard against three types of
possible errors:
* transmission errors, when for example a packet is lost due to
noise on a line or congestion in a queue;
* component failure, when for example an interface to a entity
becomes unavailable;
* entity failure, when for example an entire entity become
unavailable.
The entities should be able to derive from the past history an
estimate of the packet loss rate due to transmission errors. In a
properly configured system, this loss rate should be kept very low,
typically less than 1%. If a Media Gateway Controller or a Media
Gateway has to repeat a message more than a few times, it is very
legitimate to assume that something else than a transmission error
is occurring. For example, given a loss rate of 1%, the probability
that five consecutive transmission attempts fail is 1 in 100
billion, an event that should occur less than once every 10 days for
a Media Gateway Controller that processes 1 000 transactions per
second. (Indeed, the number of repetition that is considered
excessive should be a function of the prevailing packet loss rate.)
We should note that the "suspicion threshold", which we will call
"Max1", is normally lower than the "disconnection threshold", which
should be set to a larger value.
A classic retransmission algorithm would simply count the number of
successive repetitions, and conclude that the association is broken
after retransmitting the packet an excessive number of times
(typically between 7 and 11 times.) In order to account for the
possibility of an undetected or in-progress "failover", we modify
the classic algorithm so that if the Media Gateway receives a valid
ServiceChange message announcing a failover, it will start
transmitting outstanding commands to that new MGC. Responses to
commands are still transmitted to the source address of the command.
In order to automatically adapt to network load, this document
specifies exponentially increasing timers. If the initial timer is
set to 200 milliseconds, the loss of a fifth retransmission will be
detected after about 6 seconds. This is probably an acceptable
waiting delay to detect a failover. The repetitions should
continue after that delay not only in order to perhaps overcome a
transient connectivity problem, but also in order to allow some more
time for the execution of a failover - waiting a total delay of 30
seconds is probably acceptable.
It is, however, important that the maximum delay of retransmissions
be bounded. Prior to any retransmission, it is checked that the
time elapsed since the sending of the initial datagram is no greater
than T-MAX. If more than T-MAX time has elapsed, the MG concludes
that the MGC has failed, and it begins its recovery process. The MG
shall use a ServiceChange with ServiceChangeMethod set to
Disconnected so that the new MGC will be aware that the MG lost one
or more transactions. The value T-MAX is related to the LONG-TIMER
value: the LONG-TIMER value is obtained by adding to T-MAX the
maximum propagation delay in the network.
D.2 Using TCP
Protocol messages as defined in this document may be transmitted
over TCP. When no port is specified by the other side (see section
7.2.8), the commands should be sent to the default port. The defined
protocol has messages as the unit of transfer, while TCP is a
stream-oriented protocol. TPKT, according to RFC1006 SHALL be used
to delineate messages within the TCP stream.
In a transaction-oriented protocol, there are still ways for
transaction requests or responses to be lost. As such, it is
recommended that entities using TCP transport implement application
level timers for each request and each response, similar to those
specified for application level framing over UDP.
D.2.1 Providing the At-Most-Once functionality
Messages, being carried over TCP, are not subject to transport
losses, but loss of a transaction request or its reply may
nonetheless be noted in real implementations. In the absence of a
timely response, commands are repeated. Most commands are not
idempotent. The state of the MG would become unpredictable if, for
example, Add commands were executed several times.
To guard against such losses, it is recommended that entities follow
the procedures in section D.1.1
D.2.2 Transaction identifiers and three way handshake
For the same reasons, it is possible that transaction replies may be
lost even with a reliable delivery protocol such as TCP. It is
recommended that entities follow the procedures in section D.1.2.2.
D.2.3 Computing retransmission timers
With reliable delivery, the incidence of loss of a transaction
request or reply is expected to be very low. Therefore, only simple
timer mechanisms are required. Exponential back-off algorithms
should not be necessary, although they could be employed where, as
in an MGC, the code to do so is already required, since MGCs must
implement ALF/UDP as well as TCP.
D.2.4 Provisional responses
As with UDP, executing some transactions may require a long time.
Entities that can predict that a transaction will require a long
execution time may send a provisional response, "Transaction
Pending". They should send this response if they receive a
repetition of a transaction that is still being executed.
Entities that receive a Transaction Pending shall switch to a longer
repetition timer for that transaction.
Entities shall retain Transactions and replies until they are
confirmed. The basic procedure of section D.1.4 should be followed,
but simple timer values should be sufficient. There is no need to
send an immediate confirmation upon receipt of a final response.
D.2.5 Ordering of commands
TCP provides ordered delivery of transactions. No special
procedures are required. It should be noted that ALF/UDP allows
sending entity to modify its behavior under congestion, and in
particular, could reorder transactions when congestion is
encountered. TCP could not achieve the same results.
ANNEX E BASIC PACKAGES (NORMATIVE)
This Annex contains definitions of some packages for use with the
Megaco protocol.
E.1 Generic
PackageID: g (0x0001)
Version: 1
Extends: None
Description: Generic package for commonly encountered items.
E.1.1 Properties
None
E.1.2 Events
Cause
-----
EventID: cause (0x0001)
Generic error event
ObservedEvents Descriptor Parameters:
General Cause
-------------
ParameterID: Generalcause (0x0001)
Description: This parameter groups the failures into six
groups, which the MGC may act upon.
Possible values: Enumerated,
"NR" Normal Release (0x0001)
"UR" Unavailable Resources (0x0002)
"FT" Failure, Temporary (0x0003)
"FP" Failure, Permanent (0x0004)
"IW" Interworking Error (0x0005)
"UN" Unsupported (0x0006)
Failure Cause
-------------
ParameterID: Failurecause (0x0002)
Description: The Release Cause is the value generated by the
Released equipment, i.e. a released network connection.
The concerned value is defined in the appropriate bearer
control protocol.
Possible Values: OCTET STRING
Signal Completion
-----------------
EventID: sc (0x0002)
Indicates termination of one or more signals for which the
notifyCompletion parameter was set to "ON". For further procedural
description, see sections 7.1.11, 7.1.17, and 7.2.7.
ObservedEvents Descriptor parameters:
Signal Identity
---------------
ParameterID: SigID (0x0001)
This parameter identifies the signals which have terminated.
Type: list
Possible values: a list of signals and/or sequential signal
lists which have terminated. A signal outside of a sequential
signal list shall be identified using the pkgdName syntax
without wildcarding. An individual signal inside of a
sequential signal list shall be identified using the sequential
signal list syntax with the correct signal list identifier,
enclosing the name of the specific signal which terminated in
pkgdName syntax.
Termination Method
------------------
ParameterID: Meth (0x0002)
Indicates the means by which the signal terminated.
Type: enumeration
Possible values:
"TO" (0x0001) Duration expired
"EV" (0x0002) Interrupted by event
"SD" (0x0003) Halted by new Signals Descriptor
"NC" (0x0004) Not completed, other cause
E.1.3 Signals
None
E.1.4 Statistics
None
E.2 Base Root Package
Base Root Package
PackageID: root (0x0002)
Version: 1
Extends: None
Description: This package defines Gateway wide properties.
E.2.1 Properties
MaxNrOfContexts
---------------
PropertyID: maxNumberOfContexts (0x0001)
The value of this property gives the maximum number of contexts that
can exist at any time. The NULL context is not included in this
number.
Type: Double
Possible values: 1 and up
Defined in: TerminationState
MaxTerminationsPerContext
-------------------------
PropertyID: maxTerminationsPerContext (0x0002)
The maximum number of allowed terminations in a context, see section
6.1
Type: Integer
Possible Values: any integer
Defined In: TerminationState
normalMGExecutionTime
---------------------
PropertyId: normalMGExecutionTime (0x0003)
Settable by the MGC to indicate the interval within which the MGC
expects a response to any transaction from the MG (exclusive of
network delay)
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
normalMGCExecutionTime
----------------------
PropertyId: normalMGCExecutionTime (0x0004)
Settable by the MGC to indicate the interval within which the MG
should expects a response to any transaction from the MGC (exclusive
of network delay)
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
ProvisionalResponseTimerValue
-----------------------------
PropertyId: ProvisionalResponseTimerValue (0x0005)
Indicates the time within which to expect a Pending Response if a
Transaction cannot be completed. Initially set to
normalMGExecutionTime or normalMGCExecutionTime as appropriate, plus
network delay, but may be lowered.
Type: Integer
Possible Values: any integer, represents milliseconds
Defined in: TerminationState
E.2.2 Events
None
E.2.3 Signals
None
E.2.4 Statistics
None
E.2.5 Procedures
None
E.3 Tone Generator Package
PackageID: tonegen (0x0003)
Version: 1
Extends: None
Description:
This package defines signals to generate audio tones. This package
does not specify parameter values. It is intended to be extendable.
Generally, tones are defined as an individual signal with a
parameter, ind, representing "interdigit" time delay, and a tone id
to be used with playtones. A tone id should be kept consistent with
any tone generation for the same tone. MGs are expected to be
provisioned with the characteristics of appropriate tones for the
country in which the MG is located.
E.3.1 Properties
None
E.3.2 Events
None
E.3.3 Signals
Play tone
---------
SignalID: pt (0x0001)
Plays audio tone over an audio channel
Signal Type: Brief
Duration: Provisioned
Additional Parameters:
Tone id list
------------
ParameterID: tl (0x0001)
Type: list of tone ids.
List of tones to be played in sequence. The list SHALL contain
one or more tone ids.
Inter signal duration
---------------------
ParameterID: ind (0x0002)
Type: integer.
Timeout between two consecutive tones in milliseconds
No tone ids are specified in this package. Packages that extend this
package can add possible values for tone id as well as adding
individual tone signals.
E.3.4 Statistics
None
E.3.5 Procedures
None
E.4 Tone Detection Package
PackageID: tonedet (0x0004)
Version: 1
Extends: None
This Package defines events for audio tone detection. Tones are
selected by name (tone id). MGs are expected to be provisioned with
the characteristics of appropriate tones for the country in which the
MG is located.
This package does not specify parameter values. It is intended to be
extendable.
E.4.1 Properties
None
E.4.2 Events
Start tone detected
-------------------
EventID: std, 0x0001
Detects the start of a tone. The characteristics of positive tone
detection is implementation dependent.
EventsDescriptor parameters:
Tone id list
------------
ParameterID: tl (0x0001)
Type: list of tone ids
Possible values: The only tone id defined in this package is
"wild card" which is "*" in text encoding and 0x0000 in binary.
Extensions to this package would add possible values for tone
id. If tl is "wild card", any tone id is detected.
ObservedEventsDescriptor parameters:
Tone id
--------
ParameterID: tid (0x0003)
Type: Enumeration
Possible values: "wildcard" as defined above is the only value
defined in this package. Extensions to this package would add
additional possible values for tone id.
End tone detected
-----------------
EventID: etd, 0x0002
Detects the end of a tone.
EventDescriptor parameters:
Tone id list
------------
ParameterID: tl (0x0001)
Type: enumeration or list of enumerated types
Possible values: No possible values are specified in this
package. Extensions to this package would add possible values
for tone id.
ObservedEventsDescriptor parameters:
Tone id
-------
ParameterID: tid (0x0003)
Type: Enumeration
Possible values: "wildcard" as defined above is the only value
defined in this package. Extensions to this package would add
possible values for tone id
Duration
--------
ParameterId: dur (0x0002)
Type: integer, in milliseconds
This parameter contains the duration of the tone from first
detection until it stopped.
Long tone detected
------------------
EventID: ltd, 0x0003
Detects that a tone has been playing for at least a certain amount
of time
EventDescriptor parameters:
Tone id list
------------
ParameterID: tl (0x0001)
Type: enumeration or list
Possible values: "wildcard" as defined above is the only value
defined in this package. Extensions to this package would add
possible values for tone id
Duration:
---------
ParameterID: dur (0x0002)
Type: integer, duration to test against
Possible values: any legal integer, expressed in milliseconds.
ObservedEventsDescriptor parameters:
Tone id
-------
ParameterID: tid (0x0003)
Possible values: No possible values are specified in this
package. Extensions to this package would add possible values
for tone id.
E.4.3 Signals
None
E.4.4 Statistics
None
E.4.5 Procedures
None
E.5 Basic DTMF Generator Package
PackageID: dg (0x0005)
Version: 1
Extends: tonegen version 1
This package defines the basic DTMF tones as signals and extends the
allowed values of parameter tl of playtone in tonegen.
E.5.1 Properties
None
E.5.2 Events
None
E.5.3 Signals
dtmf character 0
----------------
SignalID: d0 (0x0010)
Generate DTMF 0 tone. The physical characteristic of DTMF 0 is
defined in the gateway.
Signal Type: Brief
Duration: Provisioned
Additional Parameters:
None
Additional Values:
-----------------
d0 (0x0010) is defined as a toneid for playtone.
The other dtmf characters are specified in exactly the same way. A
table with all signal names and signal IDs is included. Note that
each dtmf character is defined as both a signal and a toneid, thus
extending the basic tone generation package. Also note that dtmf
SignalIds are different from the names used in a digit map.
+------------------+-------------------+
| Signal Name | Signal ID/tone id |
+------------------+-------------------+
| dtmf character 0 | d0 (0x0010) |
| dtmf character 1 | d1 (0x0011) |
| dtmf character 2 | d2 (0x0012) |
| dtmf character 3 | d3 (0x0013) |
| dtmf character 4 | d4 (0x0014) |
| dtmf character 5 | d5 (0x0015) |
| dtmf character 6 | d6 (0x0016) |
| dtmf character 7 | d7 (0x0017) |
| dtmf character 8 | d8 (0x0018) |
| dtmf character 9 | d9 (0x0019) |
| dtmf character * | ds (0x0020) |
| dtmf character # | do (0x0021) |
| dtmf character A | da (0x001a) |
| dtmf character B | db (0x001b) |
| dtmf character C | dc (0x001c) |
| dtmf character D | dd (0x001d) |
+------------------+-------------------+
E.5.4 Statistics
None
E.5.5 Procedures
None
E.6 DTMF detection Package
PackageID: dd (0x0006)
Version: 1
Extends: tonedet version 1
This package defines the basic DTMF tones detection. This Package
extends the possible values of tone id in the "start tone detected"
"end tone detected" and "long tone detected" events.
Additional tone id values are all tone ids described in package dg
(basic DTMF generator package).
The following table maps DTMF events to digit map symbols as
described in section 7.1.14.
+------+--------------+
| DTMF | Event Symbol |
+------+--------------+
| d0 | "0" |
| d1 | "1" |
| d2 | "2" |
| d3 | "3" |
| d4 | "4" |
| d5 | "5" |
| d6 | "6" |
| d7 | "7" |
| d8 | "8" |
| d9 | "9" |
| da | "A" or "a" |
| db | "B" or "b" |
| dc | "C" or "c" |
| dd | "D" or "d" |
| ds | "E" or "e" |
| do | "F" or "f" |
+------+--------------+
E.6.1 Properties
None
E.6.2 Events
DTMF digits
-----------
EventIds are defined with the same names as the SignalIds defined in
the table found in section E.5.3.
DigitMap Completion Event
-------------------------
EventID: ce, 0x0001
Generated when a digit map completes as described in section 7.1.14.
EventsDescriptor parameters: digit map processing is activated only
if a digit map parameter is present, specifying a digit map by name
or by value. Other parameters such as a KeepActive flag or embedded
Events or Signals Descriptors may be present.
ObservedEventsDescriptor parameters:
DigitString
-----------
ParameterID: ds (0x0001)
Type: string of digit map symbols (possibly empty) returned as
a quotedString.
Possible values: a sequence of the characters "0" through "9",
"A" through "F", and the long duration modifier "Z".
Description: the portion of the current dial string as
described in section 7.1.14 which matched part or all of an
alternative event sequence specified in the digit map.
Termination Method
------------------
ParameterID: Meth (0x0003)
Type: enumeration
Possible values:
"UM" (0x0001) Unambiguous match
"PM" (0x0002) Partial match, completion by timer
expiry or unmatched event
"FM" (0x0003) Full match, completion by timer expiry
or unmatched event
Description: indicates the reason for generation of the event.
See the procedures in section 7.1.14.
E.6.3 Signals
None
E.6.4 Statistics
None
E.6.5 Procedures
None
E.7 Call Progress Tones Generator Package
PackageID: cg, 0x0007
Version: 1
Extends: tonegen version 1
This package defines the basic call progress tones as signals and
extends the allowed values of the tl parameter of playtone in tonegen
.
E.7.1 Properties
None
E.7.2 Events
None
E.7.3 Signals
Dial Tone
---------
SignaID: dt (0x0030)
Generate dial tone. The physical characteristic of dial tone is
available in the gateway.
Signal Type: Timeout
Duration: Provisioned
Additional Parameters:
None
Additional Values
-----------------
dt (0x0030) is defined as a tone id for playtone
The other tones of this package are defined in exactly the same way.
A table with all signal names and signal IDs is included. Note
that each tone is defined as both a signal and a toneid, thus
extending the basic tone generation package.
+---------------------------+-------------------+
| Signal Name | Signal ID/tone id |
+---------------------------+-------------------+
| Dial Tone | dt (0x0030) |
| Ringing Tone | rt (0x0031) |
| Busy Tone | bt (0x0032) |
| Congestion Tone | ct (0x0033) |
| Special Information Tone | sit(0x0034) |
| Warning Tone | wt (0x0035) |
| Payphone Recognition Tone | pt (0x0036) |
| Call Waiting Tone | cw (0x0037) |
| Caller Waiting Tone | cr (0x0038) |
+---------------------------+-------------------+
E.7.4 Statistics
None
E.7.5 Procedures
NOTE - The required set of tone ids corresponds to those defined in
Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)].
See E.180 for definition of the meanings of these tones.
E.8 Call Progress Tones Detection Package
PackageID: cd (0x0008)
Version: 1
Extends: tonedet version 1
This package defines the basic call progress detection tones. This
Package extends the possible values of tone id in the "start tone
detected", "end tone detected" and "long tone detected" events.
Additional values
-----------------
tone id values are defined for start tone detected, end tone detected
and long tone detected with the same values as those in package cg
(call progress tones generation package).
The required set of tone ids corresponds to Recommendation E.180/Q.35
[ITU-T Recommendation E.180/Q.35 (1998)]. See Recommendation
E.180/Q.35 for definition of the meanings of these tones.
E.8.1 Properties
none
E.8.2 Events
Events are defined as in the call progress tones generator package
(cg) for the tones listed in the table of section E.7.3
E.8.3 Signals
none
E.8.4 Statistics
none
E.8.5 Procedures
none
E.9 Analog Line Supervision Package
PackageID: al, 0x0009
Version: 1
Extends: None
This package defines events and signals for an analog line.
E.9.1 Properties
None
E.9.2 Events
onhook
------
EventID: on (0x0004)
Detects handset going on hook. Whenever an events descriptor is
activated that requests monitoring for an on-hook event and the line
is already on-hook, then the MG shall behave according to the setting
of the "strict" parameter.
EventDescriptor parameters
Strict Transition
-----------------
ParameterID: strict (0x0001)
Type: enumeration
Possible values: "exact" (0x00), "state" (0x01), "failWrong"
(0x02)
"exact" means that only an actual hook state transition to on-
hook is to be recognized;
"state" means that the event is to be recognized either if the
hook state transition is detected or if the hook state is
already on-hook;
"failWrong" means that if the hook state is already on-hook,
the command fails and an error is reported.
ObservedEventsDescriptor parameters
Initial State
-------------
ParameterID: init (0x0002)
Type: Boolean
Possible values:
True means that the event was reported because the line was
already on-hook when the events descriptor containing this
event was activated;
False means that the event represents an actual state
transition to on-hook.
offhook
-------
EventID: of (0x0005)
Detects handset going off hook. Whenever an events descriptor is
activated that requests monitoring for an off-hook event and the
line is already off-hook, then the MG shall behave according to the
setting of the "strict" parameter.
EventDescriptor parameters
Strict Transition
-----------------
ParameterID: strict (0x0001)
Type: enumeration
Possible values: "exact" (0x00), "state" (0x01), "failWrong"
(0x02)
"exact" means that only an actual hook state transition to off-
hook is to be recognized;
"state" means that the event is to be recognized either if the
hook state transition is detected or if the hook state is
already off-hook;
"failWrong" means that if the hook state is already off-hook,
the command fails and an error is reported.
ObservedEventsDescriptor parameters
Initial State
-------------
ParameterID: init (0x0002)
Type: Boolean
Possible values:
True means that the event was reported because the line was
already off-hook when the events descriptor containing this
event was activated;
False means that the event represents an actual state
transition to off-hook.
flashhook
---------
EventID: fl, 0x0006
Detects handset flash. A flash occurs when an onhook is followed by
an offhook between a minimum and maximum duration.
EventDescriptor parameters
Minimum duration
----------------
ParameterID: mindur (0x0004)
Type: integer in milliseconds
Default value is provisioned
Maximum duration
----------------
ParameterID: maxdur (0x0005)
Type: integer in milliseconds
Default value is provisioned
ObservedEventsDescriptor parameters
None
E.9.3 Signals
ring
----
SignalID: ri, 0x0002
Applies ringing on the line
Signal Type: TimeOut
Duration: Provisioned
Additional Parameters:
Cadence
-------
ParameterID: cad (0x0006)
Type: list of integers representing durations of alternating on
and off segments, constituting a complete ringing cycle
starting with an on. Units in milliseconds.
Default is fixed or provisioned. Restricted function MGs may
ignore cadence values they are incapable of generating.
Frequency
---------
ParameterID: freq (0x0007)
Type: integer in Hz
Default is fixed or provisioned. Restricted function MGs may
ignore frequency values they are incapable of generating.
E.9.4 Statistics
None
E.9.5 Procedures
If the MGC sets an EventsDescriptor containing a hook state
transition event (on-hook or off-hook) with the "strict" (0x0001)
parameter set to "failWrong", and the hook state is already what the
transition implies, the execution of the command containing that
EventsDescriptor fails. The MG SHALL include error code 540
"Unexpected initial hook state" in its reponse.
E.9.6 Error Code
This package defines a new error code:
540 - Unexpected initial hook state
The procedure for use of this code is given in section E.9.5.
E.10 Basic Continuity Package
PackageID: ct (0x000a)
Version: 1
Extends: None
This package defines events and signals for continuity test. The
continuity test includes provision of either a loopback or
transceiver functionality.
E.10.1 Properties
None
E.10.2 Events
Completion
----------
EventID: cmp, 0x0005
This event detects test completion of continuity test.
EventDescriptor parameters
None
ObservedEventsDescriptor parameters
Result
------
ParameterID: res (0x0008)
Type: Enumeration
Possible values: success (0x0001), failure (0x0000)
E.10.3 Signals
Continuity test
---------------
SignalID: ct (0x0003)
Initiates sending of continuity test tone on the termination to
which it is applied.
Signal Type: TimeOut
Default value is provisioned
Additional Parameters:
None
Respond
-------
SignalID: rsp (0x0004)
The signal is used to respond to a continuity test . See section
E.10.5 for further explanation.
Signal Type: On/Off
Default duration is provisioned
Additional Parameters:
None.
E.10.4 Statistics
None
E.10.5 Procedures
When a MGC wants to initiate a continuity test, it sends a command to
the MG containing
* a signals descriptor with the ct signal, and
* an events descriptor containing the cmp event.
Upon reception of a command containing the ct signal and cmp event,
the MG initiates the continuity test tone for the specified
termination. If the return tone is detected and any other required
conditions are satisfied before the signal times out, the cmp event
shall be generated with the value of the result parameter equal to
success. In all other cases, the cmp event shall be generated with
the value of the result parameter equal to failure.
When a MGC wants the MG to respond to a continuity test, it sends a
command to the MG containing a signals descriptor with the rsp
signal. Upon reception of a command with the rsp signal, the MG
either applies a loopback or (for 2-wire circuits) awaits reception
of a continuity test tone. In the loopback case, any incoming
information shall be reflected back as outgoing information. In the
2-wire case, any time the appropriate test tone is received, the
appropriate response tone should be sent. The MGC determines when to
remove the rsp signal.
When a continuity test is performed on a termination, no echo devices
or codecs shall be active on that termination.
Performing voice path assurance as part of continuity testing is
provisioned by bilateral agreement between network operators.
E.11 Network Package
PackageID: nt (0x000b)
Version: 1
Extends: None
This package defines properties of network terminations independent
of network type.
E.11.1 Properties
Maximum Jitter Buffer
---------------------
PropertyID: jit (0x0007)
This property puts a maximum size on the jitter buffer.
Type: integer in milliseconds
Possible Values: This property is specified in milliseconds.
Defined In: LocalControlDescriptor
Characteristics: read/write
E.11.2 Events
network failure
---------------
EventID: netfail, 0x0005
The termination generates this event upon detection of a failure due
to external or internal network reasons.
EventDescriptor parameters
None
ObservedEventsDescriptor parameters
cause
-----
ParameterID: cs (0x0001)
Type: String
Possible values: any text string
This parameter may be included with the failure event to provide
diagnostic information on the reason of failure.
quality alert
-------------
EventID: qualert, 0x0006
This property allows the MG to indicate a loss of quality of the
network connection. The MG may do this by measuring packet loss,
interarrival jitter, propogation delay and then indicating this using
a percentage of quality loss.
EventDescriptor parameters
Threshold
---------
ParameterId: th (0x0001)
Type: integer
Possible Values: threshold for percent of quality loss
measured, calculated based on a provisioned method, that could
take into consideration packet loss, jitter, and delay for
example. Event is triggered when calculation exceeds the
threshold.
ObservedEventsDescriptor parameters
Threshold
---------
ParameterId: th (0x0001)
Type: integer
Possible Values: percent of quality loss measured, calculated
based on a provisioned method, that could take into
consideration packet loss, jitter, and delay for example.
E.11.3 Signals
none
E.11.4 Statistics
Duration
--------
StatisticsID: dur (0x0001)
Description: Provides duration of time the termination has been in
the context.
Type: Double, in milliseconds
Octets Sent
-----------
StatisticID: os (0x0002)
Type: double
Possible Values: any 64 bit integer
Octets Received
---------------
StatisticID: or (0x0003)
Type: double
Possible Values: any 64 bit integer
E.11.5 Procedures
none
E.12 RTP Package
PackageID: rtp (0x000c)
Version: 1
Extends: Network Package version 1
This package is used to support packet based multimedia data transfer
by means of the Real-time Transport Protocol (RTP) [RFC1889].
E.12.1 Properties
None
E.12.2 Events
Payload Transition
EventID: pltrans, 0x0001
This event detects and notifies when there is a transition of the
RTP payload format from one format to another.
EventDescriptor parameters
None
ObservedEventsDescriptor parameters
rtppayload
----------
ParameterID: rtppltype, 0x01
Type: list of enumerated types.
Possible values: The encoding method shall be specified by
using one or several valid encoding names, as defined in the
RTP AV Profile or registered with IANA.
E.12.3 Signals
None
E.12.4 Statistics
Packets Sent
------------
StatisticID: ps (0x0004)
Type: double
Possible Values: any 64 bit integer
Packets Received
----------------
StatisticID: pr (0x0005)
Type: double
Possible Values: any 64 bit integer
Packet Loss
-----------
StatisticID: pl (0x0006)
Describes the current rate of packet loss on an RTP stream, as
defined in IETF RFC1889. Packet loss is expressed as percentage
value: number of packets lost in the interval between two reception
reports, divided by the number of packets expected during that