rfc3149.txt

RFC 的详细文档！

      This signal is used to indicate the state of a feature key.  It
      should be ignored by phones without this capability.

      This signal has two parameters: key number and state.  The key
      number maps directly to the feature key number.  The state is a
      high level description of the state of the key.  This allows
      different phones to implement different indications of state.  For
      example, Phone A may have a multi-color LED associated with
      feature keys that can blink at different cadences.  Phone B might
      have an LCD beside the keys that can display text or icons.  It is
      up to each phone vendor to determine how to present the state
      indication.

      The following states are used:

       ______________________
      | State | Definition   |
      |_______|______________|
      |  en   | enabled      |
      |  db   | disabled     |
      |  id   | idle         |
      |  dt   | dial tone    |
      |  cn   | connected    |
      |  dc   | disconnected |
      |  rg   | ringing      |
      |  rb   | ringback     |
      |  ho   | holding      |
      |  he   | held         |
      |_______|______________|

      For example: an RQNT with "S: KY/ks(5,en)" will cause an indicator
      corresponding to fk5 to indicate that it is enabled.  An RQNT with
      "S: KY/ks(2,rg)" will cause an indicator corresponding to fk2 to
      indicate that it is ringing.

   "en" state

      The associated feature is enabled.  Used for keys that turn a
      feature on or off, such as "Do Not Disturb."

   "db" state

      The associated feature is disabled.  Used for keys that turn a
      feature on or off, such as "Do Not Disturb."





Srinath, et al.              Informational                      [Page 7]

RFC 3149              MGCP Business Phone Packages        September 2001


   "id" state

      The specified line appearance is in the idle state, available for
      a call.

   "dt" state

      The specified line appearance is providing dial-tone.

   "cn" state

      The specified line appearance is actively in a call, in the
      connected state.

   "dc" state

      The specified line appearance is disconnected, but the
      corresponding line is still active (the user is still offhook).

   "rg" state

      The specified line appearance is terminating an incoming call, in
      the ringing state.

   "rb" state

      The specified line appearance is originating an outgoing call, in
      the ringing-back state.

   "ho" state

      The specified line appearance is in the holding state, with the
      far end held.

   "he" state

      The specified line appearance is in the held state, with the far
      end holding.

   Set Label (ls)

      This signal is used to set the label on a key.  This is used for
      phones that have an LCD next to the feature keys.  It should be
      ignored by phones without this capability.

      This signal has 2 parameters: key number and label.  The key
      number maps directly to the feature key number.  The label is free
      form text, restricted to the capabilities of the phone.



Srinath, et al.              Informational                      [Page 8]

RFC 3149              MGCP Business Phone Packages        September 2001


      For example, an RQNT with "S: KY/ls(1,2200)" sets the label next
      to the fk1 feature key to the string "2200" (a phone extension).

2.2 Business Phone Package

   Package Name: BP

   The Business Phone Package groups signals other than those related to
   feature keys and displays.

 ____________________________________________________________________
| Symbol   |   Definition               |   R |   S      Duration    |
|__________|____________________________|_____|______________________|
| hd       | Force Offhook              |     |   OO                 |
| hu       | Force Onhook               |     |   OO                 |
| beep     | Beep                       |     |   BR                 |
|__________|____________________________|_____|______________________|

   Force Offhook (hd)

      This signal is used to force the phone offhook.  If the phone has
      a speaker phone, it should be activated.  This signal can be
      negated by the user by hanging up.

      This can be used if a feature key causes a call to be initiated.
      See the sample call flow in Appendix C.

      This can also be used for application integration.  For example, a
      user could select a number in an application on their PC, and the
      phone would be forced offhook and a call initiated.

   Force Onhook (hu)

      This signal forces the phone onhook.  This can be used when the
      far-end disconnects, or if a feature key causes a call to be
      terminated.

   Beep (beep)

      Play a beep on the phone.

2.3 Display XML Package

   Package Name: XML

   The XML Package contains one event/signal that is used to convey XML
   data to and from the phone.




Srinath, et al.              Informational                      [Page 9]

RFC 3149              MGCP Business Phone Packages        September 2001


 _____________________________________________________________________
| Symbol   |   Definition               |   R |   S      Duration    |
|__________|____________________________|_____|______________________|
| xml      | XML Data                   |   x |   OO                 |
|__________|____________________________|_____|______________________|

   XML Data (xml)

      As an event, if this event is requested in an RQNT with "R:
      XML/xml", any posts of data from an XML script are returned in an
      NTFY with "O: XML/xml(post data here)".

      As a signal, the parameterized data indicates a URL to an XML
      script (possibly local), as well as substitution values that
      depend on the XML script selected.  See section 5 for more
      information.

3. Endpoint Naming and Phone Type Determination

   Because the display state can be asynchronous from the signaling
   state of the phone, it is desirable to address the display as a
   separate MGCP endpoint.

   For example, suppose a call is presented to the phone, and a display
   is presented that gives the user the option of redirecting the caller
   immediately to voice-mail.  Selecting the option via the display
   would cause an XML post to occur, cancelling any timeout signals (the
   ringing).

   In order to simplify the handling of such scenarios, it is expected
   that the related display have a different MGCP endpoint name, created
   by inserting a prefix before the phone endpoint name.  The prefix
   used shall be "disp/".

   For example, if the phone endpoint has the name
   "[e-mail]", the display endpoint would be named
   "disp/[e-mail]".

   The Call Agent must be able to determine which feature key number
   corresponds to a particular pre-assigned function.  For example, one
   phone may have the pre-assigned functions of 'redial' and 'hold'
   mapped to feature keys numbered fk1 and fk23, respectively. Another
   phone may not report fk23 at all, and have the pre-assigned function
   of 'transfer' mapped to fk1.  Also, since the programming of feature
   keys would be resident in the Call Agent, a user-interface that






Srinath, et al.              Informational                     [Page 10]

RFC 3149              MGCP Business Phone Packages        September 2001


   allows the programming of these keys must know the keys supported on
   the phone, in order for the Call Agent to request the appropriate
   feature keys.

   Determination of such basic capabilities must occur at the moment
   when the phone sends its first RSIP message to a Call Agent.  While
   it might be possible to define packages with events and signals that
   allow for an exhaustive discovery of the layout of a particular
   phone, a simpler and more reasonable approach would be for the Call
   Agent to discover the make and model of the phone, and thus determine
   the capabilities of the phone.  To this end, an experimental
   parameter, "X-UA" has been introduced for use in the Requested-Info
   field (F:) of the AUEP method.  The response to the "X-UA" is
   expected to be a string that uniquely identifies the make and model
   of the phone.  Note that per RFC 2705, a Gateway must ignore
   experimental parameters prefixed as "X-" that it cannot support,
   versus respond with an error code such as 511 (Unrecognized
   extension).  See the sample call flow in Appendix C.

4. Functions that should be Locally Implemented

   Some functions should be implemented locally on the Gateway.  These
   are listed in the following sections.

4.1 Volume Control

   Volume for ringing, handset, and speaker phone should be implemented
   locally on the Gateway.

4.2 Audio Path

   If the phone includes a speaker phone, activating the speaker phone
   from the idle state should generate an offhook (L/hd) event.  The
   user should then be able to switch to handset mode by lifting the
   handset, and be able to switch back to speaker phone mode without any
   interaction with the Call Agent.  De-activating the speaker phone
   with the handset on-hook should generate an onhook (L/hu) event.

4.3 Microphone mute button and light

   If the phone includes a microphone mute button and (optionally) an
   associated indicator (e.g., light), the functionality of these items
   should be implemented locally on the Gateway.








Srinath, et al.              Informational                     [Page 11]

RFC 3149              MGCP Business Phone Packages        September 2001


5. XML Package Support

   Not all business phones have the same display and keypad
   capabilities.  To support these varying devices in a consistent
   manner, this section outlines an XML framework that is used to drive
   the phone.  In this framework, the Call Agent pushes XML requests to
   the Gateway using MGCP signals.  These XML requests indicate the XML
   document that is to be rendered on the phone.

   When a user inputs data or makes a selection from a display, the
   Gateway "posts" an XML request to the Call Agent using MGCP events.

5.1 XML Documents

   When an XML signal request is sent to an endpoint, it indicates the
   XML documents that the endpoint must process.  These documents
   contain tags that are a subset of the Wireless Markup Language (WML)
   [3] plus some non-WML additions.  These tags specify items to be
   displayed as well as XML events that may be reported as the result of
   user input.

   Each XML document, known as a card, defines a user interaction.  A
   group of cards is called a deck.  One or more decks define an
   application.  The cards define soft key behavior as well as display
   behavior, and are mapped to components that implement the behavior of
   a basic graphical user interface on the display phone.  Based on the
   available requirements, the components needed are:

      - Input box:

        allows user input, including editing capabilities, via the
        keypad.

      - Enumerated list box:

        allows the user to select one of a list of items.

      - Itemized list box:

        allows the user to select an item using a soft key.

      - Text box:

        displays read-only text to the user.

      - Echo box:

        displays but does not process user input.



Srinath, et al.              Informational                     [Page 12]

RFC 3149              MGCP Business Phone Packages        September 2001


   A card may have the following properties.

      1. Timed content (e.g., card expiration)
      2. Static content  (e.g., text)
      3. Dynamic content (e.g., call timers/time)

   Additionally, cards may also contain variables to be substituted for
   values that are specified in an XML request.  See section 5.2 for