SIP Working Group K. Lingle Internet-Draft Cisco Systems, Inc. Expires: August 1, 2005 J. Mule CableLabs J. Maeng D. Walker January 28, 2005 Management Information Base for Session Initiation Protocol (SIP) draft-ietf-sip-mib-09.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2005. Copyright Notice Copyright (C) The Internet Society (2005). 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 Lingle, et al. Expires August 1, 2005 [Page 1] Internet-Draft SIP MIB Modules January 2005 manage Session Initiation Protocol (SIP) entities, which include User Agents, Proxy, Redirect and Registrar servers. Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Internet-Standard Management Framework . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of SIP MIB . . . . . . . . . . . . . . . . . . . . 3 5.1 Textual Conventions . . . . . . . . . . . . . . . . . . . 5 5.2 Relationship to the Network Services MIB . . . . . . . . . 6 6. Accommodating SIP Extension Methods . . . . . . . . . . . . 9 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 SIP Textual Conventions . . . . . . . . . . . . . . . . . 10 7.2 SIP Common MIB Module . . . . . . . . . . . . . . . . . . 13 7.3 SIP User Agent MIB Module . . . . . . . . . . . . . . . . 52 7.4 SIP Server MIB Module (Proxy, Redirect and Registrar Servers) . . . . . . . . . . . . . . . . . . . . . . . . . 56 8. Changes from Previous Draft Revisions . . . . . . . . . . . 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 86 9.1 Registration of Numeric Identifiers for SIP methods . . . 86 9.2 IANA-assigned OBJECT IDENTIFIER values for the SIP MIB modules . . . . . . . . . . . . . . . . . . . . . . . . . 88 10. Security Considerations . . . . . . . . . . . . . . . . . . 88 11. Contributor Acknowledgments . . . . . . . . . . . . . . . . 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 12.1 Normative References . . . . . . . . . . . . . . . . . . 90 12.2 Informational References . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 92 Intellectual Property and Copyright Statements . . . . . . . 93 Lingle, et al. Expires August 1, 2005 [Page 2] Internet-Draft SIP MIB Modules January 2005 1. 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]. 2. 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, 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. 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]. 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 The Session Initiation Protocol (SIP) RFC 3261 [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, 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 SIP MIB This memo specifies four MIB modules. They are SIP-COMMON-MIB, Lingle, et al. Expires August 1, 2005 [Page 3] Internet-Draft SIP MIB Modules January 2005 SIP-SERVER-MIB, SIP-UA-MIB and SIP-TC. SIP-COMMON-MIB contains common objects used in all the SIP entities. SIP-SERVER-MIB contains objects specific to Proxy, Redirect and Registrar servers, and SIP-UA-MIB includes objects specific to User Agents. SIP-TC defines the textual conventions used throughout MIB modules. The MIB Modules contain 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 server), 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. * sipCommonStatsSummary: 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. * sipCommonStatsMethod: This object group defines a table containing the SIP method statistics objects applicable to all SIP entities, including the number 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. * sipCommonStatsOther: This object group defines additional statistic 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: Lingle, et al. Expires August 1, 2005 [Page 4] Internet-Draft SIP MIB Modules January 2005 o sipStatusCodeNotif: indicates that a specific status code has been sent or received by the system. o sipStatusCodeThreshExceededNotif: indicates that a specific status code has been sent or received by the system enough to exceed the configured threshold. 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. * sipProxyCfg: 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) and realm, etc. * sipProxyStats: 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. * sipRegCfg: This object group defines common configuration objects for SIP Registrar servers including the ability to accept third-party registrations, 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. * sipRegStats: This object group contains summary statistics objects for SIP Registrar servers, precisely, 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 to use 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 4.2 describes handling of multiple instances in detail. 5.1 Textual Conventions The data types SipTransportProtocol, SipEntityRole, SipOptionTagHeaders, and SipMethodIdentifier are used as Textual Lingle, et al. Expires August 1, 2005 [Page 5] Internet-Draft SIP MIB Modules January 2005 Conventions in this document. They are defined in the SIP-TC MIB module. 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, it 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 to adopt the following application name conventions: 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" 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 MUST 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 Lingle, et al. Expires August 1, 2005 [Page 6] Internet-Draft SIP MIB Modules January 2005 "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 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 sipServiceStartTime defined in the SIP-COMMON-MIB module, o applOperStatus: the value of applOperStatus SHOULD reflect the operational status of sipServiceOperStatus, at least by means of a mapping, o applLastChange: the value of applLastChange MUST be identical to the value of sipServiceLastChange 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. 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. Lingle, et al. Expires August 1, 2005 [Page 7] Internet-Draft SIP MIB Modules January 2005 SIP-COMMON-MIB sipCommonCfgTable might be populated as: +-----------+--------------------+----------------------+-----+ | applIndex | sipProtocolVersion | sipServiceOperStatus | ... | +-----------+--------------------+----------------------+-----+ | 1 | "SIP/2.0" | up(1) | 2 | | "SIP/2.0" | restarting(4) | | | +-----------+--------------------+----------------------+-----+ while sipProxyCfgTable in SIP-SERVER-MIB might be populated as: +-----------+----------------------+-----+ | applIndex | sipProxyStatefulness | ... | +-----------+----------------------+-----+ | 1 | stateless(1) | | +-----------+----------------------+-----+ and sipRegUserTable in SIP-SERVER-MIB might be populated as: +-----------+--------------+-------------------+-----+ | applIndex | sipUserIndex | sipUserUri | ... | +-----------+--------------+-------------------+-----+ | 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. Lingle, et al. Expires August 1, 2005 [Page 8] Internet-Draft SIP MIB Modules January 2005 SIP-COMMON-MIB sipCommonCfgTable might be populated as: +-----------+--------------------+----------------------+ | applIndex | sipProtocolVersion | sipServiceOperStatus | +-----------+--------------------+----------------------+ | 1 | "SIP/2.0" | up(1) | +-----------+--------------------+----------------------+ while sipRegUserTable in SIP-SERVER-MIB might be populated as: +-----------+--------------+-------------------+-----+ | applIndex | sipUserIndex | sipUserUri | ... | +-----------+--------------+-------------------+-----+ | 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 sipServiceOperStatus is as follows: +----------------------+-----------------------+-------------------+ | sipServiceOperStatus | -- corresponds to --> | applOperStatus | +----------------------+-----------------------+-------------------+ | 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. 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 Lingle, et al. Expires August 1, 2005 [Page 9] Internet-Draft SIP MIB Modules January 2005 SIP-COMMON-MIB module to accommodate these extension methods, we use a method identifier (SipMethodIdentifier textual-convention) to represent all SIP methods registered with IANA. See IANA Consideration section. For example, the sipMethodSupportedTable 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 a SNMP manager. 7. Definitions 7.1 SIP Textual Conventions SIP-TC DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; sipTC MODULE-IDENTITY LAST-UPDATED "200501281700Z" 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 392 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs Lingle, et al. Expires August 1, 2005 [Page 10] Internet-Draft SIP MIB Modules January 2005 postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 3708 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) MIB Textual Conventions module used by other SIP-related MIB Modules. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." -- RFC Ed: replace XXXX with actual RFC number and remove this note REVISION "200501281700Z" DESCRIPTION "Initial version of the IETF SIP-TC module. This version published as part of RFC XXXX." -- RFC Ed: replace XXXX with actual RFC number and remove this note ::= { mib-2 XXX1 } -- RFC Ed: replace XXX1 with actual IANA assigned number for this -- sipTC mib module and remove this note -- -- Textual Conventions -- SipTransportProtocol ::= 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." SYNTAX BITS { other(0), -- none of the following Lingle, et al. Expires August 1, 2005 [Page 11] Internet-Draft SIP MIB Modules January 2005 udp(1), tcp(2), sctp(3), tls(4) } -- REFERENCE "RFC 3261, Section 18" SipEntityRole ::= 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." SYNTAX BITS { other(0), userAgent(1), proxyServer(2), redirectServer(3), registrarServer(4) } SipOptionTagHeaders ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This convention defines the header fields that use the option 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." SYNTAX BITS { require(0), -- Require header proxyRequire(1), -- Proxy-Require header supported(2), -- Supported header unsupported(3) -- Unsupported header } -- REFERENCE "RFC 3261, Section 19.2" SipMethodIdentifier ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This is an IETF Assigned Numbers Authority (IANA) assigned number that uniquely identifies a SIP method. The scope of uniqueness is the context of all defined SIP methods. Experimental support of extension methods is Lingle, et al. Expires August 1, 2005 [Page 12] Internet-Draft SIP MIB Modules January 2005 acceptable and expected. Extention methods are those defined in Internet-Draft documents but not yet allocated an official number 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 defined by IANA. That system MUST ensure no collisions with officially assigned method identifier values and MUST provide a identifier to method name mapping via a mechanism like sipMethodSupportedTable." SYNTAX Unsigned32 (1..4294967295) END 7.2 SIP Common MIB Module SIP-COMMON-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Gauge32, TimeTicks, Unsigned32, mib-2 FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB SipTransportProtocol, SipMethodIdentifier, Lingle, et al. Expires August 1, 2005 [Page 13] Internet-Draft SIP MIB Modules January 2005 SipEntityRole, SipOptionTagHeaders FROM SIP-TC applIndex FROM NETWORK-SERVICES-MIB InetPortNumber FROM INET-ADDRESS-MIB; sipCommonMIB MODULE-IDENTITY LAST-UPDATED "200501281700Z" 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 392 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 3708 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) Common MIB module. This module defines objects which MAY be common to all SIP entities. SIP is an application-layer signalling protocol for creating, modifying and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June Lingle, et al. Expires August 1, 2005 [Page 14] Internet-Draft SIP MIB Modules January 2005 2002). This MIB is defined for managing objects which are common to SIP User Agents (UAs), Proxy, Redirect and Registrar servers. Objects specific to each of these entities MAY be managed using entity specific MIBs defined in other modules. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. 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 Lingle, et al. Expires August 1, 2005 [Page 15] Internet-Draft SIP MIB Modules January 2005 for the domain it handles. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." -- RFC Ed: replace XXXX with actual RFC number and -- remove this note REVISION "200501281700Z" DESCRIPTION "Initial version of the IETF SIP-COMMON-MIB module. This version published as part of RFC XXXX." -- RFC Ed: replace XXXX with actual RFC number and remove this note ::= { mib-2 XXX2 } -- RFC Ed: replace XXX2 with actual IANA assigned number and remove this note -- Top-Level Components of this MIB. sipCommonMIBNotifs OBJECT IDENTIFIER ::= { sipCommonMIB 0 } sipCommonMIBObjects OBJECT IDENTIFIER ::= { sipCommonMIB 1 } sipCommonMIBConform OBJECT IDENTIFIER ::= { sipCommonMIB 2 } -- -- This MIB contains objects that are common to all SIP entities. -- -- Common basic configuration sipCommonCfgBase OBJECT IDENTIFIER ::= { sipCommonMIBObjects 1 } -- Protocol timer configuration sipCommonCfgTimer OBJECT IDENTIFIER ::= { sipCommonMIBObjects 2 } -- SIP message summary statistics sipCommonStatsSummary OBJECT IDENTIFIER ::= { sipCommonMIBObjects 3 } -- Per method statistics sipCommonStatsMethod OBJECT IDENTIFIER ::= { sipCommonMIBObjects 4 } -- Per Status code or status code class statistics sipCommonStatusCode OBJECT IDENTIFIER ::= { sipCommonMIBObjects 5 } -- Transaction statistics sipCommonStatsTrans OBJECT IDENTIFIER ::= { sipCommonMIBObjects 6 } Lingle, et al. Expires August 1, 2005 [Page 16] Internet-Draft SIP MIB Modules January 2005 -- Method retry statistics sipCommonStatsRetry OBJECT IDENTIFIER ::= { sipCommonMIBObjects 7 } -- Other statistics sipCommonStatsOther OBJECT IDENTIFIER ::= { sipCommonMIBObjects 8 } -- Accessible-for-notify objects sipCommonNotifObjects OBJECT IDENTIFIER ::= { sipCommonMIBObjects 9 } -- -- Common Configuration Objects -- sipCommonCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the common configuration objects applicable to all SIP entities." ::= { sipCommonCfgBase 1 } sipCommonCfgEntry OBJECT-TYPE SYNTAX SipCommonCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common configuration. Each row represents objects for a particular SIP entity instance present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCommonCfgTable 1 } SipCommonCfgEntry ::= SEQUENCE { sipProtocolVersion SnmpAdminString, sipServiceOperStatus INTEGER, sipServiceStartTime TimeTicks, sipServiceLastChange TimeTicks, sipOrganization SnmpAdminString, sipMaxTransactions Unsigned32, sipServiceNotifEnable BITS, Lingle, et al. Expires August 1, 2005 [Page 17] Internet-Draft SIP MIB Modules January 2005 sipEntityType SipEntityRole } sipProtocolVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object will reflect the version of SIP supported by this SIP entity. It will follow the same format as SIP version information contained in the SIP messages generated by this SIP entity. For example, entities supporting SIP version 2 will return 'SIP/2.0' as dictated by the standard." REFERENCE "RFC 3261, Section 7.1" ::= { sipCommonCfgEntry 1 } sipServiceOperStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), up(2), down(3), congested(4), restarting(5), quiescing(6), testing(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the current operational state of the SIP application. unknown : The operational status cannot be determined for some reason. up : The application is operating normally, and is processing (receiving and possibly issuing) SIP requests and responses. down : The application is currently unable to process SIP messages. congested : The application is operational but no additional inbound transactions can be accommodated at the moment. restarting : The application is currently unavailable but it is in the process of restarting and will, presumably, soon be able to process SIP messages. Lingle, et al. Expires August 1, 2005 [Page 18] Internet-Draft SIP MIB Modules January 2005 quiescing : The application is currently operational but has been administratively put into quiesce mode. Additional inbound transactions MAY be rejected. testing : The application is currently in test mode and MAY not be able to process SIP messages. The operational status values defined for this object are not based on any specific information contained in the SIP standard." ::= { sipCommonCfgEntry 2 } sipServiceStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the SIP entity was last started. If started prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { sipCommonCfgEntry 3 } sipServiceLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time the SIP entity entered its current operational state. If the current state was entered prior to the last re-initialization of the local network management subsystem, then this object contains a zero value." ::= { sipCommonCfgEntry 4 } sipOrganization OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the organization name which the SIP entity inserts into Organization headers of SIP messages processed by this system. If the string is empty, no Organization header is to be generated." REFERENCE "RFC 3261, Section 20.25" ::= { sipCommonCfgEntry 5 } Lingle, et al. Expires August 1, 2005 [Page 19] Internet-Draft SIP MIB Modules January 2005 sipMaxTransactions OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the maximum number of simultaneous transactions that the SIP entity can manage. In general the value of this object SHOULD reflect a level of transaction processing that is considered high enough to impact the systems CPU and/or memory resources to the point of deteriorating SIP call processing but not high enough to cause catastrophic system failure." ::= { sipCommonCfgEntry 6 } sipServiceNotifEnable OBJECT-TYPE SYNTAX BITS { sipServiceColdStart(0), sipServiceWarmStart(1), sipServiceStatusChanged(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies which SIP service related notifications are enabled. Each bit represents a specific notification. If a bit has a value 1, the associated notification is enabled and will be generated by the SIP entity at the approriate time. The notifications are OPTIONAL, and if they are not implemented this object's value has no meaning and MUST be 0. Setting this object in that circumstance SHOULD result in a badValue error. If notifications are supported, this object's default value SHOULD reflect sipServiceColdStart and sipServiceWarmStart enabled and sipServiceStatusChanged disabled." ::= { sipCommonCfgEntry 7 } sipEntityType OBJECT-TYPE SYNTAX SipEntityRole MAX-ACCESS read-only STATUS current DESCRIPTION " This object identifies the list of SIP entities this row is related to. It is defined as a bit map. Each bit represents a type of SIP entity. If a bit has value 1, the SIP entity represented by this row plays the role of this entity type. Lingle, et al. Expires August 1, 2005 [Page 20] Internet-Draft SIP MIB Modules January 2005 If a bit has value 0, the SIP entity represented by this row does not act as this entity type Combinations of bits can be set when the SIP entity plays multiple SIP roles." ::= { sipCommonCfgEntry 8 } -- -- Support for multiple ports -- sipPortTable OBJECT-TYPE SYNTAX SEQUENCE OF SipPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of ports that each SIP entity in this system is allowed to use. These ports can be advertised using the Contact header in a REGISTER request or response." ::= { sipCommonCfgBase 2 } sipPortEntry OBJECT-TYPE SYNTAX SipPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Specification of a particular port. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipPort } ::= { sipPortTable 1 } SipPortEntry ::= SEQUENCE { sipPort InetPortNumber, sipTransportRcv SipTransportProtocol } sipPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object reflects a particular port that can be used by Lingle, et al. Expires August 1, 2005 [Page 21] Internet-Draft SIP MIB Modules January 2005 the SIP application." ::= { sipPortEntry 1 } sipTransportRcv OBJECT-TYPE SYNTAX SipTransportProtocol MAX-ACCESS read-only STATUS current DESCRIPTION "This object will specify the transport protocol the SIP entity will use to receive SIP messages. This object is a bit map. Each bit represents a transport protocol. If a bit has value 1, then that transport protocol is currently being used. If a bit has value 0, then that transport protocol is currently not being used." ::= { sipPortEntry 2 } -- -- Support for SIP option tags (SIP extensions). -- SIP extensions MAY be supported or required by SIP entities. -- sipOptionTagTable OBJECT-TYPE SYNTAX SEQUENCE OF SipOptionTagEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of the SIP option tags (SIP extensions) that either required, supported, or unsupported by the SIP entity. These option tags are used in the Require, Proxy-Require, Supported and Unsupported header fields. Example: if a user agent client supports and requires the server to support reliability of provisional responses, this table contains a row with the string '100rel' in sipOptionTag and the value 0xA0 in sipOptionTagHeaderField. If a server does not support the required feature (indicated in a Require header to a UAS, or in a Proxy- Require to a Proxy Server), the server returns a 420 Bad Extension listing the feature in an Unsupported header. Normally the list of such features supported by an entity is static (i.e. will not change over time)." REFERENCE "RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40" ::= { sipCommonCfgBase 3 } Lingle, et al. Expires August 1, 2005 [Page 22] Internet-Draft SIP MIB Modules January 2005 sipOptionTagEntry OBJECT-TYPE SYNTAX SipOptionTagEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular SIP option tag (extension) supported or unsupported by the SIP entity, and which may be supported or required by a peer. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex, sipOptionTagIndex } ::= { sipOptionTagTable 1 } SipOptionTagEntry ::= SEQUENCE { sipOptionTagIndex Unsigned32, sipOptionTag SnmpAdminString, sipOptionTagHeaderField SipOptionTagHeaders } sipOptionTagIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table." ::= { sipOptionTagEntry 1 } sipOptionTag OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the SIP option tag. The option tag names are registered with IANA and available at http://www.iana.org." ::= { sipOptionTagEntry 2 } sipOptionTagHeaderField OBJECT-TYPE SYNTAX SipOptionTagHeaders MAX-ACCESS read-only Lingle, et al. Expires August 1, 2005 [Page 23] Internet-Draft SIP MIB Modules January 2005 STATUS current DESCRIPTION "This object indicates whether the SIP option tag is supported (Supported header), unsupported (Unsupported header), required (Require or Proxy-Require header) by the SIP entity. A SIP option tag may be both supported and required." ::= { sipOptionTagEntry 3 } -- -- Supported SIP Methods -- sipMethodSupportedTable OBJECT-TYPE SYNTAX SEQUENCE OF SipMethodSupportedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains a list of methods supported by each SIP entity in this system. This MAY include, but is not limited to, the standard set of SIP methods discussed in Section 7.1 of RFC 3261. Any additional methods that MAY be incorporated into the SIP protocol can be represented by this table without any requirement to update this MIB. The table is informational in nature; conveying to the NMS capabilities of the managed system. From a protocol point of view, the list of methods advertised by the SIP entity in the Allow header (Section 20.5 of RFC 3261) MUST be consistent with the methods reflected in this table." ::= { sipCommonCfgBase 4 } sipMethodSupportedEntry OBJECT-TYPE SYNTAX SipMethodSupportedEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular method supported by the SIP entity. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). Lingle, et al. Expires August 1, 2005 [Page 24] Internet-Draft SIP MIB Modules January 2005 The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex, sipMethodSupportedIndex } ::= { sipMethodSupportedTable 1 } SipMethodSupportedEntry ::= SEQUENCE { sipMethodSupportedIndex SipMethodIdentifier, sipMethodName SnmpAdminString } sipMethodSupportedIndex OBJECT-TYPE SYNTAX SipMethodIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table and reflects an assigned number used to identifier a specific SIP method. This identifier is suitable for referenceing the associated method throughout this and other MIBs supported by this managed system." ::= { sipMethodSupportedEntry 1 } sipMethodName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the supported method's name. The method name MUST be all upper case (eg, 'FOO')." ::= { sipMethodSupportedEntry 2 } -- -- SIP Timer Configuration -- sipCommonCfgTimerTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonCfgTimerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains timer configuration objects applicable to SIP user agent and SIP stateful Proxy Server entities." ::= { sipCommonCfgTimer 1 } sipCommonCfgTimerEntry OBJECT-TYPE Lingle, et al. Expires August 1, 2005 [Page 25] Internet-Draft SIP MIB Modules January 2005 SYNTAX SipCommonCfgTimerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of timer configuration. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex } ::= { sipCommonCfgTimerTable 1 } SipCommonCfgTimerEntry ::= SEQUENCE { sipCfgTimerA Unsigned32, sipCfgTimerB Unsigned32, sipCfgTimerC Unsigned32, sipCfgTimerD Unsigned32, sipCfgTimerE Unsigned32, sipCfgTimerF Unsigned32, sipCfgTimerG Unsigned32, sipCfgTimerH Unsigned32, sipCfgTimerI Unsigned32, sipCfgTimerJ Unsigned32, sipCfgTimerK Unsigned32, sipCfgTimerT1 Unsigned32, sipCfgTimerT2 Unsigned32, sipCfgTimerT4 Unsigned32 } sipCfgTimerA OBJECT-TYPE SYNTAX Unsigned32 (100..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for the INVITE method. The retransmit timer doubles after each retransmission, ensuring an exponential backoff in network traffic. This object represents the initial time a SIP entity will wait to receive a provisional response to an INVITE before resending the INVITE request." REFERENCE "RFC 3261, Section 17.1.1.2" Lingle, et al. Expires August 1, 2005 [Page 26] Internet-Draft SIP MIB Modules January 2005 DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 1 } sipCfgTimerB OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive a final response to an INVITE. The timer is started upon transmission of the initial INVITE request." REFERENCE "RFC 3261, Section 17.1.1.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 2 } sipCfgTimerC OBJECT-TYPE SYNTAX Unsigned32 (180000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP Proxy Server will wait to receive a provisional response to an INVITE. The Timer C MUST be set for each client transaction when an INVITE request is proxied." REFERENCE "RFC 3261, Section 16.6" DEFVAL { 180000 } ::= { sipCommonCfgTimerEntry 3 } sipCfgTimerD OBJECT-TYPE SYNTAX Unsigned32 (0..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the amount of time that the server transaction can remain in the 'Completed' state when unreliable transports are used. The default value MUST be greater than 32000 for UDP transport and its value MUST be 0 for TCP/SCTP transport." REFERENCE "RFC 3261, Section 17.1.1.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 4 } Lingle, et al. Expires August 1, 2005 [Page 27] Internet-Draft SIP MIB Modules January 2005 sipCfgTimerE OBJECT-TYPE SYNTAX Unsigned32 (100..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for a non-INVITE method while in 'Trying State'. The retransmit timer doubles after each retransmission until it reaches T2 to ensure an exponential backoff in network traffic. This object represents the initial time a SIP entity will wait to receive a provisional response to the request before resending the non-INVITE request." REFERENCE "RFC 3261, Section 17.1.2.2" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 5 } sipCfgTimerF OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive a final response to a non-INVITE request. The timer is started upon transmission of the initial request." REFERENCE "RFC 3261, Section 17.1.2.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 6 } sipCfgTimerG OBJECT-TYPE SYNTAX Unsigned32 (0..1000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the initial value for the retransmit timer for final responses to INVITE requests. If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. Lingle, et al. Expires August 1, 2005 [Page 28] Internet-Draft SIP MIB Modules January 2005 The default value MUST be T1 for UDP transport and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 7 } sipCfgTimerH OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a server will wait to receive an ACK before it abandons retransmitting the response. The timer is started upon entering the 'Completed' state." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 8 } sipCfgTimerI OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP entity will wait to receive additional ACK message retransmissions. The timer is started upon entering the 'Confirmed' state. The default value MUST be T4 for UDP transport and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.2.1" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 9 } sipCfgTimerJ OBJECT-TYPE SYNTAX Unsigned32 (32000..300000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP server will wait to receive retransmissions of non-INVITE request. The timer is started upon entering the 'Completed' state for non-INVITE transactions. When timer J fires, the server Lingle, et al. Expires August 1, 2005 [Page 29] Internet-Draft SIP MIB Modules January 2005 MUST transition to the 'Terminated' state." REFERENCE "RFC 3261, Section 17.2.2" DEFVAL { 32000 } ::= { sipCommonCfgTimerEntry 10 } sipCfgTimerK OBJECT-TYPE SYNTAX Unsigned32 (0..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum time a SIP client will wait to receive retransmissions of responses to non-INVITE requests. The timer is started upon entering the 'Completed' state for non-INVITE transactions. When timer K fires, the server MUST transition to the 'Terminated' state. The default value MUST be T4 for UDP transport and its value MUST be 0 for reliable transport like TCP/SCTP." REFERENCE "RFC 3261, Section 17.1.2.2" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 11 } sipCfgTimerT1 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T1 timer for a SIP entity. T1 is an estimate of the round-trip time (RTT) between the client and server transactions." REFERENCE "RFC 3261, Section 17" DEFVAL { 500 } ::= { sipCommonCfgTimerEntry 12 } sipCfgTimerT2 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T2 timer for a SIP entity. T2 is the maximum retransmit interval for non-INVITE requests and INVITE responses. It's used in various parts of the protocol to reset other Timer* objects Lingle, et al. Expires August 1, 2005 [Page 30] Internet-Draft SIP MIB Modules January 2005 to this value." REFERENCE "RFC 3261, Section 17" DEFVAL { 4000 } ::= { sipCommonCfgTimerEntry 13 } sipCfgTimerT4 OBJECT-TYPE SYNTAX Unsigned32 (200..10000) UNITS "milliseconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the T4 timer for a SIP entity. T4 is the maximum duration a message will remain in the network. It represents the amount of time the network will take to clear messages between client and server transactions. It's used in various parts of the protocol to reset other Timer* objects to this value." REFERENCE "RFC 3261, Section 17" DEFVAL { 5000 } ::= { sipCommonCfgTimerEntry 14 } -- -- Common Statistics Objects -- -- -- Summary Statistics -- sipSummaryStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipSummaryStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the summary statistics objects applicable to all SIP entities. Each row represents those objects for a particular SIP entity present in this system." ::= { sipCommonStatsSummary 1 } sipSummaryStatsEntry OBJECT-TYPE SYNTAX SipSummaryStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lingle, et al. Expires August 1, 2005 [Page 31] Internet-Draft SIP MIB Modules January 2005 "A row of summary statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipSummaryStatsTable 1 } SipSummaryStatsEntry ::= SEQUENCE { sipSummaryInRequests Counter32, sipSummaryOutRequests Counter32, sipSummaryInResponses Counter32, sipSummaryOutResponses Counter32, sipSummaryTotalTransactions Counter32 } sipSummaryInRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the total number of SIP request messages received by the SIP entity including retransmissions." ::= { sipSummaryStatsEntry 1 } sipSummaryOutRequests OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP request messages sent out (originated and relayed) by the SIP entity. Where a particular message is sent more than once, for example as a retransmission, or as a result of forking, each transmission is counted separately." ::= { sipSummaryStatsEntry 2 } sipSummaryInResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP response messages received by the SIP entity including Lingle, et al. Expires August 1, 2005 [Page 32] Internet-Draft SIP MIB Modules January 2005 retransmissions." ::= { sipSummaryStatsEntry 3 } sipSummaryOutResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the total number of SIP response messages sent (originated and relayed) by the SIP entity including retransmissions." ::= { sipSummaryStatsEntry 4 } sipSummaryTotalTransactions OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of transactions that are in progress and transactions that have reached the terminated state. It is not applicable to stateless SIP Proxy Servers. A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also include an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. The branch ID parameter in the Via header field values serves as a transaction identifier. A transaction is identified by the CSeq sequence number within a single call leg. The ACK request has the same CSeq number as the corresponding INVITE request, but comprises a transaction of its own. In the case of a forked request, each branch counts as a single transaction. For a transaction stateless Proxy Server, this counter is always 0." Lingle, et al. Expires August 1, 2005 [Page 33] Internet-Draft SIP MIB Modules January 2005 ::= { sipSummaryStatsEntry 5 } -- -- SIP Method Statistics -- Total counts for each SIP method. -- sipMethodStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipMethodStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the method statistics objects for SIP entities. Each row represents those objects for a particular SIP entity present in this system." ::= { sipCommonStatsMethod 1 } sipMethodStatsEntry OBJECT-TYPE SYNTAX SipMethodStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of per entity method statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipStatsMethod } ::= { sipMethodStatsTable 1 } SipMethodStatsEntry ::= SEQUENCE { sipStatsMethod SipMethodIdentifier, sipStatsOutbounds Counter32, sipStatsInbounds Counter32 } sipStatsMethod OBJECT-TYPE SYNTAX SipMethodIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies the SIP method related to the objects in a particular row." ::= { sipMethodStatsEntry 1 } Lingle, et al. Expires August 1, 2005 [Page 34] Internet-Draft SIP MIB Modules January 2005 sipStatsOutbounds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of requests sent by the SIP entity, excluding retransmissions. Retransmissions are counted separately and are not reflected in this counter." REFERENCE "RFC 3261, Section 7.1" ::= { sipMethodStatsEntry 2 } sipStatsInbounds OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of requests received by the SIP entity. Retransmissions are counted separately and are not reflected in this counter." REFERENCE "RFC 3261, Section 7.1" ::= { sipMethodStatsEntry 3 } -- -- Support for specific status codes -- sipStatusCodesTable OBJECT-TYPE SYNTAX SEQUENCE OF SipStatusCodesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the list of SIP status codes which each SIP entity in this system has been requested to monitor. It is the mechanism by which specific status codes are monitored." ::= { sipCommonStatusCode 2 } sipStatusCodesEntry OBJECT-TYPE SYNTAX SipStatusCodesEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This row contains information on a particular SIP status Lingle, et al. Expires August 1, 2005 [Page 35] Internet-Draft SIP MIB Modules January 2005 code that the SIP entity has been requested to monitor. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipStatusCodeMethod, sipStatusCodeValue } ::= { sipStatusCodesTable 1 } SipStatusCodesEntry ::= SEQUENCE { sipStatusCodeMethod SipMethodIdentifier, sipStatusCodeValue Unsigned32, sipStatusCodeIns Counter32, sipStatusCodeOuts Counter32, sipStatusCodeRowStatus RowStatus } sipStatusCodeMethod OBJECT-TYPE SYNTAX SipMethodIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table and reflects an assigned number used to identifier a specific SIP method." ::= { sipStatusCodesEntry 1 } sipStatusCodeValue OBJECT-TYPE SYNTAX Unsigned32 (100..999) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object contains a SIP status code value that the SIP entity has been requested to monitor. All of the other information in the row is related to this value." ::= { sipStatusCodesEntry 2 } sipStatusCodeIns OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of response messages received by the SIP entity with the status code value contained in the sipStatusCodeValue column." ::= { sipStatusCodesEntry 3 } Lingle, et al. Expires August 1, 2005 [Page 36] Internet-Draft SIP MIB Modules January 2005 sipStatusCodeOuts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of response messages sent by the SIP entity with the status code value contained in the sipStatusCodeValue column." ::= { sipStatusCodesEntry 4 } sipStatusCodeRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The row augmentation in sipStatusCodeNotifTable will be governed by the value of this RowStatus. This object is REQUIRED to create or delete rows by a manager. The values 'createAndGo' and 'destroy' are the only valid values allowed for this object. If a row exists, it will reflect a status of 'active' when queried." ::= { sipStatusCodesEntry 5 } -- -- support for specific status code notifications -- sipStatusCodeNotifTable OBJECT-TYPE SYNTAX SEQUENCE OF SipStatusCodeNotifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains objects to control notifications related to particular status codes each SIP entity in this system has been requested to monitor. There is an entry in this table corresponding to each entry in sipStatusCodesTable. Therefore, this table augments that table and utilizes the same index methodology. The objects in this table are not included directly in the sipStatusCodesTable simply to keep the status code notification control objects seperate from Lingle, et al. Expires August 1, 2005 [Page 37] Internet-Draft SIP MIB Modules January 2005 the actual status code statistics." ::= { sipCommonStatusCode 3 } sipStatusCodeNotifEntry OBJECT-TYPE SYNTAX SipStatusCodeNotifEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This row contains information controlling notifications for a particular SIP status code that the SIP entity has been requested to monitor." AUGMENTS { sipStatusCodesEntry } ::= { sipStatusCodeNotifTable 1 } SipStatusCodeNotifEntry ::= SEQUENCE { sipStatusCodeNotifSend TruthValue, sipStatusCodeNotifEmitMode INTEGER, sipStatusCodeNotifThresh Unsigned32, sipStatusCodeNotifInterval Unsigned32 } sipStatusCodeNotifSend OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object controls whether a sipStatusCodeNotif is emitted when the status code value specified in by sipStatusCodeValue is sent or received. If the value of this object is 'true', then a notification is sent. If it is 'false', no notification is sent. Note well, that a notification MAY be emitted for every message sent or received that contains the particular status code. Depending on the status code involved, this can cause a significant number of notification emissions that could be detrimental to network performance. Managers are forewarned to be prudent in the use of this object to enable notifications. Look to sipStatusCodeNotifEmitMode for alternative controls for sipStatusCodeNotif emissions." DEFVAL { false } ::= { sipStatusCodeNotifEntry 1 } sipStatusCodeNotifEmitMode OBJECT-TYPE SYNTAX INTEGER { normal(1), oneShot(2), Lingle, et al. Expires August 1, 2005 [Page 38] Internet-Draft SIP MIB Modules January 2005 triggered(3) -- read-only } MAX-ACCESS read-write STATUS current DESCRIPTION "The object sipStatusCodeNotifSend MUST be set to 'true' for the values of this object to have any effect. It is RECOMMENDED that the desired emit mode be established by this object prior to setting sipStatusCodeNotifSend to 'true'. This object and the sipStatusCodeNotifSend object can obviously be set independently, but their respective values will have a dependency on each other and the resulting notifications. This object specifies the mode for emissions of sipStatusCodeNotif notifications. normal : sipStatusCodeNotif notifications will be emitted by the system for each SIP response messages sent or received that contains the desired status code. oneShot : Only one sipStatusCodeNotif notification will be emitted. It will be the next SIP response messages sent or received that contains the desired status code. No more notifications are emitted until this object is set to either 'oneShot' again or 'normal'. This option is provided as a means of quelling the potential promiscuous behavior that can be associated with the sipStatusCodeNotif. triggered : This value is only readable and cannot be set. It reflects the default value of the object or that the 'oneShot' case has occurred and indicates the mode needs to be reset to get further notifications. The mode is reset by setting this object to 'oneShot' or 'normal'." DEFVAL { triggered } ::= { sipStatusCodeNotifEntry 2 } sipStatusCodeNotifThresh OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write Lingle, et al. Expires August 1, 2005 [Page 39] Internet-Draft SIP MIB Modules January 2005 STATUS current DESCRIPTION "This object specifies the number of response messages sent or received by this system that are considered excessive. Based on crossing that threshold, a sipStatusCodeThreshExceededInNotif notification or a sipStatusCodeThreshExceededOutNotif will be sent. The sipStatusCodeThreshExceededIn/OutNotif can be used as an early warning mechanism in lieu of using sipStatusCodeNotif. Note that the configuration applied by this object will be applied equally to inbound and outbound response messages." DEFVAL { 500 } ::= { sipStatusCodeNotifEntry 3 } sipStatusCodeNotifInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object specifies the time interval over which if sipCommonStatusCodeThresh is exceeded, with respect to sent or received messages, a sipStatusCodeThreshExceededIn/Out notification will be sent. Note that the configuration applied by this object will be applied equally to inbound and outbound response messages." DEFVAL { 60 } ::= { sipStatusCodeNotifEntry 4 } -- -- Transaction Statistics -- sipCurrentTransTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCurrentTransEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on the transactions currently awaiting definitive responses by each SIP entity in this system. Lingle, et al. Expires August 1, 2005 [Page 40] Internet-Draft SIP MIB Modules January 2005 This table does not apply to transaction stateless Proxy Servers." ::= { sipCommonStatsTrans 1 } sipCurrentTransEntry OBJECT-TYPE SYNTAX SipCurrentTransEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular SIP entity's current transactions. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipCurrentTransTable 1 } SipCurrentTransEntry ::= SEQUENCE { sipCurrentTransactions Gauge32 } sipCurrentTransactions OBJECT-TYPE SYNTAX Gauge32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of transactions awaiting definitive (non-1xx) response. In the case of a forked request, each branch counts as a single transaction corresponding to the entity identified by applIndex." ::= { sipCurrentTransEntry 1 } -- -- SIP Retry Statistics -- -- This group contains various statistic objects about -- retransmission counts. -- sipCommonStatsRetryTable OBJECT-TYPE SYNTAX SEQUENCE OF SipCommonStatsRetryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Lingle, et al. Expires August 1, 2005 [Page 41] Internet-Draft SIP MIB Modules January 2005 "This table contains retry statistics objects applicable to each SIP entity in this system." ::= { sipCommonStatsRetry 1 } sipCommonStatsRetryEntry OBJECT-TYPE SYNTAX SipCommonStatsRetryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of retry statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex, sipStatsRetryMethod } ::= { sipCommonStatsRetryTable 1 } SipCommonStatsRetryEntry ::= SEQUENCE { sipStatsRetryMethod SipMethodIdentifier, sipStatsRetries Counter32, sipStatsRetryFinalResponses Counter32, sipStatsRetryNonFinalResponses Counter32 } sipStatsRetryMethod OBJECT-TYPE SYNTAX SipMethodIdentifier MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies the SIP method related to the objects in a row." ::= { sipCommonStatsRetryEntry 1 } sipStatsRetries OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of request retransmissions that have been sent by the SIP entity. Note that there could be multiple retransmissions per request." ::= { sipCommonStatsRetryEntry 2 } sipStatsRetryFinalResponses OBJECT-TYPE Lingle, et al. Expires August 1, 2005 [Page 42] Internet-Draft SIP MIB Modules January 2005 SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of Final Response retries that have been sent by the SIP entity. Note that there could be multiple retransmissions per request." ::= { sipCommonStatsRetryEntry 3 } sipStatsRetryNonFinalResponses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the total number of non-Final Response retries that have been sent by the SIP entity." ::= { sipCommonStatsRetryEntry 4 } -- -- Other Common Statistics -- sipOtherStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipOtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains other common statistics supported by each SIP entity in this system." ::= { sipCommonStatsOther 1 } sipOtherStatsEntry OBJECT-TYPE SYNTAX SipOtherStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular SIP entity's other common statistics. Each row represents those objects for a particular SIP entity present in this system. applIndex is used to uniquely identify these instances of SIP entities and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788)." INDEX { applIndex } ::= { sipOtherStatsTable 1 } Lingle, et al. Expires August 1, 2005 [Page 43] Internet-Draft SIP MIB Modules January 2005 SipOtherStatsEntry ::= SEQUENCE { sipNumUnsupportedUris Counter32, sipNumUnsupportedMethods Counter32, sipOtherwiseDiscardedMsgs Counter32 } sipNumUnsupportedUris OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of RequestURIs received with unsupported scheme. A server normally responds to such requests with a 400 Bad Request status code." ::= { sipOtherStatsEntry 1 } sipNumUnsupportedMethods OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SIP requests received with unsupported methods. A server normally responds to such requests with a 501 (Not Implemented) or 405 (Method Not Allowed)." ::= { sipOtherStatsEntry 2 } sipOtherwiseDiscardedMsgs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Number of SIP messages received that for any number of reasons was discarded without a response." ::= { sipOtherStatsEntry 3 } -- -- Notification related objects -- -- -- Status code related notification objects. -- sipStatusCodeNotifTo OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION Lingle, et al. Expires August 1, 2005 [Page 44] Internet-Draft SIP MIB Modules January 2005 "This object contains the value of the To header in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'To: Watson ." ::= { sipCommonNotifObjects 1 } sipStatusCodeNotifFrom OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the value of the From header in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'From: Watson '." ::= { sipCommonNotifObjects 2 } sipStatusCodeNotifCallId OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the value of the CallId in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'Call-ID: 5551212@information.com'." ::= { sipCommonNotifObjects 3 } sipStatusCodeNotifCSeq OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains the CSeq value in the message containing the status code that caused the notification. The header name will be part of this object value. For example, 'CSeq: 1722 INVITE'." ::= { sipCommonNotifObjects 4 } -- -- General notification related objects. -- sipNotifApplIndex OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify Lingle, et al. Expires August 1, 2005 [Page 45] Internet-Draft SIP MIB Modules January 2005 STATUS current DESCRIPTION "This object contains the applIndex as described in RFC 2788. This object is created in order to allow a variable binding containing a value of applIndex in a notification." ::= { sipCommonNotifObjects 5 } sipNotifSequenceNumber OBJECT-TYPE SYNTAX Unsigned32 (1..2147483647) MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "This object contains a sequence number for each notification generated by this SIP entity. Each notification SHOULD have a unique sequence number. A network manager can use this information to determine whether notifications from a particular SIP entity have been missed. The value of this object MUST start at 1 and increase by one with each generated notification. If a system restarts, the sequence number MAY start again from 1." ::= { sipCommonNotifObjects 6 } -- -- Notifications -- sipStatusCodeNotif NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, sipNotifApplIndex, sipStatusCodeNotifTo, sipStatusCodeNotifFrom, sipStatusCodeNotifCallId, sipStatusCodeNotifCSeq, sipStatusCodeIns, sipStatusCodeOuts } STATUS current DESCRIPTION "Signifies that a specific status code has been sent or received by the system." ::= { sipCommonMIBNotifs 1 } sipStatusCodeThreshExceededInNotif NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, Lingle, et al. Expires August 1, 2005 [Page 46] Internet-Draft SIP MIB Modules January 2005 sipNotifApplIndex, sipStatusCodeIns } STATUS current DESCRIPTION "Signifies that a specific status code was found to have been received by the system enough to exceed the configured threshold. This notification can be used as an early warning mechanism in lieu of using sipStatusCodeNotif." ::= { sipCommonMIBNotifs 2 } sipStatusCodeThreshExceededOutNotif NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, sipNotifApplIndex, sipStatusCodeOuts } STATUS current DESCRIPTION "Signifies that a specific status code was found to have been sent by the system enough to exceed the configured threshold. This notification can be used as an early warning mechanism in lieu of using sipStatusCodeNotif." ::= { sipCommonMIBNotifs 3 } sipServiceColdStart NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, sipNotifApplIndex, sipServiceStartTime } STATUS current DESCRIPTION "Signifies that the SIP service has reinitialized itself or started for the first time. This SHOULD result from a hard 'down' to 'up' administrative status change. The configuration or behavior of the service MAY be altered." ::= { sipCommonMIBNotifs 4 } sipServiceWarmStart NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, sipNotifApplIndex, sipServiceLastChange Lingle, et al. Expires August 1, 2005 [Page 47] Internet-Draft SIP MIB Modules January 2005 } STATUS current DESCRIPTION "Signifies that the SIP service has reinitialized itself and is restarting after an adminstrative 'reset'. The configuration or behavior of the service MAY be altered." ::= { sipCommonMIBNotifs 5 } sipServiceStatusChanged NOTIFICATION-TYPE OBJECTS { sipNotifSequenceNumber, sipNotifApplIndex, sipServiceLastChange, sipServiceOperStatus } STATUS current DESCRIPTION "Signifies that the SIP service operational status has changed." ::= { sipCommonMIBNotifs 6 } -- -- Conformance -- sipCommonMIBCompliances OBJECT IDENTIFIER ::= { sipCommonMIBConform 1 } sipCommonMIBGroups OBJECT IDENTIFIER ::= { sipCommonMIBConform 2 } -- -- Compliance Statements -- sipCommonCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities." MODULE -- this module MANDATORY-GROUPS { sipCommonConfigGroup, sipCommonStatsGroup } GROUP sipCommonConfigTimerGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to Lingle, et al. Expires August 1, 2005 [Page 48] Internet-Draft SIP MIB Modules January 2005 not provide any timer configuration." GROUP sipCommonStatsRetryGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any retry statistics." GROUP sipCommonNotifGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonStatusCodeNotifGroup and sipCommonNotifObjectsGroup MUST also be implemented." GROUP sipCommonStatusCodeNotifGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonNotifGroup and sipCommonNotifObjectsGroup MUST also be implemented." GROUP sipCommonNotifObjectsGroup DESCRIPTION "This group is OPTIONAL. A SIP entity can elect to not provide any notifications. If implemented, the sipCommonStatusCodeNotifGroup and sipCommonNotifGroup MUST also be implemented." ::= { sipCommonMIBCompliances 1 } -- -- Units of Conformance -- sipCommonConfigGroup OBJECT-GROUP OBJECTS { sipProtocolVersion, sipServiceOperStatus, sipServiceStartTime, sipServiceLastChange, sipTransportRcv, sipOptionTag, sipOptionTagHeaderField, sipOrganization, sipMaxTransactions, sipServiceNotifEnable, sipEntityType, sipMethodName } Lingle, et al. Expires August 1, 2005 [Page 49] Internet-Draft SIP MIB Modules January 2005 STATUS current DESCRIPTION "A collection of objects providing configuration common to all SIP enities." ::= { sipCommonMIBGroups 1 } sipCommonConfigTimerGroup OBJECT-GROUP OBJECTS { sipCfgTimerA, sipCfgTimerB, sipCfgTimerC, sipCfgTimerD, sipCfgTimerE, sipCfgTimerF, sipCfgTimerG, sipCfgTimerH, sipCfgTimerI, sipCfgTimerJ, sipCfgTimerK, sipCfgTimerT1, sipCfgTimerT2, sipCfgTimerT4 } STATUS current DESCRIPTION "A collection of objects providing timer configuration common to all SIP enities." ::= { sipCommonMIBGroups 2 } sipCommonStatsGroup OBJECT-GROUP OBJECTS { sipSummaryInRequests, sipSummaryOutRequests, sipSummaryInResponses, sipSummaryOutResponses, sipSummaryTotalTransactions, sipStatsOutbounds, sipStatsInbounds, sipStatusCodeIns, sipStatusCodeOuts, sipStatusCodeRowStatus, sipCurrentTransactions, sipNumUnsupportedUris, sipNumUnsupportedMethods, sipOtherwiseDiscardedMsgs } STATUS current DESCRIPTION Lingle, et al. Expires August 1, 2005 [Page 50] Internet-Draft SIP MIB Modules January 2005 "A collection of objects providing statistics common to all SIP entities." ::= { sipCommonMIBGroups 3 } sipCommonStatsRetryGroup OBJECT-GROUP OBJECTS { sipStatsRetries, sipStatsRetryFinalResponses, sipStatsRetryNonFinalResponses } STATUS current DESCRIPTION "A collection of objects providing retry statistics." ::= { sipCommonMIBGroups 4 } sipCommonNotifGroup NOTIFICATION-GROUP NOTIFICATIONS { sipStatusCodeNotif, sipStatusCodeThreshExceededInNotif, sipStatusCodeThreshExceededOutNotif, sipServiceColdStart, sipServiceWarmStart, sipServiceStatusChanged } STATUS current DESCRIPTION "A collection of notifications common to all SIP entities." ::= { sipCommonMIBGroups 5 } sipCommonStatusCodeNotifGroup OBJECT-GROUP OBJECTS { sipStatusCodeNotifSend, sipStatusCodeNotifEmitMode, sipStatusCodeNotifThresh, sipStatusCodeNotifInterval } STATUS current DESCRIPTION "A collection of objects related to controlling and attribution of notifications common to all SIP entities." ::= { sipCommonMIBGroups 6 } sipCommonNotifObjectsGroup OBJECT-GROUP OBJECTS { sipStatusCodeNotifTo, sipStatusCodeNotifFrom, sipStatusCodeNotifCallId, sipStatusCodeNotifCSeq, Lingle, et al. Expires August 1, 2005 [Page 51] Internet-Draft SIP MIB Modules January 2005 sipNotifApplIndex, sipNotifSequenceNumber } STATUS current DESCRIPTION "A collection of accessible-for-notify objects related to the notification defined in this MIB module." ::= { sipCommonMIBGroups 7 } END 7.3 SIP User Agent MIB Module SIP-UA-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF applIndex FROM NETWORK-SERVICES-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB SipEntityRole FROM SIP-TC; sipUAMIB MODULE-IDENTITY LAST-UPDATED "200501281700Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Cisco Systems, Inc. Lingle, et al. Expires August 1, 2005 [Page 52] Internet-Draft SIP MIB Modules January 2005 postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 392 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 3708 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) User Agent (UA) MIB module. SIP is an application-layer signalling protocol for creating, modifying and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June 2002). A User Agent is an application that contains both a User Agent Client (UAC) and a User Agent Server (UAS). A UAC is an application that initiates a SIP request. A UAS is an application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects, or redirects the request. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." -- RFC Ed: replace XXXX with actual RFC number and remove this note REVISION "200501281700Z" DESCRIPTION "Initial version of the IETF SIP-UA-MIB module. This version published as part of RFC XXXX." -- RFC Ed: replace XXXX with actual RFC number and remove this note ::= { mib-2 XXX3 } Lingle, et al. Expires August 1, 2005 [Page 53] Internet-Draft SIP MIB Modules January 2005 -- RFC Ed: replace XXX3 with actual IANA assigned number -- RFC Ed: and remove these notes -- Top-Level Components of this MIB. sipUAMIBObjects OBJECT IDENTIFIER ::= { sipUAMIB 1 } sipUAMIBConform OBJECT IDENTIFIER ::= { sipUAMIB 2 } -- -- This MIB contains objects related to SIP User Agents. -- sipUACfgServer OBJECT IDENTIFIER ::= { sipUAMIBObjects 1 } -- -- SIP Server Configuration -- sipUACfgServerTable OBJECT-TYPE SYNTAX SEQUENCE OF SipUACfgServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains SIP server configuration objects applicable to each SIP user agent in this system." ::= { sipUACfgServer 1 } sipUACfgServerEntry OBJECT-TYPE SYNTAX SipUACfgServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of server configuration. Each row represents those objects for a particular SIP user agent present in this system. applIndex is used to uniquely identify these instances of SIP user agents and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here. The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex, sipUACfgServerIndex } ::= { sipUACfgServerTable 1 } SipUACfgServerEntry ::= SEQUENCE { sipUACfgServerIndex Unsigned32, sipUACfgServerAddrType InetAddressType, sipUACfgServerAddr InetAddress, Lingle, et al. Expires August 1, 2005 [Page 54] Internet-Draft SIP MIB Modules January 2005 sipUACfgServerFunction SipEntityRole } sipUACfgServerIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier of a server address when multiple addresses are configured by the SIP entity. If one address isn't reachable, then another can be tried." ::= { sipUACfgServerEntry 1 } sipUACfgServerAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the type of address contained in the associated instance of sipUACfgServerAddr." REFERENCE "INET-ADDRESS-MIB (RFC 3291)" ::= { sipUACfgServerEntry 2 } sipUACfgServerAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the address of a SIP server this user agent will use to proxy/redirect calls." REFERENCE "INET-ADDRESS-MIB (RFC 3291)" ::= { sipUACfgServerEntry 3 } sipUACfgServerFunction OBJECT-TYPE SYNTAX SipEntityRole MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the function of the SIP server this user agent should communicate with: registrar, proxy (outbound proxy), etc." ::= { sipUACfgServerEntry 4 } -- -- Conformance -- Lingle, et al. Expires August 1, 2005 [Page 55] Internet-Draft SIP MIB Modules January 2005 sipUAMIBCompliances OBJECT IDENTIFIER ::= { sipUAMIBConform 1 } sipUAMIBGroups OBJECT IDENTIFIER ::= { sipUAMIBConform 2 } -- -- Compliance Statements -- sipUACompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities." MODULE -- this module MANDATORY-GROUPS { sipUAConfigGroup } ::= { sipUAMIBCompliances 1 } -- -- Units of Conformance -- sipUAConfigGroup OBJECT-GROUP OBJECTS { sipUACfgServerAddrType, sipUACfgServerAddr, sipUACfgServerFunction } STATUS current DESCRIPTION "A collection of objects providing configuration for SIP User Agents." ::= { sipUAMIBGroups 1 } END 7.4 SIP Server MIB Module (Proxy, Redirect and Registrar Servers) SIP-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, Gauge32, mib-2 FROM SNMPv2-SMI Lingle, et al. Expires August 1, 2005 [Page 56] Internet-Draft SIP MIB Modules January 2005 TruthValue, TimeStamp, DateAndTime FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB applIndex FROM NETWORK-SERVICES-MIB InetAddressType, InetAddress FROM INET-ADDRESS-MIB; sipServerMIB MODULE-IDENTITY LAST-UPDATED "200501281700Z" 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 392 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 3708 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) Server MIB module. Lingle, et al. Expires August 1, 2005 [Page 57] Internet-Draft SIP MIB Modules January 2005 SIP is an application-layer signaling protocol for creating, modifying and terminating multimedia sessions with one or more participants. These sessions include Internet multimedia conferences and Internet telephone calls. SIP is defined in RFC 3261 (June 2002). This MIB is defined for the management of SIP Proxy, Redirect and Registrar Servers. A Proxy Server acts as both a client and a server. It accepts requests from other clients, either responding to them or passing them on to other servers, possibly after modification. A Redirect Server accepts requests from clients and returns zero or more addresses to that client. Unlike a User Agent Server it does not accept calls. A Registrar is a server that accepts REGISTER requests. A Registrar is typically co-located with a Proxy or Redirect Server. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." -- RFC Ed: replace XXXX with actual RFC number and remove this note REVISION "200501281700Z" DESCRIPTION "Initial version of the IETF SIP-SERVER-MIB module. This version published as part of RFC XXXX." -- RFC Ed: replace XXXX with actual RFC number and remove this note ::= { mib-2 XXX4 } -- RFC Ed: replace XXX4 with actual IANA assigned number and remove this note -- Top-Level Components of this MIB. sipServerMIBObjects OBJECT IDENTIFIER ::= { sipServerMIB 1 } sipServerMIBConform OBJECT IDENTIFIER ::= { sipServerMIB 2 } -- -- These groups contain objects common to all SIP servers. -- sipServerCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 1 } -- -- Common Server Configuration Objects -- sipServerCfgTable OBJECT-TYPE Lingle, et al. Expires August 1, 2005 [Page 58] Internet-Draft SIP MIB Modules January 2005 SYNTAX SEQUENCE OF SipServerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable to SIP Redirect and Proxy Servers." ::= { sipServerCfg 1 } sipServerCfgEntry OBJECT-TYPE SYNTAX SipServerCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common configuration. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here. The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex } ::= { sipServerCfgTable 1 } SipServerCfgEntry ::= SEQUENCE { sipServerHostAddrType InetAddressType, sipServerHostAddr InetAddress } sipServerHostAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of Internet address by which the SIP server is reachable." REFERENCE "RFC 3261, Section 19.1.1" ::= { sipServerCfgEntry 1 } sipServerHostAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current Lingle, et al. Expires August 1, 2005 [Page 59] Internet-Draft SIP MIB Modules January 2005 DESCRIPTION "This is the host portion of a SIP URI that is assigned to the SIP server. It MAY contain a fully qualified domain name, or an IP address. The length of the value will depend on the type of address specified. sipServerHostAddrType formalizes the type of address given by this object. It is the users responsibility to maintain consistency between this object and the type specified by sipServerHostAddrType." REFERENCE "RFC 3261, Section 19.1.1" ::= { sipServerCfgEntry 2 } -- -- This group contains MIB objects related to SIP Proxy Servers. -- sipProxyCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 3 } sipProxyStats OBJECT IDENTIFIER ::= { sipServerMIBObjects 4 } -- -- Proxy Server Configuration -- sipProxyCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipProxyCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable to SIP Proxy Servers." ::= { sipProxyCfg 1 } sipProxyCfgEntry OBJECT-TYPE SYNTAX SipProxyCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common proxy configuration. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here. The objects in this table entry SHOULD be non-volatile and their value SHOULD be kept at reboot." INDEX { applIndex } Lingle, et al. Expires August 1, 2005 [Page 60] Internet-Draft SIP MIB Modules January 2005 ::= { sipProxyCfgTable 1 } SipProxyCfgEntry ::= SEQUENCE { sipProxyStatefulness INTEGER, sipProxyRecursion TruthValue, sipProxyRecordRoute TruthValue, sipProxyAuthMethod BITS, sipProxyAuthRealm SnmpAdminString } sipProxyStatefulness OBJECT-TYPE SYNTAX INTEGER { stateless(1), transactionStateful(2), callStateful(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the default mode of operation for the Proxy Server entity. A stateless proxy is a logical entity that does not maintain the client or server transaction state machines when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. If the value of this object is stateless(1), the proxy defaults to stateless operations. A transaction stateful proxy, or simply a 'stateful proxy', is a logical entity that maintains the client and server transaction state machines during the processing of a request. A (transaction) stateful proxy is not the same as a call stateful proxy. If the value if this object is transactionStateful(2), the proxy is stateful on a transaction basis. A call stateful proxy is a logical entity if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. If the value of this object is callStateful(3), the proxy is call stateful." REFERENCE "RFC 3261, Section 16" ::= { sipProxyCfgEntry 1 } Lingle, et al. Expires August 1, 2005 [Page 61] Internet-Draft SIP MIB Modules January 2005 sipProxyRecursion OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether or not the Proxy performs recursive search on the Contacts provided in 3xx redirects. If the value of this object is 'true', a recursive search is performed. If the value is 'false', no search is performed, the 3xx response is sent upstream towards the source of the request." REFERENCE "RFC 3261 Sections 16.5 and 16.6" ::= { sipProxyCfgEntry 2 } sipProxyRecordRoute OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether or not the proxy adds itself to the Record-Route header as a default action. This header is used to list the proxies that insist on being in the signaling path for subsequent requests related to the call-leg. If the value of this object is 'true', the proxy adds itself to the end of the Record-Route header, creating the header if required. If the value is 'false', the proxy does not add itself to the Record-Route header." REFERENCE "RFC 3261, Section 20.30" ::= { sipProxyCfgEntry 3 } -- -- Security -- sipProxyAuthMethod OBJECT-TYPE SYNTAX BITS { none(0), tls(1), digest(2) } MAX-ACCESS read-only STATUS current Lingle, et al. Expires August 1, 2005 [Page 62] Internet-Draft SIP MIB Modules January 2005 DESCRIPTION "This object reflects the authentication methods that MAY be used to authenticate request originators. bit 0 no authentication is performed bit 1 TLS is used bit 2 HTTP Digest is used." REFERENCE "RFC 3261 Sections 22, 23, 26, 26.2.3" ::= { sipProxyCfgEntry 4 } sipProxyAuthRealm OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the realm used in Proxy-Authenticate headers. Note that this MAY need to be stored per user." REFERENCE "RFC 3261, Section 22.1" ::= { sipProxyCfgEntry 5 } -- -- Proxy Server Statistics -- sipProxyStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipProxyStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the statistics objects applicable to all SIP Proxy Servers in this system." ::= { sipProxyStats 1 } sipProxyStatsEntry OBJECT-TYPE SYNTAX SipProxyStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of summary statistics. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of Lingle, et al. Expires August 1, 2005 [Page 63] Internet-Draft SIP MIB Modules January 2005 applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipProxyStatsTable 1 } SipProxyStatsEntry ::= SEQUENCE { sipNumProxyRequireFailures Counter32 } sipNumProxyRequireFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the number of occurrences of unsupported options being specified in received Proxy- Require headers. Such occurrences result in a 420 Bad Extension status code being returned." ::= { sipProxyStatsEntry 1 } -- -- This group contains MIB objects related to SIP Registrars. -- sipRegCfg OBJECT IDENTIFIER ::= { sipServerMIBObjects 5 } sipRegStats OBJECT IDENTIFIER ::= { sipServerMIBObjects 6 } -- -- Registrar Configuration -- sipRegCfgTable OBJECT-TYPE SYNTAX SEQUENCE OF SipRegCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains configuration objects applicable SIP Registrars." ::= { sipRegCfg 1 } sipRegCfgEntry OBJECT-TYPE SYNTAX SipRegCfgEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of common Registrar configuration. Each row represents those objects for a particular SIP Lingle, et al. Expires August 1, 2005 [Page 64] Internet-Draft SIP MIB Modules January 2005 server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipRegCfgTable 1 } SipRegCfgEntry ::= SEQUENCE { sipRegAllowThirdParty TruthValue, sipRegMaxContactExpiryDuration Unsigned32, sipRegMaxUsers Unsigned32, sipRegCurrentUsers Gauge32, sipRegDfltRegActiveInterval Unsigned32 } sipRegAllowThirdParty OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects whether or not the Registrar SHOULD allow third party registrations. In third-party registration, the entity issuing the request (in the From header) is different from the entity being registered (in the To header) to whom the provided Contact information applies. If the value of this object is 'true', the Registrar allows third-party registrations. If the value is 'false', third-party registrations are rejected: a 403 (Forbidden) status code is returned to the requester. This object SHOULD be non-volatile and its value SHOULD be kept at reboot." REFERENCE "RFC 3261, Section 10.2" ::= { sipRegCfgEntry 1 } sipRegMaxContactExpiryDuration OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum expiry that may be requested by a User Agent for a particular Contact. Lingle, et al. Expires August 1, 2005 [Page 65] Internet-Draft SIP MIB Modules January 2005 User Agents can specify expiry using either an Expiry header in a REGISTER request, or using an Expires parameter in a Contact header in a REGISTER request. If the value requested by the User Agent is greater than the value of this object, then the contact information is given the duration specified by this object, and that duration is indicated to the User Agent in the response." ::= { sipRegCfgEntry 2 } sipRegMaxUsers OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the maximum number of users that the Registrar supports. The current number of users is reflected by sipRegCurrentUsers." ::= { sipRegCfgEntry 3 } sipRegCurrentUsers OBJECT-TYPE SYNTAX Gauge32 (0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the number of users currently registered with the Registrar." ::= { sipRegCfgEntry 4 } sipRegDfltRegActiveInterval OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "This object reflects the default time interval the Registrar considers registrations to be active. The value is used to compute the Expires header in the REGISTER response. If a user agent requests a time interval shorter than specified by this object, the Registrar SHOULD honor that request. If a Contact entry does not have an 'expires' parameter, the value of the Expires header field is used instead. If a Contact entry has no 'expires' parameter and no the Expires header field is present, the value of this object is used as the default value. This object SHOULD be non-volatile and its value SHOULD be kept at reboot." REFERENCE "RFC 3261, Section 10.2" Lingle, et al. Expires August 1, 2005 [Page 66] Internet-Draft SIP MIB Modules January 2005 ::= { sipRegCfgEntry 5 } -- -- Per User Information -- sipRegUserTable OBJECT-TYPE SYNTAX SEQUENCE OF SipRegUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on all users registered to each Registrar in this system." ::= { sipRegCfg 2 } sipRegUserEntry OBJECT-TYPE SYNTAX SipRegUserEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry contains information for a single user registered to this Registrar. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex, sipUserIndex } ::= { sipRegUserTable 1 } SipRegUserEntry ::= SEQUENCE { sipUserIndex Unsigned32, sipUserUri SnmpAdminString, sipUserAuthenticationFailures Counter32 } sipUserIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This object uniquely identifies a conceptual row in the table." ::= { sipRegUserEntry 1 } Lingle, et al. Expires August 1, 2005 [Page 67] Internet-Draft SIP MIB Modules January 2005 sipUserUri OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the user's address-of-record. It is the main form by which the Registrar knows the user. The format is typically 'user@domain'. It is contained in the To header for all REGISTER requests." ::= { sipRegUserEntry 2 } sipUserAuthenticationFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of times the user has failed authentication." ::= { sipRegUserEntry 3 } -- -- Per Contact Information -- sipContactTable OBJECT-TYPE SYNTAX SEQUENCE OF SipContactEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information on every location where a registered user (specified by sipUserIndex) wishes to be found (i.e. the user has provided Contact information to each SIP Registrar in this system)." ::= { sipRegCfg 3 } sipContactEntry OBJECT-TYPE SYNTAX SipContactEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This entry contains information for a single Contact. Multiple contacts may exist for a single user. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of Lingle, et al. Expires August 1, 2005 [Page 68] Internet-Draft SIP MIB Modules January 2005 applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex, sipUserIndex, sipContactIndex } ::= { sipContactTable 1 } SipContactEntry ::= SEQUENCE { sipContactIndex Unsigned32, sipContactDisplayName SnmpAdminString, sipContactURI SnmpAdminString, sipContactLastUpdated TimeStamp, sipContactExpiry DateAndTime, sipContactPreference SnmpAdminString } sipContactIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Along with the sipUserIndex, this object uniquely identifies a conceptual row in the table." ::= { sipContactEntry 1 } sipContactDisplayName OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the display name for the Contact. For example, 'Santa at Home', or 'Santa on his Sled', corresponding to contact URIs of sip:BigGuy@sip.northpole.ca or sip:sclaus817@sip.mobile.com, respectively." ::= { sipContactEntry 2 } sipContactURI OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains either a SIP URI where the user can be contacted. This URI is normally returned to a client from a Redirect Server, or is used as the RequestURI in a SIP request line for requests forwarded by a proxy." ::= { sipContactEntry 3 } Lingle, et al. Expires August 1, 2005 [Page 69] Internet-Draft SIP MIB Modules January 2005 sipContactLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates the time when this contact information was accepted. If the contact information is updated via a subsequent REGISTER of the same information, this object is also updated." ::= { sipContactEntry 4 } sipContactExpiry OBJECT-TYPE SYNTAX DateAndTime MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the date and time when the contact information will no longer be valid. Such times may be specified by the user at registration (Expires header or expiry parameter in the Contact information), or a system default can be applied." ::= { sipContactEntry 5 } sipContactPreference OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This object indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. A registering user may provide this preference as a 'qvalue'parameter in the Contact header. The format of this item is a decimal number between 0 and 1 (for example 0.9). Higher values indicate locations preferred by the user." REFERENCE "RFC 3261, Section 10.2.1.2, 16.6 and 20.10" ::= { sipContactEntry 6 } -- -- Registrar Statistics -- sipRegStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF SipRegStatsEntry Lingle, et al. Expires August 1, 2005 [Page 70] Internet-Draft SIP MIB Modules January 2005 MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains the summary statistics objects applicable to all SIP Registrars in this system." ::= { sipRegStats 1 } sipRegStatsEntry OBJECT-TYPE SYNTAX SipRegStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A row of summary statistics. Each row represents those objects for a particular SIP server present in this system. applIndex is used to uniquely identify these instances of SIP servers and correlate them through the common framework of the NETWORK-SERVICES-MIB (RFC 2788). The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." INDEX { applIndex } ::= { sipRegStatsTable 1 } SipRegStatsEntry ::= SEQUENCE { sipRegAcceptedRegistrations Counter32, sipRegRejectedRegistrations Counter32 } sipRegAcceptedRegistrations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number of REGISTER requests that have been accepted (status code 200) by the Registrar. This includes additions of new contact information, refreshing contact information, as well as requests for deletion of contact information." ::= { sipRegStatsEntry 1 } sipRegRejectedRegistrations OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains a count of the number REGISTER Lingle, et al. Expires August 1, 2005 [Page 71] Internet-Draft SIP MIB Modules January 2005 requests that have been rejected by the Registrar." ::= { sipRegStatsEntry 2 } -- -- Conformance -- sipServerMIBCompliances OBJECT IDENTIFIER ::= { sipServerMIBConform 1 } sipServerMIBGroups OBJECT IDENTIFIER ::= { sipServerMIBConform 2 } -- -- Compliance Statements -- sipProxyServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Proxy Servers." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup, sipProxyConfigGroup, sipProxyStatsGroup } ::= { sipServerMIBCompliances 1 } sipRedirectServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Redirect Servers." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup } ::= { sipServerMIBCompliances 2 } sipRegistrarServerCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SIP entities acting as Registrars." MODULE -- this module MANDATORY-GROUPS { sipServerConfigGroup, sipRegistrarConfigGroup, sipRegistrarStatsGroup } GROUP sipRegistrarUsersGroup DESCRIPTION "This is an optional group." ::= { sipServerMIBCompliances 3 } Lingle, et al. Expires August 1, 2005 [Page 72] Internet-Draft SIP MIB Modules January 2005 -- -- Units of Conformance -- sipServerConfigGroup OBJECT-GROUP OBJECTS { sipServerHostAddrType, sipServerHostAddr } STATUS current DESCRIPTION "A collection of objects providing configuration common to SIP Proxy and Redirect servers." ::= { sipServerMIBGroups 1 } sipProxyConfigGroup OBJECT-GROUP OBJECTS { sipProxyStatefulness, sipProxyRecursion, sipProxyRecordRoute, sipProxyAuthMethod, sipProxyAuthRealm } STATUS current DESCRIPTION "A collection of objects providing configuration for SIP Proxy servers." ::= { sipServerMIBGroups 2 } sipProxyStatsGroup OBJECT-GROUP OBJECTS { sipNumProxyRequireFailures } STATUS current DESCRIPTION "A collection of objects providing statistics for SIP Proxy servers." ::= { sipServerMIBGroups 3 } sipRegistrarConfigGroup OBJECT-GROUP OBJECTS { sipRegAllowThirdParty, sipRegMaxContactExpiryDuration, sipRegMaxUsers, sipRegCurrentUsers, sipRegDfltRegActiveInterval } STATUS current DESCRIPTION Lingle, et al. Expires August 1, 2005 [Page 73] Internet-Draft SIP MIB Modules January 2005 "A collection of objects providing configuration for SIP Registrars." ::= { sipServerMIBGroups 4 } sipRegistrarStatsGroup OBJECT-GROUP OBJECTS { sipRegAcceptedRegistrations, sipRegRejectedRegistrations } STATUS current DESCRIPTION "A collection of objects providing statistics for SIP Registrars." ::= { sipServerMIBGroups 5 } sipRegistrarUsersGroup OBJECT-GROUP OBJECTS { sipUserUri, sipUserAuthenticationFailures, sipContactDisplayName, sipContactURI, sipContactLastUpdated, sipContactExpiry, sipContactPreference } STATUS current DESCRIPTION "A collection of objects related to registered users." ::= { sipServerMIBGroups 6 } END 8. Changes from Previous Draft Revisions -- RFC Ed: this entire section to be removed by RFC Editor before publication. Changes from draft-ietf-sip-mib-08. The majority of changes are in response to additional SIP Working Group comments. o General * The IANA Consideration section was updated and a new section 9.2 was added to conform with the Guidelines for Authors and Reviewers of MIB Documents, draft-ietf-ops-mib-review-guidelines-03.txt, section 3.7. Lingle, et al. Expires August 1, 2005 [Page 74] Internet-Draft SIP MIB Modules January 2005 * In general the ability to configure SIP entities via read-create or read-write objects was removed and those objects MAX-ACCESS constrained to read-only. This change was made based on general consensus that SNMP should be limited to monitoring rather than configuring/provisoning. * The section 5.2 (Relationship to the Network Services MIB) was updated to allow each instance of a SIP entity to have its own row in the applTable (a unique aplication identifier should now be appended to the "sip_xxx" entity-name). We also lowered the level of requirement on the naming convention to a SHOULD instead of a MUST per wg input. * Updated the ORGANISATION clause of all MIB modules to include the full SIP working group name. * Minor other editorial changes were made to the document. * Updated Security consideration section. o SIP-COMMON-MIB * Module description of various SIP entities enhanced. * sipServiceAdminStatus removed from the MIB due to general removal of configuration capability. Resulting OID value changes to succeeding entry objects. * sipOrganization MAX-ACCESS changed to read-only. * sipCfgTimerA MAX-ACCESS changed to read-only. * sipCfgTimerB MAX-ACCESS changed to read-only. * sipCfgTimerC MAX-ACCESS changed to read-only. * sipCfgTimerD MAX-ACCESS changed to read-only. * sipCfgTimerE MAX-ACCESS changed to read-only. * sipCfgTimerF MAX-ACCESS changed to read-only. * sipCfgTimerG MAX-ACCESS changed to read-only. * sipCfgTimerH MAX-ACCESS changed to read-only. * sipCfgTimerI MAX-ACCESS changed to read-only. * sipCfgTimerJ MAX-ACCESS changed to read-only. * sipCfgTimerK MAX-ACCESS changed to read-only. * sipCfgTimerT1 MAX-ACCESS changed to read-only. * sipCfgTimerT2 MAX-ACCESS changed to read-only. * sipCfgTimerT4 MAX-ACCESS changed to read-only. * sipStatusCodesTable indexing changed to also include sipStatusCodeMethod. Thusly, introducing sipStatusCodeMethod as a new not-accessible object in that table. Resulting OID value changes to succeeding entry objects. * sipCfgTimer* OBJECT clauses regarding MIN-ACCESS levels in the MODULE-COMPLIANCE were no longer needed due to MAX-ACCESS changes for those objects. * The description clause of sipStatsInbounds was changed to state that retransmissions are not counted. * The description clause of sipStatsRetries was changed to indicate there could be multiple retries per request (we also corrected a typo by removing the specific mention to INVITE requests). Lingle, et al. Expires August 1, 2005 [Page 75] Internet-Draft SIP MIB Modules January 2005 * The description clause of sipStatsRetryFinalResponses was changed to indicate there could be multiple retries per response. o SIP-SERVER-MIB * Removed sipCommonCfgExpires OID declaration as this object group no longer exists since draft08. * sipUserTableRowStatus removed from the MIB due to general removal of configuration capability. In conjuction, RowStatus textual convention is no longer imported. * sipServerHostAddrType MAX-ACCESS changed to read-only. * sipServerHostAddr MAX-ACCESS changed to read-only. * sipProxyRecursion MAX-ACCESS changed to read-only. * sipProxyRecordRoute MAX-ACCESS changed to read-only. * sipProxyAuthMethod MAX-ACCESS changed to read-only. * sipRegAllowThirdParty MAX-ACCESS changed to read-only. * sipRegMaxContactExpiryDuration MAX-ACCESS changed to read-only. * sipRegDfltRegActiveInterval MAX-ACCESS changed to read-only. * sipUserUri MAX-ACCESS changed to read-only. * 'smime' removed as a possible value for sipProxyAuthMethod. o SIP-UA-MIB * sipUACfgServerStatus removed from the MIB due to general removal of configuration capability. In conjuction, RowStatus textual convention is no longer imported. * sipUACfgServerAddrType MAX-ACCESS changed to read-only. * sipUACfgServerAddr MAX-ACCESS changed to read-only. * sipUACfgServerFunction MAX-ACCESS changed to read-only. Changes from draft-ietf-sip-mib-07. The vast majority of changes are in response to the Working Group Last Call and expert review comments. o General * IANA requirements section added to specify the need for registered numbers for all SIP methods. These will be used in the MIB objects. * Updated the security consideration section to reflect the addition and deletion of a number of objects. o SIP-COMMON-MIB * Module description of various SIP entities enhanced. * sipMaxSessions renamed sipMaxTransactions. Workgroup last call reviewers suggested a change based on some change of terms in the standard. Transactions seemed the appropriate term. The object description was also enhanced. * sipRequestUriHostMatching object removed based on comments from workgroup last call comments. * sipEntityType changed from enumerated INTEGER to SipEntityRole textual convention syntax. Lingle, et al. Expires August 1, 2005 [Page 76] Internet-Draft SIP MIB Modules January 2005 * sipServiceAdminStatus enumerated value 'quiesceSessions' changed to 'quiesceDialogs'. * sipPortTable was redesigned. sipTransportSnd object was removed as it did not make much sense. sipPortStatus was removed to prevent any row creation deletion. The remaining object, sipTransportRcv was made read-only. * sipUriSupportedTable was removed as it was not deemed useful anymore. * sipExtMethodSupportedTable replaced with a general sipMethodSupportedTable. IANA SIP method identifiers/numbers will be used in this new table. The previous concept of explicitly defining objects per the current well-know methods and then providing separate, semantically similar, 'extension methods' tables has been eliminated. * sipCommonCfgTimerExtMethodTable was removed. No more need for 'extension methods' tables. * sipCommonCfgRetryTable was removed. Limits on retransmissions are controlled by timers in the SIP standard now rather than by maximum counts; therefore, these objects were no longer relevant. sipCommonConfigRetryGroup was likewise removed. * sipFtrSupportedTable was redesigned as sipOptionTagsTable. * sipCommonCfgTimerExtMethodTable was removed. * sipSummaryTotalTransactions description changed to reflect that in the case of forked request, _each_ branch rather than _all_ branches count as a single transaction. * sipMethodStatsTable was redesigned, taking into account the new SipMethodIdentifer textual convention. The objects were generalized to two: sipStatsOutbound and sipStatsInbound. The indexing object (sipStatsMethod) has syntax SipMethodIdentifier and thereby identifies the method associated with the instances of in/out counter objects. * sipCurrentTransactions description changed to reflect that in the case of forked request, _each_ branch rather than _all_ branches count as a single transaction. * sipCommonStatsRetryTable was redesigned, taking into account the new SipMethodIdentifer textual convention. A single, generalize object (sipStatsRetries) replaces several method-specific objects. The new, additional indexing object (sipStatsRetryMethod) has syntax SipMethodIdentifier and thereby identifies the method associated with the instances of the counter objects in each row. * sipCommonStatsRetryExtMethodTable was removed. * sipStatusCodeClassesTable removed. * sipOtherStatsTable has two new objects added: sipNumUnsupportedMethods and sipOtherwiseDiscardedMsgs. * The following object-groups were removed because their associated objects were removed: sipCommonConfigTimerExtMethodGroup, sipCommonConfigRetryGroup, Lingle, et al. Expires August 1, 2005 [Page 77] Internet-Draft SIP MIB Modules January 2005 sipCommonConfigRetryExtMethodGroup, sipCommonStatsRetryExtMethodsGroup, and sipCommonConfigExpiresGroup. The references to these object-groups as optional in the module-compliance was updated accordingly. * GROUP clause for sipCommonStatsRetryGroup in module-compliance was udpated to no longer state any dependency on sipCommonConfigRetryGroup (now removed). * New OBJECT clauses were added to the module-compliance to formalize MIN-ACCESS read-only for objects in sipCommonCfgTimerTable. * sipCommonConfigGroup udpated with new objects (sipOptionTag, sipOptionTagHeaderField, sipMethodName), removed objects (sipTransportSnd, sipPortStatus, sipUriSupported, sipFtrSupported, sipExtMethodName, sipRequestUriHostMatching), and changed objects (sipMaxTransactions). * sipCommonStatsGroup updated with new objects (sipStatsOutbounds, sipStatsInbounds, sipNumUnsupportedMethods, sipOtherwiseDiscardedMsgs) and removed objects (sipStatsInviteIns, sipStatsInviteOuts, sipStatsAckIns, sipStatsAckOuts, sipStatsByeIns, sipStatsByeOuts, sipStatsCancelIns, sipStatsCancelOuts, sipStatsOptionsIns, sipStatsOptionsOuts, sipStatsRegisterIns, sipStatsRegisterOuts, sipStatsExtMethodIns, sipStatsExtMethodOuts, sipStatsInfoClassIns, sipStatsInfoClassOuts, sipStatsSuccessClassIns, sipStatsSuccessClassOuts, sipStatsRedirClassIns, sipStatsRedirClassOuts, sipStatsReqFailClassIns, sipStatsReqFailClassOuts, sipStatsServerFailClassIns, sipStatsServerFailClassOuts, sipStatsGlobalFailClassIns, sipStatsGlobalFailClassOuts, sipStatsOtherClassesIns, sipStatsOtherClassesOuts). * sipCommonStatsRetryGroup updated with new object (sipStatsRetries) and removed objects (sipStatsRetryInvites, sipStatsRetryByes, sipStatsRetryCancels, sipStatsRetryRegisters, sipStatsRetryOptions). o SIP-SERVER-MIB * Module description of various SIP entities enhanced. * sipServerStats 'placeholder' IOD removed. No objects were ever defined under that subtree. * Removed the following objects from sipProxyCfgTable: sipRequestMaxExpires, sipProxySendsCancel, sipProxyForwardAll1xx, sipProxyProvideAlternatives, and sipProxyNonceLifeTime. sipProxyConfigGroup updated accordingly. * sipProxyStatefulness MAX-ACCESS changed to read-only. * DEFVAL removed from sipRegMaxContactExpiryDuration. * sipContactRetryAfter removed from sipContactTable. Lingle, et al. Expires August 1, 2005 [Page 78] Internet-Draft SIP MIB Modules January 2005 * sipUser* and sipContact* objects were moved from sipRegistrarConfigGroup to a new object-group: sipRegistrarUsersGroup. The new group was made an optional group in the MODULE-COMPLIANCE. o SIP-UA-MIB * SipEntityRole imported from SIP-TC module and used as the syntax for new object sipUACfgServerFunction. * sipUACfgSipServerTable (and objects therein) have their descriptors changed to sipUACfgServer* ("Sip" removed). sipUAConfigGroup updated accordingly. * sipUACfgServerFunction added to sipUACfgServerTable. * DEFVAL { ipv4 } removed from sipUACfgServerAddrType. o SIP-TC * New textual conventions: SipEntityRole, SipOptionTagHeaders, and SipMethodIdentifier added. Changes from draft-ietf-sip-mib-06 o General * Minor editorial changes in the Textual Conventions section. o SIP-COMMON-MIB * sipStatusCodeValue SYNTAX changed from INTEGER to Unsigned32. * Optional sipCommonNotifObjectsGroup explicitly added to MODULE-COMPLIANCE. * Removed OBJECT refinement for sipStatusCodeRowStatus added to compliance in previous revision. SMIC MIB compiler issues required it to be commented out. Instead, simply removed it. o SIP-SERVER-MIB * Removed OID placeholders: sipRedirCfg, sipRedirStats. sipRegCfg and sipRegStats OID values subsequently changed as a result. o SIP-UA-MIB * Removed OBJECT refinement for sipUACfgSipServerStatus added to compliance in previous revision. SMIC MIB compiler issues required it to be commented out. Instead, simply removed it. Changes from draft-ietf-sip-mib-05 o Front paper/Back paper and General changes * Removed all references and special handling of SIP INFO method Removed references and objects specific to RFC 2976: INFO will be treated as any SIP extension method. * Changed requirements verbs from lowercase to uppercase wherever appropriate. * Added RFC Editor notes. * Updated all REFERENCE clauses and DESCRIPTIONS from RFC 2543 to RFC 3261. * Explained the approach taken for extension methods that might be defined in the future. Lingle, et al. Expires August 1, 2005 [Page 79] Internet-Draft SIP MIB Modules January 2005 * Defined a mapping of sipServiceOperStatus to applOperStatus. * Enhanced Security section with details on various objects. * Added descriptive language to various Entry objects regarding the expected persistence of data across system restarts. o SIP-COMMON-MIB * Removed sipTransactionTable after input from SIP community. * Made all extension method tables augmentations of sipExtMethodSupportedTable. This resulted in the removal of the following objects: sipCfgTimerExtMethodName, sipCfgRetryExtMethodName, sipStatsExtMethodName, sipStatsRetryExtMethodName. * sipCommonStatusCodeNotifEmitMode default value changed to 'triggered'. * sipStatusCodeThreshExceededNotif was replaced by two notifications: sipStatusCodeThreshExceededOutNotif and sipStatusCodeThreshExceededInNotif. * Re-arranged the enumerated value of sipServiceOperStatus; making 'unknown' the first value. Added some words to the DESCRIPTION of that object stating the values are not based on anything in the SIP standard. * Clarified rules for capitalization of sipExtMethodName. * All counters in the MIB are consistent with respect to resetting to zero. No counters can be reset to zero. Entries in sipStatusCodesTable can simply be created or destroyed - no ability to set to 'notInService' where there was the question/possibility of resetting the counters to zero. sipStatsExtMethodTable no longer has its own RowStatus object, so it too can no longer be set to 'notInService' where there was the question/possibility of resetting the counters to zero. sipStatsExtMethodTable rows are augmentations of sipExtMethodSupportedEntry. * OBJECT refinement for sipStatusCodeRowStatus added to compliance. * Clarified the relationship between sipCommonStatusCodeNotifEmitMode and sipCommonStatusCodeNotifSend. * Explained the existence of sipNotifApplIndex object better. * sipCfgExpiresStatusCodeValue syntax changed from INTEGER to Unsigned32. * sipEntityType object added to sipCommonCfgTable. * All accessible-for-notify objects are moved into sipCommonNotifObjects group. OIDs for actual notifications are re-assigned as a result. * sipNotifSequenceNumber accessible-for-notify object added as a way for managers to gain insight into possible missed notifications. It is bound to each notification defined in the MIB. Lingle, et al. Expires August 1, 2005 [Page 80] Internet-Draft SIP MIB Modules January 2005 * New notifications related to SIP service operational status are added: sipServiceColdStart, sipServiceWarmStart, and sipServiceLastChanged. * New object sipServiceNotifEnable added to control the new SIP related notifications. * Minor object descriptor changes: sipStatusCodesTable renamed to sipStatusCodeClassesTable SipStatusCodesEntry renamed to SipStatusCodeClassesEntry sipStatusCodesEntry renamed to sipStatusCodeClassesEntry sipCommonStatusCodeTable renamed to sipStatusCodesTable SipCommonStatusCodeEntry renamed to SipStatusCodesEntry sipCommonStatusCodeEntry renamed to sipStatusCodesEntry sipCommonStatusCodeValue renamed to sipStatusCodeValue sipCommonStatusCodeIns renamed to sipStatusCodeIns sipCommonStatusCodeOuts renamed to sipStatusCodeOuts sipCommonStatusCodeStatus renamed to sipStatusCodeRowStatus sipCommonStatusCodeNotifTable renamed to sipStatusCodeNotifTable SipCommonStatusCodeNotifEntry renamed to SipStatusCodeNotifEntry sipCommonStatusCodeNotifEntry renamed to sipStatusCodeNotifEntry sipCommonStatusCodeNotifSend renamed to sipStatusCodeNotifSend sipCommonStatusCodeNotifEmitMode renamed to sipStatusCodeNotifEmitMode sipCommonStatusCodeNotifThresh renamed to sipStatusCodeNotifThresh sipCommonStatusCodeNotifInterval renamed to sipStatusCodeNotifInterval * Removed all INFO method specific objects: sipCfgRetryInfo, sipStatsInfoIns, sipStatsInfoOuts, and sipStatsRetryInfos * Clarifying words added to sipStatusCodeNotifTable DESCRIPTION to explain why it's a separate table from sipStatusCodesTable. o SIP-SERVER-MIB * Deleted objects related to 'action' parameter. RFC 3261 section 10.2 deprecates the 'action' parameter deleted 3 objects: sipServerContactDfltAction, sipServerRespectUAAction, sipContactAction. * Deleted pgp-related objects. RFC 3261 section 23 deprecates use of pgp deleted 3 objects: sipProxyAuthPgpAlgorithm, sipPgpPrivateKey, sipPgpVersion. * Removed sipProxyStateTimeout object. Timers G and timer H have been introduced in RFC 3261 for this purpose (see RFC 3261 section 17.2.1). * Updated description clause of sipProxyStatefulness. The 3 definitions of stateless/statefulness now match the text in RFC 3261. * Changed DEFVAL for object sipProxyProvideAlternatives. Changed DEFVAL to true to align with RFC 3261 that states that 485 responses SHOULD contain a contact header and 303 MAY... and updated REFERENCE clause to "RFC 3261 Sections 13.2.2.2 and 16.5". Lingle, et al. Expires August 1, 2005 [Page 81] Internet-Draft SIP MIB Modules January 2005 * Removed basic authentication value from sipProxyAuthMethod object Per section 22 of RFC 3261, deprecated. * Changed SYNTAX of sipProxyNonceLifeTime from Integer32 to Unsigned32. * Updated description clause of sipRegDfltRegActiveInterval Per RFC 3261 Section 10.2. o SIP-UA-MIB * OBJECT refinement for sipUACfgSipServerStatus added to compliance. * Changed the object descriptors of sipUACfgSipServerAddrIndex to sipUACfgSipServerIndex, and sipUACfgSipServerAddrStatus to sipUACfgSipServerStatus. Changes from draft-ietf-sip-mib-04 o Started realignment with SIP RFC3261. Changes from draft-ietf-sip-mib-03 o Front paper/Back paper and General changes * Rewrote section on Network Services MIB * Fixed minor editorial nits o SIP-COMMON-MIB * CONTACT-INFO "SIP MIB email" changed to sip@ietf.org * sipInviteTimeout was removed from the MIB. See below regarding new sipCommonCfgExpires objects. They provide equivalent functionality with extensibility beyond INVITE. * sipCommonCfgExpires OID subtree added. Per method Expires configuration objects were added there. This new high-level OID was placed under the existing sipCommonCfgRetry OID and therefore, caused the OIDs for the subsequent groups to change (incrementing by one). * Objects from tables under sipCommonCfgExpires were added to a new OBJECT-GROUP sipCommonConfigExpiresGroup, and that group was listed as optional in sipCommonCompliance. * Minor DESCRIPTION change for sipCommonCfgEntry. No behavior change. * sipServiceOperStatus SYNTAX changed. New values added: congested and quiescing Old values removed: halted The order of the enumeration was altered as well. * sipServiceAdminStatus SYNTAX changed. New values added: noop, up, down, quieseSessions, and quieseApplications Old values removed: shutdown, restart, stop, rts. These changes were made based on comments from last call reviewer and general known ambiguities in the previous design of the object. * Clarifying changes to the DESCRIPTION of sipServiceStartTime. * Clarifying changes to the DESCRIPTION of sipServiceStartTime. * Clarification of behavior for sipPortStatus while row is 'active' Lingle, et al. Expires August 1, 2005 [Page 82] Internet-Draft SIP MIB Modules January 2005 * Clarifying changes to the DESCRIPTION of sipUriSupportedTable. * Clarifying changes to the DESCRIPTIONs of sipFtrSupportedTable, sipFtrSupportedEntry, and sipFtrSupported. Specifically, IETF standard features and non-standard features are now represented by this table. Only non-standard features were mentioned in prior revisions of the draft. * Reference to usage of RFC 2788 applIndex moved from sipCommonCfgTimerExtMethodTable to sipCommonCfgTimerExtMethodEntry. This was the convention for other table/entry definitions in the MIB, so these objects were previously unconventional. * DEFVAL removed from sipCfgTimerExtMethodTimer. The generic nature of the "extension" object does not lend itself to being able to specify a particular default value. * Since the removal of the DEFVAL clause from sipCfgTimerExtMethodTimer, a value for that object must be specified when creating a sipCommonCfgTimerExtMethodEntry. The description of sipCfgTimerExtMethodStatus was updated to reflect this. * sipCommonCfgRetryExtMethodTable is now properly defined under sipCommonCfgRetry OID space instead of under sipCommonCfgTimer OID space. * DEFVAL removed from sipCfgRetryExtMethodRetry. The generic nature of the "extension" object does not lend itself to being able to specify a particular default value. * Since the removal of the DEFVAL clause from sipCfgRetryExtMethodRetry, a value for that object must be specified when creating a sipCommonCfgRetryExtMethodEntry. The description of sipCfgRetryExtMethodStatus was updated to reflect this. * Clarifying changes to the DESCRIPTION of sipSummaryTotalTransactions. Specifically, the object is not applicable to stateless SIP proxy servers and the object should always return a value of 0 if implemented by a stateless proxy. * Clarifying changes to the DESCRIPTION of sipStatsExtMethodStatus. * sipStatsOtherClassesIns and sipStatsOtherClassesOuts counter objects were added to sipStatusCodesTable to handle possible future classes of response status codes. * Text referring specifically to Redirect Server in sipStatsRedirClassIns and sipStatsRedirClassOuts was removed. * Text defining protocol behavior in sipStatsServerFailClassIns, sipStatsServerFailClassOuts, sipStatsGlobalFailClassIns, and sipStatsGlobalFailClassOuts was removed. * sipCommonStatusCodeNotifInterval SYNTAX changed from TimeTicks to Unsigned32 w/ a UNITS of "seconds" added to the definition. DEFVAL clause changed accordingly. Lingle, et al. Expires August 1, 2005 [Page 83] Internet-Draft SIP MIB Modules January 2005 * sipStatusCodeNotifTo, sipStatusCodeNotifFrom, sipStatusCodeNotifCallId, and sipStatusCodeNotifCSeq all had clarifying changes to their DESCRIPTIONs. Specifically, the header name will be part of the object value and example values were given. * Clarifying changes to the DESCRIPTION of sipCurrentTransTable and sipTransactionTable. Specifically, these tables are not applicable to transaction stateless SIP Proxy Servers. * Minor grammatical change to the DESCRIPTION of sipCurrentTransEntry. * sipTransMethod and sipTransActivityInfo objects were added to sipTransactionTable while sipTransCallingPartyContentType and sipTransCalledPartyContentType were removed. * Clarifying changes to the DESCRIPTION of sipTransState. Specifically, noting that not all values of the object are applicable to all transaction types. * sipTransTo, sipTransFrom, sipTransCallId, and sipTransCSeq all had clarifying changes to their DESCRIPTIONs. Specifically, the header name will be part of the object value and example values were given. * Minor grammatical change to the DESCRIPTION of sipOtherStatsEntry. * sipCommonStatusCodeIns and sipCommonStatusCodeOuts objects were added to the varbind of sipStatusCodeNotif. * Appropriate changes were made to sipCommonStatsGroup OBJECT-GROUP based on objects being added and/or removed from the MIB. o SIP-SERVER-MIB * CONTACT-INFO "SIP MIB email" changed to sip@ietf.org * The statement "Unlike a Proxy server it does not initiate requests." was removed from where a Redirect Server is defined in the MIB's DESCRIPTION. * sipServerMIBNotifs OID removed. No notifications were ever defined under this subtree. * Clarifying text added to all of the Table DESCRIPTIONS stating that the value of applIndex used in this MIB corresponds to the value of applIndex used in the SIP-COMMON-MIB. * Clarifying changes to the DESCRIPTION of sipProxyStatefulness. * sipContactPreference SYNTAX changed from OCTET STRING to SnmpAdminString. o SIP-UA-MIB * CONTACT-INFO "SIP MIB email" changed to sip@ietf.org * sipUAMIBNotifs OID removed. No notifications were ever defined under this subtree. * sipUAStats OID removed. No notifications were ever defined under this subtree. * Clarifying text added to all of the Table DESCRIPTIONS stating that the value of applIndex used in this MIB corresponds to the Lingle, et al. Expires August 1, 2005 [Page 84] Internet-Draft SIP MIB Modules January 2005 value of applIndex used in the SIP-COMMON-MIB. o SIP-TC * CONTACT-INFO "SIP MIB email" changed to sip@ietf.org Changes from draft-ietf-sip-mib-02 o General * Eliminated the SIP-MIB-SMI modules. Each MIB module will now get it's own IANA OID. * Top-level OID subtrees restructured in each MIB. * General cleanup/removal of "placeholder" OID subtrees for object groups and notifications that never materialized. o SIP-COMMON-MIB * Removed sipCfgInitialTimerAck. * Removed sipCfgRetryAck. * Removed sipStatsRetryAcks. * sipCommonStatsRetryExtMethodEntry was missing its INDEX clause. * sipNumUnsupportedUris OID was "5" when it was the only object in the table. OID is now "1". * High-level OID structure of the MIB is now sequential. * Incorrect object descriptor for sipCfgInitialTimerRsp inconsistent with reference in compliance section. * Inconsistencies between sipCommonStatsRetryGroup definition and SipCommonStatsRetryEntry OBJECT-TYPE corrected. * sipNotifApplIndex was not in any object group in the conformance section. o SIP-SERVER-MIB * Removed sipInformationTryingInterval. * Removed sipRxProxyAuthTable. * Removed sipRegRespHasContacts. * Removed sipRegContactDfltExpiryDate. * Removed sipRegContactDfltExpiryDuration. * Removed sipUserPassword. * sipRequestMaxExpires DESCRIPTION changed to no longer specifically mention 400 response. * sipProxyStateful object descriptor changed to sipProxyStatefullness and the SYNTAX changed from TruthValue to an enumerated INTEGER. * sipProxyStateTimeout DESCRIPTION changed to now reflect only INVITE. * Gauge32 was not being IMPORTed. * sipServerContactDfltAction showed up in conformance and other object descriptions in an older form. * sipServerHost replaced with InetAddressType/InetAddress object pair (sipServerHostAddrType and sipServerHostAddr). o SIP-UA-MIB * IMPORTed Unsigned32 to support sipUACfgSipServerAddrIndex. * sipUACfgSipServerEntry was referencing the wrong auxiliary object and listing that object in the conformance section. Lingle, et al. Expires August 1, 2005 [Page 85] Internet-Draft SIP MIB Modules January 2005 * sipUACfgSipServerEntry listed sipUACfgSipServerStatus when it should have been listing sipUACfgSipServerAddrStatus. * SIP-UA-MIB IMPORTed Counter32, but never used it. Removed the IMPORT of Counter32. 9. IANA Considerations 9.1 Registration of Numeric Identifiers for SIP methods 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 augments the existing sub-registry for SIP Methods to include a unique numeric method identifier for each registered SIP method. The SIP-TC and SIP-COMMON-MIB modules require that a unique numeric identifier be assigned by IANA for each SIP Method registered in the above registry. In the SIP-TC module, we have indeed defined a textual-convention to represent a SIP method by a unique numeric identifier, SipMethodIdentifier. In the SIP-COMMON-MIB module, a number of MIB objects use this textual-convention where it is sufficient or more effective to refer to a method by a number rather than by a character string. For example, the SIP methods supported by a SIP entity can be found in the sipSupportedMethodTable, a table indexed by an object of type SipMethodIdentifier. The mapping of method identifiers to method names - as assigned by IANA can then be represented in the SIP MIB by the sipSupportedMethodTable in the SIP-COMMON-MIB as follows: +-------------------------+------------------------+ | sipMethodSupportedIndex | sipMethodSupportedName | +-------------------------+------------------------+ | 1 | "ACK" | | 2 | "BYE" | | 3 | "CANCEL" | | 5 | "INVITE" | | 8 | "OPTIONS" | +-------------------------+------------------------+ The following section requests the assignment of a unique numeric identifier for all the SIP methods already registered. For new SIP method, their registration will automatically trigger the assignment of a new numeric method identifier. In other words, this sub-registration is completely linked with the existing procedures to register SIP methods as specified in RFC 3261 [RFC3261] and RFC 3427 [RFC3427]. This document modifies the IANA registry for SIP Method names by Lingle, et al. Expires August 1, 2005 [Page 86] Internet-Draft SIP MIB Modules January 2005 adding a new column called "Method Identifiers", as shown in the table below: +-----------+-----------+--------------------+ | Methods | Reference | Method Identifiers | +-----------+-----------+--------------------+ | ACK | [RFC3261] | 1 | | BYE | [RFC3261] | 2 | | CANCEL | [RFC3261] | 3 | | INFO | [RFC2976] | 4 | | INVITE | [RFC3261] | 5 | | MESSAGE | [RFC3428] | 6 | | NOTIFY | [RFC3265] | 7 | | OPTIONS | [RFC3261] | 8 | | PRACK | [RFC3262] | 9 | | PUBLISH | [RFC3903] | 10 | | REFER | [RFC3515] | 11 | | REGISTER | [RFC3261] | 12 | | SUBSCRIBE | [RFC3265] | 13 | | UPDATE | [RFC3311] | 14 | +-----------+-----------+--------------------+ Note that the response code table is not affected by this update and the procedures defined in RFC 3261 [RFC3261] section 27.4 must be followed. In addition, this document modifies the procedures for registering a new SIP method. When a new SIP Method is added to the SIP Method names registry, this document instructs IANA to assign the next whole number in sequence to the newly registered method. If multiple method names are registered at the same time, the RFC with the lowest number should be assigned its number first. If more than one method is assigned in the same document, the method name alphabetically first should be registered first. Lingle, et al. Expires August 1, 2005 [Page 87] Internet-Draft SIP MIB Modules January 2005 9.2 IANA-assigned OBJECT IDENTIFIER values for the SIP MIB modules The MIB modules defined in this document use the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: +--------------+-------------------------+ | Descriptor | OBJECT IDENTIFIER value | +--------------+-------------------------+ | sipTC | { mib-2 XXX1 } | | sipCommonMIB | { mib-2 XXX2 } | | sipUAMIB | { mib-2 XXX3 } | | sipServerMIB | { mib-2 XXX4} | +--------------+-------------------------+ -- RFC Ed:(note to be removed prior to publication): the IANA is requested to assign 4 values in the SMI Numbers registry for "XXX1", "XXX2", "XXX3", and "XXX4", all under the 'mib-2' sub-tree and to record the assignments in the SMI Numbers registry. When the assignments have been made, the RFC Editor is asked to replace "XXX1" through "XXX4" (here and in the 4 MIB modules) with the corresponding assigned value and to remove this note. 10. Security Considerations There are a number of management objects defined in the SIP-COMMON-MIB MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The following read-create object in SIP-COMMON-MIB is used to configure the status code statistics that will be monitored by the SIP entity: sipStatusCodeRowStatus: if this object is SET maliciously, it may result in an over allocation of resources in a system for the purpose of accumulating and maintaining statistics. The following read-write objects in SIP-COMMON-MIB are used to configure the behavior of certain SNMP notifications potentially generated by a SIP entity: sipStatusCodeNotifSend, sipStatusCodeNotifEmitMode, sipStatusCodeNotifThresh, sipStatusCodeNotifInterval, sipServiceNotifEnable: If these objects are SET maliciously, it may result in a system and/or network performance impact due to the generation of SNMP Lingle, et al. Expires August 1, 2005 [Page 88] Internet-Draft SIP MIB Modules January 2005 notifications. Some of the readable objects in the MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. The following object values may contain private or confidential customer information like first name, last name, customer identification, location, company affiliation, the time the information was updated, etc. sipContactDisplayName, sipContactURI, sipContactLastUpdated and sipOrganization. The sipCommonCfgTable table contains some objects that may help attackers gain knowledge about the status and operations of the SIP service. In particular, the object value of sipServiceOperStatus may indicate that the SIP entity is in congested state and may lead attackers to build additional service attacks to overload the system. The sipEntityType object indicates the type of SIP entity and the sipMethodSupportedTable table contains in the SIP-COMMON-MIB MIB module list of SIP methods supported by each entity in the system. Gaining access to this information may allow attackers to build method specific attacks or use unsupported methods to create denial of service attack scenarios. In the SIP-UA-MIB MIB module, the sipUACfgServerTable contains the address of the SIP servers providing services to the UA and obtaining this information may disclose some private or sensitive information about the SIP service usage. In the SIP-SERVER-MIB MIB module, the sipProxyAuthMethod object defines the authentication methods supported by the server and may be used to build specific denial of service attackers targeted at the security mechanisms employed by the SIP entity. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this set of MIB modules. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see RFC 3410 [RFC3410]), including full support for the SNMPv3 cryptographic mechanisms (for Lingle, et al. Expires August 1, 2005 [Page 89] Internet-Draft SIP MIB Modules January 2005 authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 11. Contributor Acknowledgments We wish to thank the members of the IETF SIP and SIPPING working groups, and the SIP-MIB Design team for their comments and suggestions. Detailed comments were provided by Tom Taylor, Kavitha Patchayappan, Dan Romascanu, Cullen Jennins, Orit Levin, AC Mahendran, Mary Barnes, Rohan Mahy, Bob Penfield, Charles Eckel and Dean Willis. 12. References 12.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2788] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC 2788, March 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, Lingle, et al. Expires August 1, 2005 [Page 90] Internet-Draft SIP MIB Modules January 2005 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002. [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 12.2 Informational References [RFC2368] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. Lingle, et al. Expires August 1, 2005 [Page 91] Internet-Draft SIP MIB Modules January 2005 Authors' Addresses Kevin Lingle Cisco Systems, Inc. 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 US Phone: +1 919 392 2029 Email: klingle@cisco.com Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 US Phone: +1 303 661 9100 Email: jfm@cablelabs.com Joon Maeng 5612 Sedona Drive Austin, TX 78759 US Phone: +1 512 418 0590 Email: jmaeng@austin.rr.com Dave Walker Email: drwalker@rogers.com Lingle, et al. Expires August 1, 2005 [Page 92] Internet-Draft SIP MIB Modules January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lingle, et al. Expires August 1, 2005 [Page 93]