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.
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
This module contains the following sections:
The following features are not supported:
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:
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.
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
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:
Table 34-1 shows how SIP response codes are mapped to H.225 error codes.
|
|
---|---|
Table 34-2 shows how H.225 error codes are mapped to SIP response codes.
|
|
---|---|
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.
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
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
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.
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.
Resume is signaled by setting the direction to a=sendrecv or, because this is the default setting, omitting the direction line altogether.
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:
The following restrictions apply to the Basic Call Hold feature:
– 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.
– Only a single media stream is allowed.
– Only a single audio codec is allowed within that stream.
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.
Following are the prerequisites for the SIP Secure calls over an H.323 interface:
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.
Following are the restrictions of the SIP Secure calls over an H.323 interface:
To implement the SIP Secure calls over an H.323 interface, configure the following:
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:
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:
The following example displays the configuration details of trust-h323-adj: