tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 2885

 
 
 

Megaco Protocol version 0.8

Part 6 of 6, p. 125 to 170
Prev RFC Part

 


prevText      Top      Up      ToC       Page 125 
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

Top      Up      ToC       Page 126 
   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

Top      Up      ToC       Page 127 
   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

Top      Up      ToC       Page 128 
       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

Top      Up      ToC       Page 129 
   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

Top      Up      ToC       Page 130 
   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.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.

Top      Up      ToC       Page 131 
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.

Top      Up      ToC       Page 132 
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.

Top      Up      ToC       Page 133 
   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

Top      Up      ToC       Page 134 
   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)

Top      Up      ToC       Page 135 
   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

   None

E.2.3 Signals

   None

E.2.4 Statistics

   None

E.2.5 Procedures

   None

E.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

Top      Up      ToC       Page 136 
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

Top      Up      ToC       Page 137 
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

   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

Top      Up      ToC       Page 138 
        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

Top      Up      ToC       Page 139 
   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

Top      Up      ToC       Page 140 
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

   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.

Top      Up      ToC       Page 141 
                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.

Top      Up      ToC       Page 142 
                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)

Top      Up      ToC       Page 143 
        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.

Top      Up      ToC       Page 144 
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)

Top      Up      ToC       Page 145 
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 (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

   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

Top      Up      ToC       Page 146 
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 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

Top      Up      ToC       Page 147 
   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

Top      Up      ToC       Page 148 
        -------
        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.

Top      Up      ToC       Page 149 
   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.

Top      Up      ToC       Page 150 
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 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.

Top      Up      ToC       Page 151 
   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)

Top      Up      ToC       Page 152 
        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

Top      Up      ToC       Page 153 
   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) [RFC 1889].

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)

Top      Up      ToC       Page 154 
   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

   none

E.13 TDM Circuit Package

   PackageID: tdmc (0x000d)
   Version: 1
   Extends: Network Package version 1

   This package is used to support TDM circuit terminations.

Top      Up      ToC       Page 155 
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/write

E.13.2 Events

   none

E.13.3 Signals

   none

Top      Up      ToC       Page 156 
E.13.4 Statistics

   None

E.13.5 Procedures

   None

Top      Up      ToC       Page 157 
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#R

A.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.

Top      Up      ToC       Page 158 
   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 $

Top      Up      ToC       Page 159 
   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}}

Top      Up      ToC       Page 160 
      }
   }

   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 {

Top      Up      ToC       Page 161 
            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
                     }
                }
             }
          }
       }
   }

Top      Up      ToC       Page 162 
   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
                    },

Top      Up      ToC       Page 163 
                    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 {

Top      Up      ToC       Page 164 
         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 {

Top      Up      ToC       Page 165 
      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
   }}

Top      Up      ToC       Page 166 
      }
   }

   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 {

Top      Up      ToC       Page 167 
             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,

Top      Up      ToC       Page 168 
                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

Top      Up      ToC       Page 169 
   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

Top      Up      ToC       Page 170 
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.