|
|
Table Of Contents
Release Notes for Cisco AS5400 Universal Gateways for Cisco IOS Release 12.2(2)XB15
Determining the Software Version
New Hardware and Software Features in Cisco IOS Release 12.2(2)XB6 to Cisco IOS Release 12.2(2)XB15
New Hardware Features in Cisco IOS Release 12.2(2)XB5
New Software Features in Cisco IOS Release 12.2(2)XB5
New Hardware and Software Features for Cisco IOS Release 12.2(2)XB3 to Cisco IOS Release 12.2(2)XB4
New Hardware Features in Cisco IOS Release 12.2(2)XB2
New Software Features in Cisco IOS Release 12.2(2)XB2
New Hardware and Software Features in Cisco IOS Release 12.2(2)XB1
New Hardware Features in Cisco IOS Release 12.2(2)XB
New Software Features in Cisco IOS Release 12.2(2)XB
Deprecated and Replacement MIBs
Building Integrated Timing Supply (BITS) Interface Port Clock Reference
FastEthernet Interface Configuration Issues
Caveats for Cisco IOS Release 12.2 XB
Open Caveats—Cisco IOS Release 12.2(2)XB15
Resolved Caveats—Cisco IOS Release 12.2(2)XB15
Open Caveats—Cisco IOS Release 12.2(2)XB14
Resolved Caveats—Cisco IOS Release 12.2(2)XB14
No Caveats—Cisco IOS Release 12.2(2)XB13
Open Caveats—Cisco IOS Release 12.2(2)XB12
Resolved Caveats—Cisco IOS Release 12.2(2)XB12
Open Caveats—Cisco IOS Release 12.2(2)XB11
Resolved Caveats—Cisco IOS Release 12.2(2)XB11
Open Caveats—Cisco IOS Release 12.2(2)XB10
Resolved Caveats—Cisco IOS Release 12.2(2)XB10
Open Caveats—Cisco IOS Release 12.2(2)XB9
Resolved Caveats—Cisco IOS Release 12.2(2)XB9
Open Caveats—Cisco IOS Release 12.2(2)XB8
Resolved Caveats—Cisco IOS Release 12.2(2)XB8
Open Caveats—Cisco IOS Release 12.2(2)XB7
Resolved Caveats—Cisco IOS Release 12.2(2)XB7
Open Caveats—Cisco IOS Release 12.2(2)XB6
Resolved Caveats—Cisco IOS Release 12.2(2)XB6
Open Caveats—Cisco IOS Release 12.2(2)XB5
Resolved Caveats—Cisco IOS Release 12.2(2)XB5
Open Caveats—Cisco IOS Release 12.2(2)XB4
Resolved Caveats—Cisco IOS Release 12.2(2)XB4
Open Caveats—Cisco IOS Release 12.2(2)XB3
Resolved Caveats—Cisco IOS Release 12.2(2)XB3
Open Caveats—Cisco IOS Release 12.2(2)XB2
Resolved Caveats—Cisco IOS Release 12.2(2)XB2
Open and Resolved Caveats—Cisco IOS Release 12.2(2)XB1
Open Caveats—Cisco IOS Release 12.2(2)XB
Resolved Caveats—Cisco IOS Release 12.2(2)XB
Cisco IOS Software Documentation Set
Obtaining Technical Assistance
Release Notes for Cisco AS5400 Universal Gateways for Cisco IOS Release 12.2(2)XB15
January 14, 2005
Cisco IOS Release 12.2(2)XB15
OL-1680-01 Rev. S2
Note
Cisco IOS Release 12.2(2)XB introduces the Cisco AS5400HPX universal gateways, which support a high performance motherboard. The Cisco AS5400HPX does not support images prior to Cisco IOS Release 12.2(2)XB.
These release notes for the Cisco AS5400 universal gateways describe the enhancements provided in Cisco IOS Release 12.2(2)XB15. These release notes are updated as needed.
For a list of the software caveats that apply to Cisco IOS Release 12.2(2)XB15, see the "Caveats for Cisco IOS Release 12.2 XB" section and Caveats for Cisco IOS Release 12.2. The caveats document is updated for every maintenance release and is located on Cisco.com and the Documentation CD-ROM.
Use these release notes with Cross-Platform Release Notes for Cisco IOS Release 12.2 located on Cisco.com and the Documentation CD-ROM.
Cisco recommends that you view the field notices for this release to see if your software or hardware platforms are affected. If you have an account on Cisco.com, you can find field notices at http://www.cisco.com/warp/customer/tech_tips/index/fn.html. If you do not have a Cisco.com login account, you can find field notices at http://www.cisco.com/warp/public/tech_tips/index/fn.html.
Contents
These release notes describe the following topics:
•
•
•
•
Introduction
The Cisco AS5400 Universal Gateway is a two-rack unit, 8, 12, or 16 T1/E1, 1 CT3 gateway that provides universal port data, voice, and fax services on any port at any time. The Cisco AS5400 offers high performance and high reliability in a compact, modular design. This cost-effective platform is intended for Internet service providers (ISPs) and enterprises requiring innovative universal services.
For information on new features and Cisco IOS commands supported by Cisco IOS Release 12.2(2)XB15, see the "New and Changed Information" section and the "Related Documentation" section.
System Requirements
This section describes the system requirements for Cisco IOS Release 12.2(2)XB15 and includes the following sections:
•
Memory Recommendations
Supported Hardware
Cisco IOS Release 12.2(2)XB15 supports the Cisco AS5400 and Cisco AS5400HPX universal gateways.
For detailed descriptions of the new hardware features, see the "New and Changed Information" section.
For additional information about supported hardware for this platform and release, please refer to the Hardware/Software Compatibility Matrix in the Cisco Software Advisor at the following location:
http://www.cisco.com/cgi-bin/front.x/Support/HWSWmatrix/hwswmatrix.cgi
Determining the Software Version
To determine the version of Cisco IOS software running on your Cisco AS5400 universal gateways, log in to the Cisco AS5400 universal gateways and enter the show version EXEC command:
Router> show versionCisco Internetwork Operating System SoftwareIOS (tm) 12.2 XB Software (c5400-is-mz), Version 12.2(2)XB15, RELEASE SOFTWAREFeature Set Tables
The Cisco IOS software is packaged in feature sets consisting of software images—depending on the platform. Each feature set contains a specific set of Cisco IOS features.
Cisco IOS Release 12.2(2)XB15 is based on the following releases:
•
•
•
All features in the above releases are in Cisco IOS Release 12.2(2)XB15. Their features are listed in the "Feature Set Tables" sections of the following release notes:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121relnt/5400/rn5400xm.htm•
Click Platform-Specific Information and Cisco AS5400 Universal Gateways at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/xprn122/index.htm•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/5400/rn5400xa.htm
Caution
Table 3 lists the features and feature sets supported by the Cisco AS5400 universal gateways in Cisco IOS Release 12.2(2)XB15 and uses the following conventions:
•
•
•
Note
Table 3 Feature List by Feature Set for the Cisco AS5400 Universal Gateways
IPsec 5612.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
No
Yes
No
Other
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
Quality of Service
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB2
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
12.2(2)XB
Yes
No
Yes
No
T.37 Fax and Store Forward Enhancement to the T.37/T.38 Fax Gateway Feature
12.2(2)XB2
Yes
Yes
Yes
Yes
12.2(2)XB
Yes
Yes
Yes
Yes
New and Changed Information
The following sections list the new hardware and software features supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB15.
New Hardware and Software Features in Cisco IOS Release 12.2(2)XB6 to Cisco IOS Release 12.2(2)XB15
No new hardware or software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB6 to Cisco IOS Release 12.2(2)XB15.
Note
New Hardware Features in Cisco IOS Release 12.2(2)XB5
No new hardware features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB5.
New Software Features in Cisco IOS Release 12.2(2)XB5
The following new software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB5:
EAP RADIUS Support
The EAP RADIUS Support feature allows users to apply to the client authentication methods that may not be supported by the network access server; this is done via the Extensible Authentication Protocol (EAP). Before this feature was introduced, support for various authentication methods for PPP connections required custom vendor-specific work and changes to the client and NAS.
EAP is an authentication protocol for PPP that supports multiple authentication mechanisms that are negotiated during the authentication phase (instead of the link control protocol [LCP] phase). EAP allows a third-party authentication server to interact with a PPP implementation through a generic interface.
MS CHAP Version 2
The MS CHAP Version 2 feature in Cisco IOS Release 12.2(2)XB5 introduces the ability of Cisco routers to utilize Microsoft Challenge Handshake Authentication Protocol Version 2 (MSCHAP V2) authentication for PPP connections between a computer using a Microsoft Windows operating system and a network access server (NAS). MSCHAP V2 authentication is an updated version of MSCHAP that is similar to, but incompatible with MSCHAP. MSCHAP V2 introduces mutual authentication between peers and a change password feature.
New Hardware and Software Features for Cisco IOS Release 12.2(2)XB3 to Cisco IOS Release 12.2(2)XB4
No new hardware or software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB3 to Cisco IOS Release 12.2(2)XB4.
New Hardware Features in Cisco IOS Release 12.2(2)XB2
No new hardware features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB2.
New Software Features in Cisco IOS Release 12.2(2)XB2
The following new software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB2:
Fax Relay Packet Loss Concealment
This feature improves the current real-time Fax over IP (commonly known as fax relay) implementation in Cisco gateways, allowing fax transmissions to work reliably over higher packet loss conditions. The improvement is the configuration of fax relay Error Correction Mode (ECM) on the Voice over IP (VoIP) dial peer. ECM provides for error-free page transmission and is available on fax machines that include memory for storage of the page data (usually high-end fax machines).
When ECM is disabled, the page is transmitted using high-speed modulation in its raw encoded format. When detecting line errors with ECM disabled, the receiving fax has three options (in order of severity):
•
•
•
When ECM is enabled, the page is transmitted in a series of blocks. After receiving the complete page data, the receiving fax indicates any frames with errors. The transmitting fax then retransmits these frames. This process is repeated until all frames are received without errors. If the receiving fax is unable to receive an error-free page, the fax transmission might fail and one of the fax machines disconnects. With packet loss levels greater than 2 percent, fax transmissions consistently fail between page transmissions when ECM is enabled.
Refer to the following document for further information:
T.37 Fax and Store Forward Enhancement to the T.37/T.38 Fax Gateway Feature
The T.37/T.38 Fax Gateway includes two features: T.38 Fax Relay and T.37 Fax and Store Forward. T.38 Fax Relay was released in Cisco IOS Release 12.1(5)XM for the Cisco AS5350 and Cisco AS5400. Cisco IOS Release 12.2(2)XB2 completes the T.37/T.38 Fax Gateway feature with the introduction of T.37 Fax and Store Forward.
When the Cisco universal gateway is equipped with universal port dial feature cards (DFCs), it supports carrier-class Voice over IP (VoIP) and fax over IP services. Since the Cisco universal gateway is H.323 compliant, it supports a family of industry-standard voice codecs and provides echo cancellation and Voice Activity Detection (VAD)/silence suppression. The DFCs work with existing telephone and fax equipment, and are compatible with H.323 standards for audio and video conferencing.
Fax over IP uses a proprietary T.38 and an H.323 connection. The T.37 path uses the Extended Simple Mail Transfer Protocol (ESMTP) store and forward method. The on-ramp gateway router accepts fax data from the PSTN or a fax machine connected to the analog line.
It converts the fax data into a TIFF attachment in a MIME e-mail message and transmits it to a store and forward SMTP server. These servers deliver the faxmail message to the off-ramp gateway router. Once the off-ramp gateway router receives the faxmail message, it processes the message and initiates a session with the destination fax machine.
The T.38 path will take precedence over the T.37 path whenever possible. This means that as a fax session is being set up, the sending gateway will first communicate using the T.38 path. If the communication fails, the sending gateway will rollover to the Cisco T.37 path if it is configured to rollover.
Refer to the following document for further information:
New Hardware and Software Features in Cisco IOS Release 12.2(2)XB1
No new hardware and software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB1.
New Hardware Features in Cisco IOS Release 12.2(2)XB
The following new hardware feature is supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB:
Cisco AS5400HPX
Note
Cisco IOS Release 12.2(2)XB introduces the Cisco AS5400HPX universal gateway, which supports a higher performance motherboard than the Cisco AS5400 universal gateways. The high performance motherboard has an upgraded CPU and L3 cache.
Refer to the following document for further information:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/as5400/hw_inst/mem_warn.htm
New Software Features in Cisco IOS Release 12.2(2)XB
The following new software features are supported by the Cisco AS5400 universal gateways for Cisco IOS Release 12.2(2)XB:
Call Transfer Capabilities Using Refer
Call transfer allows a wide variety of decentralized multiparty call operations. These decentralized call operations form the basis for third-party call control, and thus are important features for Voice over IP (VoIP) and SIP. Call transfer is also critical for conference calling, where calls can transition smoothly between multiple point-to-point links and IP level multicasting.
Refer to the following document for further information:
Configurable PSTN Cause Code to SIP Response Mapping
For calls to be established between a SIP network and a PSTN network, the two networks must be able to interoperate. One aspect of their interoperation is the mapping of PSTN cause codes, which indicate reasons for PSTN call failure or completion, to SIP status codes or events. The opposite is also true: SIP status codes or events are mapped to PSTN cause codes. Event mapping tables found in this document show the standard or default mappings between SIP and PSTN.
However, you may want to customize the SIP user agent software to override the default mappings between the SIP and PSTN networks. The Configurable PSTN Cause Code to SIP Response Mapping feature allows you to configure specific map settings between the PSTN and SIP networks. Thus, any SIP status code can be mapped to any PSTN cause code, or vice versa. When set, these settings can be stored in the NVRAM and are restored automatically on bootup.
Refer to the following document for further information:
DTMF Relay Using NTE
The SIP NTE DTMF relay feature is used for the following applications:
•
•
Note
Reliable DTMF Relay
The SIP NTE DTMF relay feature provides reliable digit relay between Cisco VoIP gateways when a low bandwidth codec is used. Using NTE to relay DTMF tones provides a standardized means of transporting DTMF tones in Real-Time Transport Protocol (RTP) packets according to section 3 of RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, developed by the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints.
Note
SIP Phone Support
The SIP NTE DTMF relay feature adds SIP phone support. When SIP IP phones are running software that does not have the capability to generate DTMF tones, the phones use NTE packets to indicate DTMF digits. With the SIP NTE DTMF relay feature, Cisco VoIP gateways can communicate with SIP phones that use NTE packets to indicate DTMF digits. The Cisco VoIP gateways can relay the digits to other endpoints.
Refer to the following document for further information:
Full Functionality Long Pound
This feature allows an IVR application to detect a long pound (new call request) at any point after the gateway accepts the incoming call. When the calling-party presses "long #", the gateway terminates any current or pending call state and initiates a new call setup.
For further information, refer to the TCL IVR API Version 2.0 Programmer's Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/vapp_dev/tclivrv2.htm.
ISDN and V.120 Support For NextPort DSPs
This feature provides full coverage for digital calls and performance enhancement for V.120 calls. The feature permits terminating synchronous ISDN and V.120 sessions without customer intervention. This feature allows the Cisco AS5400 series universal gateways to terminate more than 256 ISDN sessions per channelized T3 (CT3) controller by adding ISDN capacity. This feature is mandatory for wholesale dial installations where ISDN is being used. This feature permits V.120 calls to operate on the NextPort DSP instead of the CT3 controller to reduce activity on the central processing unit and to increase the V.120 call capability. Support for these enhancements is automatic, and no configuration steps are required.
MGCP 1.0 with NCS 1.0 and TGCP 1.0 Profiles
This feature implements the following protocols on the supported Cisco media gateways:
•
•
· Trunking Gateway Control Protocol (TGCP) 1.0, the PacketCable profile of MGCP 1.0 for trunking gateways (TGWs)The MGCP 1.0 specification and the NCS and TGCP profiles support new packages, endpoints, and event definitions. In addition, the specifications provide more detail regarding error recovery. In general, the latest edition of the MGCP specification provides greater feature functionality and guidelines for more reliable implementations of the protocol. MGCP 1.0 has the ability to interoperate with H.323 and SIP control agents, which allows leverage of the feature sets available in the different protocols, and provides the ability to migrate smoothly from one protocol to another.
Media Gateway Control Protocol (MGCP) 1.0 is a protocol for the control of Voice over IP (VoIP) calls by external call-control elements known as media gateway controllers (MGCs) or call agents (CAs). It is described in the informational RFC2705, published by the Internet Society. MGCP 1.0 provides flexible interoperability with a wide variety of call agents, thus enabling an extensive range of solutions.
The NCS and TGCP protocol specifications were developed through PacketCable, an industry-wide initiative to establish interoperability standards for multimedia services over cable facilities using packet technology, led by CableLabs, an industry consortium. The NCS and TGCP protocol specifications contain extensions and modifications to MGCP while preserving basic MGCP architecture and constructs. NCS 1.0 is designed for use with analog, single-line user equipment on residential gateways, while TGCP 1.0 is intended for use in VoIP-to-PSTN trunking gateways in a cable environment. TGCP and NCS allow participation in packet cable solutions, but the specifications do not preclude using them in non-cable environments.
Refer to the following document for further information:
MGCP-Based Fax (T.38) and DTMF Relay
The MGCP Based Fax (T.38) and DTMF (IETF) Relay feature adds support for fax relay and DTMF relay with MGCP. The fax relay component conforms to ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks, which determines procedures for real-time facsimile communication in various gateway control protocol (XGCP) applications. The DTMF relay component conforms to RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, developed by the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group. Per RFC 2833, DTMF is relayed using Named Telephony Events (NTEs) in Real-Time Transport Protocol (RTP) packets.
This feature provides two modes of implementation for each component: gateway (GW)-controlled mode and call agent (CA)-controlled mode. In GW-controlled mode, GWs negotiate DTMF and fax relay transmission by exchanging capability information in Session Description Protocol (SDP) messages. That transmission is transparent to the CA. GW-controlled mode allows use of the MGCP Based Fax (T.38) and DTMF (IETF) Relay feature without upgrading the CA software to support the feature.
In CA-controlled mode, CAs use MGCP messaging to instruct GWs to process fax and DTMF traffic. For MGCP T.38 Fax Relay, the CAs can also instruct GWs to revert to GW-controlled mode if the CA is unable to handle the fax control messaging traffic; for example, in overloaded or congested networks.
Refer to the following document for further information:
MGCP VoIP Call Admission Control
MGCP CAC determines if calls can be accepted on the IP network based on available network resources. Prior to this release, MGCP VoIP calls were established regardless of the available resources on the gateway or network. The gateway had no mechanism for gracefully refusing calls if resources were not available to process the call. New calls would fail with unexpected behavior and in-progress calls would experience quality-related problems.
Refer to the following document for further information:
NAS Package for MGCP
This feature adds support for the MGCP NAS package on the Cisco AS5350 and Cisco AS5400 Universal Gateways. With this implementation, data calls can be terminated on a trunking media gateway that is serving as a network access server (NAS). Trunks on the NAS are controlled and managed by a call agent supporting MGCP for both voice and data calls. The call agent must support the MGCP NAS package.
These capabilities are enabled by the universal port functionality of the Cisco AS5350 and the Cisco AS5400, which allows these platforms to operate simultaneously as network access servers and voice gateways to deliver universal services on any port at any time. These universal services include dial access, real-time voice and fax, wireless data access, and unified communications.
Refer to the following document for further information:
Particle Drivers
This feature is a collection of performance and reliability improvements for the Cisco AS5350, Cisco AS5400 and Cisco AS5400HPX universal gateways. It includes particles-based packet drivers for improved performance. These particle drivers optimize Cisco IOS fastswitching code and significantly improve the way IOS uses processor cache memory. Data packets for some protocols, such as MLPPP, IP Multicast, and cRTP, are fastswitched with particle drivers. Cisco IOS CEF switching paths are highly optimized with particle drivers.
ECC Error Correction and Dual Watchdog Timers
The feature includes ECC error correction and Dual Watchdog Timers for improved reliability.
PRI/Q.931 Signaling Backhaul for Call Agent Applications
PRI/Q.931 signaling backhaul is the ability to reliably transport the signaling (Q.931 and above layers) from a PRI trunk that is physically connected to a media gateway (for example, a Cisco AS5350 or Cisco AS5400) to a media gateway controller (Cisco VSC3000) for processing. Additionally, the Cisco VSC3000 can respond through the same interface. For the purposes of this document, the media gateway controller will be referred to as the virtual switch controller (VSC).
The backhaul takes place between a media gateway and a VSC. The gateways provide an interface between the Public Switched Telephone Network (PSTN) and the packet network world (IP or ATM). The VSC provides call processing and gateway control.
The general principle behind signaling backhaul is to reliably pass as many layers of a protocol stack as possible through a gateway directly to the VSC.
Generally, signaling backhaul would occur at a common boundary for all protocols. For ISDN, the signaling backhaul will take place at the layer 2 (Q.921) and layer 3 (Q.931) boundary. The lower layers of the protocol will be terminated and processed on the gateway, while the upper layers will be backhauled to the VSC. The upper layers of the protocol are backhauled, or transported, to the VSC using Reliable User Datagram Protocol, or RUDP over IP. RUDP provides autonomous notification of connected and failed sessions, and in-sequence, guaranteed delivery of signaling protocols across an IP network. Backhaul session manager is a software function on the VSC and gateway that manages RUDP sessions. It also groups sessions between endpoints and establishes a selection priority, and collects these groups together to form a set.
Signaling backhaul provides the additional advantage of distributed protocol processing. This permits greater expandability and scalability while offloading lower layer protocol processing from the VSC.Refer to the following document for further information:
RADIUS Packet of Disconnect
This feature consists of a method for terminating a call that has already been connected. This "Packet of Disconnect" (POD) is a RADIUS access_reject packet and is intended to be used in situations where the AAA server wants to disconnect the user after the session has been accepted by the RADIUS access_accept packet. This may be needed in at least two situations:
•
•
Refer to the following document for further information:
RFC2782 Compliance for DNS SRV
SIP on Cisco VoIP gateways uses Domain Name System Server (DNS SRV) query to determine the IP address of the user endpoint. The query string has a prefix in the form of "protocol.transport." and is attached to the fully qualified domain name (FQDN) of the next hop SIP server. This prefix style, from RFC 2052, has always been available; however, with this release, a second style is also available. The second style is in compliance with RFC 2782, and prepends the protocol label with an underscore "_"; as in "_protocol._transport.". The addition of the underscore reduces the risk of the same name being used for unrelated purposes. The form compliant with RFC 2782 is the default style.
Use the srv version command to configure the DNS SRV feature.
For further information, refer to the RFC2782 Compliance (Style of DNS SRV Queries) section at:
SIP Gateway Support for Bind Command
In previous releases of Cisco IOS software, the source address of a packet going out of the gateway was never deterministic. That is, the session protocols and VoIP layers always depended on the IP layer to give the best local address. The best local address was then used as the source address (the address showing where the SIP request came from) for signaling and media packets. Using this nondeterministic address occasionally caused confusion for firewall applications, as a firewall could not be configured with an exact address and would take action on several different source address packets.
However, the bind interface command allows you to configure the source IP address of signaling and media packets to a specific interface's IP address. Thus, the address that goes out on the packet is bound to the IP address of the interface specified with the bind command. Packets that are not destined to the bound address are discarded.
When you do not want to specify a bind address, or if the interface is down, the IP layer still provides the best local address.
Refer to the following document for further information:
SIP Gateway Support of RSVP and "tel" URL
The SIP Gateway Support of RSVP and TEL URL feature provides the following SIP enhancements:
•
•
•
•
•
•
•
RSVP
In previous Cisco IOS releases, SIP applications over IP networks functioned as best-effort services — their media packets were delivered with no performance guarantees. However, SIP Gateway Support of RSVP and TEL URL ensures quality of service (QoS) by coordinating SIP call signaling and RSVP resource management. This feature reserves sufficient network-layer resources to guarantee bandwidth and bounds on packet loss, delay, and jitter; thus ensuring that the called party's phone rings only after bandwidth required for the call has been successfully reserved.
Telephone URL Format in SIP Messages
The SIP Gateway Support of RSVP and TEL URL feature also supports Telephone Uniform Resource Locators or TEL URL. Currently SIP gateways support URLs in the SIP format. SIP URLs are used in SIP messages to indicate the originator, recipient, and destination of the SIP request. However, SIP gateways may also encounter URLs in other formats, such as TEL URLs. TEL URLs describe voice call connections. They also enable the gateway to accept TEL calls sent through the Internet, and to generate TEL URLs in the request line of outgoing INVITEs requests.
Interaction with Forking Proxies
Support for call forking enables the terminating gateway to handle multiple requests and the originating gateway to handle multiple provisional responses for the same call. Interaction with forking proxies applies to gateways acting as a user agent client (UAC), and takes place when a user is registered to several different locations. When the UAC sends an INVITE message to a proxy, the proxy forks the request and sends it to multiple user agents (UAs). The SIP gateway processes multiple 18X responses by treating them as independent transactions under the same call ID. When the relevant dial peers are configured for QoS, the gateway maintains state and initiates RSVP reservations for each of these independent transactions. When it receives an acknowledgment, such as a 200 OK, the gateway accepts the successful acknowledgment and destroys state for all other transactions.
The forking functionality sets up RSVP for each transaction only if the dial peers are configured for QoS. If not, the calls proceed as best-effort.
SIP Hairpinning
SIP hairpinning is a call routing capability in which an incoming call on a specific gateway is signaled through the IP network and back out the same gateway. This can be a public switched telephone network (PSTN) call routed into the IP network and back out to the PSTN over the same gateway. Similarly, SIP hairpinning can be a call signaled from a line (for example, a telephone line) to the IP network and back out to a line on the same access gateway. With SIP hairpinning, unique gateways for ingress and egress are no longer necessary.
Reliability of SIP Provisional Responses
SIP reliable provisional responses ensure that media information is exchanged and resource reservation can take place prior to connecting the call. Provisional acknowledgement (PRACK) and conditions met (COMET) are two methods that have been implemented.
PRACK allows reliable exchanges of SIP provisional responses between SIP endpoints. COMET indicates if the pre-conditions for a given call or session have been met.
Configurable Screening Indicator
Screening Indicator (SI) is a signaling-related information element found in octet 3a of the ISDN SETUP message that can be used as an authorization mechanism for incoming calls. Enhancements have been made to the Tool Command Language (TCL) Interactive Voice Response (IVR) 2.0 command set that allow SIP terminating gateways to assign a specific value to the screening indicator through the use of TCL scripts.
RFC2782 Compliance (Style of DNS SRV Queries)
SIP on Cisco VoIP gateways uses Domain Name System Server (DNS SRV) query to determine the IP address of the user endpoint. The query string has a prefix in the form of "protocol.transport." and is attached to the fully qualified domain name (FQDN) of the next hop SIP server. This prefix style, from RFC 2052, has always been available; however, with this release, a second style is also available. The second style is in compliance with RFC 2782, and prepends the protocol label with an underscore "_"; as in "_protocol._transport.". The addition of the underscore reduces the risk of the same name being used for unrelated purposes. The form compliant with RFC 2782 is the default style.
Refer to the following document for further information:
SIP INVITE Request with Malformed Via Header
A SIP INVITE requests that a user or service participate in a session. Each INVITE contains a Via header that indicates the transport path taken by the request so far, and where to send a response.
In the past, when an INVITE contained a malformed Via header, the gateway would print a debug message and discard the INVITE without incrementing a counter. However, the printed debug message was often inadequate, and it was difficult to detect that messages were being discarded.
The SIP INVITE Request with Malformed Via Header feature provides a response to the malformed request. A counter, Client Error: Bad Request, increments when a response is sent for a malformed Via field. Bad Request is a class 400 response and includes the explanation Malformed Via Field. The response is sent to the source IP address (the IP address where the SIP request originated) at User Datagram Protocol (UDP) port 5060.
Note
Refer to the following document for further information:
SIP T.38 Fax Relay
The SIP T.38 Fax Relay feature adds standards-based fax support to SIP and conforms to ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks. The ITU-T standard specifies real-time transmission of faxes between two regular fax terminals over an IP network.
Refer to the following document for further information:
V.44 LZJH Compression
V.44 LZJH is a new compression standard based on Lempel-Ziv that uses a new string-matching algorithm that increases upload and download speeds to make Internet access and Web browsing faster. The V.44 call success rate (CSR) is similar to V.42bis with significant compression improvement for most file types, including HTML files. V.44 applies more millions of instructions per second (MIPS) than V.42bis toward the same application data stream and yields better compression rates in almost any data stream in which V.42bis shows positive results.
V.44 supports automatic switching between compressed and transparent modes on NextPort DFC-108NP-bearing platforms. Automatic switching allows overall performance gain without loss in throughput for file streams that are not compressible.
V.44 is globally controlled through dialed number ID service (DNIS), calling line ID (CLID), and resource pool manager server (RPMS) virtual groups, and performance improvement is determined by the LZJH algorithms. The NextPort Dial Feature Card (DFC) is responsible for the ITU implementation of V.44 and the collection of statistics related to the new feature.
To support V.44 LZJH compression, the control switch module (CSM) has been modified. MIBs that show the status of V.42bis have been extended to show V.44 configuration status. New disconnect reasons help manage V.44 session status and debugging.
For further details, please see:
V.92 Modem on Hold
V.92 Modem on Hold allows a dial-in customer to suspend a modem session to answer an incoming voice call or to place an outgoing call while engaged in a modem session. When the dial-in customer uses Modem on Hold to suspend an active modem session to engage in an incoming voice call, the Internet service provider (ISP) modem listens to the original modem connection and waits for the dial-in customer's modem to resume the connection. When the voice call ends, the modem signals the telephone system to end the second call and return to the original modem connection, then the modem signals the ISP modem that it is ready to resume the modem call. Both modems renegotiate the connection, and the original exchange of data continues.
Note
For further details, please see:
V.92 Quick Connect
V.92 Quick Connect speeds up the client-to-server startup negotiation, reducing the overall connect time up to 30 percent. The client modem retains line condition information and characteristics of the connection to the Internet service provider (ISP), which reduces connect time by avoiding some of the initial signal handshaking.
For further details, please see:
MIBs
Current MIBs
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
http://tools.cisco.com/ITDIT/MIBS/servlet/index
If Cisco MIB Locator does not support the MIB information that you need, you can also obtain a list of supported MIBs and download MIBs from the Cisco MIBs page at the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
To access Cisco MIB Locator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions found at this URL:
Deprecated and Replacement MIBs
Old Cisco Management Information Bases (MIBs) will be replaced in a future release. Currently, OLD-CISCO-* MIBs are being converted into more scalable MIBs—without affecting existing Cisco IOS products or NMS applications. You can update from deprecated MIBs to the replacement MIBs as shown in Table 4.
Limitations and Restrictions
The MICA and Microcom modems are not supported on the Cisco AS5400. Both modem and voice services are supported by using the NextPort dial feature card.
Important Notes
The following sections contain important notes about Cisco IOS Release 12.2(2) XB12 that can apply to the Cisco AS5400.
Building Integrated Timing Supply (BITS) Interface Port Clock Reference
The BITS interface port requires a T1 line composite clock reference set at 1.544 MHz and an E1 line composite clock reference set at 2.048 MHz.
H.323 and SIP Coexistence
Cisco IOS Software Release 12.2(2)XB6 provides support for session initiation protocol (SIP) and H.323 coexistence on the Cisco IOS gateway. SIP and H.323 coexistence is supported for the Cisco AS5400 and Cisco AS5350 platforms. The following H.323, SIP, and other features function simultaneously on the Cisco IOS gateway.
H.323 Features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
SIP Features
•
•
•
•
•
•
•
•
•
•
Other Features
•
•
•
•
FastEthernet Interface Configuration Issues
Voice testing with the Cisco AS5400 and the FastEthernet interface requires the following configurations:
•
Field Notices and Bulletins
For general information about the types of documents listed in this section, refer to the following document:
http://www.cisco.com/warp/customer/cc/general/bulletin/software/general/1654_pp.htm
•
•
•
Caveats for Cisco IOS Release 12.2 XB
Caveats describe unexpected behavior in Cisco IOS software releases. Severity 1 caveats are the most serious caveats; severity 2 caveats are less serious. Severity 3 caveats are moderate caveats, and only select severity 3 caveats are included in the caveats document.
This section contains only open and resolved caveats for the current Cisco IOS maintenance release.
All caveats in Cisco IOS Release 12.1(5)XM, Cisco IOS Release 12.2(1), and Cisco IOS Release 12.2(2)XB are also in Cisco IOS Release 12.2(2) XB12.
For information on caveats in Cisco IOS Release 12.1(5)XM see the "Caveats" section in the Release Notes for Cisco AS5400 Universal Gateways for Cisco IOS Release 12.1 XM at http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121relnt/5400/rn5400xm.htm.
For information on caveats in Cisco IOS Release 12.2(1), see Caveats for Cisco IOS Release 12.2, which lists severity 1 and 2 caveats and select severity 3 caveats and is located on Cisco.com and the Documentation CD-ROM.
For information on caveats in Cisco IOS Release 12.2 XA at see the "Caveats" section in the Release Notes for Cisco AS5400 Universal Gateways for Cisco IOS Release 12.1 XB at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122relnt/5400/rn5400xa.htm
Note
Open Caveats—Cisco IOS Release 12.2(2)XB15
There are no open caveats specific to Cisco IOS Release 12.2(2)XB15 that require documentation in the release notes.
Resolved Caveats—Cisco IOS Release 12.2(2)XB15
All the caveats listed in this section are resolved in Cisco IOS Release 12.2(2)XB15. This section describes only severity 1 and 2 caveats and select severity 3 caveats.
Table 5 Resolved Caveats for Cisco IOS Release 12.2(2)XB15
CSCec87533
ios fw hang then crash with h323 corrupt packet
Cisco products running IOS contain vulnerabilities in the processing of H.323 messages, which are typically used in packetized voice or multimedia applications. Features such as NAT and IOS Firewall must inspect H.323 messages and may be vulnerable as well. A test suite has been developed by the University of Oulu to target this protocol and identify vulnerabilities.
Support for the H.323 protocol was introduced in Cisco IOS Software Release 11.3T, and all later Cisco IOS releases are affected if configured for various types of Voice/Multimedia Application support. The vulnerabilities can be exploited repeatedly to produce a denial of service (DoS).
There are workarounds available that may mitigate the impact, but these techniques may not be appropriate for use in all customer networks.
This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml.
Open Caveats—Cisco IOS Release 12.2(2)XB14
There are no open caveats specific to Cisco IOS Release 12.2(2)XB14 that require documentation in the release notes.
Resolved Caveats—Cisco IOS Release 12.2(2)XB14
All the caveats listed in this section are resolved in Cisco IOS Release 12.2(2)XB14. This section describes only severity 1 and 2 caveats and select severity 3 caveats.
Table 6 Resolved Caveats for Cisco IOS Release 12.2(2)XB14
CSCdx76632
as5300 crashed in MultiBitDecode
Cisco products running IOS contain vulnerabilities in the processing of H.323 messages, which are typically used in packetized voice or multimedia applications. Features such as NAT and IOS Firewall must inspect H.323 messages and may be vulnerable as well. A test suite has been developed by the University of Oulu to target this protocol and identify vulnerabilities.
Support for the H.323 protocol was introduced in Cisco IOS Software Release 11.3T, and all later Cisco IOS releases are affected if configured for various types of Voice/Multimedia Application support. The vulnerabilities can be exploited repeatedly to produce a denial of service (DoS).
There are workarounds available that may mitigate the impact, but these techniques may not be appropriate for use in all customer networks.
This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml.
CSCea19885
Bus error at address 0xD0D0D0B, Process CCH323_CT
Symptoms: A Cisco router that has a voice feature such as H.323 enabled may reload because of a bus error at address 0xD0D0D0B.
Conditions: This symptom is observed on a Cisco 3700 series but may also occur on other routers.
Workaround: There is no workaround.
CSCea27536
Router crash when H323v3/v4 pkts pass through NAT router
Cisco products running IOS contain vulnerabilities in the processing of H.323 messages, which are typically used in packetized voice or multimedia applications. Features such as NAT and IOS Firewall must inspect H.323 messages and may be vulnerable as well. A test suite has been developed by the University of Oulu to target this protocol and identify vulnerabilities.
Support for the H.323 protocol was introduced in Cisco IOS Software Release 11.3T, and all later Cisco IOS releases are affected if configured for various types of Voice/Multimedia Application support. The vulnerabilities can be exploited repeatedly to produce a denial of service (DoS).
There are workarounds available that may mitigate the impact, but these techniques may not be appropriate for use in all customer networks.
This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml.
NAT router (which is H323v2 stack aware) crashes when H323v3/v4 pkt is processed as "ip nat service h323all" is turned on.
Workaround: Turn off "ip nat service h323all" or move to 12.3T image (which has NAT-H323v3/v4) support
CSCea32240
H323 crashes in strncpy when receiving invalid setup packet
Cisco products running IOS contain vulnerabilities in the processing of H.323 messages, which are typically used in packetized voice or multimedia applications. Features such as NAT and IOS Firewall must inspect H.323 messages and may be vulnerable as well. A test suite has been developed by the University of Oulu to target this protocol and identify vulnerabilities.
Support for the H.323 protocol was introduced in Cisco IOS Software Release 11.3T, and all later Cisco IOS releases are affected if configured for various types of Voice/Multimedia Application support. The vulnerabilities can be exploited repeatedly to produce a denial of service (DoS).
There are workarounds available that may mitigate the impact, but these techniques may not be appropriate for use in all customer networks.
This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20040113-h323.shtml.
CSCea33065
H323 Spurious memory access in h450ProcRcvdApdus
Cisco products running
