H.323 to SIP Interworking

The H.323 to SIP interworking capability is very important in Voice over IP (VoIP) services since both protocols are widely used in the industry. When one VoIP service provider uses Session Initiation Protocol (SIP) and another provider uses H.323, the two protocols need to interwork to enable the customers to contact each other. H.323 is an older protocol that is gradually supplanted by SIP. The customers who have their VoIP network managed using H.323 may have to transition to SIP in the future. During this transition, both protocols need to interwork on the customers’ VoIP network.

The following H.323 to SIP interworking features are supported:

In addition, T.38 fax passthrough is supported for SIP, H.323-H.323, and SIP-H.323 calls. See the Fax Support chapter for more information.

Note This feature is supported in the unified model in Cisco IOS XE Release 2.5 and later.

Feature History for H.323 to SIP Interworking

 

Release
Modification

Cisco IOS XE Release 2.5

H.323 to SIP interworking capability was introduced on the Cisco ASR1000 Series Aggregation Services Routers.

Cisco IOS XE Release 3.2S

Allow the secure SIP calls to be interworked with the H.323 networks on the Cisco ASR1000 Series Aggregation Services Routers.

Contents

This module contains the following sections:

Restrictions for H.323-SIP Interworking

The following features are not supported:

  • Transcoding of interworking calls.
  • Media bypass for interworking calls.
  • H.323 DTMF signaling using any method other than the alphanumeric method of UserInputIndication.
  • Interworking of endpoint registrations (not supported by H.323).
  • Failover of interworking calls (because H.323 call legs cannot be preserved across a failover).
  • Interworking of any SIP method other than INVITE, ACK, CANCEL, BYE, INFO, or PRACK.
  • End-to-end authentication on an interworking call. For example, an H.323 call branch cannot challenge a SIP call branch and vice versa. The Session Border Controller (SBC) itself can challenge a SIP call branch, but not an H.323 call branch.
  • User-configurable mapping of cause codes.
  • User-configurable mapping of codec types.
  • Interworking of signaling support for Silence Suppression/VAD. It is assumed that the majority of endpoints interoperate correctly without explicitly signaling silence suppression.
  • Interworking of video calls.
  • Interworking of fax calls partially. T.38 fax is supported for SIP, H.323-H.323, and SIP-H.323 calls.
  • Payload interworking is not supported.

Information About H.323-SIP Interworking

Following the usual process, after the SBC applies the call and number policy tables, a final adjacency and account are chosen. In H.323 to SIP interworking, the originating and terminating adjacencies are configured for different protocols. For example, the originating adjacency can be configured for H.323 and the terminating adjacency can be configured for SIP.

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.

The SBC supports the following features of H.323 to SIP and SIP to H.323 interworking:

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

When you are configuring the SBC to interwork calls between H.323 and SIP networks, you can also consider the following configuration tasks:

  • For networks that use RFC2833 telephone-event signaling, you may want to configure telephone-event support on the H.323 or SIP side for improved call setup efficiency.
  • For DTMF interworking with H.323-SIP calls, you may want to configure the telephone-event payload type supported by the caller and callee through Call Admission Control (CAC) policy. This allows for improved call setup efficiency.
  • To allow passthrough of display name updates, for example, following a third-party call transfer—you may want to whitelist the SIP Remote-Party-ID header.

H.323 to SIP Support for Emergency Calls

Cisco Unified Border Element (SP Edition) supports H.323 to SIP call routing for emergency calls. Cisco Unified Border Element (SP Edition) routes voice and video calls according to the configured session routing policy. A call is categorized as “emergency” based on the dialed number or on the Resource-Priority header if it is originated on the SIP side. Based on the emergency categorization, special routing and Call Admission Control (CAC) logic is applied.

H.323 Slow Start Calls to SIP Calls

Cisco Unified Border Element (SP Edition) supports interworking of H.323 Slow Start upstream calls made to a SIP endpoint.

As a result of a H.323 Slow start call, the downstream SIP end point has no media information from the calling endpoint at the time it sends the initial SIP INVITE. The SBC has the ability to send a default session description protocol (SDP) offer on the INVITE that proposes a single media stream for voice traffic, listing the following candidate codecs in decreasing order of preference: G.729, G.711 U-law, G.711 A-law, and G.723.

The answer received on the 200 OK response may have either reduced the number of codecs for the stream to 1 (called a “mono-answer”), or the 200 OK response still has multiple codecs in the stream (called a “multi-answer”). The “multi-answer” is unacceptable to the H.323 protocol. The SBC has the ability to refine the codec list by making a re-INVITE to the SIP endpoint containing only the first codec. Figure 34-1 shows the flows that take place during this process.

Figure 34-1 H.323 Slow Start Calls to SIP Calls

H.323 to SIP Cause Code Mapping

Cisco Unified Border Element (SP Edition) supports mapping of SIP response codes to H.225 error codes used by H.323 and mapping of H.225 error codes to SIP response codes.

In H.323 to SIP interworking, the SBC provides call rejection with the proper cause code in the following manner:

  • If a downstream SIP endpoint rejects a call, the response is translated into the H.225 error code set for the upstream H.323 device. The SIP endpoint may also reject attempts by the SBC to refine the codec list.
  • If a downstream H.323 endpoint rejects a call, there are two possible actions—the H.323 gatekeeper may reject admission for the call, or the endpoint sends a Release Complete to reject the call.

Table 34-1 shows how SIP response codes are mapped to H.225 error codes.

 

Table 34-1 SIP Response Codes Mapped to H.225 Error Codes

SIP error code in
H.225 error code out

301

UnreachableDestination

302

UnreachableDestination

400

Undefined Reason

401

No Permission

403

Security Denied

404

UnreachableDestination

405

Undefined Reason

406

Undefined Reason

407

No Permission

408

Undefined Reason

410

Unreachable Destination

413

Undefined Reason

414

Undefined Reason

415

Undefined Reason

416

Undefined Reason

420

Undefined Reason

421

Undefined Reason

423

Undefined Reason

480

Destination Rejection

481

Unreachable Destination

482

Undefined Reason

483

Undefined Reason

487

Destination Rejection

488

Undefined Reason

501

Undefined Reason

503

Undefined Reason

504

Undefined Reason

505

Undefined Reason

513

Undefined Reason

603

Undefined Reason

604

Unreachable Destination

606

Undefined Reason

Table 34-2 shows how H.225 error codes are mapped to SIP response codes.

 

Table 34-2 H.225 Error Codes Mapped to SIP Response Codes

H.225 error code in
SIP error code out

NoBandwidth

500

UnreachableDestination

604

DestinationRejection

486

No Permission

401

GatewayResource

503

BadFormatAddress

404

SecurityDenied

403

InvalidRevision

503

UnreachableGatekeeper

503

AdaptiveBusy

503

InConf

503

RouteCallToGatekeeper

503

CallForwarded

503

RouteCallToMC

503

FacilityCallDeflection

503

CalledPartyNotRegistered

503

CallerNotregistered

503

ConferenceListChoice

503

StartH245

503

NewConnectionNeeded

503

NoH245

503

NewTokens

503

FeatureSetUpdate

503

ForwardedElements

503

TransportedInformation

503

SIP Calls to H.323 Fast Start Calls

Cisco Unified Border Element (SP Edition) supports interworking of upstream SIP endpoints calling to downstream H.323 Fast Start endpoints. This support includes support for Early Media.

Early Media Support

The capability for SIP endpoints calling to H.323 Fast Start endpoints includes support for Early Media, where the Fast Start response may be received before the Connect. Early Media can flow when the caller (SIP endpoint) makes a media proposal on the initial call setup request and the callee (the H.323 endpoint) responds to the offer before the call is connected. In this case, the H.323 endpoint expects an SDP offer on the initial INVITE.

H.323 may send a “Progress Indicator” on any H.225 message that it sends the SBC. A progress indicator of a value of 1 or 8 indicates that the H.323 endpoint will send early media. In an interworking call, only the first Progress Indicator received from the H.323 endpoint is acted upon.

If the H.323 endpoint sends a progress indicator with a value of 1 or 8, then in an interworking call with a SIP upstream call, if sufficient media parameters have been negotiated with the H.323 endpoint, the SBC returns a 183 provisional response to the SIP caller with the SDP indicating early media.

Depending on the Call Admission Control (CAC) configuration, the SBC may allow early media to be passed through at this point. If insufficient media parameters have been received to build the SDP to send to the SIP endpoint, then the SBC waits for media negotiation with the H.323 endpoint to reach a point where the SDP can be generated and then the SBC can send the 183 provisional response. Figure 34-2 shows the flows that take place during this process.

Figure 34-2 SIP with SDP Offer Call to H.323 Fast Start

 

H.323 Fast Start Calls to SIP Calls

Cisco Unified Border Element (SP Edition) supports interworking of H.323 Fast Start upstream calls made to a downstream SIP endpoint.

If the Fast Start offer from the H.323 device includes alternative codec options, the SDP offer sent to the downstream SIP device lists all of these alternative codecs in the same order of preference as that supplied by H.323. The most preferred codec is listed first. If the SIP endpoint accepts more than one codec, this is not acceptable on the H.323 Fast Start Response. Therefore, the SBC is able to refine the offer. The SBC makes another offer to the SIP device with a single codec option, by taking the most preferred codec listed in the SDP answer and constructing a new offer with that codec in it. If the downstream SIP device accepts this offer, then a FastStart response is returned, selecting that codec.

If the SIP endpoint SDP does not need to be refined, the fast start response will go back on the first available message to the H.323 endpoint.

The SIP endpoint may send early media as soon as it has sent the multi-SDP answer. However, the early media will fail to get through until the mono-SDP answer is received and processed, and the Progress Indicator and Fast Start response sent to the H.323 endpoint. See the “Early Media Support” section.

Figure 34-3 shows the flows that take place during this process.

Figure 34-3 H.323 Fast Start Calls to SIP Calls

 

SIP to H.323 Interworking for Basic Call Hold

The SIP/H.323 interworking for basic call hold feature enables Cisco Unified Border Element (SP Edition) to translate, hold, and resume signaling in H.323 and SIP interworking calls.

Note Basic call hold does not require external configuration and is enabled by default.

SIP Requirements

In RFC-3264 SDP Offer-Answer protocol, basic call hold is signaled by a re-Offer that includes an a=sendonly', 'a=inactive', or 'c=IN IP4 0.0.0.0' line.

  • a=sendonly or c=IN IP4 0.0.0.0 indicates that the offerer wants to keep transmitting. The Answer may optionally force the offerer to cease transmitting by setting a=inactive or c=IN IP4 0.0.0.0.
  • a=inactive indicates that the offerer will also cease transmitting. In this case, the answerer must also reply with a=inactive.

Resume is signaled by setting the direction to a=sendrecv or, because this is the default setting, omitting the direction line altogether.

For SIP, requirements are:

  • The SBC must support receipt of all of the above forms of call hold signaling. On transmit, control should preferably be provided over the form that is used.
  • Translation of a re-offer that opens or closes the send direction (not just the receive direction).
  • Case of the offerer or answerer changing their RTP address/port on a call hold resume offer or a call hold answer.
  • Sending a re-Offer on a SIP re-INVITE and processing the answer on the INVITE 200 rsp.
  • Processing an incoming answer on the first re-INVITE response even if that is not the final response (In this case, a duplicate answer on the final 200 response must be ignored).
  • Receipt of a re-offer on a SIP INVITE request.
  • Sending an answer on a re-INVITE 200 response.

H.323 Requirements

In H.245, basic call hold is signaled by sending an empty terminal capability set (defined in H.323 section 8.4.6, and known as "TCS=0"or "ECS"). The receiver of the TCS=0 must close its send channel and avoid re-opening it. Resume is signaled by sending a non-empty terminal capability set. At this point, the send channel is re-opened. In terms of the H.245 message flows:

  • Terminal capabilities are transmitted using a TerminalCapabilitySet (TCS). This message is responded to with a TerminalCapabilitySetAck (TCS Ack) or TerminalCapabilitySetReject.
  • A channel is opened with an H.245 OpenLogicalChannel (OLC). This is responded to with an OpenLogicalChannelAck (OLC Ack) or OpenLogicalChannelReject.
  • A channel is closed with an H.245 CloseLogicalChannel (CLC). A CloseLogicalChannelAck (CLC Ack) indicates that this message has been processed.

For H.323, requirements are:

  • Sending, receiving, and acting on empty and non-empty capability sets in an interworking call, including the situation in which both sides have put the other on hold.
  • Translation of channel close and re-open outside the context of call hold / resume.
  • Address changing for a new incarnation of a channel that uses different RTP/RTCP addresses/ports from the previous incarnation of the channel. (In line with existing behavior, SBC may continue to assume that each side of an H.245 RTP session uses a single RTP and RTCP IP address, and that the RTCP port = RTP port + 1.)
  • Receiving TCS=0 from downstream before call connection.
  • Ignoring a TCS=0 received from upstream before call connection (to prevent problems on the SIP side).

Basic Call Hold Restrictions

The following restrictions apply to the Basic Call Hold feature:

  • Third-party rerouting (where a device separate from the SBC reroutes the call) is not fully supported.
  • The SBC does not support the following SIP mechanisms for carrying out Offer-Answer exchanges:

– Offer on an UPDATE request, INVITE 18x response, INVITE 200 response or PRACK request.

– Answer to a renegotiation on anything other than an INVITE 200 response.

  • No call hold during early media. Translation of call hold/resume is allowed only after a call is established. This restriction follows from the previous restriction that prevents the SBC from receiving or generating Offers on INVITE 18x or UPDATE in SIP.
  • The SBC cannot originate or terminate H.450.4 call hold protocol.
  • The SBC supports receipt of an OLC Ack with port set to 0, but the SBC does not transmit an OLC Ack with port set to 0.
  • New timers are not configurable.
  • Existing general interworking restrictions are still in place:

– Only a single media stream is allowed.

– Only a single audio codec is allowed within that stream.

– Transcoding and DTMF interworking is not supported.

– Media bypass is not supported.

Overview: Extending the SIP Secure Calls over the H.323 Interface

Data security has become the prime objective enhances service providers, corporates, and government institutes. Cisco IOS XE Release 3.2S enhances the security feature, by extending support to the secure calls coming from either a H323 adjacency or a SIP adjacency. Before this enhancement, the SBC supported only the SIP secure calls, and the SIP secure calls were not able to interwork with the H.323 networks. After this enhancement, the SIP secure calls received from a SIP adjacency and routed over an H323 adjacency can be sent by configuring the corresponding H323 adjacency as trusted. Also, calls coming from H323 adjacency can be configured as secure calls.

To configure an H.323 adjacency as trusted for handling the SIP secure calls received from a SIP adjacency, use the trunk trusted command. Defining an adjacency as trusted, distinguishes it from untrusted adjacencies. If an incoming call is a secure call, it goes through trusted adjacency. If no trusted adjacencies are configured, the incoming secure call is rejected with the SIP response code 403 (Forbidden) or an H.225 with the reason as Security Denied. If the incoming call is not a secure call, it can go through a trusted adjacency or untrusted adjacency.

To handle the calls coming from H.323 adjacency and to treat them as secure calls, configure the H.323 adjacency as secure using the inbound secure command. The outgoing SIP calls become a SIP-secure calls.

Prerequisites for the SIP Secure Calls over an H.323 Interface

Following are the prerequisites for the SIP Secure calls over an H.323 interface:

  • The minimum software image required for this feature to work is the Cisco IOS XE 3.2S Software image.
  • An H.323 adjacency must be configured as trusted before configuring the incoming calls as secure.

Note All the H.323 adjacencies that are defined are by default untrusted. If you want to change an adjacency from trusted to untrusted, configure the incoming calls for the adjacency as insecure by using the no inbound secure command.

Restrictions for the SIP Secure Calls over an H.323 Interface

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.

Configuring the SIP Secure Calls over an H.323 Interface

To implement the SIP Secure calls over an H.323 interface, configure the following:

  • An H.323 outgoing adjacency as Trusted for handling the SIP secure calls received from the SIP adjacency.
  • Incoming calls from an H.323 adjacency as secure calls for calls coming from an H.323 adjacency.

The following section provides procedure for configuring an H.323 adjacency as trusted and configuring incoming calls from an H.323 adjacency as secure calls:

SUMMARY STEPS

1. configure terminal

2. sbc sbcname

3. sbe

4. adjacency h323 adjacency-name

5. trunk trusted

6. inbound secure

DETAILED STEPS

 

Command or Action
Purpose

Step 1

configure terminal

 

Router# configure terminal

Enters the global configuration mode.

Step 2

sbc service-name

 

Router(config)# sbc mysbc

Enters the mode of an SBC service.

Use the service-name argument to define the name of the service.

Step 3

sbe

 

Router(config-sbc)# sbe

Enters the mode of an SBE entity within an SBC service.

Step 4

adjacency h323 adjacency-name

 

Router(config-sbc-sbe)# adjacency h323 trust-h323-adj

Enters the H.323 adjacency mode to configure the parameters for the specified adjacency name.

Step 5

trunk trusted

 

Router(config-sbc-sbe-adj-h323)# trunk trusted

Configures the H.323 adjacency as trusted.

Step 6

inbound secure

 

Router(config-sbc-sbe-adj-h323)# inbound secure

Configures the incoming calls from the H.323 adjacency as secure calls.

Note If the H.323 adjacency is configured as untrusted, incoming calls cannot be configured as secure calls.

 

Configuration Example: Implementing Secure SIP Calls over an H.323 Adjacency

The following example shows how to configure an H.323 adjacency as Trusted and mark the incoming calls on an H.323 adjacency as secure calls:

Router# configure terminal
Router(config)# sbc mysbc
Router(config-sbc)# sbe
Router(config-sbc-sbe)# adjacency h323 trust-h323-adj
Router(config-sbc-sbe-adj-h323)# trunk trusted
Router(config-sbc-sbe-adj-h323)# inbound secure
 

The following example displays the configuration details of trust-h323-adj:

Router# show sbc mySBC sbe adjacencies trust-h323-adj detail
 
SBC Service "mysbc"
Adjacency trust-h323-adj (H.323)
Status: Detached
Signaling address: 0.0.0.0:1720 (default)
Signaling-peer: 0.0.0.0:1720 (default)
Admin Domain: None
Account:
Media passthrough: Yes
Group:
Hunting triggers: Global Triggers
Hunting mode: Global Mode
Techology Prefix:
H245 Tunnelling: Enabled
Fast-Slow Interworking: None
Trust-level: Trusted
Call-security: Secure
Realm: None
Warrant Match-Order: None