tech-invite   World Map     

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

RFC 2705

 
 
 

Media Gateway Control Protocol (MGCP) Version 1.0

Part 4 of 5, p. 91 to 124
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 91 
3.6.  Transmission over UDP

   MGCP messages are transmitted over UDP. Commands are sent to one of
   the IP addresses defined in the DNS for the specified endpoint . The
   responses are sent back to the source address of the commands.

   When no port is specified for the endpoint, the commands should be
   sent:

   *  by the Call Agents, to the default MGCP port for gateways, 2427.

   *  by the Gateways, to the default MGCP port for Call Agents, 2727.

3.6.1.  Providing the At-Most-Once functionality

   MGCP messages, being carried over UDP, may be subject to losses. In
   the absence of a timely response, commands are repeated. Most MGCP
   commands are not idempotent.  The state of the gateway would become

Top      Up      ToC       Page 92 
   unpredictable if, for example, CreateConnection commands were
   executed several times.  The transmission procedures must thus
   provide an "At-Most-Once" functionality.

   MGCP 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 being executed. The transaction identifiers of
   incoming commands are compared to the transaction identifiers of the
   recent responses. If a match is found, the MGCP entity does not
   execute the transaction, but simply repeats the response. The
   remaining commands will be compared to the list of current
   transaction. If a match is found, the MGCP entity does not execute
   the transaction, which is simply ignored.

   The procedure use 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 can be destroyed either LONG-TIMER seconds
   after the response is issued, or when the gateway (or the call agent)
   receives a confirmation that the response has been received, through
   the "Response Acknowledgement attribute". For transactions that are
   acknowledged through this attribute, the gateway 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.

3.6.2.  Transaction identifiers and three ways handshake

   Transaction identifiers are integer numbers in the range from 0 to
   999,999,999.  Call-agents may decide to use a specific number space
   for each of the gateways that they manage, or to use the same number
   space for all gateways that belong to some arbitrary group.  Call
   agents may decide to share the load of managing a large gateway
   between several independent processes.  These processes will share
   the same transaction number space.  There are multiple possible
   implementations of this sharing, such as having a centralized
   allocation of transaction identifiers, or pre-allocating non-
   overlapping ranges of identifiers to different processes.  The
   implementations must guarantee that unique transaction identifiers
   are allocated to all transactions that originate from a logical call
   agent, as defined in the "states, failover and race conditions"
   section. Gateways can simply detect duplicate transactions by looking
   at the transaction identifier only.

Top      Up      ToC       Page 93 
   The Response Acknowledgement Attribute can be found in any command.
   It carries a set of "confirmed transaction-id ranges."

   MGCP gateways may choose to delete the copies of the responses to
   transactions whose id is included in "confirmed transaction-id
   ranges" received in the Response Confirmation messages. They should
   silently discard further commands from that Call Agent 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 gateway issued
   its last response to that call agent, or when a gateway resumes
   operation.  In this situation, commands should be accepted and
   processed, without any test on the transaction-id.

   Commands that carry the "Response Acknowledgement attribute" may be
   transmitted in disorder.  The gateway shall retain the union of the
   "confirmed transaction-id ranges" received in recent commands.

3.6.3.  Computing retransmission timers

   It is the responsibility of the requesting entity to provide suitable
   time outs for all outstanding commands, and to retry commands when
   time outs have been exceeded. Furthermore, when repeated commands
   fail to be acknowledged, it is the responsibility of the requesting
   entity to seek redundant services and/or clear existing or pending
   connections.

   The specification purposely avoids specifying any value for the
   retransmission timers. These values are typically network dependent.
   The retransmission timers should normally estimate the timer by
   measuring the time spent between the sending of a command and the
   return of a response. 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. In MGCP, the maximum value
   of the timer should however be bounded, in order to guarantee that no
   repeated packet will be received by the gateways after LONG-TIMER
   seconds.  A suggested maximum value is 4 seconds.

Top      Up      ToC       Page 94 
   After any retransmission, the MGCP 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.

3.6.4.  Piggy backing

   There are cases when a Call Agent will want to send several messages
   at the same time to the same gateways.  When several MGCP messages
   have to be sent in the same UDP packets, they should be separated by
   a line of text that contain a single dot, as in for example:

         200 2005 OK
         DLCX 1244 card23/21@trgw-7.example.net MGCP 1.0
         C: A3C47F21456789F0
         I: FDE234C8

   The piggy-backed messages should be processed exactly has if they had
   been received in several simultaneous messages.

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

   Gateways that can predict that a transaction will require a long
   execution time may send a provisional response, with response code
   100.  They should send this response if they receive a repetition of
   a transaction that is still being executed.

   MGCP entities that receive a provisional response shall switch to a
   longer repetition timer for that transaction.

Top      Up      ToC       Page 95 
4.  States, failover and race conditions.

   In order to implement proper call signalling, the Call Agent must
   keep track of the state of the endpoint, and the gateway must make
   sure that events are properly notified to the call agent.  Special
   conditions exist when the gateway or the call agent are restarted:
   the gateway must be redirected to a new call agent during "failover"
   procedures, the call agent must take special action when the gateway
   is taken offline, or restarted.

4.1.  Basic Asumptions

   The support of "failover" is based on the following assumptions:

   *  Call Agents are identified by their domain name, not their network
      addresses, and several addresses can be associated with a domain
      name.

   *  An endpoint has one NotifiedEntity associated with it any given
      point in time.

   *  The NotifiedEntity is the last value of the "NotifiedEntity"
      parameter received for this endpoint (including wild-carded end-
      point-names). If no explicit "NotifiedEntity" parameter has been
      received, the "NotifiedEntity" defaults to the provisioned
      NotifiedEntity value, or if no value was provisioned to the source
      address of the last command received for the endpoint,

   *  Responses to commands are always sent to the source address of the
      command, regardless of the NotifiedEntity.

   *  When the "notified entity" refers to a domain name that resolves
      to multiple IP- address, endpoints are capable of switching
      between different interfaces on the same  logical call agent,
      however they cannot switch to other (backup) call agent(s) on
      their own. A backup call agent can however instruct them to
      switch, either directly or indirectly.

   *  If an entire call agent becomes unavailable, the endpoints managed
      by that call agent will eventually become "disconnected". The only
      way for these endpoints to become connected again is either for
      the failed call agent to become available, or for a backup call
      agent to contact the affected endpoints.

   *  When a backup call agent has taken over control of a group of
      endpoints, it is assumed that the failed call agent will
      communicate and synchronize with the backup call agent in order to

Top      Up      ToC       Page 96 
      transfer control of the affected endpoints back to the original
      call agent (if that's even desired - maybe the failed call agent
      should simply become the backup call agent now).

   We should note that handover conflict resolution between separate
   CA's is not in place - we are relying strictly on the CA's knowing
   what they are doing and communicating with each other (although
   AuditEndpoint can be used to learn about the current NotifiedEntity).

4.2.  Security, Retransmission, and Detection of Lost Associations:

   The media gateway control protocol is organized as a set of
   transactions, each of which is composed of a command and a response,
   commonly referred to as an acknowledgement.  The MGCP messages, being
   carried over UDP, may be subject to losses. In the absence of a
   timely response, commands are repeated. MGCP 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 transaction identifiers of incoming commands are compared to the
   transaction identifiers of the recent responses. If a match is found,
   the MGCP entity does not execute the transaction, but simply repeats
   the response. The remaining commands will be compared to the list of
   current transaction. If a match is found, the MGCP entity does not
   execute the transaction, which is simply ignored - a response will be
   provided when the execution of the command is complete.

   The repetition mechanism is used to guard against four 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 call agent
      becomes unavailable,

   *  call agent failure, when for example an entire call agent becomes
      unavailable,

   *  failover, when a new call agent is "taking over" transparently.

   The elements 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 call agent or a gateway has to repeat a
   message more than a few times, it is very legitimate to assume that

Top      Up      ToC       Page 97 
   something else than a transmission error is occurring.  For example,
   given a loss rate of 1%, the probability that 5 consecutive
   transmission attempts fail is 1 in 100 billion, an event that should
   occur less than once every 10 days for a call agent that processes
   1,000 transactions per second. (Indeed, the number of repetition that
   is considered excessive should be a function of the prevailing packet
   loss rate.) We should note that the "suspicion threshold", which we
   will call "Max1", is normally lower than the "disconnection
   threshold", which should be set to a larger value.

      Command issued: N=0
              |
       transmission: N++
              |  +------------ retransmission: N++ -----------+
              |  |                                            |
              |  |       transmission                         |
              |  |  +---to new address -+<--------------------|--+
              |  |  |        N=0        |                     |  |
              V  V  V                   |                     |  |
        +-----------+                   |                     |  |
        | awaiting  |- new call agent ->+  +------------+     |  |
        |  response |--- timer elapsed --->| N > Max1 ? |-(no)+  |
        +-----------+ <----------+         +------------+     ^  |
              |   |              |               |            |  |
              |   +- wrong key? -+             (yes)          |  |
              |                                  |            |  |
      response received                    (if N=Max1,        |  |
              |                             or N=Max2         |  |
              |                             check DNS)        |  |
              v                                  |            |  |
            (end)                       +---------------+     |  |
                                        |more addresses?|(yes)|--+
                                        +---------------+     |
                                                 |            |
                                               (no)           |
                                                 |            |
                                           +------------+     |
                                           | N > Max2 ? |(no)-+
                                           +------------+
                                                 |
                                               (yes)
                                                 |
                                                 v
                                          (disconnected)

   A classic retransmission algorithm would simply count the number of
   successive repetitions, and conclude that the association is broken
   after re-transmitting the packet an excessive number of times

Top      Up      ToC       Page 98 
   (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 as follows:

   *  We request that the gateway always checks for the presence of a
      new call agent. It can be noticed either by

      -  receiving a valid multicast message announcing a failover, or

      -  receiving a command where the NotifiedEntity points to the new
         call agent, or

      -  receiving a redirection response pointing to a new Call Agent.

      If a new call agent is detected, the gateway starts transmitting
      outstanding commands to that new agent.  Responses to commands are
      still transmitted to the source address of the command.

   *  we request that if the number of repetitions for this Call Agent
      is larger than "Max1", that the gateway actively queries the name
      server in order to detect the possible change of the call agent
      interfaces.

   *  The gateway may have learned several IP addresses for the call
      agent. If the number of repetitions is larger than "Max1" and
      lower than "Max2", and there are more interfaces that have not
      been tried, then the gateway should direct the retransmissions to
      alternate addresses.

   *  If there are no more interfaces to try, and the number of
      repetitions is Max2, then the gateway contacts the DNS one more
      time to see if any other interface should have become available.
      If not, the gateway is now disconnected.

   The procedure will maximize the chances of detecting an ongoing
   failover. It poses indeed two very specific problems, the potentially
   long delays of a timer based procedure and the risk of confusion
   caused by the use of cryptographic protections.

   In order to automatically adapt to network load, MGCP 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.

Top      Up      ToC       Page 99 
   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 endpoint becomes
   disconnected. 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.

   Another potential cause of connection failure would be the reception
   of a "wrong key" message, sent by a call agent that could not
   authenticate the command, presumably because it had lost the security
   parameters of the association.  Such messages are actually not
   authorized in IPSEC, and they should in fact not be taken at face
   value: an attacker could easily forge "wrong key" messages in order
   to precipitate the loss of a control connection.  The current
   algorithm ignores these messages, which translates into a strict
   reliance on timers.  The algorithm could in fact be improved, maybe
   by executing a check with the key server of the call agent after
   "Max1" repetitions.

4.3.  Race conditions

   MGCP deals with race conditions through the notion of a "quarantine
   list" and through explicit detection of desynchronization.

   MGCP does not assume that the transport mechanism will maintain the
   order of command and responses.  This may cause race conditions, that
   may be obviated through a proper behavior of the call agent. (Note
   that some race conditions are inherent to distributed systems; they
   would still occur, even if the commands were transmitted in strict
   order.)

   In some cases, many gateways may decide to restart operation at the
   same time.  This may occur, for example, if an area loses power or
   transmission capability during an earthquake or an ice storm.  When
   power and transmission are reestablished, many gateways may decide to
   send "RestartInProgress" commands simultaneously, leading to very
   unstable operation.

4.3.1.  Quarantine list

   MGCP controlled gateways will receive "notification requests" that
   ask them to watch for a list of "events."  The protocol elements that
   determine the handling of these events are the "Requested Events"
   list, the "Digit Map" and the "Detect Events" list.

Top      Up      ToC       Page 100 
   When the endpoint is initialized, the requested events list and the
   digit map are empty.  After reception of a command, the gateway
   starts observing the endpoint for occurrences of the events mentioned
   in the list.

   The events are examined as they occur. The action that follows is
   determined by the "action" parameter associated to the event in the
   list of requested events, and also by the digit map.  The events that
   are defined as "accumulate" or "treat according to digit map" are
   accumulated in a list of events, the events that are marked as
   "treated according to the digit map" will additionally be accumulated
   in the dialed string. This will go on until one event is encountered
   that triggers a Notification to the "notified entity."

   The gateway, at this point, will transmit the notification command
   and will place the endpoint in a "notification" state. As long as the
   endpoint is in this notification state, the events that are to be
   detected on the endpoint are stored in a "quarantine" buffer for
   later processing.  The events are, in a sense, "quarantined." All
   events that are specified by the union of the RequestedEvents
   parameter and the most recently received DetectEvent parameter or, in
   the absence of the latter, all events that are referred to in the
   RequestedEvents, should be detected and quarantined, regardless of
   the action associated to the event.

   The endpoint exits the "notification state" when the acknowledgement
   of the Notify  command is received. The Notify command may be
   retransmitted in the "notification state", as specified in section
   3.5. When the endpoint exits the "notification state" it resets the
   list of observed events and the "current dial string" of the endpoint
   to a null value.

   Following that point, the behavior of the gateway depends on the
   value of The QuarantineHandling parameter in the notification
   request.  If the Call Agent specified that it expected at most one
   notification in response to the notification request command, then
   the gateway should simply keep on accumulating events in the
   quarantine list until it receives the next notification request
   command.

   If the gateway is authorized to send multiple successive Notify
   commands, it will proceed as follows.  When the gateway exits the
   "notification state", it resets the list of observed events and the
   "current dial string" of the endpoint to a null value and starts
   processing the list of quarantined events, using the already received
   list of requested events and digit map. When processing these events,

Top      Up      ToC       Page 101 
   the gateway may encounter an event which requires a Notify command to
   be sent. If that is the case, the gateway can adopt one of the two
   following behaviors:

   *  it can immediately transmit a Notify command that will report all
      events that were accumulated in the list of observed events until
      the triggering event, included, leaving the unprocessed events in
      the quarantine list,

   *  or it can attempt to empty the quarantined list and transmit a
      single Notify command reporting several sets of events and
      possibly several dial strings. The dial string is reset to a null
      value after each triggering event. The events that follow the last
      triggering event are left in the quarantine list.

   If the gateway transmits a Notify command, the end point will remain
   in the "notification state" until the acknowledgement is received. If
   the gateway does not find a quarantined event that requests a Notify
   command, it places the end point in a normal state.  Events are then
   processed as they come, in exactly the same way as if a Notification
   Request command had just been received.

   A gateway may receive at any time a new Notification Request command
   for the end point. When a new notification request is received in the
   notification state, the gateway shall ensure that the pending
   notification is received by the Call Agent prior to a successful
   response to the new NotificationRequest. It does so by using the
   "piggy-backing" functionality of the protocol. The messages will then
   be sent in a single packetto the source of the new
   NotificationRequest, regardless of respectively the source and
   "notified entity" for the old and new command. The steps involved are
   the following:

   a) the gateway builds a message that carries in a single packet a
      repetition of the old pending Notify command and the
      acknowledgement of the new notification request.

   b) the endpoint is then taken out of the "notification state" without
      waiting for the acknowledgement of the notification command.

   c) a copy of the unacknowledged Notify command command is kept until
      an acknowledgement is received.  If a timer elapses, the
      notification will be repeated, in a packet that will also carry a
      repetition of the acknowledgement of the notification request.

Top      Up      ToC       Page 102 
   d) if the acknowledgement is lost, the Call Agent will retransmit the
      Notification Request.  The gateway will reply to this repetition
      by retransmitting in a single packet the unacknowledged Notify and
      the acknowledgement of the notification request.

   e) if the gateway has to transmit a Notify before the previous Notify
      is acknowledged, it should construct a packet that piggybacks a
      repetition of the old Notify, a repetition of the acknowledgement
      of the last notification request and the new Notify.

   f) Gateways that cannot piggyback several packets in the same message
      should elect to leave the endpoint in the "notification" state as
      long as the last notification is not acknowledged.

   After receiving the Notification Request command, the requested
   events list and digit map (if a new one was provided) are replaced by
   the newly received parameters, and the list of observed events and
   accumulated dial string are reset to a null value.  The behavior is
   conditioned by the value of the QuarantineHandling parameter. The
   parameter may specify that quarantined events, or previously observed
   events, should be discarded, in which case they will be. If the
   parameter specifies that the quarantined events should be processed,
   the gateway will start processing the list of quarantined events or
   previously observed events, using the newly received list of
   requested events and digit map. When processing these events, the
   gateway may encounter an event which requires a Notify command to be
   sent. If that is the case, the gateway will immediately transmit a
   Notify command that will report all events that were accumulated in
   the list of observed events until the triggering event, included,
   leaving the unprocessed events in the quarantine buffer, and will
   enter the "notification state".

   A new notification request may be received while the gateway has
   accumulated events according to the previous notification requests,
   but has not yet detected a notification-triggering events.  The
   handling of not-yet-notified events is determined, as with the
   quarantined events, by the quarantine handling parameters:

   *  If the quarantine-handling parameter specifies that quarantined
      events shall be ignored, the observed event list is simply reset.

   *  If the quarantine-handling parameter specifies that quarantined
      events shall be processed, the observed event list is transferred
      to the quarantined event list.  The observed event list is then
      reset, and the quarantined event list is processed.

Top      Up      ToC       Page 103 
   Call Agents SHOULD provide the response to a successful Notify
   message and the new NotificationRequest in the same datagram using
   the piggy-backing mechanism.

4.3.2.  Explicit detection

   A key element of the state of several endpoints is the position of
   the hook. A race condition may occur when the user decides to go
   off-hook before the Call Agent has the time to ask the gateway to
   notify an off hook event (the "glare" condition well known in
   telephony), or if the user goes on-hook before the Call Agent has the
   time to request the event's notification.

   To avoid this race condition, the gateway should check the condition
   of the endpoint before acknowledging a NotificationRequest. It should
   return an error:

   1- If the gateway is requested to notify an "off hook" transition
      while the phone is already off hook,

   2- If the gateway is requested to notify an "on hook" or "flash hook"
      condition while the phone is already on hook.

   It should be noted, that the condition check is performed at the time
   the notification request is received, where as the actual event that
   caused the current condition may have either been reported, or
   ignored earlier, or it may currently be quarantined.

   The other state variables of the gateway, such as the list of
   RequestedEvent or list of requested signals, are entirely replaced
   after each successful NotificationRequest, which prevents any long
   term discrepancy between the Call Agent and the gateway.

   When a NotificationRequest is unsuccessful, whether it is included in
   a connection-handling command or not, the gateway will simply
   continue as if the command had never been received. As all other
   transactions, the NotificationRequest should operate as an atomic
   transaction, thus any changes initiated as a result of the command
   should be reverted.

   Another race condition may occur when a Notify is issued shortly
   before the reception by the gateway of a NotificationRequest. The
   RequestIdentifier is used to correlate Notify commands with
   NotificationRequest commands.

Top      Up      ToC       Page 104 
4.3.3.  Ordering of commands, and treatment of disorder

   MGCP does not mandate that the underlying transport protocol
   guarantees the sequencing of commands sent to a gateway or an
   endpoint.  This property tends to maximize the timeliness of actions,
   but it has a few draw backs.  For example:

   *  Notify commands may be delayed and arrive to the call agent after
      the transmission of a new Notification Request command,

   *  If a new NotificationRequest is transmitted before a previous one
      is acknowledged, there is no guarantee that the previous one will
      not be received in second position.

   Call Agents that want to guarantee consistent operation of the end
   points can use the following rules:

   1) When a gateway handles several endpoints, commands pertaining to
      the different endpoints can be sent in parallel, for example
      following a model where each endpoint is controlled by its own
      process or its own thread.

   2) When several connections are created on the same endpoint,
      commands pertaining to different connections can be sent in
      parallel.

   3) On a given connection, there should normally be only one
      outstanding command (create or modify).  However, a
      DeleteConnection command can be issued at any time.  In
      consequence, a gateway may sometimes receive a ModifyConnection
      command that applies to a previously deleted connection.  Such
      commands should be ignored, and an error code should be returned.

   4) On a given endpoint, there should normally be only one outstanding
      NotificationRequest command at any time.  The RequestId parameter
      should be used to correlate Notify commands with the triggering
      notification request.

   5) In some cases, an implicitly or explicitly wildcarded
      DeleteConnection command that applies to a group of endpoints can
      step in front of a pending CreateConnection command.  The Call
      Agent should individually delete all connections whose completion
      was pending at the time of the global DeleteConnection command.
      Also, new CreateConnection commands for endpoints named by the
      wild-carding cannot be sent until the wild-carded DeleteConnection
      command is acknowledged.

Top      Up      ToC       Page 105 
   6) When commands are embedded within each other, sequencing
      requirements for all commands must be adhered to. For example a
      Create Connection command with a Notification Request in it must
      adhere to the sequencing for CreateConnection and
      NotificationRequest at the same time.

   7) AuditEndpoint and AuditConnection is not subject to any
      sequencing.

   8) RestartInProgress must always be the first command sent by an
      endpoint as defined by the restart procedure. Any other command or
      response must be delivered after this RestartInProgress command
      (piggy-backing allowed).

   9) When multiple messages are piggy-backed in a single packet, the
      messages are always processed in order.

   These rules do not affect the gateway, which should always respond to
   commands.

4.3.4.  Fighting the restart avalanche

   Let's suppose that a large number of gateways are powered on
   simultaneously.  If they were to all initiate a RestartInProgress
   transaction, the call agent would very likely be swamped, leading to
   message losses and network congestion during the critical period of
   service restoration. In order to prevent such avalanches, the
   following behavior is suggested:

   1) When a gateway is powered on, it should initiate a restart timer
      to a random value, uniformly distributed between 0 and a maximum
      waiting delay (MWD). Care should be taken to avoid synchronicity
      of the random number generation between multiple gateways that
      would use the same algorithm.

   2) The gateway should then wait for either the end of this timer, the
      reception of a command from the call agent, or the detection of a
      local user activity, such as for example an off-hook transition on
      a residential gateway.

   3) When the timer elapses, when a command is received, or when an
      activity is detected, the gateway should initiate the restart
      procedure.

Top      Up      ToC       Page 106 
   The restart procedure simply requires the endpoint to guarantee that
   the first message (command or response) that the Call Agent sees from
   this endpoint is a RestartInProgress message informing the Call Agent
   about the restart. The endpoint is free to take full advantage of
   piggy-backing to achieve this.

   It is expected that each endpoint in a gateway will have a
   provisionable Call Agent, i.e., "notified entity", to direct the
   initial restart message towards. When the collection of endpoints in
   a gateway is managed by more than one Call Agent, the above procedure
   must be performed for each collection of endpoints managed by a given
   Call Agent. The gateway MUST take full advantage of wild-carding to
   minimize the number of RestartInProgress messages generated when
   multiple endpoints in a gateway restart and the endpoints are managed
   by the same Call Agent.

   The value of MWD is a configuration parameter that depends on the
   type of the gateway. The following ]reasoning can be used to
   determine the value of this delay on residential gateways.

   Call agents are typically dimensioned to handle the peak hour traffic
   load, during which, in average, 10% of the lines will be busy,
   placing calls whose average duration is typically 3 minutes.  The
   processing of a call typically involves 5 to 6 MGCP transactions
   between each end point and the call agent.  This simple calculation
   shows that the call agent is expected to handle 5 to 6 transactions
   for each end point, every 30 minutes on average, or, to put it
   otherwise, about one transaction per end point every 5 to 6 minutes
   on average.  This suggest that a reasonable value of MWD for a
   residential gateway would be 10 to 12 minutes.  In the absence of
   explicit configuration, residential gateways should adopt a value of
   600 seconds for MWD.

   The same reasoning suggests that the value of MWD should be much
   shorter for trunking gateways or for business gateways, because they
   handle a large number of endpoints, and also because the usage rate
   of these endpoints is much higher than 10% during the peak busy hour,
   a typical value being 60%.  These endpoints, during the peak hour,
   are this expected to contribute about one transaction per minute to
   the call agent load. A reasonable algorithm is to make the value of
   MWD per "trunk" endpoint six times shorter than the MWD per
   residential gateway, and also inversely proportional to the number of
   endpoints that are being restarted. for example MWD should be set to
   2.5 seconds for a gateway that handles a T1 line, or to 60
   milliseconds for a gateway that handles a T3 line.

Top      Up      ToC       Page 107 
4.3.5.  Disconnected Endpoints

   In addition to the restart procedure, gateways also have a
   "disconnected" procedure, which is initiated when an endpoint becomes
   "disconnected" as described in Section 3.4.2. It should here be
   noted, that endpoints can only become disconnected when they attempt
   to communicate with the Call Agent. The following steps are followed
   by an endpoint that becomes "disconnected":

   1. A "disconnected" timer is initialized to a random value, uniformly
      distributed between 0 and a provisionable "disconnected" initial
      waiting delay (Tdinit), e.g., 15 seconds.  Care MUST be taken to
      avoid synchronicity of the random number generation between
      multiple gateways and endpoints that would use the same algorithm.

   2. The gateway then waits for either the end of this timer, the
      reception of a command from the call agent, or the detection of a
      local user activity for the endpoint, such as for example an off-
      hook transition.

   3. When the "disconnected" timer elapses, when a command is received,
      or when a local user activity is detected, the gateway initiates
      the "disconnected" procedure for the endpoint. In the case of
      local user activity, a provisionable "disconnected" minimum
      waiting delay (Tdmin) must furthermore have elapsed since the
      gateway became disconnected or the last time it initiated the
      "disconnected" procedure in order to limit the rate at which the
      procedure is performed.

   4. If the "disconnected" procedure still left the endpoint
      disconnected, the "disconnected" timer is then doubled, subject to
      a provisionable "disconnected" maximum waiting delay (Tdmax),
      e.g., 600 seconds, and the gateway proceeds with step 2 again.

   The "disconnected" procedure is similar to the restart procedure in
   that it now simply states that the endpoint MUST send a
   RestartInProgress command to the Call Agent informing it that the
   endpoint was disconnected and furthermore guarantee that the first
   message (command or response) that the Call Agent now sees from this
   endpoint MUST be this RestartInProgress command. The endpoint MUST
   take full advantage of piggy-backing in achieving this. The Call
   Agent may then for instance decide to audit the endpoint, or simply
   clear all connections for the endpoint.

   This specification purposely does not specify any additional behavior
   for a disconnected endpoint. Vendors MAY for instance choose to
   provide silence, play reorder tone, or even enable a downloaded wav
   file to be played.

Top      Up      ToC       Page 108 
   The default value for Tdinit is 15 seconds, the default value for
   Tdmin, is 15 seconds, and the default value for Tdmax is 600 seconds.

5.  Security requirements

   If unauthorized entities could use the MGCP, they would be able to
   set-up unauthorized calls, or to interfere with authorized calls. We
   expect that MGCP messages will always be carried over secure Internet
   connections, as defined in the IP security architecture as defined in
   RFC 2401, using either the IP Authentication Header, defined in RFC
   2402, or the IP Encapsulating Security Payload, defined in RFC 2406.
   The complete MGCP protocol stack would thus include the following
   layers:

                ________________________________
               |              MGCP             |
               |_______________________________|
               |              UDP              |
               |_______________________________|
               |          IP security          |
               | (authentication or encryption)|
               |_______________________________|
               |              IP               |
               |_______________________________|
               |       transmission media      |
               |_______________________________|

   Adequate protection of the connections will be achieved if the
   gateways and the Call Agents only accept messages for which IP
   security provided an authentication service. An encryption service
   will provide additional protection against eavesdropping, thus
   forbidding third parties from monitoring the connections set up by a
   given endpoint

   The encryption service will also be requested if the session
   descriptions are used to carry session keys, as defined in SDP.

   These procedures do not necessarily protect against denial of service
   attacks by misbehaving gateways or misbehaving call agents. However,
   they will provide an identification of these misbehaving entities,
   which should then be deprived of their authorization through
   maintenance procedures.

Top      Up      ToC       Page 109 
5.1.  Protection of media connections

   MGCP allows call agent to provide gateways with "session keys" that
   can be used to encrypt the audio messages, protecting against
   eavesdropping.

   A specific problem of packet networks is "uncontrolled barge-in."
   This attack can be performed by directing media packets to the IP
   address and UDP port used by a connection. If no protection is
   implemented, the packets will be decompressed and the signals will be
   played on the "line side".

   A basic protection against this attack is to only accept packets from
   known sources, checking for example that the IP source address and
   UDP source port match the values announced in the "remote session
   description."  But this has two inconveniences: it slows down
   connection establishment and it can be fooled by source spoofing:

   *  To enable the address-based protection, the call agent must obtain
      the remote session description of the e-gress gateway and pass it
      to the in-gress gateway.  This requires at least one network round
      trip, and leaves us with a dilemma: either allow the call to
      proceed without waiting for the round trip to complete, and risk
      for example "clipping" a remote announcement, or wait for the full
      round trip and settle for slower call-set-up procedures.

   *  Source spoofing is only effective if the attacker can obtain valid
      pairs of source destination addresses and ports, for example by
      listening to a fraction of the traffic. To fight source spoofing,
      one could try to control all access points to the network.  But
      this is in practice very hard to achieve.

   An alternative to checking the source address is to encrypt and
   authenticate the packets, using a secret key that is conveyed during
   the call set-up procedure. This will no slow down the call set-up,
   and provides strong protection against address spoofing.

6.  Event packages and end point types

   This section provides an initial definition of packages and event
   names.  More packages can be defined in additional documents.

Top      Up      ToC       Page 110 
6.1.  Basic packages

   The list of basic packages includes the following:

                _________________________________________
               | Package                      |   name  |
               |______________________________|_________|
               | Generic Media Package        |   G     |
               | DTMF package                 |   D     |
               | MF Package                   |   M     |
               | Trunk Package                |   T     |
               | Line Package                 |   L     |
               | Handset Package              |   H     |
               | RTP Package                  |   R     |
               | Network Access Server Package|   N     |
               | Announcement Server Package  |   A     |
               | Script Package               |   Script|
               |______________________________|_________|


   In the tables of events for each package, there are five columns:

      Symbol: the unique symbol used for the event
      Definition: a short description of the event

      R: an x appears in this column is the event can be Requested by
         the call agent.

      S: if nothing appears in this column for an event, then the event
         cannot be signaled on command by the call agent. Otherwise, the
         following symbols identify the type of event:

      OO On/Off signal.  The signal is turned on until commanded by the
         call agent to turn it off, and vice versa.

      TO Timeout signal.  The signal lasts for a given duration unless
         it is superseded by a new signal.

      BR Brief signal.  The event has a short, known duration.

      Duration: specifies the duration of TO signals.

Top      Up      ToC       Page 111 
6.1.1.  Generic Media Package

   Package Name: G

   The generic media package group the events and signals that can be
   observed on several types of endpoints, such as trunking gateways,
   access gateways or residential gateways.

  _____________________________________________________________________
 | Symbol   |   Definition               |   R |   S      Duration    |
 |__________|____________________________|_____|______________________|
 | mt       |   Modem detected           |   x |                      |
 | ft       |   Fax tone detected        |   x |                      |
 | ld       |   Long duration connection |   x |                      |
 | pat(###) |   Pattern ### detected     |   x |   OO                 |
 | rt       |   Ringback tone            |     |   TO                 |
 | rbk(###) |   ring back on connection  |     |   TO     180 seconds |
 | cf       |   Confirm tone             |     |   BR                 |
 | cg       |   Network Congestion tone  |     |   TO                 |
 | it       |   Intercept tone           |     |   OO                 |
 | pt       |   Preemption tone          |     |   OO                 |
 | of       |   report failure           |   x |                      |
 |__________|____________________________|_____|______________________|

   The signals are defined as follows:

      The pattern definition can be used for specific algorithms such as
      answering machine detection, tone detection, and the like.

   Ring back tone (rt)
      an Audible Ring Tone, a combination of two AC tones with
      frequencies of 440 and 480 Hertz and levels of -19 dBm each, to
      give a combined level of -16 dBm.  The cadence for Audible Ring
      Tone is 2 seconds on followed by 4 seconds off. See GR- 506-CORE -
      LSSGR:  SIGNALING, Section 17.2.5.

   Ring back on connection
      A ring back tone, applied to the connection whose identifier is
      passed as a parameter.

   The "long duration connection" is detected when a connection has been
   established for more than 1 hour.

Top      Up      ToC       Page 112 
6.1.2.  DTMF package

   Package name: D

    _______________________________________________________________
   | Symbol |   Definition              |   R |   S      Duration |
   |________|___________________________|_____|___________________|
   | 0      |   DTMF 0                  |   x |   BR              |
   | 1      |   DTMF 1                  |   x |   BR              |
   | 2      |   DTMF 2                  |   x |   BR              |
   | 3      |   DTMF 3                  |   x |   BR              |
   | 4      |   DTMF 4                  |   x |   BR              |
   | 5      |   DTMF 5                  |   x |   BR              |
   | 6      |   DTMF 6                  |   x |   BR              |
   | 7      |   DTMF 7                  |   x |   BR              |
   | 8      |   DTMF 8                  |   x |   BR              |
   | 9      |   DTMF 9                  |   x |   BR              |
   | #      |   DTMF #                  |   x |   BR              |
   | *      |   DTMF *                  |   x |   BR              |
   | A      |   DTMF A                  |   x |   BR              |
   | B      |   DTMF B                  |   x |   BR              |
   | C      |   DTMF C                  |   x |   BR              |
   | D      |   DTMF D                  |   x |   BR              |
   | L      |   long duration indicator |   x |          2 seconds|
   | X      |   Wildcard, match         |   x |                   |
   |        |   any digit 0-9           |     |                   |
   | T      |   Interdigit timer        |   x |          4 seconds|
   | of     |   report failure          |   x |                   |
   |________|___________________________|_____|___________________|

   The "interdigit timer" T is a digit input timer that can be used in
   two ways:

   *  When timer T is used with a digit map, the timer is not started
      until the first digit is entered, and the timer is restarted after
      each new digit is entered until either a digit map match or
      mismatch occurs. In this case, timer T functions as an inter-digit
      timer.

   *  When timer T is used without a digit map, the timer is started
      immediately and simply cancelled (but not restarted) as soon as a
      digit is entered. In this case, timer T can be used as an
      interdigit timer when overlap sending is used.

      When used with a digit map, timer T takes on one of two values,
      T(partial) or T(critical). When at least one more digit is
      required for the digit string to match any of the patterns in the
      digit map, timer T takes on the value T(partial), corresponding to

Top      Up      ToC       Page 113 
      partial dial timing. If a timer is all that is required to produce
      a match, timer T takes on the value T(critical) corresponding to
      critical timing. When timer T is used without a digit map, timer T
      takes on the value T(critical).  The default value for T(partial)
      is 16 seconds and the default value for T(critical) is 4 seconds.
      The provisioning process may alter both of these.

      The "long duration indicator" is observed when a DTMF signal is
      produced for a duration larger than two seconds.  In this case,
      the gateway will detect two successive events: first, when the
      signal has been recognized, the DTMF signal, and then, 2 seconds
      later, the long duration signal.

6.1.3.  MF Package

      Package Name: M

       ________________________________________________________
      | Symbol |   Definition       |   R |   S      Duration |
      |________|____________________|_____|___________________|
      | 0      |   MF 0             |   x |   BR              |
      | 1      |   MF 1             |   x |   BR              |
      | 2      |   MF 2             |   x |   BR              |
      | 3      |   MF 3             |   x |   BR              |
      | 4      |   MF 4             |   x |   BR              |
      | 5      |   MF 5             |   x |   BR              |
      | 6      |   MF 6             |   x |   BR              |
      | 7      |   MF 7             |   x |   BR              |
      | 8      |   MF 8             |   x |   BR              |
      | 9      |   MF 9             |   x |   BR              |
      | X      |   Wildcard, match  |   x |                   |
      |        |   any digit 0-9    |     |                   |
      | T      |   Interdigit timer |   x |          4 seconds|
      | K0     |   MF K0 or KP      |   x |   BR              |
      | K1     |   MF K1            |   x |   BR              |
      | K2     |   MF K2            |   x |   BR              |
      | S0     |   MF S0 or ST      |   x |   BR              |
      | S1     |   MF S1            |   x |   BR              |
      | S2     |   MF S2            |   x |   BR              |
      | S3     |   MF S3            |   x |   BR              |
      | wk     |   Wink             |   x |   BR              |
      | wko    |   Wink off         |   x |   BR              |
      | is     |   Incoming seizure |   x |   OO              |
      | rs     |   Return seizure   |   x |   OO              |
      | us     |   Unseize circuit  |   x |   OO              |
      | of     |   report failure   |   x |                   |
      |________|____________________|_____|___________________|

Top      Up      ToC       Page 114 
   The definition of the MF package events is as follows:

   Wink
      A transition from unseized to seized to unseized trunk states
      within a specified period.  Typical seizure period is 100-350
      msec.)

   Incoming seizure
      Incoming indication of call attempt.

   Return seizure:
      Seizure in response to outgoing seizure.

   Unseize circuit:
      Unseizure of a circuit at the end of a call.

   Wink off:
      A signal used in operator services trunks.  A transition from
      seized to unseized to seized trunk states within a specified
      period of 100-350 ms. (To be checked)

6.1.4.  Trunk Package

   Package Name: T

   _____________________________________________________________________
  | Symbol |   Definition                   |   R |   S      Duration  |
  |________|________________________________|_____|____________________|
  | co1    |   Continuity tone (single tone,|   x |   OO               |
  |        |   or return tone)              |     |                    |
  | co2    |   Continuity test (go tone,    |   x |   OO               |
  |        |   in dual tone procedures)     |     |                    |
  | lb     |   Loopback                     |     |   OO               |
  | om     |   Old Milliwatt Tone (1000 Hz) |   x |   OO               |
  | nm     |   New Milliwatt Tone (1004 Hz) |   x |   OO               |
  | tl     |   Test Line                    |   x |   OO               |
  | zz     |   No circuit                   |   x |   OO               |
  | as     |   Answer Supervision           |   x |   OO               |
  | ro     |   Reorder Tone                 |   x |   TO     30 seconds|
  | of     |   report failure               |   x |                    |
  | bl     |   Blocking                     |     |   OO               |
  |________|________________________________|_____|____________________|

   The definition of the trunk package signal events is as follows:

   Continuity Tone (co1):
      A tone at 2010 + or - 30 Hz.

Top      Up      ToC       Page 115 
   Continuity Test (co2):
      A tone at the 1780 + or - 30 Hz.

   Milliwatt Tones:
      Old Milliwatt Tone (1000 Hz), New Milliwatt Tone (1004 Hz)

   Line Test:
      105 Test Line test progress tone (2225 Hz + or - 25 Hz at -10 dBm0
      + or -- 0.5dB).

   No circuit:
      (that annoying tri-tone, low to high)

   Answer Supervision:

   Reorder Tone:
      Reorder tone is a combination of two AC tones with frequencies of
      480 and 620 Hertz and levels of -24 dBm each, to give a combined
      level of -21 dBm.  The cadence for Station Busy Tone is 0.25
      seconds on followed by 0.25 seconds off, repeating continuously.
      See GR-506-CORE - LSSGR: SIGNALING, Section 17.2.7.

   Blocking:
      The call agent can place the circuit in a blocked state by
      applying the "bl(+)" signal to the endpoint.  It can unblock it by
      applying the "bl(-)" signal.

   The continuity tones are used when the call agent wants to initiate a
   continuity test. There are two types of tests, single tone and dual
   tone. The Call agent is expected to know, through provisioning
   information, which test should be applied to a given endpoint. For
   example, the call agent that wants to initiate a single frequency
   test will send to the gateway a command of the form:

         RQNT 1234 epx-t1/17@tgw2.example.net
         X: AB123FE0
         S: co1
         R: co1

   If it wanted instead to initiate a dual-tone test, it would send the
   command:

         RQNT 1234 epx-t1/17@tgw2.example.net
         X: AB123FE0
         S: co2
         R: co1

Top      Up      ToC       Page 116 
   The gateway would send the requested signal, and in both cases would
   look for the return of the 2010 Hz tone (co1).  When it detects that
   tone, it will send the corresponding  notification.

   The tones are of type OO: the gateway will keep sending them until it
   receives a new notification request.

6.1.5.  Line Package

   Package Name: L

________________________________________________________________________
|Symbol       |   Definition                 |   R |   S    Duration   |
|_____________|______________________________|_____|___________________|
|adsi(string) |   adsi display               |     |   BR              |
|vmwi         |   visual message             |     |   OO              |
|             |   waiting indicator          |     |                   |
|hd           |   Off hook transition        |   x |                   |
|hu           |   On hook transition         |   x |                   |
|hf           |   Flash hook                 |   x |                   |
|aw           |   Answer tone                |   x |   OO              |
|bz           |   Busy tone                  |     |   TO   30 seconds |
|ci(ti,nu,na) |   Caller-id                  |     |   BR              |
|wt           |   Call Waiting tone          |     |   TO   30 seconds |
|wt1, wt2,    |   Alternative call           |     |                   |
|wt3, wt4     |   waiting tones              |     |                   |
|dl           |   Dial tone                  |     |   TO   16 seconds |
|mwi          |   Message waiting ind.       |     |   TO   16 seconds |
|nbz          |   Network busy               |   x |   OO              |
|             |   (fast cycle busy)          |     |                   |
|ro           |   Reorder tone               |     |   TO   30 seconds |
|rg           |   Ringing                    |     |   TO   180 seconds|
|r0, r1, r2,  |   Distinctive ringing        |     |   TO   180 seconds|
|r3, r4, r5,  |                              |     |                   |
|r6 or r7     |                              |     |                   |
|rs           |   Ringsplash                 |     |   BR              |
|p            |   Prompt tone                |   x |   BR              |
|e            |   Error tone                 |   x |   BR              |
|sl           |   Stutter dialtone           |     |   TO   16 seconds |
|v            |   Alerting Tone              |     |   OO              |
|y            |   Recorder Warning Tone      |     |   OO              |
|sit          |   SIT tone                   |     |                   |
|z            |   Calling Card Service Tone  |     |   OO              |
|oc           |   Report on completion       |   x |                   |
|ot           |   Off hook warning tone      |     |   TO   indefinite |
|s(###)       |   Distinctive tone pattern   |   x |   BR              |
|of           |   report failure             |   x |                   |
|_____________|______________________________|_____|___________________|

Top      Up      ToC       Page 117 
   The definition of the tones is as follows:

   Dial tone:
      A combined 350 + 440 Hz tone.

   Visual Message Waiting Indicator
      The transmission of the VMWI messages will conform to the
      requirements in Section 2.3.2, "On-hook Data Transmission Not
      Associated with Ringing" in TR-H-000030 and the CPE guidelines in
      SR-TSV-002476. VMWI messages will only be sent from the SPCS when
      the line is idle. If new messages arrive while the line is busy,
      the VMWI indicator message will be delayed until the line goes
      back to the idle state. The CA should periodically refresh the
      CPE's visual indicator. See TR-NWT-001401 - Visual Message Waiting
      Indicator Generic Requirements; and GR- 30-CORE - Voiceband Data
      Transmission Interface.

   Message waiting Indicator
      See GR-506-CORE, 17.2.3.

   Alerting Tone:
      a 440 Hz Tone of 2 second duration followed by 1/2 second of tone
      every 10 seconds.

   Ring splash
      Ringsplash, also known as "Reminder ring" is a burst of ringing
      that may be applied to the physical forwarding line (when idle) to
      indicate that a call has been forwarded and to remind the user
      that a CF subfeature is active.  In the US, it is defined to be a
      0.5(-0,+0.1) second burst of power ringing. See TR-TSY-000586 -
      Call Forwarding Subfeatures.

   Call waiting tone
      Call Waiting tone is defined in GR-506-CORE, 14.2. Call Waiting
      feature is defined in TR-TSY-000571. By defining "wt" as a TO
      signal you are really defining the feature which seems wrong to me
      (given the spirit of MGCP), hence the definition of "wt" as a BR
      signal in ECS, per GR-506-CORE. Also, it turns out that there is
      actually four different call waiting tone patterns (see GR-506-
      CORE, 14.2) so we have wt1, wt2, wt3, wt4.

   Caller Id (ci(time, number, name)):
      The caller-id event carries three parameters, the time of the
      call, the calling number and the calling name. Each of the three
      fields are optional, however each of the commas will always be
      included.  See TR-NWT-001188, GR-30-CORE, and TR-NWT-000031.

Top      Up      ToC       Page 118 
   Recorder Warning Tone:
      1400 Hz of Tone of 0.5 second duration every 15 seconds.

   SIT tone:
      used for indicating a line is out of service.

   Calling Card Service Tone:
      60 ms of 941 + 1477 Hz and 940 ms of 350 + 440 Hz (dial tone),
      decaying exponentially with a time constant of 200 ms.

   Distinctive tone pattern:
      where ### is any number between 000 and 999, inclusive.  Can be
      used for distinctive ringing, customized dial tone, etc.

   Report on completion
      The report on completion event is detected when the gateway was
      asked to perform one or several signals of type TO on the
      endpoint, and when these signals were completed without being
      stopped by the detection of a requested event such as off-hook
      transition or dialed digit.  The completion report may carry as
      parameter the name of the signal that came to the end of its live
      time, as in:

            O: L/oc(L/dl)

   Ring back on connection
      A ring back tone, applied to the connection wghose identifier is
      passed as a parameter.

   We should note that many of these definitions vary from country to
   country.  The frequencies listed above are the one in use in North
   America.  There is a need to accommodate different tone sets in
   different countries, and there is still an ongoing debate on the best
   way to meet that requirement:

   *  One solution is to define different event packages specifying for
      example the German dialtone as "L-DE/DL".

   *  Another solution is to use a management interface to specify on an
      endpoint basis which frequency shall be associated to what tone.

Top      Up      ToC       Page 119 
6.1.6.  Handset emulation package

   Package Name: H

________________________________________________________________________
|Symbol       |   Definition                 |   R |   S    Duration   |
|_____________|______________________________|_____|___________________|
|adsi(string) |   adsi display               |   x |   BR              |
|tdd          |                              |     |                   |
|vmwi         |                              |     |                   |
|hd           |   Off hook transition        |   x |   OO              |
|hu           |   On hook transition         |   x |   OO              |
|hf           |   Flash hook                 |   x |   BR              |
|aw           |   Answer tone                |   x |   OO              |
|bz           |   Busy tone                  |   x |   OO              |
|wt           |   Call Waiting tone          |   x |   TO   30 seconds |
|dl           |   Dial tone (350 + 440 Hz)   |   x |   TO   120 seconds|
|nbz          |   Network busy               |   x |   OO              |
|             |   (fast cycle busy)          |     |                   |
|rg           |   Ringing                    |   x |   TO   30 seconds |
|r0, r1, r2,  |   Distinctive ringing        |   x |   TO   30 seconds |
|r3, r4, r5,  |                              |     |                   |
|r6 or r7     |                              |     |                   |
|p            |   Prompt tone                |   x |   BR              |
|e            |   Error tone                 |   x |   BR              |
|sdl          |   Stutter dialtone           |   x |   TO   16 seconds |
|v            |   Alerting Tone              |   x |   OO              |
|y            |   Recorder Warning Tone      |   x |   OO              |
|t            |   SIT tone                   |   x |                   |
|z            |   Calling Card Service Tone  |   x |   OO              |
|oc           |   Report on completion       |   x |                   |
|ot           |   Off hook warning tone      |   x |   OO              |
|s(###)       |   Distinctive tone pattern   |   x |   BR              |
|of           |   report failure             |   x |                   |
|_____________|______________________________|_____|___________________|


   The handset emulation package is an extension of the line package, to
   be used when the gateway is capable of emulating a handset.  The
   difference with the line package is that events such as "off hook"
   can be signalled as well as detected.

Top      Up      ToC       Page 120 
6.1.7.  RTP Package

   Package Name: R

    ____________________________________________________________________
   | Symbol  |   Definition                   |   R |   S      Duration|
   |_________|________________________________|_____|__________________|
   | UC      |   Used codec changed           |   x |                  |
   | SR(###) |   Sampling rate changed        |   x |                  |
   | JI(###) |   Jitter buffer size changed   |   x |                  |
   | PL(###) |   Packet loss exceeded         |   x |                  |
   | qa      |   Quality alert                |   x |                  |
   | co1     |   Continuity tone (single tone,|   x |   OO             |
   |         |   or return tone)              |     |                  |
   | co2     |   Continuity test (go tone,    |   x |   OO             |
   |         |  in dual tone procedures)      |     |                  |
   | of      |   report failure               |   x |                  |
   |_________|________________________________|_____|__________________|

   Codec Changed:
      Codec changed to hexadecimal codec number enclosed in parenthesis,
      as in UC(15), to indicate the codec was changed to PCM mu-law.
      Codec Numbers are specified in RFC 1890, or in a new definition of
      the audio profiles for RTP that replaces this RFC.  Some
      implementations of media gateways may not allow the codec to be
      changed upon command from the call agent.  codec changed to codec
      hexadecimal ##.

   Sampling Rate Changed:
      Sampling rate changed to decimal number in milliseconds enclosed
      in parenthesis, as in SR(20), to indicate the sampling rate was
      changed to 20 milliseconds.  Some implementations of media
      gateways may not allow the sampling rate to be changed upon
      command from a call agent.

   Jitter Buffer Size Changed:
      When the media gateway has the ability to automatically adjust the
      depth of the jitter buffer for received RTP streams, it is useful
      for the media gateway controller to receive notification that the
      media gateway has automatically increased its jitter buffer size
      to accomodate increased or decreased variability in network
      latency.  The syntax for requesting notification is "JI", which
      tells the media gateway that the controller wants notification of
      any jitter buffer size changes.  The syntax for notification from
      the media gateway to the controller is "JI(####)", where the ####
      is the new size of the jitter buffer, in milliseconds.

Top      Up      ToC       Page 121 
   Packet Loss Exceeded:
      Packet loss rate exceed the threshold of the specified decimal
      number of packets per 100,000 packets, where the packet loss
      number is contained in parenthesis.  For example, PL(10) indicates
      packets are being dropped at a rate of 1 in 10,000 packets.

   Quality alert
      The packet loss rate or the combination of delay and jitter exceed
      a specified quality threshold.

   The continuity tones are the same as those defined in the Trunk
   package.  They can be use in conjunction with the Network LoopBack or
   Network Continuity Test modes to test the continuity of an RTP
   circuit.

   The "operation failure" code can be used to report problems such as
   the loss of underlying connectivity.  The observed event can include
   as parameter the reason code of the failure.

6.1.8.  Network Access Server Package

   Package Name: N

       ____________________________________________________________
      | Symbol |   Definition             |   R |   S     Duration|
      |________|__________________________|_____|_________________|
      | pa     |  Packet arrival          |  x  |                 |
      | cbk    |  Call back request       |  x  |                 |
      | cl     |  Carrier lost            |  x  |                 |
      | au     |   Authorization succeeded|  x  |                 |
      | ax     |   Authorization denied   |  x  |                 |
      | of     |   Report failure         |  x  |                 |
      |________|__________________________|_____|_________________|


   The packet arrival event is used to notify that at least one packet
   was recently sent to an Internet address that is observed by an
   endpoint.  The event report includes the Internet address, in
   standard ASCII encoding, between parenthesis:

         O: pa(192.96.41.1)

   The call back event is used to notify that a call back has been
   requested during the initial phase of a data connection. The event
   report includes the identification of the user that should be called
   back, between parenthesis:

         O: cbk(user25)

Top      Up      ToC       Page 122 
6.1.9.  Announcement Server Package

   Package Name: A

    ___________________________________________________________________
   | Symbol         |   Definition           |   R |   S      Duration|
   |________________|________________________|_____|__________________|
   | ann(url,parms) |   Play an announcement |     |   TO     variable|
   | oc             |   Report on completion |   x |                  |
   | of             |   Report failure       |   x |                  |
   |________________|________________________|_____|__________________|

   The announcement action is qualified by an URL name and by a set of
   initial parameters as in for example:

         S: ann(http://scripts.example.net/all-lines-busy.au)

   The "operation complete" event will be detected when the announcement
   is played out. If the announcement cannot be played out, an operation
   failure event can be returned.  The failure may be explained by a
   commentary, as in:

         O: A/of(file not found)

6.1.10.  Script Package

   Package Name: Script

    ______________________________________________________________
   | Symbol    |   Definition           |   R |   S  |   Duration|
   |___________|________________________|_____|______|___________|
   | java(url) |   Load a java script   |     |   TO |   variable|
   | perl(url) |   Load a perl script   |     |   TO |   variable|
   | tcl(url)  |   Load a TCL script    |     |   TO |   variable|
   | xml(url)  |   Load an XML script   |     |   TO |   variable|
   | oc        |   Report on completion |   x |      |           |
   | of        |   Report failure       |   x |      |           |
   |___________|________________________|_____|______|___________|

   The "language" action define is qualified by an URL name and by a set
   of initial parameters as in for example:

         S: script/java(http://scripts.example.net/credit-
            card.java,long,1234)

Top      Up      ToC       Page 123 
   The current definition defines keywords for the most common
   languages.  More languages may be defined in further version of this
   documents.  For each language, an API specification will describe how
   the scripts can issue local "notificationRequest" commands, and
   receive the corresponding notifications.

   The script produces an output which consists of one or several text
   string, separated by commas.  The text string are reported as a
   commentary in the report on completion, as in for example:

         O: script/oc(21223456794567,9738234567)

   The failure report may also return a string, as in:

         O: script/oc(21223456794567,9738234567)

   The definition of the script environment and the specific actions in
   that environment are for further study.

6.2.  Basic endpoint types and profiles

   We define the following basic endpoint types and profiles:

   *  Trunk gateway (ISUP)

   *  Trunk gateway (MF)

   *  Network Access Server (NAS)

   *  Combined NAS/VOIP gateway

   *  Access Gateway

   *  Residential Gateway

   *  Announcement servers

Top      Up      ToC       Page 124 
   These gateways are supposed to implement the following packages

       ___________________________________________________________
      | Gateway                    |   Supported packages        |
      |____________________________|_____________________________|
      | Trunk gateway (ISUP)       |   GM, DTMF, TK, RTP         |
      | Trunk gateway (MF)         |   GM, MF, DTMF, TK, RTP     |
      | Network Access Server (NAS)|   GM, MF, TK, NAS           |
      | Combined NAS/VOIP gateway  |   GM, MF, DTMF, TK, NAS, RTP|
      | Access Gateway (VOIP)      |   GM, DTMF, MF, RTP         |
      | Access Gateway (VOIP+NAS)  |   GM, DTMF, MF, NAS, RTP    |
      | Residential Gateway        |   GM, DTMF, Line, RTP       |
      | Announcement Server        |   ANN, RTP                  |
      |____________________________|_____________________________|


   Advanced announcement servers may also support the Script package.

   Advanced trunking servers may support the ANN package, the Script
   package, and in some cases the Line and Handset package as well.



(page 124 continued on part 5)

Next RFC Part