tech-invite   World Map     

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

RFC 3015

 
 
 

Megaco Protocol Version 1.0

Part 6 of 6, p. 131 to 179
Prev RFC Part

 


prevText      Top      Up      ToC       Page 131 
ANNEX D TRANSPORT OVER IP (NORMATIVE)

D.1 Transport over IP/UDP using Application Level Framing

   Protocol messages defined in this document may be transmitted over
   UDP.  When no port is provided by the peer (see section 7.2.8),
   commands should be sent to the default port number, 2944 for text-
   encoded operation or 2945 for binary-encoded operation.  Responses
   must be sent to the address and port from which the corresponding
   commands were sent.

   Implementors using IP/UDP with ALF should be aware of the
   restrictions of the MTU on the maximum message size.

Top      Up      ToC       Page 132 
D.1.1 Providing At-Most-Once Functionality

   Messages, being carried over UDP, may be subject to losses. In the
   absence of a timely response, commands are repeated. Most commands
   are not idempotent.  The state of the MG would become unpredictable
   if, for example, Add commands were executed several times.  The
   transmission procedures shall thus provide an "At- Most-Once"
   functionality.

   Peer protocol entities are expected to keep in memory a list of the
   responses that they sent to recent transactions and a list of the
   transactions that are currently outstanding. The transaction
   identifier of each incoming message is compared to the transaction
   identifiers of the recent responses sent to the same MId. If a match
   is found, the entity does not execute the transaction, but simply
   repeats the response. If no match is found, the message will be
   compared to the list of currently outstanding transactions. If a
   match is found in that list, indicating a duplicate transaction, the
   entity does not execute the transaction (see section D.1.4 for
   procedures on sending TransactionPending).

   The procedure uses a long timer value, noted LONG-TIMER in the
   following.  The timer should be set larger than the maximum duration
   of a transaction, which should take into account the maximum number
   of repetitions, the maximum value of the repetition timer and the
   maximum propagation delay of a packet in the network.  A suggested
   value is 30 seconds.

   The copy of the responses may be destroyed either LONG-TIMER seconds
   after the response is issued, or when the entity receives a
   confirmation that the response has been received, through the
   "Response Acknowledgement parameter". For transactions that are
   acknowledged through this parameter, the entity shall keep a copy of
   the transaction-id for LONG-TIMER seconds after the response is
   issued, in order to detect and ignore duplicate copies of the
   transaction request that could be produced by the network.

D.1.2 Transaction identifiers and three-way handshake

D.1.2.1 Transaction identifiers

   Transaction identifiers are 32 bit integer numbers.  A Media Gateway
   Controller may decide to use a specific number space for each of the
   MGs that they manage, or to use the same number space for all MGs
   that belong to some arbitrary group.  MGCs may decide to share the
   load of managing a large MG between several independent processes.
   These processes will share the same transaction number space.  There
   are multiple possible implementations of this sharing, such as

Top      Up      ToC       Page 133 
   having a centralized allocation of transaction identifiers, or pre-
   allocating non-overlapping ranges of identifiers to different
   processes.  The implementations shall guarantee that unique
   transaction identifiers are allocated to all transactions that
   originate from a logical MGC (identical mId). MGs can simply detect
   duplicate transactions by looking at the transaction identifier and
   mId only.

D.1.2.2 Three-way handshake

   The TransactionResponse Acknowledgement parameter can be found in
   any message. It carries a set of "confirmed transaction-id ranges".
   Entities may choose to delete the copies of the responses to
   transactions whose id is included in "confirmed transaction-id
   ranges" received in the transaction response messages. They should
   silently discard further commands when the transaction-id falls
   within these ranges.

   The "confirmed transaction-id ranges" values shall not be used if
   more than LONG-TIMER seconds have elapsed since the MG issued its
   last response to that MGC, or when a MG resumes operation.  In this
   situation, transactions should be accepted and processed, without
   any test on the transaction-id.

   Messages that carry the "Transaction Response Acknowledgement"
   parameter may be transmitted in any order.  The entity shall retain
   the "confirmed transaction-id ranges" received for LONG-TIMER
   seconds.

   In the binary encoding, if only the firstAck is present in a
   response acknowledgement (see Annex A.2), only one transaction is
   acknowledged.  If both firstAck and lastAck are present, then the
   range of transactions from firstAck to lastAck is acknowledged.  In
   the text encoding, a horizontal dash is used to indicate a range of
   transactions being acknowledged (see Annex B.2).

D.1.3 Computing retransmission timers

   It is the responsibility of the requesting entity to provide
   suitable time outs for all outstanding transactions, and to retry
   transactions when time outs have been exceeded. Furthermore, when
   repeated transactions fail to be acknowledged, it is the
   responsibility of the requesting entity to seek redundant services
   and/or clear existing or pending connections.  Implementations SHALL
   ensure that the algorithm used to calculate retransmission timing
   performs an exponentially increasing backoff of the retransmission
   timeout for each retransmission or repetition after the first one.

Top      Up      ToC       Page 134 
   The specification purposely avoids specifying any value for the
   retransmission timers. These values are typically network dependent.
   The retransmission timers should normally estimate the timer value
   by measuring the time spent between the sending of a command and the
   return of a response.

   Note - One possibility is to use the algorithm implemented in TCP-
   IP, which uses two variables:

   *  The average acknowledgement delay, AAD, estimated through an
      exponentially smoothed average of the observed delays.

   *  The average deviation, ADEV, estimated through an exponentially
      smoothed average of the absolute value of the difference between
      the observed delay and the current average.  The retransmission
      timer, in TCP, is set to the sum of the average delay plus N times
      the average deviation. The maximum value of the timer should
      however be bounded for the protocol defined in this document, in
      order to guarantee that no repeated packet would be received by
      the gateways after LONG-TIMER seconds.  A suggested maximum value
      is 4 seconds.

   After any retransmission, the entity SHOULD do the following:

   *  It should double the estimated value of the average delay, AAD

   *  It should compute a random value, uniformly distributed between
      0.5 AAD and AAD

   *  It should set the retransmission timer to the sum of that random
      value and N times the average deviation.

   This procedure has two effects. Because it includes an exponentially
   increasing component, it will automatically slow down the stream of
   messages in case of congestion. Because it includes a random
   component, it will break the potential synchronization between
   notifications triggered by the same external event.

D.1.4 Provisional responses

   Executing some transactions may require a long time. Long execution
   times may interact with the timer based retransmission procedure.
   This may result either in an inordinate number of retransmissions,
   or in timer values that become too long to be efficient. Entities
   that can predict that a transaction will require a long execution
   time may send a provisional response, "Transaction Pending".  They
   SHOULD send this response if they receive a repetition of a
   transaction that is still being executed.

Top      Up      ToC       Page 135 
   Entities that receive a Transaction Pending shall switch to a
   different repetition timer for repeating requests.  The root
   termination has a property (ProvisionalResponseTimerValue), which
   can be set to the requested maximum number of milliseconds between
   receipt of a command and transmission of the TransactionPending
   response.  Upon receipt of a final response following receipt of
   provisional responses, an immediate confirmation shall be sent, and
   normal repetition timers shall be used thereafter.  An entity that
   sends a provisional response, SHALL include the immAckRequired field
   in the ensuing final response, indicating that an immediate
   confirmation is expected.  Receipt of a Transaction Pending after
   receipt of a reply shall be ignored.

D.1.5 Repeating Requests, Responses and Acknowledgements

   The protocol is organized as a set of transactions, each of which is
   composed request and a response, commonly referred to as an
   acknowledgement.  The protocol messages, being carried over UDP, may
   be subject to losses. In the absence of a timely response,
   transactions are repeated. Entities are expected to keep in memory a
   list of the responses that they sent to recent transactions, i.e. a
   list of all the responses they sent over the last LONG-TIMER
   seconds, and a list of the transactions that are currently being
   executed.

   The repetition mechanism is used to guard against three types of
   possible errors:

   *  transmission errors, when for example a packet is lost due to
      noise on a line or congestion in a queue;
   *  component failure, when for example an interface to a entity
      becomes unavailable;
   *  entity failure, when for example an entire entity become
      unavailable.

   The entities should be able to derive from the past history an
   estimate of the packet loss rate due to transmission errors.  In a
   properly configured system, this loss rate should be kept very low,
   typically less than 1%.  If a Media Gateway Controller or a Media
   Gateway has to repeat a message more than a few times, it is very
   legitimate to assume that something else than a transmission error
   is occurring.  For example, given a loss rate of 1%, the probability
   that five consecutive transmission attempts fail is 1 in 100
   billion, an event that should occur less than once every 10 days for
   a Media Gateway Controller that processes 1 000 transactions per
   second. (Indeed, the number of repetition that is considered
   excessive should be a function of the prevailing packet loss rate.)

Top      Up      ToC       Page 136 
   We should note that the "suspicion threshold", which we will call
   "Max1", is normally lower than the "disconnection threshold", which
   should be set to a larger value.

   A classic retransmission algorithm would simply count the number of
   successive repetitions, and conclude that the association is broken
   after retransmitting the packet an excessive number of times
   (typically between 7 and 11 times.) In order to account for the
   possibility of an undetected or in-progress "failover", we modify
   the classic algorithm so that if the Media Gateway receives a valid
   ServiceChange message announcing a failover, it will start
   transmitting outstanding commands to that new MGC.  Responses to
   commands are still transmitted to the source address of the command.

   In order to automatically adapt to network load, this document
   specifies exponentially increasing timers.  If the initial timer is
   set to 200 milliseconds, the loss of a fifth retransmission will be
   detected after about 6 seconds.  This is probably an acceptable
   waiting delay to detect a failover.   The repetitions should
   continue after that delay not only in order to perhaps overcome a
   transient connectivity problem, but also in order to allow some more
   time for the execution of a failover - waiting a total delay of 30
   seconds is probably acceptable.

   It is, however, important that the maximum delay of retransmissions
   be bounded.  Prior to any retransmission, it is checked that the
   time elapsed since the sending of the initial datagram is no greater
   than T-MAX. If more than T-MAX time has elapsed, the MG concludes
   that the MGC has failed, and it begins its recovery process. The MG
   shall use a ServiceChange with ServiceChangeMethod set to
   Disconnected so that the new MGC will be aware that the MG lost one
   or more transactions.  The value T-MAX is related to the LONG-TIMER
   value: the LONG-TIMER value is obtained by adding to T-MAX the
   maximum propagation delay in the network.

D.2 Using TCP

   Protocol messages as defined in this document may be transmitted
   over TCP.  When no port is specified by the other side (see section
   7.2.8), the commands should be sent to the default port. The defined
   protocol has messages as the unit of transfer, while TCP is a
   stream-oriented protocol.  TPKT, according to RFC1006 SHALL be used
   to delineate messages within the TCP stream.

   In a transaction-oriented protocol, there are still ways for
   transaction requests or responses to be lost.  As such, it is
   recommended that entities using TCP transport implement application

Top      Up      ToC       Page 137 
   level timers for each request and each response, similar to those
   specified for application level framing over UDP.

D.2.1 Providing the At-Most-Once functionality

   Messages, being carried over TCP, are not subject to transport
   losses, but loss of a transaction request or its reply may
   nonetheless be noted in real implementations. In the absence of a
   timely response, commands are repeated. Most commands are not
   idempotent.  The state of the MG would become unpredictable if, for
   example, Add commands were executed several times.

   To guard against such losses, it is recommended that entities follow
   the procedures in section D.1.1

D.2.2 Transaction identifiers and three way handshake

   For the same reasons, it is possible that transaction replies may be
   lost even with a reliable delivery protocol such as TCP.  It is
   recommended that entities follow the procedures in section D.1.2.2.

D.2.3 Computing retransmission timers

   With reliable delivery, the incidence of loss of a transaction
   request or reply is expected to be very low.  Therefore, only simple
   timer mechanisms are required. Exponential back-off algorithms
   should not be necessary, although they could be employed where, as
   in an MGC, the code to do so is already required, since MGCs must
   implement ALF/UDP as well as TCP.

D.2.4 Provisional responses

   As with UDP, executing some transactions may require a long time.
   Entities that can predict that a transaction will require a long
   execution time may send a provisional response, "Transaction
   Pending". They should send this response if they receive a
   repetition of a transaction that is still being executed.

   Entities that receive a Transaction Pending shall switch to a longer
   repetition timer for that transaction.

   Entities shall retain Transactions and replies until they are
   confirmed.  The basic procedure of section D.1.4 should be followed,
   but simple timer values should be sufficient. There is no need to
   send an immediate confirmation upon receipt of a final response.

Top      Up      ToC       Page 138 
D.2.5 Ordering of commands

   TCP provides ordered delivery of transactions.  No special
   procedures are required.  It should be noted that ALF/UDP allows
   sending entity to modify its behavior under congestion, and in
   particular, could reorder transactions when congestion is
   encountered.  TCP could not achieve the same results.

ANNEX E BASIC PACKAGES (NORMATIVE)

   This Annex contains definitions of some packages for use with the
   Megaco protocol.

E.1 Generic

   PackageID: g (0x0001)
   Version: 1
   Extends: None

   Description: Generic package for commonly encountered items.

E.1.1 Properties

   None

E.1.2 Events

   Cause
   -----
   EventID:     cause (0x0001)

   Generic error event

   ObservedEvents Descriptor Parameters:

        General Cause
        -------------
        ParameterID: Generalcause (0x0001)

        Description: This parameter groups the failures into six
        groups, which the MGC may act upon.

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

Top      Up      ToC       Page 140 
        Termination Method
        ------------------
        ParameterID:  Meth (0x0002)

        Indicates the means by which the signal terminated.

        Type: enumeration

        Possible values:
                "TO" (0x0001) Duration expired
                "EV" (0x0002) Interrupted by event
                "SD" (0x0003) Halted by new Signals Descriptor
                "NC" (0x0004) Not completed, other cause

E.1.3 Signals

   None

E.1.4 Statistics

   None

E.2 Base Root Package

   Base Root Package
   PackageID: root (0x0002)
   Version: 1
   Extends: None

   Description: This package defines Gateway wide properties.

E.2.1 Properties

   MaxNrOfContexts
   ---------------
   PropertyID: maxNumberOfContexts (0x0001)

   The value of this property gives the maximum number of contexts that
   can exist at any time.  The NULL context is not included in this
   number.

   Type: Double

   Possible values: 1 and up

   Defined in: TerminationState

Top      Up      ToC       Page 141 
   MaxTerminationsPerContext
   -------------------------
   PropertyID: maxTerminationsPerContext (0x0002)

   The maximum number of allowed terminations in a context, see section
   6.1

   Type: Integer

   Possible Values: any integer

   Defined In: TerminationState

   normalMGExecutionTime
   ---------------------
   PropertyId: normalMGExecutionTime (0x0003)

   Settable by the MGC to indicate the interval within which the MGC
   expects a response to any transaction from the MG (exclusive of
   network delay)

   Type: Integer

   Possible Values: any integer, represents milliseconds

   Defined in: TerminationState

   normalMGCExecutionTime
   ----------------------
   PropertyId: normalMGCExecutionTime (0x0004)

   Settable by the MGC to indicate the interval within which the MG
   should expects a response to any transaction from the MGC (exclusive
   of network delay)

   Type: Integer

   Possible Values: any integer, represents milliseconds

   Defined in: TerminationState

   ProvisionalResponseTimerValue
   -----------------------------
   PropertyId: ProvisionalResponseTimerValue (0x0005)

Top      Up      ToC       Page 142 
   Indicates the time within which to expect a Pending Response if a
   Transaction cannot be completed.  Initially set to
   normalMGExecutionTime or normalMGCExecutionTime as appropriate, plus
   network delay, but may be lowered.

   Type: Integer

   Possible Values: any integer, represents milliseconds

   Defined in: TerminationState

E.2.2 Events

   None

E.2.3 Signals

   None

E.2.4 Statistics

   None

E.2.5 Procedures

   None

E.3 Tone Generator Package

   PackageID: tonegen (0x0003)
   Version: 1
   Extends: None

   Description:
   This package defines signals to generate audio tones. This package
   does not specify parameter values. It is intended to be extendable.
   Generally, tones are defined as an individual signal with a
   parameter, ind, representing "interdigit" time delay, and a tone id
   to be used with playtones.  A tone id should be kept consistent with
   any tone generation for the same tone. MGs are expected to be
   provisioned with the characteristics of appropriate tones for the
   country in which the MG is located.

E.3.1 Properties

   None

Top      Up      ToC       Page 143 
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 144 
E.4 Tone Detection Package

   PackageID: tonedet (0x0004)
   Version: 1
   Extends: None

   This Package defines events for audio tone detection. Tones are
   selected by name (tone id). MGs are expected to be provisioned with
   the characteristics of appropriate tones for the country in which the
   MG is located.

   This package does not specify parameter values. It is intended to be
   extendable.

E.4.1 Properties

   None

E.4.2 Events

   Start tone detected
   -------------------
   EventID: std, 0x0001

   Detects the start of a tone. The characteristics of positive tone
   detection is implementation dependent.

   EventsDescriptor parameters:

        Tone id list
        ------------
        ParameterID: tl (0x0001)

        Type:  list of tone ids

        Possible values: The only tone id defined in this package is
        "wild card" which is "*" in text encoding and 0x0000 in binary.
        Extensions to this package would add possible values for tone
        id. If tl is "wild card", any tone id is detected.

   ObservedEventsDescriptor parameters:

        Tone id
        --------
        ParameterID: tid (0x0003)

        Type: Enumeration

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

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

Top      Up      ToC       Page 147 
E.5 Basic DTMF Generator Package

   PackageID: dg (0x0005)
   Version: 1
   Extends: tonegen version 1

   This package defines the basic DTMF tones as signals and extends the
   allowed values of parameter tl of playtone in tonegen.

E.5.1 Properties

   None

E.5.2 Events

   None

E.5.3 Signals

   dtmf character 0
   ----------------
   SignalID: d0 (0x0010)

   Generate DTMF 0 tone. The physical characteristic of DTMF 0 is
   defined in the gateway.

   Signal Type: Brief

   Duration: Provisioned

   Additional Parameters:

   None

   Additional Values:
   -----------------

   d0 (0x0010) is defined as a toneid for playtone.

   The other dtmf characters are specified in exactly the same way. A
   table with all signal names and signal IDs is included.  Note that
   each dtmf character is defined as both a signal and a toneid, thus
   extending the basic tone generation package.  Also note that dtmf
   SignalIds are different from the names used in a digit map.

Top      Up      ToC       Page 148 
         +------------------+-------------------+
         | Signal Name      | Signal ID/tone id |
         +------------------+-------------------+
         | dtmf character 0 | d0 (0x0010)       |
         | dtmf character 1 | d1 (0x0011)       |
         | dtmf character 2 | d2 (0x0012)       |
         | dtmf character 3 | d3 (0x0013)       |
         | dtmf character 4 | d4 (0x0014)       |
         | dtmf character 5 | d5 (0x0015)       |
         | dtmf character 6 | d6 (0x0016)       |
         | dtmf character 7 | d7 (0x0017)       |
         | dtmf character 8 | d8 (0x0018)       |
         | dtmf character 9 | d9 (0x0019)       |
         | dtmf character * | ds (0x0020)       |
         | dtmf character # | do (0x0021)       |
         | dtmf character A | da (0x001a)       |
         | dtmf character B | db (0x001b)       |
         | dtmf character C | dc (0x001c)       |
         | dtmf character D | dd (0x001d)       |
         +------------------+-------------------+

E.5.4 Statistics

   None

E.5.5 Procedures

   None

E.6 DTMF detection Package

   PackageID: dd (0x0006)
   Version: 1
   Extends: tonedet version 1

   This package defines the basic DTMF tones detection. This Package
   extends the possible values of tone id in the "start tone detected"
   "end tone detected" and "long tone detected" events.

   Additional tone id values are all tone ids described in package dg
   (basic DTMF generator package).

   The following table maps DTMF events to digit map symbols as
   described in section 7.1.14.

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

Top      Up      ToC       Page 150 
   ObservedEventsDescriptor parameters:

        DigitString
        -----------
        ParameterID: ds (0x0001)

        Type: string of digit map symbols (possibly empty) returned as
        a quotedString.

        Possible values: a sequence of the characters "0" through "9",
        "A" through "F", and the long duration modifier "Z".

        Description: the portion of the current dial string as
        described in section 7.1.14 which matched part or all of an
        alternative event sequence specified in the digit map.

        Termination Method
        ------------------
        ParameterID:    Meth (0x0003)

        Type: enumeration

        Possible values:
                "UM" (0x0001) Unambiguous match
                "PM"  (0x0002) Partial match, completion by timer
                expiry or unmatched event
                "FM"  (0x0003) Full match, completion by timer expiry
                or unmatched event

        Description: indicates the reason for generation of the event.
        See the procedures in section 7.1.14.

E.6.3 Signals

   None

E.6.4 Statistics

   None

E.6.5 Procedures

   None

Top      Up      ToC       Page 151 
E.7 Call Progress Tones Generator Package

   PackageID: cg, 0x0007
   Version: 1
   Extends: tonegen version 1

   This package defines the basic call progress tones as signals and
   extends the allowed values of the tl parameter of playtone in tonegen
   .

E.7.1 Properties

   None

E.7.2 Events

   None

E.7.3 Signals

   Dial Tone
   ---------
   SignaID: dt (0x0030)

   Generate dial tone. The physical characteristic of dial tone is
   available in the gateway.

   Signal Type: Timeout

   Duration: Provisioned

   Additional Parameters:
   None

   Additional Values
   -----------------
   dt (0x0030) is defined as a tone id for playtone
   The other tones of this package are defined in exactly the same way.
   A table with all signal names and  signal IDs is included.  Note
   that each tone is defined as both a signal and a toneid, thus
   extending the basic tone generation package.

Top      Up      ToC       Page 152 
            +---------------------------+-------------------+
            | Signal Name               | Signal ID/tone id |
            +---------------------------+-------------------+
            | Dial Tone                 | dt (0x0030)       |
            | Ringing Tone              | rt (0x0031)       |
            | Busy Tone                 | bt (0x0032)       |
            | Congestion Tone           | ct (0x0033)       |
            | Special Information Tone  | sit(0x0034)       |
            | Warning Tone              | wt (0x0035)       |
            | Payphone Recognition Tone | pt (0x0036)       |
            | Call Waiting Tone         | cw (0x0037)       |
            | Caller Waiting Tone       | cr (0x0038)       |
            +---------------------------+-------------------+

E.7.4 Statistics

   None

E.7.5 Procedures

   NOTE - The required set of tone ids corresponds to those defined in
   Recommendation E.180/Q.35 [ITU-T Recommendation E.180/Q.35 (1998)].
   See E.180 for definition of the meanings of these tones.

E.8 Call Progress Tones Detection Package

   PackageID: cd (0x0008)
   Version: 1
   Extends: tonedet version 1

   This package defines the basic call progress detection tones. This
   Package extends the possible values of tone id in the "start tone
   detected", "end tone detected" and "long tone detected" events.

   Additional values
   -----------------

   tone id values are defined for start tone detected, end tone detected
   and long tone detected with the same values as those in package cg
   (call progress tones generation package).

   The required set of tone ids corresponds to Recommendation E.180/Q.35
   [ITU-T Recommendation E.180/Q.35 (1998)].  See Recommendation
   E.180/Q.35 for definition of the meanings of these tones.

E.8.1 Properties

   none

Top      Up      ToC       Page 153 
E.8.2 Events

   Events are defined as in the call progress tones generator package
   (cg) for the tones listed in the table of section E.7.3

E.8.3 Signals

   none

E.8.4 Statistics

   none

E.8.5 Procedures

   none

E.9 Analog Line Supervision Package

   PackageID: al, 0x0009
   Version: 1
   Extends: None

   This package defines events and signals for an analog line.

E.9.1 Properties

   None

E.9.2 Events

   onhook
   ------
   EventID: on (0x0004)

   Detects handset going on hook. Whenever an events descriptor is
   activated that requests monitoring for an on-hook event and the line
   is already on-hook, then the MG shall behave according to the setting
   of the "strict" parameter.

   EventDescriptor parameters

        Strict Transition
        -----------------
        ParameterID: strict (0x0001)

        Type: enumeration

Top      Up      ToC       Page 154 
        Possible values: "exact" (0x00), "state" (0x01), "failWrong"
        (0x02)

        "exact" means that only an actual hook state transition to on-
        hook is to be recognized;

        "state" means that the event is to be recognized either if the
        hook state transition is detected or if the hook state is
        already on-hook;

        "failWrong" means that if the hook state is already on-hook,
        the command fails and an error is reported.

   ObservedEventsDescriptor parameters

        Initial State
        -------------
        ParameterID: init (0x0002)

        Type: Boolean

        Possible values:

        True means that the event was reported because the line was
        already on-hook when the events descriptor containing this
        event was activated;

        False means that the event represents an actual state
        transition to on-hook.


   offhook
   -------
   EventID: of (0x0005)

   Detects handset going off hook. Whenever an events descriptor is
   activated that requests monitoring for an off-hook event and the
   line is already off-hook, then the MG shall behave according to the
   setting of the "strict" parameter.

   EventDescriptor parameters


        Strict Transition
        -----------------
        ParameterID: strict (0x0001)

        Type: enumeration

Top      Up      ToC       Page 155 
        Possible values: "exact" (0x00), "state" (0x01), "failWrong"
        (0x02)

        "exact" means that only an actual hook state transition to off-
        hook is to be recognized;

        "state" means that the event is to be recognized either if the
        hook state transition is detected or if the hook state is
        already off-hook;

        "failWrong" means that if the hook state is already off-hook,
        the command fails and an error is reported.


   ObservedEventsDescriptor parameters

        Initial State
        -------------
        ParameterID: init (0x0002)

        Type: Boolean

        Possible values:

        True means that the event was reported because the line was
        already off-hook when the events descriptor containing this
        event was activated;

        False means that the event represents an actual state
        transition to off-hook.

   flashhook
   ---------
   EventID: fl, 0x0006

   Detects handset flash. A flash occurs when an onhook is followed by
   an offhook between a minimum and maximum duration.

   EventDescriptor parameters

        Minimum duration
        ----------------
        ParameterID: mindur (0x0004)

        Type: integer in milliseconds

        Default value is provisioned

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

Top      Up      ToC       Page 157 
E.9.4 Statistics

   None

E.9.5 Procedures

   If the MGC sets an EventsDescriptor containing a hook state
   transition event (on-hook or off-hook) with the "strict" (0x0001)
   parameter set to "failWrong", and the hook state is already what the
   transition implies, the execution of the command containing that
   EventsDescriptor fails.  The MG SHALL include error code 540
   "Unexpected initial hook state" in its reponse.

E.9.6 Error Code

   This package defines a new error code:
        540 - Unexpected initial hook state
   The procedure for use of this code is given in section E.9.5.

E.10 Basic Continuity Package

   PackageID: ct (0x000a)
   Version: 1
   Extends: None

   This package defines events and signals for continuity test. The
   continuity test includes provision of either a loopback or
   transceiver functionality.

E.10.1 Properties

   None

E.10.2 Events

   Completion
   ----------
   EventID: cmp, 0x0005

   This event detects test completion of continuity test.

   EventDescriptor parameters

   None

   ObservedEventsDescriptor parameters

Top      Up      ToC       Page 158 
        Result
        ------
        ParameterID: res (0x0008)

        Type: Enumeration

        Possible values: success (0x0001), failure (0x0000)

E.10.3 Signals

   Continuity test
   ---------------
   SignalID: ct (0x0003)

   Initiates sending of continuity test tone on the termination to
   which it is applied.

   Signal Type: TimeOut

   Default value is provisioned

   Additional Parameters:

   None

   Respond
   -------
   SignalID: rsp (0x0004)

   The signal is used to respond to a continuity test .  See section
   E.10.5 for further explanation.

   Signal Type: On/Off

   Default duration is provisioned

   Additional Parameters:

   None.

E.10.4 Statistics

   None

Top      Up      ToC       Page 159 
E.10.5 Procedures

   When a MGC wants to initiate a continuity test, it sends a command to
   the MG containing

   *  a signals descriptor with the ct signal, and
   *  an events descriptor containing the cmp event.

   Upon reception of a command containing the ct signal and cmp event,
   the MG initiates the continuity test tone for the specified
   termination.  If the return tone is detected and any other required
   conditions are satisfied before the signal times out, the cmp event
   shall be generated with the value of the result parameter equal to
   success.  In all other cases, the cmp event shall be generated with
   the value of the result parameter equal to failure.

   When a MGC wants the MG to respond to a continuity test, it sends a
   command to the MG containing a signals descriptor with the rsp
   signal.  Upon reception of a command with the rsp signal, the MG
   either applies a loopback or (for 2-wire circuits) awaits reception
   of a continuity test tone.  In the loopback case, any incoming
   information shall be reflected back as outgoing information.  In the
   2-wire case, any time the appropriate test tone is received, the
   appropriate response tone should be sent.  The MGC determines when to
   remove the rsp signal.

   When a continuity test is performed on a termination, no echo devices
   or codecs shall be active on that termination.

   Performing voice path assurance as part of continuity testing is
   provisioned by bilateral agreement between network operators.

E.11 Network Package

   PackageID: nt (0x000b)
   Version: 1
   Extends: None

   This package defines properties of network terminations independent
   of network type.

E.11.1 Properties

   Maximum Jitter Buffer
   ---------------------
   PropertyID: jit (0x0007)

   This property puts a maximum size on the jitter buffer.

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

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

Top      Up      ToC       Page 162 
   Octets Received
   ---------------
   StatisticID: or (0x0003)

   Type: double

   Possible Values: any 64 bit integer

E.11.5 Procedures

   none

E.12 RTP  Package

   PackageID: rtp (0x000c)
   Version: 1
   Extends: Network Package version 1

   This package is used to support packet based multimedia data transfer
   by means of the Real-time Transport Protocol (RTP) [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.

Top      Up      ToC       Page 163 
E.12.3 Signals

   None

E.12.4 Statistics

   Packets Sent
   ------------
   StatisticID: ps (0x0004)

   Type: double

   Possible Values: any 64 bit integer

   Packets Received
   ----------------
   StatisticID: pr (0x0005)

   Type: double

   Possible Values: any 64 bit integer

   Packet Loss
   -----------
   StatisticID: pl (0x0006)

   Describes the current rate of packet loss on an RTP stream, as
   defined in IETF 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)

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

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)

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

E.13.4 Statistics

   None

E.13.5 Procedures

   None

Top      Up      ToC       Page 166 
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.isi.edu/in-notes/iana/assignments/rtp-parameters

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.

   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.

Top      Up      ToC       Page 167 
   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,
                            tdmc/gain=2,  ; in dB,
                            tdmc/ec=on
                        },
                        Local {
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 0
   a=fmtp:PCMU VAD=X-NNVAD ; special voice activity
                           ; detection algorithm
                        }

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

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

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

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

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

Top      Up      ToC       Page 174 
   }

   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 175 
   20. The MG2 replies.

   MEGACO/1 [125.125.125.111]:55555
   Reply = 50007 {
      Context = - {
   AuditValue = A5556 {
             Media {
                 TerminationState { ServiceStates = InService,
                        Buffer = OFF },
                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
                    } } },
             Events,
             Signals,
             DigitMap,
             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 {

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

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

Top      Up      ToC       Page 178 
Authors' Addresses

   Fernando Cuervo
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, ON K1Y 4H7
   Canada
   E-mail: cuervo@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

   * The contribution of Christian Huitema was developed while he was
     employed by Telcordia Technologies.

   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

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