CISCO-SIP-CALLS-MIB

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..255) · OCTET STRING · hint 255t

This object represents the protocol specific unique identifier for this call.

INTEGER1 = uac2 = uas · Integer32

This object denotes whether the call is a UAC or a UAS one. 'uac' - User Agent Client 'uas' - User Agent Server.

CSipCallState1 = none2 = idle3 = setupBuffered4 = sentInvite5 = rcvdProceeding6 = outgoingResrResv7 = outgoingResrAllocated8 = active9 = rcvdTransfer10 = disconnecting11 = dead12 = rcvdInvite13 = sentQosProgress14 = incomingResrResv15 = sentAlerting16 = sentSuccess17 = midCallLocalRespPending18 = sendMidCallInvitePending19 = sentMidCallInvite20 = rcvdSubscribe21 = subscribeSuccess22 = subscribeExpired23 = sentPreAuthRequest24 = sendNotify25 = subscribeIdle26 = sentSubscribe27 = subscribed28 = initTransfer29 = outgoingRegister30 = incomingRegister31 = rcvdUnsolicitedNotifyA textual convention containing the list of call states a SIP call undergoes. The list of call states and their descriptions are given below : 'none' - None of the following. 'idle' - SIP communication has not been initiated. 'setupBuffered' - A setup indication has been received from the application, but it has been buffered. The INVITE will be sent at a later time. 'sentInvite' - A SIP INVITE request has been sent and no response has been received. 'rcvdProceeding' - A non-final response (1xx) has been received in response to an INVITE request. 'outgoingResrResv' - A PRACK has been sent after receiving a 183 and QoS resource reservation has been initiated. 'outgoingResrAllocated' - QoS reservations have completed and an UPDATE has been sent. 'active' - A 2xx (Success) response has been received for an INVITE message and the call is now active. 'rcvdTransfer' - A SIP REFER request was received for an active call. 'disconnecting' - A SIP BYE or CANCEL request has been sent and no response has been received. 'dead' - The call has been cleared in normal or abnormal fashion. 'rcvdInvite' - A SIP INVITE request has been received for an incoming SIP call. 'sentQosProgress' - An INVITE with QoS precondition has been received. A 183 Session Progress response has been sent in response. 'incomingResrResv' - A 200 (OK) for a PRACK has been sent out and QoS resource reservation has been initiated. 'sentAlerting' - A SIP 180 (Ringing) response has been sent. 'sentSuccess' - A SIP 2xx response has been sent. 'midCallLocalRespPending' - A SIP mid-call INVITE was received and the response has not been sent yet. 'sendMidCallInvitePending' - A SIP call is active and a mid-call INVITE needs to be sent. 'sentMidCallInvite' - A SIP mid-call INVITE has been sent. 'rcvdSubscribe' - A SIP SUBSCRIBE request was received. 'subscribeSuccess' - A response for the SUBSCRIBE request was received. 'subscribeExpired' - The SUBSCRIBE request for a particular event has expired. 'sentPreAuthRequest' - A SIP INVITE was received and a preauthorization request has been sent. 'sendNotify' - A NOTIFY message for an event earlier subscribed was sent. 'subscribeIdle' - This state is the initialization state for SUBSCRIBE/NOTIFY messages. 'sentSubscribe' - A SIP SUBSCRIBE request has been sent. 'subscribed' - The user agent has been subscribed with the messaging system. 'initTransfer' - A SIP REFER request was received and the call was placed on hold in preparation for the transfer. 'outgoingRegister' - A SIP REGISTER message has been sent. 'incomingRegister' - A SIP REGISTER message has been received. 'rcvdUnsolicitedNotify' - A Cisco-proprietary unsolicited NOTIFY message was received. · Integer32

This object reflects the current state of the call.

CSipCallSubstate1 = none2 = sentDns3 = proceedingProceeding4 = rcvdInviteCallSetup5 = rcvdInviteProceeding6 = sentEnum7 = ackPending8 = sentNotify9 = callTransferSendByeAlsoA textual convention containing the list of call substates a SIP call undergoes. The list of substates and their descriptions are given below: 'none' - None of the following. 'sentDns' - A DNS request has been sent to the DNS server. 'proceedingProceeding' - A non-final 1xx response was received, while in rcvdProceeding state. 'rcvdInviteCallSetup' - A SIP INVITE has been received and the call is being set up. 'rcvdInviteProceeding' - A 100 (Trying) response was received for a INVITE request. 'sentEnum' - An ENUM query is in progress. 'ackPending' - An acknowledgement pending for any message sent. 'sentNotify' - A NOTIFY message for any subscribed event was sent. 'callTransferSendByeAlso' - A BYE request was sent with an 'Also' header. · Integer32

This object reflects the current substate of the call.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..64) · OCTET STRING · hint 255t

Indicates the calling number.

SnmpAdminStringAn octet string containing administrative information, preferably in human-readable form. To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in [RFC2279]. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC3416]. Note that the size of an SnmpAdminString object is measured in octets, not characters. SIZE (0..64) · OCTET STRING · hint 255t

Indicates the called Number.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the signaling source IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the signaling source IP address. Its value should be interpreted within the context of the associated cSipCallActiveSigSrcIpAddrType object.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the signaling destination request IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the signaling destination request IP address. Its value should be interpreted within the context of the associated cSipCallActiveDestReqIpAddrType object.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

This object reflects the signaling destination request port number.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the signaling destination response IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the signaling destination response IP address. Its value should be interpreted within the context of the associated cSipCallActiveDestResIpAddrType object.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

This object reflects the signaling destination response port number.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the signaling destination IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the signaling destination IP address. It may be either a DNS hostname or an IP address. Its value should be interpreted within the context of the associated cSipCallActiveDestIpAddrType object.

Unsigned32

If the call is a media-forked one, this object reflects the number of media streams.

Unsigned32

If the call is a media-forked one, this object reflects the number of media streams currently active.

Unsigned32

The unique media stream identifier for a single call.

INTEGER1 = invalidStreamState2 = idle3 = adding4 = deleting5 = changing6 = active7 = dead · Integer32

The current state of the media stream. 'invalidStreamState' - None of the following. 'idle' - Initialization state. The stream is yet to be forked. 'adding' - The stream is getting forked. 'deleting' - The stream is being deleted from the call. 'changing' - The stream is in the process of changing its state. 'active' - The stream is now active and communication is on. 'dead' - The stream has been cleared.

Integer32 (-1..2147483647)

This object represents the stream call identifier indicated by the media stream header. A value of -1 indicates that the stream is in DEAD state.

INTEGER1 = voiceOnly2 = dtmfRelay3 = voiceAndDtmfRelay · Integer32

This object identifies the type of the Media Stream. 'voiceOnly' - Voice-only media streams send all audio from the DS0 channel. 'dtmfRelay' - Dual Tone Multi Frequency Tones. 'voiceAndDtmfRelay' - Send both encoded voice and DTMF-relay packets.

CvcCoderTypeRate1 = other2 = fax24003 = fax48004 = fax72005 = fax96006 = fax144007 = fax1200010 = g729r800011 = g729Ar800012 = g726r1600013 = g726r2400014 = g726r3200015 = g711ulawr6400016 = g711Alawr6400017 = g728r1600018 = g723r630019 = g723r530020 = gsmr1320021 = g729Br800022 = g729ABr800023 = g723Ar630024 = g723Ar530025 = ietfg729r800026 = gsmeEr1220027 = clearChannel28 = g726r4000029 = llcc30 = gsmAmrNb31 = g72232 = iLBC33 = iLBCr1520034 = iLBCr1333035 = g722r480036 = g722r560037 = g722r640038 = iSAC39 = aaclc40 = aacldRepresents the coder type-rate for voice/fax compression used during a call. *** ABBREVIATIONS, ACRONYMS AND SYMBOLS *** GSM - Global System for Mobile Communication AMR-NB - Adaptive Multi Rate - Narrow Band iLBC - internet Low Bitrate Codec iSAC - internet Speech Audio Codec other - none of the following. fax2400 - FAX 2400 bps fax4800 - FAX 4800 bps fax7200 - FAX 7200 bps fax9600 - FAX 9600 bps fax14400 - FAX 14400 bps fax12000 - FAX 12000 bps g729r8000 - G.729 8000 bps (pre-IETF bit ordering) g729Ar8000 - G.729 ANNEX-A 8000 bps g726r16000 - G.726 16000 bps g726r24000 - G.726 24000 bps g726r32000 - G.726 32000 bps g711ulawr64000 - G.711 u-Law 64000 bps g711Alawr64000 - G.711 A-Law 64000 bps g728r16000 - G.728 16000 bps g723r6300 - G.723.1 6300 bps g723r5300 - G.723.1 5300 bps gsmr13200 - GSM full rate 13200 bps g729Br8000 - G.729 ANNEX-B 8000 bps g729ABr8000 - G.729 ANNEX-A & B 8000 bps g723Ar6300 - G723.1 Annex A 6300 bps g723Ar5300 - G723.1 Annex A 5300 bps ietfg729r8000 - G.729 8000 bps (IETF bit ordering) gsmeEr12200 - GSM Enhanced Full Rate 12200 bps clearChannel - CLEAR channel codec g726r40000 - G.726 40000 bps llcc - Lossless compression codec gsmAmrNb - GSM AMR-NB 4750 - 12200 bps g722 - G.722 2400 - 6400 bps iLBC - iILBC 13330 or 15200 bps iLBCr15200 - iLBC 15200 bps iLBCr13330 - iLBC 13330 bps g722r4800 - G.722 (modes 1, 2, 3) g722r5600 - G.722 (modes 1, 2) g722r6400 - G.722 (mode 1) iSAC - iSAC (10 to 32 kbps) aaclc - AAC-LC Advanced Audio Coding Low Complexity aacld - AAC-LD MPEG-4 Low Delay Audio CoderReference: [1] RFC 3267: For introduction about GSM AMR-NB codec, section 3.1 [2] RFC 3952: For introduction about iLBC codec, section 2 · Integer32

This object reflects the codec selected for the media stream.

Integer32 (-1..127)

The RTP payload type of the media stream. RTP payload specifies the data transported by RTP in a packet, for example audio samples or compressed video data. A value of -1 means that no codec has been negotiated. RFC 3551 specifies the payload type number to be used with different codecs. The following are some of the standard payload types applicable to SIP calls : PT Encoding Name 0 PCMU(G711ulaw) 3 GSM 4 G723 8 PCMA(G711alaw) 9 G722 15 G728 18 G729 96--127 dynamic For other codecs, dynamic payload types in the range 96--127 are negotiated during call setup. Also note that Cisco has preassigned certain payload types in this dynamic range for certain encodings: PT Function 96 fax 97 fax-ack 100 NSE 101 NTE 121 DTMF-relay 122 Fax-relay 123 CAS 125 ClearChan ⓘ

INTEGER1 = inBandVoice2 = rtpNte · Integer32

This object reflects the DTMF-relay selected for the media stream indicated by the media stream header. 'inBandVoice' - DTMF digits are sent as in-band audio. 'rtpNte' - RTP Named Telephony Event. RTP-NTE is described in RFC 2833.

Integer32 (-1..127)

The RTP payload type of the negotiated DTMF-relay. RTP payload specifies the data transported by RTP in a packet, for example audio samples or compressed video data. A value of -1 means that no codec has been negotiated. RFC 3551 specifies the payload type number to be used with different codecs. The following are some of the standard payload types applicable to SIP calls : PT Encoding Name 0 PCMU(G711ulaw) 3 GSM 4 G723 8 PCMA(G711alaw) 9 G722 15 G728 18 G729 96--127 dynamic For other codecs, dynamic payload types in the range 96--127 are negotiated during call setup. Also note that Cisco has preassigned certain payload types in this dynamic range for certain encodings: PT Function 96 fax 97 fax-ack 100 NSE 101 NTE 121 DTMF-relay 122 Fax-relay 123 CAS 125 ClearChan ⓘ

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the media stream source IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the source IP address of the media stream. Its value should be interpreted within the context of the associated cSipMediaStreamSrcIpAddrType object.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

This object reflects the UDP port of the media stream source.

InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 textual convention. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 textual convention. ipv4z(3) A non-global IPv4 address including a zone index as defined by the InetAddressIPv4z textual convention. ipv6z(4) A non-global IPv6 address including a zone index as defined by the InetAddressIPv6z textual convention. dns(16) A DNS domain name as defined by the InetAddressDNS textual convention. Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType. To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation. Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32

Internet type of the media stream destination IP address.

InetAddressDenotes a generic Internet address. An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row. The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error. When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING

This object reflects the destination IP address of the media stream. Its value should be interpreted within the context of the associated cSipMediaStreamDestIpAddrType object.

InetPortNumberRepresents a 16 bit port number of an Internet transport layer protocol. Port numbers are assigned by IANA. A current list of all assignments is available from <http://www.iana.org/>. The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where a port number is unknown, or when the value zero is used as a wildcard in a filter.Reference: STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960 (0..65535) · Unsigned32 · hint d

This object reflects the UDP port of the media stream destination.