Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model

H.323 Call Routing

Cisco Unified Border Element (SP Edition) supports the following H.323 call routing features:

• H.323 Hunting
• Picking a Next Hop in Routing Policy
• Support for H.323 Addressing
• DNS Name Resolution
• Number Validation and Editing
• Load Balancing
• Inter-VPN Calling

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.

H.323 Video Codec Support

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.

H.323 Slow Start to H.323 Fast Start Interop

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.

Separate H.245 Control Channel

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 has received a startH245 Facility
• The SBC needs to send out an H.245 message and tunneling is not available

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:

• Where possible, the SBC connects to the peer instead.
• Where impossible, the SBC offers its own H.245 address in a startH245 Facility and waits for 10 seconds for the peer to connect. This timeout is not configurable.

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.

Restrictions for Separate H.245 Control Channel

The restrictions for the H.245 control channel are:

• The SBC does not support a model, in which it induces the peers in an H.323-H.323 call to set up the H.245 TCP connection directly between themselves or to the data border element (DBE).
• No show command is provided to list the H.245 transport status on a per-adjacency or per-call basis.
• The H.245 security is not supported.

H.245 Passthrough

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.

Restrictions for H.245 Passthrough

The restrictions for the H.245 passthrough are:

• Configuration to block passthrough of certain messages or message elements is not included in this feature and is covered separately.
• In a media bypass call, no Session Description Protocol (SDP) appears in the billing records.
• The SBC does not support rate limiting of passed-through H.245 traffic, other than generic rate limiting of all signaling traffic.

Slow Start Media Relay

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:

• Fax upspeed: Where endpoints switch over from a low-bit-rate audio codec to ITU-T G.711
• TCS=0: Where one endpoint induces the other to temporarily close all of its channels

Switchover to T.38 fax is described below in “T.38 Fax Relay” section.

Restrictions for Slow Start Media Relay

The restrictions for slow start media relay are:

• The SBC does not support bidirectional H.245 channels in fast start or Open Logical Channel (OLCs).
• Dual tone multifrequency (DTMF) interworking is not supported between different types of UserInputIndication.
• For SIP-SIP and H.323-H.323 calls, no user configuration is needed for DTMF interworking, which is triggered solely by capability negotiation.
• The SBC does not support multipoint capabilities.

Codec Mappings

The following codec mappings (Table 20-1) are used by the SBC to represent H.245 codecs as SDP for the purpose of:

• Billing records (media relay only)
• DBE programming (media relay only)
• Bandwidth allocation (media relay and media bypass). The bandwidth here is calculated based on the SDP, not directly from the H.245.

Note the following:

• H.245 video and data codecs, other than T.38 and also H.261, H.263, H.264 for H.323-H.323 calls, are not supported by the SBC for media relay and media bypass.
• The subset of codecs supported for H.323/SIP interworking is much smaller (for more information see the H.323 to SIP Interworking chapter)

For general information, see the Codec Handling chapter.

DTMF Interworking

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.

Restrictions for DTMF Interworking

The restrictions for DTMF internetworking are as follows:

• The alphanumeric UserInputIndication method and DTMF RFC 2833 are supported for DTMF interworking.
• The SBE assumes that a peer, advertising any form of UserInputCapability is capable of sending and receiving alphanumeric DTMF.
• No manual configuration is provided to force DTMF interworking to occur.
• Detection or insertion of DTMF as in-band audio data is not supported.

Transcoding

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.

Restrictions for Transcoding

The restrictions for H.323 transcoding are:

• No transcoding support for SIP-H.323 and H.323-H.323 calls.
• The decision whether to use a transcoder is taken once per call, and is not modified if endpoints issue updated TerminalCapabilitySets (including TCS=0).
• When transcoding is required, the SBC enforces symmetric codecs for the call.
• Transcoding is never invoked in a fast start call. If no channels are suitable, endpoints must drop to slow start at which point transcoding may be invoked.
• The only codecs supported for transcoding are G.711 (PCMU and PCMA) and G.729 (with and without annex B), and the only transcoder tested with them is the Cisco MGX 8880 switch.

RAS Tech Prefix

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

request (RRQ):

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).

Restrictions for RAS Tech Prefix

• This feature does not support zone prefixes, for example, registration of prefix AliasAddresses with the gatekeeper.

User Protocol Timer Control

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.

• Q.931/H.225 Setup Timer T303
• Q.931/H.225 Establishment Timer T301
• Q.931/H.225 Incoming Call Proceeding Timer T310

The following RAS timeout and retry counts are configurable.

• GRQ
• RRQ
• URQ
• ARQ
• BRQ
• DRQ

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.

The following timers are hardcoded:

• TCP shutdown timeout—when gracefully closing a TCP connection, the time allowed for remote closure before closing it ungracefully. The hardcoded value is 1 second.
• TCP connect timeout—time allowed before giving up on a TCP connection attempt to a remote peer. The hardcoded value is 1 second.

Restrictions for User Protocol Timer Control

User protocol timer control restrictions are:

• Changing timer values or retry counts while adjacencies are attached is allowed, but does not affect timers’ or gatekeeper’s transactions that are already in progress.
• No facility is provided to configure all RAS timeouts at once.
• H.245 timers are not included here since they only run in interworking scenarios.
• The SBC does not support the configuration of the following Q.931/H.225 timers:

– Q.931/H.225 Overlap Sending Timer T302

– Q.931/H.225 Overlap Receiving Timer T304

– Q.931/H.225 Status Timer T322

• The SBC does not support the configuration of the following RAS timers:

– IRQ

– IRR

– RAI

– SCI

T.38 Fax Relay

This feature provides support for media relay of T.38 fax. The following features are supported:

• Both fax-only and fax-plus voice calls.
• Switchover from voice to T.38 fax.
• T.38 relay over unnumbered datagram protocol transport layer (UDPTL) only, and unidirectional H.245 channels only.

T.38 H.245 - SDP Mapping

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.

H.245 Mode Request

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.

RAS Maximum Bit Rate

In accordance with H.323v5 standards, the SBC counts UDP but not TCP towards the maximum bit rate agreed with the gatekeeper.

H.323 Annex D / T.38 Annex B Interoperability

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.

Restrictions

The restrictions are as follows:

• The SBC cannot be configured to advertise the t38FaxAnnexbOnly field of SupportedProtocols in RAS messages, and ignores this field on receipt.
• No support for TCP or Secure Real-Time Transport Protocol (SRTP) transport.
• No support for bidirectional H.245 channel signaling.

Q.931/H.225 Passthrough

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:

• ASN.1 syntax for Q.931 / H.225 messages is reproduced in this document.
• The following tags are attached to ASN.1 subtrees, specifying the passthrough behavior.

– 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.

Call Proceeding Passthrough

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.

• A Progress is used if the Call Proceeding contains a progress indicator.
• A Facility is used otherwise.

Unsupported Messages

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.

• Status, Status Enquiry
• SetupAck
• Information
• Notify
• userInformation.

Privacy

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.

Setting of Protocol Version

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.

Q.931 / H.225 Base Passthrough Profile

Restrictions

• Any message elements from Q.931/H.225 that are not listed in this section cannot be passed through.
• Passthrough of security tokens is not supported.

H.323 Privacy

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:

• If an H.323 adjacency is configured to allow private information, then the SBC does not apply privacy service even if an incoming message requests it or the CAC policy is configured to enable privacy.
• If an H.323 adjacency is not configured to allow private information, but a CAC policy is configured to enable privacy, then the SBC applies the privacy service to outgoing messages.
• If an incoming message requests the privacy service, but a CAC policy has not been configured to enable privacy, then the SBC applies the service if the adjacency is configured to apply the privacy service.
• If an incoming message requests the privacy service when both the CAC policy and the adjacency have not been configured to apply the privacy service, then the SBC does not apply the privacy service and allows the private information to pass through.

Restrictions and Limitations

Restrictions and limitations are as follows:

• The SBC does not apply the H.323 privacy service to H.245 and RAS messages.
• Currently, the CAC policy for callee privacy is available for the H.323 signaling stack at “connect time”, and only if a connectedNumber is present. As a result, the callee privacy service is not applied to the Q.931 protocol messages that pass through before or after a call is connected when a connectedNumber is not present. Due to this limitation, the SBC forwards the Q.931 Alerting, Q.931 Progress, and Q.931 Release Complete messages without applying the privacy service request to them.
• In an interworking call, the SBC only applies privacy requests based on the CAC policy.

H.245 Address in Call Proceeding

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.

Multiple TCP for H.323

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.

Extending SIP Secure calls over H.323 Interface

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 SBC does not signal secure H.323 calls using the procedure described in H.235. It also does not recognize the secure nature of the incoming H.323 calls using the H.235 procedures.
• The SBC does not use a TLS or IPSec to send call signalling for secure H.323 calls.

Limited H.323 ID Routing and Passthrough Support

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:

• The call is not routed correctly, because the SBC does not read the information in the H.225 destination address field, and this is the only field in which routing information is made available by the T3.
• The destinationAddress field is blocked by the SBC, so even if the call were routed correctly, the receiving T3 does not have the information of the screen that has to be presented with the video stream.

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.

Restrictions for Limited H.323 ID Routing and Passthrough Support

The Limited H.323 ID Routing and Passthrough Support feature has the following restrictions:

• This feature is not supported on an inbound SIP adjacency, as the configuration is done on the inbound H.323 adjacencies.
• If the inbound adjacency for a call is H.323, you can derive the caller and the callee numbers from the H.225 and H.323 ID addresses by setting h225 address usage to prefix. You cannot pass through the complete H323-ID format addresses directly.
• H.225 addresses cannot pass through during the H.323-SIP interworking because an AliasAddress field cannot be inserted in a SIP message.

Configuring H.323 Slow Start to H.323 Fast Start Interop

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.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency h323 adjacency-name

5. start fast

6. exit

DETAILED STEPS

Configuring Separate H.245 Control Channel

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.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency h323 adjacency-name

5. h245-tunnel disable

6. exit

DETAILED STEPS

Configuring RAS Tech Prefix

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.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency h323 adjacency-name

5. tech-prefix tech-prefix

6. exit

DETAILED STEPS

Configuring User Protocol Timer Control

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. h323 | adjacency h323 adjacency-name

5. adjacency timeout value

6. h225 timeout

7. ras retry

8. ras rrq ttl value

9. ras rrq keepalive value

10. ras timeout

11. exit

12. show sbc sbc-name sbe h323 timers

DETAILED STEPS

Configuring H.323 Privacy

This feature allows the SBC to apply the H.323 privacy service on outbound messages.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency h323 adjacency-name

5. allow private info

6. privacy restrict outbound

7. exit

DETAILED STEPS

Configuring H.245 Address in Call Proceeding

This feature allows the address of the H.323 listening socket to be published in the Q.931 call proceeding message.

SUMMARY STEPS

1. configure terminal

2. sbc service-name

3. sbe

4. adjacency h323 adjacency-name

5. h245-address-pass wait-connect

6. exit

DETAILED STEPS

Configuring Limited H.323 ID Routing and Passthrough Support

This section shows how to configure the Limited H.323 ID Routing and Passthrough Support feature:

• Configuring H.225 Address Passthrough
• Configuring H.225 Address Usage

Configuring H.225 Address Passthrough

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.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. adjacency h323 adjacency-name

5. h225 address block

6. end

7. show sbc sbc-name sbe adjacencies adjacency-name detail

DETAILED STEPS

Configuring H.225 Address Usage

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.

SUMMARY STEPS

1. configure terminal

2. sbc sbc-name

3. sbe

4. adjacency h323 adjacency-name

5. h225 address usage { e164 | h323id }

6. end

7. show sbc sbc-name sbe adjacencies adjacency-name detail

DETAILED STEPS

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.