tech-invite   World Map     

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

RFC 4780

Proposed STD
Pages: 83
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SIP

Management Information Base for the Session Initiation Protocol (SIP)

Part 1 of 3, p. 1 to 15
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                          K. Lingle
Request for Comments: 4780                           Cisco Systems, Inc.
Category: Standards Track                                      J-F. Mule
                                                               CableLabs
                                                                J. Maeng
                                                               D. Walker
                                                              April 2007


                    Management Information Base for
                 the Session Initiation Protocol (SIP)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that are used to
   manage Session Initiation Protocol (SIP) entities, which include User
   Agents, and Proxy, Redirect and Registrar servers.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................2
   2. Conventions .....................................................2
   3. The Internet-Standard Management Framework ......................2
   4. Overview ........................................................3
   5. Structure of the SIP MIB ........................................3
      5.1. Textual Conventions ........................................6
      5.2. Relationship to the Network Services MIB ...................6
      5.3. IMPORTed MIB Modules and REFERENCE Clauses ................10
   6. Accommodating SIP Extension Methods ............................11
   7. Definitions ....................................................12
      7.1. SIP Textual Conventions ...................................12
      7.2. SIP Common MIB Module .....................................15
      7.3. SIP User Agent MIB Module .................................55
      7.4. SIP Server MIB Module (Proxy, Redirect, and
           Registrar Servers) ........................................59
   8. IANA Considerations ............................................77
   9. Security Considerations ........................................78
   10. Contributor Acknowledgments ...................................80
   11. References ....................................................80
      11.1. Normative References .....................................80
      11.2. Informative References ...................................81

1.  Introduction

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that are used to
   manage Session Initiation Protocol (SIP) entities, which include User
   Agents, and Proxy, Redirect and Registrar servers.  The managed
   objects defined in this document are intended to provide basic SIP
   protocol management for SIP entities.  The management of
   application-specific or service-specific SIP configuration is out of
   scope.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

Top      ToC       Page 3 
   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a set
   of MIB modules that are compliant to the SMIv2, which is described in
   STD 58, comprised of RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC
   2580 [RFC2580].

4.  Overview

   SIP [RFC3261] is an application-layer control (signaling) protocol
   for creating, modifying, and terminating sessions with one or more
   participants.  These sessions include Internet telephone calls,
   multimedia distribution, and multimedia conferences.

   This MIB provides some managed objects for SIP entities defined in
   RFC 3261 [RFC3261] - User Agents (UA), and Proxy, Redirect, and
   Registrar servers.  It is intended to provide management of the basic
   SIP entities.  It provides for monitoring of status and protocol
   statistics, as well as for configuration of SIP entities.

5.  Structure of the SIP MIB

   Four MIB modules are specified: SIP-COMMON-MIB, SIP-SERVER-MIB, SIP-
   UA-MIB, and SIP-TC-MIB.  SIP-COMMON-MIB contains common MIB objects
   used in all the SIP entities.  SIP-SERVER-MIB contains objects
   specific to Proxy, Redirect, and Registrar servers.  SIP-UA-MIB
   includes objects specific to User Agents.  SIP-TC-MIB defines the
   textual conventions used throughout the MIB modules.

   The MIB modules contain the following groups of objects:

   SIP-COMMON-MIB: Management objects common to all the SIP entities

   o  sipCommonMIBObjects

      *  sipCommonCfgBase: This object group defines configuration
         objects common to all SIP entities, including the SIP protocol
         version, the type of SIP entity (UA, proxy, redirect, registrar
         servers), the operational and administrative status, the SIP
         organization name, the maximum number of SIP transactions an
         entity can manage, etc.

      *  sipCommonCfgTimer: This object group defines timer
         configuration objects applicable to SIP user agent and stateful
         SIP proxy entities.

Top      ToC       Page 4 
      *  sipCommonSummaryStats: This object group defines a table
         containing the summary statistics objects applicable to all SIP
         entities, including the total number of all SIP requests and
         responses in/out and the total number of transactions.

      *  sipCommonMethodStats: This object group defines a table
         containing the SIP method statistics objects applicable to all
         SIP entities, including the number of outbound and inbound
         requests on a per method basis.  Retransmissions, where
         appropriate, are also included in these statistics.

      *  sipCommonStatusCode: This object group defines a table
         indicating the number of SIP responses (in and out) that the
         SIP entity has been requested to monitor on a per-method basis
         (100, 200, 302, etc.).

      *  sipCommonStatsTrans: This object group defines a table
         containing a gauge reflecting the number of transactions
         currently awaiting definitive responses by the managed SIP
         entity.

      *  sipCommonStatsRetry: This object group defines statistic
         objects indicating the number of retransmissions sent on a
         per-method basis.

      *  sipCommonOtherStats: This object group defines additional
         statistics objects including the number of SIP requests
         received with unsupported URIs, the number of requests received
         with unsupported SIP methods, and the number of discarded
         messages.

      *  sipCommonNotifObjects: This object group defines objects
         accessible only via a notification (MAX ACCESS clause of
         accessible-for-notify): they are related to the SNMP
         notifications defined in this MIB module.

   The SIP-COMMON-MIB also contains notifications, including:

   o  sipCommonStatusCodeNotif: indicates that a specific status code
      has been sent or received by the system.

   o  sipCommonStatusCodeThreshExceededNotif: indicates that a specific
      status code has been sent or received by the system frequently
      enough to exceed the configured threshold.

Top      ToC       Page 5 
   SIP-SERVER-MIB: Groups of objects for SIP Proxy, Redirect, and
   Registrar servers

   o  sipServerMIBObjects

      *  sipServerCfg: This object group defines common server
         configuration objects including the SIP server host address.

      *  sipServerProxyCfg: This object group defines configuration
         objects for SIP Proxy Servers including the proxy mode of
         operation (stateless, stateful, call stateful), the proxy
         authentication method(s), realm, etc.

      *  sipServerProxyStats: This object group defines a table
         containing the statistics objects applicable to SIP Proxy
         Servers.  It includes the number of occurrences of unsupported
         options being specified in received Proxy-Require headers.

      *  sipServerRegCfg: This object group defines common configuration
         objects for SIP Registrar servers, including the ability to
         accept third-party registrations, such as the maximum
         registration expiry that may be requested by user agents, the
         maximum number of users the registrar can support, the number
         of currently registered users, per contact registration
         information, etc.

      *  sipServerRegStats: This object group contains summary
         statistics objects for SIP Registrar servers.  Precisely, it
         contains the number of REGISTER requests that have been
         accepted or rejected.

   SIP-UA-MIB: Group of objects for SIP User Agents

   o  sipUAMIBObjects

      *  sipUACfgServer: This object group specifies SIP server
         configuration objects applicable to SIP user agents including
         the Internet address of the SIP Server the UA uses to register,
         proxy, or redirect calls.

   To conform with this specification, an SNMP agent MUST implement the
   SIP-TC-MIB module, plus the SIP-COMMON-MIB module and one of the SIP
   entity-type-specific MIB modules (SIP-SERVER-MIB or SIP-UA-MIB) as
   applicable for each instance of a SIP entity being managed.  If a
   device has more than one SIP entity or multiple instances of the same
   entity type, it MUST implement multiple SIP modules.  Section 5.2
   describes handling of multiple instances in detail.

Top      ToC       Page 6 
5.1.  Textual Conventions

   The data types SipTCTransportProtocol, SipTCEntityRole,
   SipTCOptionTagHeaders, and SipTCMethodName are defined in the SIP-
   TC-MIB module and used as Textual Conventions in this document.

5.2.  Relationship to the Network Services MIB

   In the design of the SIP MIB, the authors considered the following
   requirement: the SIP MIB must allow a single system with a single
   SNMP agent to support multiple instances of various SIP MIB modules.
   This requirement is met by using the framework provided by the
   Network Services Monitoring MIB, NETWORK-SERVICES-MIB, RFC 2788
   [RFC2788].

   A device implementing the SIP MIB MUST support the NETWORK-SERVICES-
   MIB and, at a minimum, MUST support the index and name objects
   (applIndex and applName) in the application table (applTable).  In
   order to allow each instance of a SIP entity to be managed as a
   separate network service application, a naming convention SHOULD be
   used to make the application name unique.  For example, if a system
   is running 2 SIP UAs that need to be managed as 2 separate SIP
   entities, by convention, the application names used in the Network
   Services Monitoring MIB application table should be "sip_ua1" and
   "sip_ua2".  This convention allows each instance to have its own row
   in the application table (applTable).

   It is therefore RECOMMENDED that the following application name
   conventions be adopted:

   o  for a SIP Proxy entity, the applName value SHOULD be equal to a
      character string starting with "sip_proxy" followed by a unique
      application instance identifier, for example, "sip_proxy1",
      "sip_proxy17".

   o  for a SIP Registrar entity, the applName value SHOULD be equal to
      a character string starting with "sip_registrar" followed by a
      unique application instance identifier, for example,
      "sip_registrar1", "sip_registrar2".

   o  for a SIP User Agent entity, the applName value SHOULD be equal to
      a character string starting with "sip_ua" followed by a unique
      application instance identifier, for example, "sip_ua1",
      "sip_ua2".

Top      ToC       Page 7 
   o  for any combination of Proxy, Registrar, or Redirect Server being
      managed as a single aggregate entity, the applName value for the
      combined server entity SHOULD reflect the appropriate combination
      followed by a unique application instance identifier.  In order to
      facilitate consistent agent behavior and management application
      expectations, the following order of names is RECOMMENDED:

         *  if Proxy exists, list first.
         *  if Proxy and Redirect exists, list Redirect second.
         *  if Registrar exists, always list last.

      For example "sip_proxy1", "sip_proxy_registrar1",
      "sip_proxy_redirect5", "sip_proxy_redirect_registrar2", or
      "sip_registrar1".

   o  Note: the value of the network service application index
      (applIndex) may be different from the instance identifier used in
      the system (the applIndex is dynamically created and is the value
      assigned by the SNMP agent at the creation of the table entry,
      whereas the value of the instance identifier to be used in the
      application name is provided as part of the application name
      applName by the system administrator or configuration files of the
      SIP entity).  This note is illustrated in the first example
      provided below.

   Finally, the SNMP agent MAY support any combination of the other
   attributes in applTable.  If supported, the following objects SHOULD
   have values populated as follows:

   o  applVersion: version of the SIP application.

   o  applUptime: the value of applUptime MUST be identical to the value
      of sipCommonCfgServiceStartTime defined in the SIP-COMMON-MIB
      module.

   o  applOperStatus: the value of applOperStatus SHOULD reflect the
      operational status of sipCommonCfgServiceOperStatus, at least by
      means of a mapping.

   o  applLastChange: the value of applLastChange MUST be identical to
      the value of sipCommonCfgServiceLastChange defined in the SIP-
      COMMON module.

   A number of other objects are defined as part of the applTable.  They
   are not included for the sake of brevity and due to the fact that
   they do not enhance the concept being presented.

Top      ToC       Page 8 
   Example 1:

   The tables below illustrate how a system acting as both Proxy and
   Registrar server might be configured to maintain separate SIP-
   COMMON-MIB instances.

   The NETWORK-SERVICES-MIB applTable might be populated as follows:

            +-----------+-------------------+----------------------+
            | applIndex |      applName     |    applDescription   |
            +-----------+-------------------+----------------------+
            |     1     |   "sip_proxy10"   |   "ACME SIP Proxy"   |
            |     2     | "sip_registrar17" | "ACME SIP Registrar" |
            +-----------+-------------------+----------------------+

   The SIP-COMMON-MIB sipCommonCfgTable would have two rows: one for the
   proxy (applIndex=1) and one for the registrar (applIndex=2).  The
   SIP-SERVER-MIB tables would, however, only be populated with one row
   indexed by applIndex=1 and applIndex=2, respectively, if the server
   provides either proxy or registrar.

   The SIP-COMMON-MIB sipCommonCfgTable might be populated as:

   +---------+------------------------+--------------------------+-----+
   |applIndex| sipCommonCfgProtocol   | sipCommonCfgServiceOper  | ... |
   |         | Version                | Status                   |     |
   +---------+------------------------+--------------------------+-----+
   |    1    |        "SIP/2.0"       |           up(1)          |     |
   |    2    |        "SIP/2.0"       |       restarting(4)      |     |
   +---------+------------------------+--------------------------+-----+

   while the sipServerProxyCfgTable in SIP-SERVER-MIB might be populated
   as:

            +-----------+-------------------------------+-----+
            | applIndex | sipServerCfgProxyStatefulness | ... |
            +-----------+-------------------------------+-----+
            |     1     |          stateless(1)         |     |
            +-----------+-------------------------------+-----+

Top      ToC       Page 9 
   and the sipServerRegUserTable in SIP-SERVER-MIB might be populated
   as:

      +-----------+-----------------------+---------------------+-----+
      | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
      +-----------+-----------------------+---------------------+-----+
      |     2     |           1           |   bob@example.com   |     |
      |     2     |           2           |  alice@example.com  |     |
      |     2     |           3           |   jim@example.com   |     |
      |     2     |           4           |   john@example.com  |     |
      +-----------+-----------------------+---------------------+-----+

   Example 2:

   This example illustrates how to represent a system acting as both
   Proxy and Registrar server, where the two entities share a single
   instance of SIP-COMMON-MIB.

   The NETWORK-SERVICES-MIB applTable might be populated as follows:

   +-----------+------------------------+------------------------------+
   | applIndex |        applName        |        applDescription       |
   +-----------+------------------------+------------------------------+
   |     1     | "sip_proxy_registrar1" |      "ACME SIP Proxy and     |
   |           |                        |          Registrar"          |
   +-----------+------------------------+------------------------------+

   The SIP-COMMON-MIB sipCommonCfgTable would have only one row to cover
   both the proxy and the registrar.

   The SIP-COMMON-MIB sipCommonCfgTable might be populated as:

  +----------+---------------------------+-----------------------------+
  |applIndex |sipCommonCfgProtocolVersion|sipCommonCfgServiceOperStatus|
  +----------+---------------------------+-----------------------------+
  |     1    |         "SIP/2.0"         |            up(1)            |
  +----------+---------------------------+-----------------------------+

Top      ToC       Page 10 
   while the sipServerRegUserTable in SIP-SERVER-MIB might be populated
   as:

      +-----------+-----------------------+---------------------+-----+
      | applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
      +-----------+-----------------------+---------------------+-----+
      |     2     |           1           |   bob@example.com   |     |
      |     2     |           2           |  alice@example.com  |     |
      |     2     |           3           |  kevin@example.com  |     |
      |     2     |           4           |    jf@example.com   |     |
      +-----------+-----------------------+---------------------+-----+

   The NETWORK-SERVICES-MIB assocTable is not considered a requirement
   for SIP systems.  It is not a mandatory group for compliance with the
   NETWORK-SERVICES-MIB module.

   The relationship between the value of applOperStatus and
   sipCommonCfgServiceOperStatus is as follows:

   +-------------------------------+---------------+-------------------+
   | sipCommonCfgServiceOperStatus |       --      |   applOperStatus  |
   |                               |  corresponds  |                   |
   |                               |     to -->    |                   |
   +-------------------------------+---------------+-------------------+
   |               up              |      -->      |         up        |
   |              down             |      -->      |        down       |
   |           congested           |      -->      |     congested     |
   |           restarting          |      -->      |     restarting    |
   |           quiescing           |      -->      |     quiescing     |
   |            testing            |      -->      |         up        |
   |            unknown            |      -->      | --indeterminate-- |
   +-------------------------------+---------------+-------------------+

   If the sipOperStatus is 'unknown', there is no corresponding value of
   applOperStatus.  Therefore, the last known value of applOperStatus
   SHOULD be maintained until the sipOperStatus transitions to a value
   that can be mapped appropriately.

5.3.  IMPORTed MIB Modules and REFERENCE Clauses

   The SIP MIB modules defined in this document IMPORT definitions
   normatively from the following MIB modules, beyond [RFC2578],
   [RFC2579], and [RFC2580]: INET-ADDRESS-MIB [RFC4001], NETWORK-
   SERVICES-MIB [RFC2788], SNMP-FRAMEWORK-MIB [RFC3411].

   This MIB module also includes REFERENCE clauses that normatively
   refer to SIP [RFC3261] and INET-ADDRESS-MIB [RFC4001].

Top      ToC       Page 11 
   Finally, this MIB module makes informative references to several RFCs
   in some of the examples described in the DESCRIPTION clauses,
   including Reliability of Provisional Responses in SIP [RFC3262] and
   SIP over SCTP [RFC4168].

6.  Accommodating SIP Extension Methods

   The core set of SIP methods is defined in RFC 3261 [RFC3261].  Other
   IETF RFCs define additional methods.  In the future, additional
   methods may be defined.  In order to avoid having to update the SIP-
   COMMON-MIB module to accommodate these extension methods, we use a
   method identifier name (SipTCMethodName TEXTUAL-CONVENTION) to
   represent all SIP methods registered with IANA.

   For example, the sipCommonMethodSupportedTable is the main table for
   listing all of the SIP methods supported by a system, including the
   SIP methods defined in RFC 3261 [RFC3261] and other SIP methods
   registered with IANA.  The table is informational in nature and
   populated by the system.  Entries cannot be added or deleted by an
   SNMP manager.

   The SIP specification (RFC 3261 [RFC3261], Section 27.4) establishes
   the sub-registries for SIP Methods and Response Codes under
   http://www.iana.org/assignments/sip-parameters.  This document uses
   the existing sub-registry for the names of registered SIP methods.

   For example, in the sipCommonMethodSupportedTable of SIP-COMMON-MIB,
   the sipCommonMethodSupportedName values can be represented as
   follows:

                +------------------------------+
                | sipCommonMethodSupportedName |
                +------------------------------+
                |             "ACK"            |
                |             "BYE"            |
                |           "CANCEL"           |
                |           "INVITE"           |
                |           "OPTIONS"          |
                +------------------------------+

Top      ToC       Page 12 
7.  Definitions

7.1.  SIP Textual Conventions

SIP-TC-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY,
    mib-2
          FROM SNMPv2-SMI        -- RFC 2578

    TEXTUAL-CONVENTION
          FROM SNMPv2-TC;        -- RFC 2579

sipTC MODULE-IDENTITY
    LAST-UPDATED "200704200000Z"
    ORGANIZATION "IETF Session Initiation Protocol Working Group"
    CONTACT-INFO
             "SIP WG email: sip@ietf.org

              Co-editor  Kevin Lingle
                         Cisco Systems, Inc.
              postal:    7025 Kit Creek Road
                         P.O. Box 14987
                         Research Triangle Park, NC 27709
                         USA
              email:     klingle@cisco.com
              phone:     +1 919 476 2029

              Co-editor  Joon Maeng
              email:     jmaeng@austin.rr.com

              Co-editor  Jean-Francois Mule
                         CableLabs
              postal:    858 Coal Creek Circle
                         Louisville, CO 80027
                         USA
              email:     jf.mule@cablelabs.com
              phone:     +1 303 661 9100

              Co-editor  Dave Walker
              email:     drwalker@rogers.com"
    DESCRIPTION
       "Session Initiation Protocol (SIP) MIB TEXTUAL-CONVENTION
        module used by other SIP-related MIB Modules.

        Copyright (C) The IETF Trust (2007).  This version of
        this MIB module is part of RFC 4780; see the RFC itself for

Top      ToC       Page 13 
        full legal notices."
    REVISION     "200704200000Z"
    DESCRIPTION
       "Initial version of the IETF SIP-TC-MIB module.  This version
        published as part of RFC 4780."
     ::= { mib-2 148 }

--
-- Textual Conventions
--

SipTCTransportProtocol ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention is a bit map.  Each bit represents a transport
        protocol.  If a bit has value 1, then that selected transport
        protocol is in some way dependent on the context of the object
        using this convention.  If a bit has value 0, then that
        transport protocol is not selected.  Combinations of bits can
        be set when multiple transport protocols are selected.

        bit 0: a protocol other than those defined here
        bit 1: User Datagram Protocol
        bit 2: Transmission Control Protocol
        bit 3: Stream Control Transmission Protocol
        bit 4: Transport Layer Security Protocol over TCP
        bit 5: Transport Layer Security Protocol over SCTP
       "
    REFERENCE "RFC 3261, Section 18 and RFC 4168"
    SYNTAX      BITS {
                  other(0),  -- none of the following
                  udp(1),
                  tcp(2),
                  sctp(3),   -- RFC4168
                  tlsTcp(4),
                  tlsSctp(5) -- RFC 4168
                }

SipTCEntityRole ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention defines the role of a SIP entity.  Examples of
        SIP entities are proxies, user agents, redirect servers,
        registrars, or combinations of the above.

        User Agent (UA): A logical entity that can act as both a user
        agent client and user agent server.

Top      ToC       Page 14 
        User Agent Client (UAC): A logical entity that creates a new
        request, and then uses the client transaction state machinery
        to send it.  The role of UAC lasts only for the duration of
        that transaction.  In other words, if a piece of software
        initiates a request, it acts as a UAC for the duration of that
        transaction.  If it receives a request later, it assumes the
        role of a user agent server for the processing of that
        transaction.

        User Agent Server (UAS): A logical entity that generates a
        response to a SIP request.  The response accepts, rejects,
        or redirects the request.  This role lasts only for the
        duration of that transaction.  In other words, if a piece of
        software responds to a request, it acts as a UAS for the
        duration of that transaction.  If it generates a request
        later, it assumes the role of a user agent client for the
        processing of that transaction.

        Proxy, Proxy Server: An intermediary entity that acts as both
        a server and a client for the purpose of making requests on
        behalf of other clients.  A proxy server primarily plays the
        role of routing, which means its job is to ensure that a
        request is sent to another entity 'closer' to the targeted
        user.  Proxies are also useful for enforcing policy.  A proxy
        interprets and, if necessary, rewrites specific parts of a
        request message before forwarding it.

        Redirect Server: A redirect server is a user agent server that
        generates 3xx responses to requests it receives, directing the
        client to contact an alternate set of URIs.

        Registrar: A registrar is a server that accepts REGISTER
        requests and places the information it receives in those
        requests into the location service for the domain it handles."
    REFERENCE
       "RFC 3261, Section 6"
    SYNTAX      BITS {
                  other(0),
                  userAgent(1),
                  proxyServer(2),
                  redirectServer(3),
                  registrarServer(4)
                }

SipTCOptionTagHeaders ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This convention defines the header fields that use the option

Top      ToC       Page 15 
        tags per Section 19.2 of RFC 3261.  These tags are used in
        Require (Section 20.32), Proxy-Require (Section 20.29),
        Supported (Section 20.37), and Unsupported (Section 20.40)
        header fields."
    REFERENCE
       "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40"
    SYNTAX      BITS {
                  require(0),       -- Require header
                  proxyRequire(1),  -- Proxy-Require header
                  supported(2),     -- Supported header
                  unsupported(3)    -- Unsupported header
                }

SipTCMethodName ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
       "This TEXTUAL-CONVENTION is a string that uniquely identifies a
        SIP method.  The scope of uniqueness is the context of all
        defined SIP methods.

        Experimental support of extension methods is acceptable and
        expected.  Extension methods are those defined in
        Internet-Draft documents but not yet allocated and
        officially sanctioned by IANA.

        To support experimental extension methods, any object using
        this TEXTUAL-CONVENTION as syntax MAY return/accept a method
        identifier value other than those sanctioned by IANA.  That
        system MUST ensure no collisions with officially assigned
        method names."
    REFERENCE
       "RFC 3261, Section 27.4"
    SYNTAX      OCTET STRING (SIZE (1..100))

END



(page 15 continued on part 2)

Next RFC Part