A H.323 Support and Compliance

Purpose

This Appendix briefly describes the H.323 Version 2 support and compliance including:

• Offer Overview

• H.323 Version 2 Compliance

• H.323 offer in relation to IMTC Testing and iNOW! Profile criteria.

• Restrictions and Limitations

• Supported Standards MIBs and RFCs

• Related Documents

H.323 Offer Overview

The CSP H.323 implementation enhances the CSP software to comply with the mandatory requirements of the H.323 Version 2 specification. This feature enhances the existing Voice over IP offering of the VDAC-ONE card for RTP bearer channels.

General Information

• Conforms to the H.323 ITU Protocol Version 2

• H.225 Call Signaling Protocol

• H.245 Control Protocol

• Registration, Admission & Status (RAS)

• Real-time Transport Protocol/Real-time Transport Control Protocol (RTP/RTCP)

• Q.931

• Gateway functionality only: Not a Gatekeeper Implementation

• Supports Fast Connect

• Supports H.323-to-SIP Interworking

• Provides well defined EXS API messages for ease of development

• Interoperability

• Backward compatible with the ITU H.323 Version 1 Protocol

• Interoperates with leading PC Clients

• Interoperates leading VoIP Gateways at the RTP level.

Media Processing Features Supported

• G.711 CODEC (A-law and µ-law) - 64 Kbps

• G.729/G.729A/B CODEC - 8 Kbps

• G.723.1 CODEC - 5.3 Kbps and 6.3 Kbps

• Voice Activity Detection (VAD)

• Comfort Noise Generation (CNG)

• Jitter Buffer Management

• Echo Cancellation

• DTMF generation/detection: Supported by the DSP
Card. (G.711 CODEC only)

H.323 Version 2 Compliance

The CSP H.323 implementation enables the CSP to send and receive all the REQUIRED or mandatory fields in the H.323 Version 2 messages.

Lightweight Registration

The CSP H.323 implementation enhances the CSP software to comply with the mandatory requirements of the H.323 Version 2 specification. This includes the Lightweight Registration Feature. H.323 Version 2 defines a lightweight registration procedure that still requires the full registration, but uses an abbreviated renewal procedure to update the gatekeeper and subsequently reduces overhead.

Lightweight registration requires each endpoint to specify a Time-to-Live (TTL) value in its Registration Request (RRQ) message. When a gatekeeper receives an RRQ message from the CSP with a TTL value, it returns an updated TTL timer value in a Registration Confirmation (RCF) message to the endpoint. Prior to the TTL timer expiring, the endpoint sends an RRQ message with the KeepAlive field set to "Yes", which refreshes the existing registration.

An H.323 Version 2 endpoint is not required to indicate a time-to-live in its registration request. If the endpoint does not indicate a time-to-live, the gatekeeper assigns one and sends it to the gateway in the RCF message. No configuration changes are permitted during a lightweight registration.

DTMF Support

Dual-Tone Multi-Frequency (DTMF) is the tone generated on a touch-tone phone when you press keypad digits. During a call you might enter the DTMF to access Interactive Voice Response (IVR) systems such as voicemail, calling card services, and so on. DTMF is transported the same way as voice in the PSTN.

There are two methods of providing this DTMF capability in an IP network:

• Out-of-band:

• H.323 provides the DTMF digit support using the User Input Indication (UII) H.245 message.

• In-band:

• Media gateways or the VDAC-ONE card can provide DTMF digits in separate RTP packet formats.

• Media streams can accurately transmit DTMF digits "in-band" using high bit-rate CODECS. Media gateways or the VDAC-ONE card with high bit-rate CODECS can reproduce DTMF digits in the same manner as it creates voice packets.

Converged networks contain media gateways and other devices with high bit-rate and/or low bit-rate CODECS. High bit-rate CODECS, such as G.711, G.726, and G.727, reproduce DTMF digits accurately. However, low bit-rate CODECS, such as G.729, and G.723.1 require DTMF tones to be put in a separate RTP payload format because they cannot reproduce DTMF tone signals accurately enough for automatic recognition. Using separate RTP payload formats for both high and low bit-rate CODECS is one way to address DTMF tone reproduction in a standard way in the IP media stream.

The CSP is capable of supporting all methods of handling DTMF digits for ultimate partner flexibility. The current plan for DTMF digit support in this version of the CSP system is as follows:

• Out-of-band DTMF digit support:

• H.323 signaling support with the H.245 message set

• In-band DTMF digit support with VDAC-ONE for high bit-rate CODECS such as G.711, G.726, and G.727:

• VDAC-ONE RTP payload formats (all CODECS)

Hookflash Relay

A 'hookflash" indication is a brief on-hook condition that occurs during a call. For example during a call, a phone user quickly depresses and then releases the hook switch on their telephone. It is not long enough to be interpreted as a signal to disconnect the call, but telephone switches and PBXs are frequently programmed to intercept hookflash indications and use them as a way to allow a user to invoke supplemental services. For example, your local service provider may allow you to enter a hookflash as a means of switching between calls if you subscribe to a call waiting service.

In the traditional telephone network, a hookflash results in a voltage change on the telephone line. Since there is no equivalent of this voltage change in an IP network, the ITU H.245 standard defines a message representing a hookflash. To send a hookflash indication using this message, an H.323 endpoint sends an H.245 User Input Indication message containing a "signal" structure with a value of "!". The value represents a hookflash indication.

The CSP H.323 implementation includes support for relaying hookflash indications using the H.245 User Input Indication message.

CODEC Negotiation

CODEC negotiation allows the gateway to offer several CODECS during the H.245 capability exchange phase and ultimately settle upon a single common CODEC during the call setup. This increases the probability of establishing a connection because there is a greater chance of overlapping audio capabilities between endpoints. During the call setup phase, the gateway uses the highest priority CODEC selected from the list that it has in common with the remote endpoint. It also adjusts to the CODEC selected by the remote endpoint so that a common CODEC is established for the receive and transmit audio directions.

H.323 Offer in Relation to IMTC Testing and iNOW! Profile Criteria

IMTC stands for the International Multimedia Telecommunications Consortium, Inc., a non-profit corporation comprising more than 120 organizations around the globe. The IMTC's mission is to promote and facilitate the development and implementation of interoperable, multimedia, conferencing solutions based on open international standards -- particularly the multimedia conferencing standards adopted by the International Telecommunication Union (ITU), as well as other standards organizations.

Table A-1 IMTC VoIP H.323 Scoresheet - CSP as a Gateway Entity

IMTC iNOW!

IMTC iNOW! stands for "interoperability NOW!". IMTC iNOW! is an industry initiative to achieve interoperability as soon as possible between different vendor's IP telephony equipment platforms. IMTC iNOW! is not a standard and it is not proprietary.

IMTC iNOW! is an initiative that is supported by the major players in IP telephony including Cantata, with new supporters being added all the time. Supporters of this initiative have committed to building or buying equipment that follows the IMTC iNOW! Profiles, publicly available documents that draw upon existing standards such as H.323. Any vendor that follows these Profiles will have the blueprint to build or operate IMTC iNOW! compliant equipment.

Table A-2 IMTC iNOW! Profile Testing Criteria

Restrictions

The CSP H.323 Version 2 offering does not operate on Release 5.x. If you are planning to use an CSP H.323 Version 2 Platform, your software requires Release 8.0 or later and the following hardware:

• Matrix Controller Series 3 card

• IP Signaling Series 3 card

• VDAC card or IP Network Interface card for relaying RTP streams

• DSP-ONE or DSP Series 2 card for detecting/generating DTMF Tones

Feature Limitations:

• Gatekeeper Functionality NOT supported

• Voice Only - Video is NOT supported

• No redundancy in the IP Signaling Series 3 card in this release.

Supported Standard MIBs and RFCs

• No MIBs are supported by this feature release.

• This feature provides support for the ITU H.323 V2 teleconferencing standard.