The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Unified Border Element (SP Edition) supports H.323, as well as Session Initiation Protocol (SIP). This H.323 interworking capability enables multimedia products and applications from multiple vendors to interoperate and allows users to communicate without concern for compatibility.
H.323 is the international standard for multimedia communication over packet-switched networks, including local area networks (LANs), wide area networks (WANs), and the Internet. It was first defined by the International Communications Union (ITU) in 1996. The most recent version is H.323 version 6 (2006).
Note This feature is supported in the unified model for Cisco IOS XE Release 2.5 and later.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:
http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html.
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
Feature History for H.323 Support
This feature requires basic understanding of H.323-related ITU standards, gatekeepers, and gateways. Gateways are responsible for edge routing decisions between the Public Switched Telephone Network (PSTN) and the H.323 network. Gatekeepers are used to group gateways into logical zones and perform call routing between them.
The restrictions for H.323 support are listed per feature in this chapter and other H.323-related chapters in the guide.
H.323 is a suite of protocols and documents that includes the ITU-T standards H.323, H.225.0, H.245, the H.450-series, and the H.460-series. Not all components of H.323 are mandatory as part of a standard H.323 system. For example, H.460.2, which describes number portability, is generally not used in enterprise video conferencing systems. Also H.323 utilizes both ITU-defined codecs and codecs defined outside the ITU to transmit audio, video, and text.
H.323 is used in Voice over Internet Protocol (VoIP), and IP-based video conferencing and serves a similar purpose to that of the Session Initiation Protocol (SIP). It was designed from the outset to operate over IP networks primarily, although H.323 may also operate over other packet-switched networks. H.323 was designed with multipoint voice and video conferencing capabilities, although most users do not take advantage of the multipoint capabilities specified in the protocol.
H.323 is more mature than SIP, but lacks the flexibility of SIP. SIP is currently less defined, but has greater scalability which could ease the Internet application integration. Like SIP, H.323 is one of the world market leaders for transporting voice and video over networks around the world, with billions of minutes of voice traffic every month. The SBC supports both SIP and H.323, enabling multimedia products and applications from multiple vendors to interoperate, and allowing users to communicate without concern for compatibility.
The following supported H.323 features are documented in another chapter in this configuration guide or represent part of standard Q.931/H.225 protocols that are documented in this chapter:
Note All H.323 calls, including established H.323-H.323 and SIP-H.323 interworking calls, are disconnected upon an SBC switchover. An SBC switchover occurs when an active RP switches over to the standby RP in a hardware redundant system (such as a Cisco ASR 1006 Router) or when the active IOS process switches over to the standby IOS process in a redundant software system (such as a Cisco ASR 1002 Router).
The following supported H.323 features are documented in this chapter. The H.323 Call Routing features are documented in the —$paratext[CT_ChapTitle]>— chapter:
Cisco Unified Border Element (SP Edition) supports the following H.323 call routing features:
Note The H.323 call routing features are noted in this chapter for reference. However, they are described in the H.323 Call Routing Features in the —$paratext[CT_ChapTitle]>— chapter.
Cisco Unified Border Element (SP Edition) allows H.323 video calls to be established through it. The supported H.323 video codecs are H.261, H.263 and H.264.
No specific configuration is required on either the end points or the SBC to enable this feature.
Cisco Unified Border Element (SP Edition) supports the ability of H.323 endpoints with different starting modes of operation to interoperate with one another. Note that only the H.323 slow start endpoint to H.323 fast start endpoint is supported, and not vice-versa.
H.323 has two modes of operation: slow start and fast start. The initiation of a call may proceed in a slow start or fast start in H.323. In a slow start, H.323 signaling consists of Setup, Call Proceeding, Alerting, and Connect steps. After these steps, the H.245 media negotiation is performed. When a call is initiated in H.323 fast start, the H.245 media negotiation is performed within the initial Setup message.
This H.323 Slow Start to H.323 Fast Start Interop feature is enabled on a per adjacency basis. You can use the start fast command to configure the H.323 fast start mode. All calls routed to an adjacency uses the fast start mode that is configured on that adjacency. H.323 endpoints start in the fast start mode for outgoing calls on the adjacency and be able to convert incoming calls to the mode configured for that endpoint on the adjacency. When the fast start mode is configured, the SBC only uses the fast start mode for outgoing calls. However, incoming slow start calls are converted to fast start mode as they cross the SBC.
If the fast start mode is not configured on the adjacency, by default, the outgoing call start is the same as the incoming call start. The mode of operation can be modified while the adjacency is active but the change will only affect new calls. See the “Configuring H.323 Slow Start to H.323 Fast Start Interop” section for configuration step information.
Note The fast start outgoing call is only a proposal, indicating the preferred mode from the SBC's perspective. The H.323 endpoint can accept it or fall back to normal slow start procedure according to the H.245 specification.
The H.323 procedures require that the SBC sets up a separate H.245 control channel over TCP. This feature complements tunneled H.245 support, enabling the user to control whether to use tunneling or not.
This feature enables the SBC to carry out an H.323-H.323 call, where two call legs can negotiate different H.245 transport mechanisms. Each call leg decides independently whether to use a separate H.245 control channel.
The SBC sets up separate H.245 control channels only when required in one of the following cases:
The SBC never requests separate H.245 control channel while tunneling is available unless the "disable tunneling" command line interface (CLI) command is set (see “Configuring Separate H.245 Control Channel” section). The SBC does not connect to an H.245 address simply because the peer offered an h245Address.
The SBC does not offer an H.245 address until it needs to, performing the following:
Since H.323 v2 onwards has support for Facility reason startH245, support for this feature is assumed in all peer devices. If the peer requires an H.245 connection and one does not exist, the partner must use a startH245 Facility to induce the SBC to connect to it.
If there is no H.245 transport possible (tunneled or separate), and H.245 messages must be sent by the SBC, then the call is terminated.
On receipt of provisionalRespToH245Tunnelling, the SBC waits to determine the final tunneling outcome before attempting separate H.245. H.245 messages are queued at this point and sent as soon as an H.245 transport becomes available.
In the event of an H.245 connection race, the SBC only disconnects if it looses. The partner must disconnect if it loses. Races are resolved by comparing the listen address/port (not the connection address/port).
Back-pressure is exerted at call scope, or connection scope when multiple calls share a connection. So, if call leg B cannot forward H.245 messages for some reason, call leg A's connection may exert TCP back pressure on the peer. If call leg A is doing H.245 tunneling, and sharing a Q.931 TCP connection with other calls, then the peer will experience back pressure on the other calls too.
The SBC tears down separate H.245 connections at the same point as their call by closing the relevant socket.
The restrictions for the H.245 control channel are:
In media bypass, H.245 content is passed unmodified between two H.323 call legs (for more information about media bypass, see the “How Adjacencies Affect Media Routing” section in the Implementing Adjacencies on Cisco Unified Border Element (SP Edition) chapter). Passthrough happens irrespective of whether an H.245 message is received over tunneled H.245 transport or a separate H.245 control channel, and does not require that both H.323 call legs use the same H.245 transport mechanism. This feature permits inserting an SBC between two H.323 devices without any change to the passing H.245 content.
This is achieved by passing through H.245 messages opaquely between the endpoints. The Fast Start request and response is passed through in the same way as mainline H.245. The only messages inspected by the SBC are fast start and logical channel signaling. These are used to derive the bandwidth used for the call.
The restrictions for the H.245 passthrough are:
The SBC supports media relay (which is media pass through the DBE) of unidirectional H.245 channels. H.245 codec types are converted to Session Description Protocol (SDP) for the purposes of the DBE programming, transcoder programming, and billing. This is done using a codec mapping table (see “T.38 Fax Relay” section).
When dealing with codec types, for which no SDP mapping exists, the SBE makes a best-effort attempt, and tries to find the best possible SDP match. You can also use the codec-restrict-to-list command to configure a Call Admission Control (CAC) policy to restrict the codecs used in signaling a call to the set of codecs given in the named list. This configured CAC policy will have the effect of blocking setup of a particular codec or of ignoring an unknown codec.
Inserting an SBC between two H.323 devices does not impact H.245 function (see “H.245 Passthrough” section). For example, the SBC does not modify the logical channel numbers of H.245 channels in a media relay call. In a distributed DBE model, H.248 signals are used to establish the necessary media terminations on the DBE.
The SBC supports renegotiation of media, using H.245 procedures, such as:
Switchover to T.38 fax is described below in “T.38 Fax Relay” section.
The restrictions for slow start media relay are:
The following codec mappings (Table 20-1) are used by the SBC to represent H.245 codecs as SDP for the purpose of:
|
|
---|---|
See T.38 Fax Relay |
For general information, see the Codec Handling chapter.
Dual-tone multi-frequency (DTMF) tones are used to transfer user requests. Different systems may support different forms of DTMF. The SBC enables the DTMF interworking between these systems.
For example, some nonstandard H.323 devices do not support the lowest common denominator of alphanumeric UserInputIndication. Such devices can only signal DTMF through RFC2833 telephony events or as in-band media data. Other devices support UserInputIndication but not the RFC2833 telephony event.
If two such devices are deployed back to back, their only option is to send DTMF tones as it is done in-band media data. Deploying an SBC between them allows each side to send DTMF, using its supported signaled method, UserInputIndication on one side and RFC2833 on the other, with the SBC interworking between the two.
This function requires the SBE to program the DBE to enable interception and insertion of RFC2833 DTMF on a particular side of the call—the side facing the RFC2833-only device. The SBE and DBE then collaborate to transfer DTMF signaling between the H.245 control channel and the RTP steam.
DTMF interworking is negotiated through TerminalCapabilitySet. Therefore, the SBC must be capable of extending the TerminalCapabilitySet to advertise support for both alphanumeric and RFC2833 methods.
The feature described in this section replaces all previous H.323 DTMF interworking functions. H.323 calls must support DTMF interworking between alphanumeric UserInputIndication and RFC2833. In this case, the SBE coordinates with the DBE to carry out DTMF insertion and interception in the Real-Time Protocol (RTP).
DTMF interworking is negotiated through TerminalCapabilitySet, not manual configuration. Therefore, the SBC must always advertise support for both alphanumeric and RFC2833 methods, if necessary by extending the TerminalCapabilitySet on its way through. (The exception is a TCS=0.)
See also the Implementing Interworking DTMF chapter for general information.
The restrictions for DTMF internetworking are as follows:
The SBC supports transcoding of slow start calls, enabling communication between different endpoints with different codecs, which otherwise cannot communicate with each other. Two H.323 endpoints deployed back-to-back might fail to agree on a mutually acceptable codec.
A typical case might be where one side is insisting on a low-bandwidth codec (such as ITU-T G.729) because of bandwidth constraints or administrative policy, and the other side only supports G.711. For example, if the calling party uses g711alaw and the callee uses G.729 annex B, the SBC can convert G.711alaw codec to g729 annex B codec and enable communication between the two. When the SBC detects that codec negotiation is needed, it uses Cisco Voice Interworking Service Module (VXSM) in the Cisco MGX 8880 switch as its media gateway to perform the transcoding. Deploying the SBC between the endpoints, in conjunction with an MGX 8880 transcoder, allows such calls to succeed.
The previous releases supported a fast-start-only version of transcoding. This function is now replaced with an implementation of transcoding that is triggered off TerminalCapabilitySet.
Transcoding is supported only for SIP-SIP calls.
See also the —$paratext[CT_ChapTitle]>— chapter for general transcoding information.
The restrictions for H.323 transcoding are:
A technology prefix is an optional H.323 standard-based feature, supported by gateways and gatekeepers, that enables more flexibility in call routing within an H.323 VoIP network. The gatekeeper uses technology prefixes to group endpoints of the same type together. Technology prefixes can also be used to identify a type, class, or pool of gateways. This feature provides per-adjacency configuration of RAS Tech Prefix and registers this prefix with the gatekeeper.
An H.323 adjacency may now be optionally configured with a single tech prefix consisting of 1-32 dialed digits. It publishes the tech prefix to the gatekeeper in the following field of the RAS registration
As with existing adjacency configuration, this field may not be changed while the adjacency is attached. This feature works in conjunction with existing SBC support for adding or removing digits on dialed numbers (see the Number Manipulation section in the —$paratext[CT_ChapTitle]>— chapter).
H.323 standards recommends timers, timeout, and retry counts for various messages. Their values are not fixed and represent a range. The ability to define these values facilitates interworking between different devices. H.323 timers and retry counts can be now configured by the user at a global and per-adjacency level. Timers are expressed in seconds.
The following Q.931/H.225 timers are configurable.
The following RAS timeout and retry counts are configurable.
The RAS RRQ TTL and keepalive times (governing lightweight RRQ behavior) are configurable. These two settings are interrelated. If the user configures unsafe values for a given adjacency, the SBE reverts to the defaults.
The adjacency retry timer is configurable, and can be used to automatically reattempt adjacency attachment when an adjacency fails for any reason.
User protocol timer control restrictions are:
– Q.931/H.225 Overlap Sending Timer T302
– Q.931/H.225 Overlap Receiving Timer T304
This feature provides support for media relay of T.38 fax. The following features are supported:
The T.38 H.245—SDP mapping is shown below:
The only parameters needed for media relay function are the port and the peak-bit rate, which are highlighted in the example. Therefore, the presence of a T.38 fax function causes the following SDP to be transmitted to the DBE:
For interworking scenarios, a complete mapping needs to be carried out.
Switchover from a voice to fax call is handled by a RequestMode exchange. In an H.323-H.323 call this exchange is passed through transparently between call legs without DBE signaling. This allows endpoints to coordinate replacement of audio with T.38 channels.
In accordance with H.323v5 standards, the SBC counts UDP but not TCP towards the maximum bit rate agreed with the gatekeeper.
T.38 Annex B is a fast start only (no H.245) version of H.323 Annex D. Interoperation with Annex B nodes is not supported by the SBC.
This feature enables message elements from Q.931/H.225 to be passed through between two H.323 call legs. This section describes the "base passthrough profile" of the SBC, listing the parts of the Q.931/H.225 message that may be passed through.
The following conventions are used in the base passthrough profile:
– P = "passthrough". This subtree is passed opaquely between call legs.
– P* = "passthrough with privacy implications". Similar to "P", but passing through this subtree may reveal information about an endpoint or a remote telephone number.
– B = "block". This subtree is unconditionally blocked by the SBC and any information contained in it is lost.
– SBC. This subtree is manipulated by the SBC. Typically, values are replaced by those local to the SBC.
A Call Proceeding message is never passed through. However, fields from it are extracted and put into a Progress or Facility in the upstream call log.
The following ITU-T Q.931 messages are not supported by the SBC either because they are forbidden in H.323 or because the SBC does not currently support their corresponding features.
Subtrees marked as "P*" - "passthrough with privacy implications" are automatically blocked if the outgoing call leg has privacy enabled in CAC policy. This automatic blocking cannot be overridden by configuration, therefore, the only way to have these fields pass through is to disable privacy.
When passing through messages, the SBC sets the version of outgoing messages to the lower value of its own ASN.1 version from that received in the original protocol message.
With the H.323 privacy feature, users can invoke identity hiding on Q.931/H.225 messages. When this feature is implemented, the SBC strips Q.931/H.225 message elements that reveal information about the remote caller or callee before passing them to the endpoints.
Note The Q.931/H.225 message elements that impact privacy are defined in the H.323 passthrough profile.
The SBC applies the privacy service to a message if it contains a privacy request submitted by a user, or if a Call Admission Control (CAC) policy on the SBC is configured to enable privacy on a caller or callee basis. If, however, the privacy configuration fields are set to default values, then the SBC forwards the message to the next call leg without applying the privacy service to the message. You can also configure the SBC to provide the H.323 privacy service on a per-adjacency basis.
The SBC applies the following rules when providing the H.323 privacy service:
Restrictions and limitations are as follows:
The SBC allows the address of the H.245 listening socket to be published in the Q.931 call proceeding message. When the caller does not support tunneling and an H.245 address published to the caller set to “wait-connect”, H.323 supplies only the H.245 address on the Q.931 connect. In default behavior, H.323 supplies the H.245 address on a Q.931 call proceeding, and all subsequent messages to the caller until the H.245 connection is opened.
The SBC supports multiple TCP connections for an H.323 call, such as one H.225 signaling channel and one H.245 signaling channel if required.
The Cisco IOS XE Release 3.2S extends the security feature, by extending support of secure calls coming from an H323 adjacency or from a SIP adjacency. Before this enhancement, SBC only supported SIP secure calls and SIP secure calls were not able to interwork with H.323 networks. After this enhancement, SIP secure calls received from SIP adjacency and routed over H323 adjacency can be sent by configuring the H323 adjacency as trusted. Also, calls coming from an H323 adjacency and if it is required to be treated as a secure call then you can configure the H323 adjacency as secured.
Following are the restrictions of the SIP Secure calls over an H.323 interface:
The Tandberg T3 device is a high-end 3-screen video-conferencing product that uses H.323 signaling. To direct the 3 video streams, it routes calls using the H.323 ID. The Destination Number.Screen Identifier H.323 ID format is used. For example, 12221120008.left, indicates that the T3 device is identified using the e164 number 12221120008, and the video stream that is being negotiated is to be presented on the left side of the screen. Similarly, H.323 negotiations for other streams with.right and.centre suffixes, and the same numeric prefix can be made.
Prior to Cisco IOS XE Release 3.3S, these calls would fail when the SBC is inserted into the signaling path for the following reasons:
From Cisco IOS XE Release 3.3S, when the SBC receives a Q.931 message that contains no routing information in the standard called party number (CdPN) field, it examines the H.225 destinationAddress field. If the field contains information of type e164, the contents is copied into the CdPN field of the message. However, if the field contains information of H.323 ID type, the SBC copies the numeric prefix of this field into the CdPN field of the message.
For information on configuring the Limited H.323 ID Routing and Passthrough Support feature, see the Configuring Limited H.323 ID Routing and Passthrough Support.
The Limited H.323 ID Routing and Passthrough Support feature has the following restrictions:
This section contains the following:
The following example describes how to configure the SBC to use the fast start mode of operation for outgoing calls; and to effect the interop capability that enables the incoming slow start calls to be converted to fast start calls as they cross the SBC.
This command disables tunneling on a per-adjacency basis, facilitating interoperability with existing devices that are confused by tunneling. The command controls both incoming and outgoing calls.
This feature provides per-adjacency configuration of RAS Tech Prefix and registers this prefix with the gatekeeper. RAS tech prefix may consist of 1-32 dialed digits.
This feature allows the SBC to apply the H.323 privacy service on outbound messages.
This feature allows the address of the H.323 listening socket to be published in the Q.931 call proceeding message.
4. adjacency h323 adjacency-name
This section shows how to configure the Limited H.323 ID Routing and Passthrough Support feature:
This task shows how to configure the SBC to block the sourceAddress and destinationAddress fields in H.225 messages received on the H.323 adjacency. When the SBC is configured to block, these fields are not sent out of the outbound H.323 adjacency.
This task shows how to interpret H.225 sourceAddress and destinationAddress fields when the Q.931 callingPartyNumber or calledPartyNumber fields are not present. When callingPartyNumber is not provided in the Q.931 part of the message, the sourceAddress in the H.225 is checked. Similarly, when the calledPartyNumber field is not present, the destinationAddress is checked.
4. adjacency h323 adjacency-name
The following example lists the adjacency that is configured in the SBE using the show sbc sbe adjacencies detail command. The output also displays information about the H.225 messages.