Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3015

Megaco Protocol Version 1.0

Pages: 179
Obsoletes:  28852886
Obsoleted by:  3525
Part 6 of 6 – Pages 131 to 179
First   Prev   None

ToP   noToC   RFC3015 - Page 131   prevText

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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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   noToC   RFC3015 - 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.