RFC 4780
Management Information Base for the Session Initiation Protocol (SIP)
Pages: 83
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 15
Network Working Group K. Lingle Request for Comments: 4780 Cisco Systems, Inc. Category: Standards Track J-F. Mule CableLabs J. Maeng D. Walker April 2007 Management Information Base for the Session Initiation Protocol (SIP) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007).Abstract
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers.
Table of Contents
1. Introduction ....................................................2 2. Conventions .....................................................2 3. The Internet-Standard Management Framework ......................2 4. Overview ........................................................3 5. Structure of the SIP MIB ........................................3 5.1. Textual Conventions ........................................6 5.2. Relationship to the Network Services MIB ...................6 5.3. IMPORTed MIB Modules and REFERENCE Clauses ................10 6. Accommodating SIP Extension Methods ............................11 7. Definitions ....................................................12 7.1. SIP Textual Conventions ...................................12 7.2. SIP Common MIB Module .....................................15 7.3. SIP User Agent MIB Module .................................55 7.4. SIP Server MIB Module (Proxy, Redirect, and Registrar Servers) ........................................59 8. IANA Considerations ............................................77 9. Security Considerations ........................................78 10. Contributor Acknowledgments ...................................80 11. References ....................................................80 11.1. Normative References .....................................80 11.2. Informative References ...................................811. Introduction
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. The managed objects defined in this document are intended to provide basic SIP protocol management for SIP entities. The management of application-specific or service-specific SIP configuration is out of scope.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].3. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a set of MIB modules that are compliant to the SMIv2, which is described in STD 58, comprised of RFC 2578 [RFC2578], RFC 2579 [RFC2579], and RFC 2580 [RFC2580].4. Overview
SIP [RFC3261] is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. This MIB provides some managed objects for SIP entities defined in RFC 3261 [RFC3261] - User Agents (UA), and Proxy, Redirect, and Registrar servers. It is intended to provide management of the basic SIP entities. It provides for monitoring of status and protocol statistics, as well as for configuration of SIP entities.5. Structure of the SIP MIB
Four MIB modules are specified: SIP-COMMON-MIB, SIP-SERVER-MIB, SIP- UA-MIB, and SIP-TC-MIB. SIP-COMMON-MIB contains common MIB objects used in all the SIP entities. SIP-SERVER-MIB contains objects specific to Proxy, Redirect, and Registrar servers. SIP-UA-MIB includes objects specific to User Agents. SIP-TC-MIB defines the textual conventions used throughout the MIB modules. The MIB modules contain the following groups of objects: SIP-COMMON-MIB: Management objects common to all the SIP entities o sipCommonMIBObjects * sipCommonCfgBase: This object group defines configuration objects common to all SIP entities, including the SIP protocol version, the type of SIP entity (UA, proxy, redirect, registrar servers), the operational and administrative status, the SIP organization name, the maximum number of SIP transactions an entity can manage, etc. * sipCommonCfgTimer: This object group defines timer configuration objects applicable to SIP user agent and stateful SIP proxy entities.
* sipCommonSummaryStats: This object group defines a table
containing the summary statistics objects applicable to all SIP
entities, including the total number of all SIP requests and
responses in/out and the total number of transactions.
* sipCommonMethodStats: This object group defines a table
containing the SIP method statistics objects applicable to all
SIP entities, including the number of outbound and inbound
requests on a per method basis. Retransmissions, where
appropriate, are also included in these statistics.
* sipCommonStatusCode: This object group defines a table
indicating the number of SIP responses (in and out) that the
SIP entity has been requested to monitor on a per-method basis
(100, 200, 302, etc.).
* sipCommonStatsTrans: This object group defines a table
containing a gauge reflecting the number of transactions
currently awaiting definitive responses by the managed SIP
entity.
* sipCommonStatsRetry: This object group defines statistic
objects indicating the number of retransmissions sent on a
per-method basis.
* sipCommonOtherStats: This object group defines additional
statistics objects including the number of SIP requests
received with unsupported URIs, the number of requests received
with unsupported SIP methods, and the number of discarded
messages.
* sipCommonNotifObjects: This object group defines objects
accessible only via a notification (MAX ACCESS clause of
accessible-for-notify): they are related to the SNMP
notifications defined in this MIB module.
The SIP-COMMON-MIB also contains notifications, including:
o sipCommonStatusCodeNotif: indicates that a specific status code
has been sent or received by the system.
o sipCommonStatusCodeThreshExceededNotif: indicates that a specific
status code has been sent or received by the system frequently
enough to exceed the configured threshold.
SIP-SERVER-MIB: Groups of objects for SIP Proxy, Redirect, and
Registrar servers
o sipServerMIBObjects
* sipServerCfg: This object group defines common server
configuration objects including the SIP server host address.
* sipServerProxyCfg: This object group defines configuration
objects for SIP Proxy Servers including the proxy mode of
operation (stateless, stateful, call stateful), the proxy
authentication method(s), realm, etc.
* sipServerProxyStats: This object group defines a table
containing the statistics objects applicable to SIP Proxy
Servers. It includes the number of occurrences of unsupported
options being specified in received Proxy-Require headers.
* sipServerRegCfg: This object group defines common configuration
objects for SIP Registrar servers, including the ability to
accept third-party registrations, such as the maximum
registration expiry that may be requested by user agents, the
maximum number of users the registrar can support, the number
of currently registered users, per contact registration
information, etc.
* sipServerRegStats: This object group contains summary
statistics objects for SIP Registrar servers. Precisely, it
contains the number of REGISTER requests that have been
accepted or rejected.
SIP-UA-MIB: Group of objects for SIP User Agents
o sipUAMIBObjects
* sipUACfgServer: This object group specifies SIP server
configuration objects applicable to SIP user agents including
the Internet address of the SIP Server the UA uses to register,
proxy, or redirect calls.
To conform with this specification, an SNMP agent MUST implement the
SIP-TC-MIB module, plus the SIP-COMMON-MIB module and one of the SIP
entity-type-specific MIB modules (SIP-SERVER-MIB or SIP-UA-MIB) as
applicable for each instance of a SIP entity being managed. If a
device has more than one SIP entity or multiple instances of the same
entity type, it MUST implement multiple SIP modules. Section 5.2
describes handling of multiple instances in detail.
5.1. Textual Conventions
The data types SipTCTransportProtocol, SipTCEntityRole, SipTCOptionTagHeaders, and SipTCMethodName are defined in the SIP- TC-MIB module and used as Textual Conventions in this document.5.2. Relationship to the Network Services MIB
In the design of the SIP MIB, the authors considered the following requirement: the SIP MIB must allow a single system with a single SNMP agent to support multiple instances of various SIP MIB modules. This requirement is met by using the framework provided by the Network Services Monitoring MIB, NETWORK-SERVICES-MIB, RFC 2788 [RFC2788]. A device implementing the SIP MIB MUST support the NETWORK-SERVICES- MIB and, at a minimum, MUST support the index and name objects (applIndex and applName) in the application table (applTable). In order to allow each instance of a SIP entity to be managed as a separate network service application, a naming convention SHOULD be used to make the application name unique. For example, if a system is running 2 SIP UAs that need to be managed as 2 separate SIP entities, by convention, the application names used in the Network Services Monitoring MIB application table should be "sip_ua1" and "sip_ua2". This convention allows each instance to have its own row in the application table (applTable). It is therefore RECOMMENDED that the following application name conventions be adopted: o for a SIP Proxy entity, the applName value SHOULD be equal to a character string starting with "sip_proxy" followed by a unique application instance identifier, for example, "sip_proxy1", "sip_proxy17". o for a SIP Registrar entity, the applName value SHOULD be equal to a character string starting with "sip_registrar" followed by a unique application instance identifier, for example, "sip_registrar1", "sip_registrar2". o for a SIP User Agent entity, the applName value SHOULD be equal to a character string starting with "sip_ua" followed by a unique application instance identifier, for example, "sip_ua1", "sip_ua2".
o for any combination of Proxy, Registrar, or Redirect Server being
managed as a single aggregate entity, the applName value for the
combined server entity SHOULD reflect the appropriate combination
followed by a unique application instance identifier. In order to
facilitate consistent agent behavior and management application
expectations, the following order of names is RECOMMENDED:
* if Proxy exists, list first.
* if Proxy and Redirect exists, list Redirect second.
* if Registrar exists, always list last.
For example "sip_proxy1", "sip_proxy_registrar1",
"sip_proxy_redirect5", "sip_proxy_redirect_registrar2", or
"sip_registrar1".
o Note: the value of the network service application index
(applIndex) may be different from the instance identifier used in
the system (the applIndex is dynamically created and is the value
assigned by the SNMP agent at the creation of the table entry,
whereas the value of the instance identifier to be used in the
application name is provided as part of the application name
applName by the system administrator or configuration files of the
SIP entity). This note is illustrated in the first example
provided below.
Finally, the SNMP agent MAY support any combination of the other
attributes in applTable. If supported, the following objects SHOULD
have values populated as follows:
o applVersion: version of the SIP application.
o applUptime: the value of applUptime MUST be identical to the value
of sipCommonCfgServiceStartTime defined in the SIP-COMMON-MIB
module.
o applOperStatus: the value of applOperStatus SHOULD reflect the
operational status of sipCommonCfgServiceOperStatus, at least by
means of a mapping.
o applLastChange: the value of applLastChange MUST be identical to
the value of sipCommonCfgServiceLastChange defined in the SIP-
COMMON module.
A number of other objects are defined as part of the applTable. They
are not included for the sake of brevity and due to the fact that
they do not enhance the concept being presented.
Example 1:
The tables below illustrate how a system acting as both Proxy and
Registrar server might be configured to maintain separate SIP-
COMMON-MIB instances.
The NETWORK-SERVICES-MIB applTable might be populated as follows:
+-----------+-------------------+----------------------+
| applIndex | applName | applDescription |
+-----------+-------------------+----------------------+
| 1 | "sip_proxy10" | "ACME SIP Proxy" |
| 2 | "sip_registrar17" | "ACME SIP Registrar" |
+-----------+-------------------+----------------------+
The SIP-COMMON-MIB sipCommonCfgTable would have two rows: one for the
proxy (applIndex=1) and one for the registrar (applIndex=2). The
SIP-SERVER-MIB tables would, however, only be populated with one row
indexed by applIndex=1 and applIndex=2, respectively, if the server
provides either proxy or registrar.
The SIP-COMMON-MIB sipCommonCfgTable might be populated as:
+---------+------------------------+--------------------------+-----+
|applIndex| sipCommonCfgProtocol | sipCommonCfgServiceOper | ... |
| | Version | Status | |
+---------+------------------------+--------------------------+-----+
| 1 | "SIP/2.0" | up(1) | |
| 2 | "SIP/2.0" | restarting(4) | |
+---------+------------------------+--------------------------+-----+
while the sipServerProxyCfgTable in SIP-SERVER-MIB might be populated
as:
+-----------+-------------------------------+-----+
| applIndex | sipServerCfgProxyStatefulness | ... |
+-----------+-------------------------------+-----+
| 1 | stateless(1) | |
+-----------+-------------------------------+-----+
and the sipServerRegUserTable in SIP-SERVER-MIB might be populated
as:
+-----------+-----------------------+---------------------+-----+
| applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
+-----------+-----------------------+---------------------+-----+
| 2 | 1 | bob@example.com | |
| 2 | 2 | alice@example.com | |
| 2 | 3 | jim@example.com | |
| 2 | 4 | john@example.com | |
+-----------+-----------------------+---------------------+-----+
Example 2:
This example illustrates how to represent a system acting as both
Proxy and Registrar server, where the two entities share a single
instance of SIP-COMMON-MIB.
The NETWORK-SERVICES-MIB applTable might be populated as follows:
+-----------+------------------------+------------------------------+
| applIndex | applName | applDescription |
+-----------+------------------------+------------------------------+
| 1 | "sip_proxy_registrar1" | "ACME SIP Proxy and |
| | | Registrar" |
+-----------+------------------------+------------------------------+
The SIP-COMMON-MIB sipCommonCfgTable would have only one row to cover
both the proxy and the registrar.
The SIP-COMMON-MIB sipCommonCfgTable might be populated as:
+----------+---------------------------+-----------------------------+
|applIndex |sipCommonCfgProtocolVersion|sipCommonCfgServiceOperStatus|
+----------+---------------------------+-----------------------------+
| 1 | "SIP/2.0" | up(1) |
+----------+---------------------------+-----------------------------+
while the sipServerRegUserTable in SIP-SERVER-MIB might be populated
as:
+-----------+-----------------------+---------------------+-----+
| applIndex | sipServerRegUserIndex | sipServerRegUserUri | ... |
+-----------+-----------------------+---------------------+-----+
| 2 | 1 | bob@example.com | |
| 2 | 2 | alice@example.com | |
| 2 | 3 | kevin@example.com | |
| 2 | 4 | jf@example.com | |
+-----------+-----------------------+---------------------+-----+
The NETWORK-SERVICES-MIB assocTable is not considered a requirement
for SIP systems. It is not a mandatory group for compliance with the
NETWORK-SERVICES-MIB module.
The relationship between the value of applOperStatus and
sipCommonCfgServiceOperStatus is as follows:
+-------------------------------+---------------+-------------------+
| sipCommonCfgServiceOperStatus | -- | applOperStatus |
| | corresponds | |
| | to --> | |
+-------------------------------+---------------+-------------------+
| up | --> | up |
| down | --> | down |
| congested | --> | congested |
| restarting | --> | restarting |
| quiescing | --> | quiescing |
| testing | --> | up |
| unknown | --> | --indeterminate-- |
+-------------------------------+---------------+-------------------+
If the sipOperStatus is 'unknown', there is no corresponding value of
applOperStatus. Therefore, the last known value of applOperStatus
SHOULD be maintained until the sipOperStatus transitions to a value
that can be mapped appropriately.
5.3. IMPORTed MIB Modules and REFERENCE Clauses
The SIP MIB modules defined in this document IMPORT definitions
normatively from the following MIB modules, beyond [RFC2578],
[RFC2579], and [RFC2580]: INET-ADDRESS-MIB [RFC4001], NETWORK-
SERVICES-MIB [RFC2788], SNMP-FRAMEWORK-MIB [RFC3411].
This MIB module also includes REFERENCE clauses that normatively
refer to SIP [RFC3261] and INET-ADDRESS-MIB [RFC4001].
Finally, this MIB module makes informative references to several RFCs in some of the examples described in the DESCRIPTION clauses, including Reliability of Provisional Responses in SIP [RFC3262] and SIP over SCTP [RFC4168].6. Accommodating SIP Extension Methods
The core set of SIP methods is defined in RFC 3261 [RFC3261]. Other IETF RFCs define additional methods. In the future, additional methods may be defined. In order to avoid having to update the SIP- COMMON-MIB module to accommodate these extension methods, we use a method identifier name (SipTCMethodName TEXTUAL-CONVENTION) to represent all SIP methods registered with IANA. For example, the sipCommonMethodSupportedTable is the main table for listing all of the SIP methods supported by a system, including the SIP methods defined in RFC 3261 [RFC3261] and other SIP methods registered with IANA. The table is informational in nature and populated by the system. Entries cannot be added or deleted by an SNMP manager. The SIP specification (RFC 3261 [RFC3261], Section 27.4) establishes the sub-registries for SIP Methods and Response Codes under http://www.iana.org/assignments/sip-parameters. This document uses the existing sub-registry for the names of registered SIP methods. For example, in the sipCommonMethodSupportedTable of SIP-COMMON-MIB, the sipCommonMethodSupportedName values can be represented as follows: +------------------------------+ | sipCommonMethodSupportedName | +------------------------------+ | "ACK" | | "BYE" | | "CANCEL" | | "INVITE" | | "OPTIONS" | +------------------------------+
7. Definitions
7.1. SIP Textual Conventions
SIP-TC-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI -- RFC 2578 TEXTUAL-CONVENTION FROM SNMPv2-TC; -- RFC 2579 sipTC MODULE-IDENTITY LAST-UPDATED "200704200000Z" ORGANIZATION "IETF Session Initiation Protocol Working Group" CONTACT-INFO "SIP WG email: sip@ietf.org Co-editor Kevin Lingle Cisco Systems, Inc. postal: 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park, NC 27709 USA email: klingle@cisco.com phone: +1 919 476 2029 Co-editor Joon Maeng email: jmaeng@austin.rr.com Co-editor Jean-Francois Mule CableLabs postal: 858 Coal Creek Circle Louisville, CO 80027 USA email: jf.mule@cablelabs.com phone: +1 303 661 9100 Co-editor Dave Walker email: drwalker@rogers.com" DESCRIPTION "Session Initiation Protocol (SIP) MIB TEXTUAL-CONVENTION module used by other SIP-related MIB Modules. Copyright (C) The IETF Trust (2007). This version of this MIB module is part of RFC 4780; see the RFC itself for
full legal notices."
REVISION "200704200000Z"
DESCRIPTION
"Initial version of the IETF SIP-TC-MIB module. This version
published as part of RFC 4780."
::= { mib-2 148 }
--
-- Textual Conventions
--
SipTCTransportProtocol ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention is a bit map. Each bit represents a transport
protocol. If a bit has value 1, then that selected transport
protocol is in some way dependent on the context of the object
using this convention. If a bit has value 0, then that
transport protocol is not selected. Combinations of bits can
be set when multiple transport protocols are selected.
bit 0: a protocol other than those defined here
bit 1: User Datagram Protocol
bit 2: Transmission Control Protocol
bit 3: Stream Control Transmission Protocol
bit 4: Transport Layer Security Protocol over TCP
bit 5: Transport Layer Security Protocol over SCTP
"
REFERENCE "RFC 3261, Section 18 and RFC 4168"
SYNTAX BITS {
other(0), -- none of the following
udp(1),
tcp(2),
sctp(3), -- RFC4168
tlsTcp(4),
tlsSctp(5) -- RFC 4168
}
SipTCEntityRole ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention defines the role of a SIP entity. Examples of
SIP entities are proxies, user agents, redirect servers,
registrars, or combinations of the above.
User Agent (UA): A logical entity that can act as both a user
agent client and user agent server.
User Agent Client (UAC): A logical entity that creates a new
request, and then uses the client transaction state machinery
to send it. The role of UAC lasts only for the duration of
that transaction. In other words, if a piece of software
initiates a request, it acts as a UAC for the duration of that
transaction. If it receives a request later, it assumes the
role of a user agent server for the processing of that
transaction.
User Agent Server (UAS): A logical entity that generates a
response to a SIP request. The response accepts, rejects,
or redirects the request. This role lasts only for the
duration of that transaction. In other words, if a piece of
software responds to a request, it acts as a UAS for the
duration of that transaction. If it generates a request
later, it assumes the role of a user agent client for the
processing of that transaction.
Proxy, Proxy Server: An intermediary entity that acts as both
a server and a client for the purpose of making requests on
behalf of other clients. A proxy server primarily plays the
role of routing, which means its job is to ensure that a
request is sent to another entity 'closer' to the targeted
user. Proxies are also useful for enforcing policy. A proxy
interprets and, if necessary, rewrites specific parts of a
request message before forwarding it.
Redirect Server: A redirect server is a user agent server that
generates 3xx responses to requests it receives, directing the
client to contact an alternate set of URIs.
Registrar: A registrar is a server that accepts REGISTER
requests and places the information it receives in those
requests into the location service for the domain it handles."
REFERENCE
"RFC 3261, Section 6"
SYNTAX BITS {
other(0),
userAgent(1),
proxyServer(2),
redirectServer(3),
registrarServer(4)
}
SipTCOptionTagHeaders ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This convention defines the header fields that use the option
tags per Section 19.2 of RFC 3261. These tags are used in
Require (Section 20.32), Proxy-Require (Section 20.29),
Supported (Section 20.37), and Unsupported (Section 20.40)
header fields."
REFERENCE
"RFC 3261, Sections 19.2, 20.32, 20.29, 20.37, and 20.40"
SYNTAX BITS {
require(0), -- Require header
proxyRequire(1), -- Proxy-Require header
supported(2), -- Supported header
unsupported(3) -- Unsupported header
}
SipTCMethodName ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TEXTUAL-CONVENTION is a string that uniquely identifies a
SIP method. The scope of uniqueness is the context of all
defined SIP methods.
Experimental support of extension methods is acceptable and
expected. Extension methods are those defined in
Internet-Draft documents but not yet allocated and
officially sanctioned by IANA.
To support experimental extension methods, any object using
this TEXTUAL-CONVENTION as syntax MAY return/accept a method
identifier value other than those sanctioned by IANA. That
system MUST ensure no collisions with officially assigned
method names."
REFERENCE
"RFC 3261, Section 27.4"
SYNTAX OCTET STRING (SIZE (1..100))
END
(page 15 continued on part 2)