RFC 2885
Megaco Protocol version 0.8
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 except if the response is to a handoff or failover, in which case the procedures of 11.5 apply. 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 8.2.3 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" receivedfor 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. 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".
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, an immediate
confirmation shall be sent, and normal repetition timers shall be
used thereafter. 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. When the MG establishes a new control association, it can retransmit to the new MGC. Alternatively, a MG may use a ServiceChange with ServiceChangeMethod equal to disconnected to inform the new MGC 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.1D.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
This Annex contains definitions of some packages for use with the Megaco protocol.E.1 Generic
PackageID: g (0x000e) Version: 1 Extends: None Description: Generic package for commonly encountered items.
E.1.1 Properties
NoneE.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 (0x000f)
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 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 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 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.E.2.2 Events
NoneE.2.3 Signals
NoneE.2.4 Statistics
NoneE.2.5 Procedures
NoneE.3 Tone Generator Package
PackageID: tonegen (0x0001) 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
NoneE.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
NoneE.3.5 Procedures
None
E.4 Tone Detection Package
PackageID: tonedet (0x0002) 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
NoneE.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 (0x0003) 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
NoneE.5.2 Events
NoneE.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 (0x0004)
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 "L".
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, 0x0005
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
NoneE.7.2 Events
NoneE.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
NoneE.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 (0x0006) 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
noneE.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.3E.8.3 Signals
noneE.8.4 Statistics
none
E.8.5 Procedures
noneE.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
NoneE.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 immediately generate an on-hook event. EventDescriptor parameters None ObservedEventsDescriptor parameters None 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 immediately generate an off- hook event. EventDescriptor parameters None
ObservedEventsDescriptor parameters
None
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
None
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: TimeOut
Default duration is provisioned
Additional Parameters:
None.
E.10.4 Statistics
NoneE.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 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 awaits reception of the continuity test tone. When the tone is received before the rsp signal times out, the MG returns the applicable return tone. If the rsp signal times out, the MG removes the detection and the return tone (if that was playing). 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/writeE.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 integerE.11.5 Procedures
noneE.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) [RFC 1889].E.12.1 Properties
NoneE.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
NoneE.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 RFC 1889. 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 interval. Type: double Possible Values: a 32 bit whole number and a 32 bit fraction. Jitter ------ StatisticID: jit (0x0007) Requests the current value of the interarrival jitter on an RTP stream as defined in IETF RFC 1889. Jitter measures the variation in interarrival time for RTP data packets. Delay ----- StatisticID:delay (0x0008) Requests the current value of packet propagation delay expressed in timestamp units. Same as average latency.E.12.5 Procedures
noneE.13 TDM Circuit Package
PackageID: tdmc (0x000d) Version: 1 Extends: Network Package version 1 This package is used to support TDM circuit terminations.
E.13.1 Properties
Echo Cancellation ----------------- PropertyID: ec (0x0008) By default, the telephony gateways always perform echo cancellation. However, it is necessary, for some calls, to turn off these operations. Type: boolean Possible Values: "on" (when the echo cancellation is requested) and "off" (when it is turned off.) The default is "on". Defined In: LocalControlDescriptor Characteristics: read/write Gain Control ------------ PropertyID: gain (0x000a) Gain control, or usage of of signal level adaptation and noise level reduction is used to adapt the level of the signal. However, it is necessary, for example for modem calls, to turn off this function. Type: enumeration (integer) Possible Values: The gain control parameter may either be specified as "automatic" (0xffffffff), or as an explicit number of decibels of gain (any other integer value). The default is provisioned in the MG. Defined In: LocalControlDescriptor Characteristics: read/writeE.13.2 Events
noneE.13.3 Signals
none
E.13.4 Statistics
NoneE.13.5 Procedures
None
APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE)
All Megaco implementors must read the normative part of this document carefully before implementing from it. No one should use the examples in this section as stand-alone explanations of how to create protocol messages. The examples in this section use SDP for encoding of the Local and Remote stream descriptors. SDP is defined in RFC 2327. If there is any discrepancy between the SDP in the examples, and RFC 2327, the RFC should be consulted for correctness. Audio profiles used are those defined in RFC 1890, and others registered with IANA. For example, G.711 A-law is called PCMA in the SDP, and is assigned profile 0. G.723 is profile 4, and H263 is profile 34. See also http://www.iana.org/numbers.htm#RA.1 Residential Gateway to Residential Gateway Call
This example scenario illustrates the use of the elements of the protocol to set up a Residential Gateway to Residential Gateway call over an IP-based network. For simplicity, this example assumes that both Residential Gateways involved in the call are controlled by the same Media Gateway Controller.A.1.1 Programming Residential GW Analog Line Terminations for Idle Behavior
The following illustrates the API invocations from the Media Gateway Controller and Media Gateways to get the Terminations in this scenario programmed for idle behavior. Both the originating and terminating Media Gateways have idle AnalogLine Terminations programmed to look for call initiation events (i.e.-offhook) by using the Modify Command with the appropriate parameters. The null Context is used to indicate that the Terminations are not yet involved in a Context. The ROOT termination is used to indicate the entire MG instead of a termination within the MG.
In this example, MG1 has the IP address 124.124.124.222, MG2 is
125.125.125.111, and the MGC is 123.123.123.4. The default Megaco
port is 55555 for all three.
1. An MG registers with an MGC using the ServiceChange command:
MG1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart,
ServiceChangeAddress=55555, Profile=ResGW/1}
}
}
}
2. The MGC sends a reply:
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
}
3. The MGC programs a Termination in the NULL context. The
terminationId is A4444, the streamId is 1, the requestId in the
Events descriptor is 2222. The mId is the identifier of the sender
of this message, in this case, it is the IP address and port
[123.123.123.4]:55555. Mode for this stream is set to SendReceive.
"al" is the analog line supervision package.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 9999 {
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = SendReceive,
ds0/gain=2, ; in dB,
ds0/ec=G165
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
; detection algorithm
}
}
},
Events = 2222 {al/of}
}
}
}
The dialplan script could have been loaded into the MG previously.
Its function would be to wait for the OffHook, turn on dialtone and
start collecting DTMF digits. However in this example, we use the
digit map, which is put into place after the offhook is detected
(step 5 below).
Note that the embedded EventsDescriptor could have been used to
combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
4. The MG1 accepts the Modify with this reply:
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 9999 {
Context = - {Modify = A4444}
}
5. A similar exchange happens between MG2 and the MGC, resulting in
an idle Termination called A5555.
A.1.2 Collecting Originator Digits and Initiating Termination
The following builds upon the previously shown conditions. It
illustrates the transactions from the Media Gateway Controller and
originating Media Gateway (MG1) to get the originating Termination
(A4444) through the stages of digit collection required to initiate a
connection to the terminating Media Gateway (MG2).
6. MG1 detects an offhook event from User 1 and reports it to the
Media Gateway Controller via the Notify Command.
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Transaction = 10000 {
Context = - {
Notify = A4444 {ObservedEvents =2222 {
19990729T22000000:al/of}}
}
}
7. And the Notify is acknowledged.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 10000 {
Context = - {Notify = A4444}
}
8. The MGC Modifies the termination to play dial tone, to look for
digits according to Dialplan0 and to look for the on-hook event now.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10001 {
Context = - {
Modify = A4444 {
Events = 2223 {
al/on, dd/ce {DigitMap=Dialplan0}
},
Signals {cg/dt},
DigitMap= Dialplan0{
(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
}
}
}
9. And the Modify is acknowledged.
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10001 {
Context = - {Modify = A4444}
}
10. Next, digits are accumulated by MG1 as they are dialed by User
1. Dialtone is stopped upon detection of the first digit. When an
appropriate match is made of collected digits against the currently
programmed Dialplan for A4444, another Notify is sent to the Media
Gateway Controller.
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Transaction = 10002 {
Context = - {
Notify = A4444 {ObservedEvents =2223 {
19990729T22010001:dd/ce{ds="916135551212",Meth=FM}}}
}
}
11. And the Notify is acknowledged.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Reply = 10002 {
Context = - {Notify = A4444}
}
12. The controller then analyses the digits and determines that a
connection needs to be made from MG1 to MG2. Both the TDM
termination A4444, and an RTP termination are added to a new context
in MG1. Mode is ReceiveOnly since Remote descriptor values are not
yet specified. Preferred codecs are in the MGC's preferred order of
choice.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10003 {
Context = $ {
Add = A4444,
Add = $ {
Media {
Stream = 1 {
LocalControl {
Mode = ReceiveOnly,
nt/jit=40, ; in ms
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
v=0
c=IN IP4 $
m=audio $ RTP/AVP 0
}
}
}
}
}
}
NOTE - The MGC states its preferred parameter values as a series of
sdp blocks in Local. The MG fills in the Local Descriptor in the
Reply.
13. MG1 acknowledges the new Termination and fills in the Local IP
address and UDP port. It also makes a choice for the codec based on
the MGC preferences in Local. MG1 sets the RTP port to 2222.
MEGACO/1 [124.124.124.222]:55555
Reply = 10003 {
Context = 2000 {
Add = A4444,
Add=A4445{
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
a=recvonly
} ; RTP profile for G.723 is 4
}
}
}
}
}
14. The MGC will now associate A5555 with a new Context on MG2, and
establish an RTP Stream (i.e, A5556 will be assigned), SendReceive
connection through to the originating user, User 1. The MGC also
sets ring on A5555.
MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50003 {
Context = $ {
Add = A5555 { Media {
Stream = 1 {
LocalControl {Mode = SendReceive} }},
Events=1234{al/of}
Signals {al/ri}
},
Add = $ {Media {
Stream = 1 {
LocalControl {
Mode = SendReceive,
nt/jit=40 ; in ms
},
Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 4
a=ptime:30
},
Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
} ; RTP profile for G.723 is 4
}
}
}
}
}
15. This is acknowledged. The stream port number is different from
the control port number. In this case it is 1111 (in the SDP).
MG2 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 50003 {
Context = 5000 {
Add = A5555{}
Add = A5556{
Media {
Stream = 1 {
Local {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
}
} ; RTP profile for G723 is 4
}
}
}
}
16. The above IPAddr and UDPport need to be given to MG1 now.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10005 {
Context = 2000 {
Modify = A4444 {
Signals {cg/rt}
},
Modify = A4445 {
Media {
Stream = 1 {
Remote {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
}
} ; RTP profile for G723 is 4
}
}
}
}
MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10005 {
Context = 2000 {Modify = A4444, Modify = A4445}
}
17. The two gateways are now connected and User 1 hears the
RingBack. The MG2 now waits until User2 picks up the receiver and
then the two-way call is established.
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Transaction = 50005 {
Context = 5000 {
Notify = A5555 {ObservedEvents =1234 {
19990729T22020002:al/of}}
}
}
From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Reply = 50005 {
Context = - {Notify = A5555}
}
From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50006 {
Context = 5000 {
Modify = A5555 {
Events = 1235 {al/on},
Signals { } ; to turn off ringing
}
}
}
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Reply = 50006 {
Context = 5000 {Modify = A4445}
}
18. Change mode on MG1 to SendReceive, and stop the ringback.
MGC to MG1:
MEGACO/1 [123.123.123.4]:55555
Transaction = 10006 {
Context = 2000 {
Modify = A4445 {
Media {
Stream = 1 {
LocalControl {
Mode=SendReceive
}
}
}
},
Modify = A4444 {
Signals { }
}
}
}
from MG1 to MGC:
MEGACO/1 [124.124.124.222]:55555
Reply = 10006 {
Context = 2000 {Modify = A4445, Modify = A4444}}
19. The MGC decides to Audit the RTP termination on MG2.
MEGACO/1 [123.123.123.4]:55555
Transaction = 50007 {
Context = - {AuditValue = A5556{
Audit{Media, DigitMap, Events, Signals, Packages, Statistics
}}
}
}
20. The MG2 replies. An RTP termination has no events nor signals,
so these are left out in the reply .
MEGACO/1 [125.125.125.111]:55555
Reply = 50007 {
Context = - {
AuditValue = A5556 {
Media {
Stream = 1 {
LocalControl { Mode = SendReceive,
nt/jit=40 },
Local {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP 4
a=ptime:30
},
Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP 4
a=ptime:30
} } },
Packages {nt-1, rtp-1},
Statistics { rtp/ps=1200, ; packets sent
nt/os=62300, ; octets sent
rtp/pr=700, ; packets received
nt/or=45100, ; octets received
rtp/pl=0.2, ; % packet loss
rtp/jit=20,
rtp/delay=40 } ; avg latency
}
}
}
21. When the MGC receives an onhook signal from one of the MGs, it
brings down the call. In this example, the user at MG2 hangs up
first.
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Transaction = 50008 {
Context = 5000 {
Notify = A5555 {ObservedEvents =1235 {
19990729T24020002:al/on}
}
}
}
From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Reply = 50008 {
Context = - {Notify = A5555}
}
22. The MGC now sends both MGs a Subtract to take down the call.
Only the subtracts to MG2 are shown here. Each termination has its
own set of statistics that it gathers. An MGC may not need to
request both to be returned. A5555 is a physical termination, and
A5556 is an RTP termination.
From MGC to MG2:
MEGACO/1 [123.123.123.4]:55555
Transaction = 50009 {
Context = 5000 {
Subtract = A5555 {Audit{Statistics}},
Subtract = A5556 {Audit{Statistics}}
}
}
From MG2 to MGC:
MEGACO/1 [125.125.125.111]:55555
Reply = 50009 {
Context = 5000 {
Subtract = A5555 {
Statistics {
nt/os=45123, ; Octets Sent
nt/dur=40 ; in seconds
}
},
Subtract = A5556 {
Statistics {
rtp/ps=1245, ; packets sent
nt/os=62345, ; octets sent
rtp/pr=780, ; packets received
nt/or=45123, ; octets received
rtp/pl=10, ; % packets lost
rtp/jit=27,
rtp/delay=48 ; average latency
}
}
}
}
23. The MGC now sets up both MG1 and MG2 to be ready to detect the
next off-hook event. See step 1. Note that this could be the default
state of a termination in the null context, and if this were the
case, no message need be sent from the MGC to the MG. Once a
termination returns to the null context, it goes back to the default
termination values for that termination.
Authors' Addresses
Fernando Cuervo
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
E-mail: fcuervo@nortelnetworks.com
Nancy Greene
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
E-mail: ngreene@nortelnetworks.com
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
USA
E-mail: huitema@microsoft.com
Abdallah Rayhan
Nortel Networks
P.O. Box 3511, Station C
Ottawa, ON K1Y 4H7
Canada
E-mail: arayhan@nortelnetworks.com
Brian Rosen Marconi 1000 FORE Drive Warrendale, PA 15086 USA E-mail: brian.rosen@marconi.com John Segers Lucent Technologies, Room HE 303 Dept. Forward Looking Work P.O. Box 18, 1270 AA Huizen The Netherlands E-mail: jsegers@lucent.com
Full Copyright Statement Copyright (C) The Internet Society (2000). 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 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.