-- extracted from draft-ietf-sip-mib-11.txt -- at Wed Jun 7 06:06:24 2006 SIP-TC DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; sipTC MODULE-IDENTITY LAST-UPDATED "200605171700Z" 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 note REVISION "200605171700Z" 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 over TCP bit 5 : Transport Layer Security Protocol over SCTP" SYNTAX BITS { other(0), -- none of the following udp(1), tcp(2), sctp(3), -- RFC4168 tlsTcp(4), tlsSctp(5) -- RFC 4168 } -- REFERENCE "RFC 3261, Section 18" -- REFERENCE "RFC 4168" 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" SipMethodName ::= 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." SYNTAX OCTET STRING (SIZE (1..128)) 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 currently provided by the -- Internet Society.