-- extracted from draft-ietf-sip-mib-12.txt -- at Tue Sep 19 06:07:02 2006 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 "200609121700Z" 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 9100 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 (2006). 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 not REVISION "200609121700Z" DESCRIPTION "Initial version of the IETF SIP-TC-MIB 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 -- 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 an official 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 -- -- Copyright (C) The Internet Society (2006). -- -- 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. -- -- 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. -- -- -- Intellectual Property -- -- 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. -- -- -- Acknowledgment -- -- Funding for the RFC Editor function is provided by the IETF -- Administrative Support Activity (IASA).