Cisco Multiservice IP-to-IP Gateway

The Cisco Multiservice IPIPGW facilitates simple and cost-effective connectivity between independent VoIP and video networks. Designed to meet enterprise and service provider SBC needs, the Cisco Multiservice IPIPGW is an integrated Cisco IOS application that runs on the following platforms:

The IPIPGW images support not only IPIPGW functionality, but also a regular TDM gateway and gatekeeper functionality. The IPIPGW images are special images, which are integrated along with the routing, switching, and security features that are available in the regular Cisco IOS images.

Deploying IPIPGWs has three prerequisites:

Architecture

On a regular Cisco voice gateway, one call leg is a TDM connection on which the call is originated or terminated. The other call leg could be a VoIP call based on any VoIP protocol. With the IPIPGW, a single voice call has two VoIP call legs. The originating call leg is matched on the incoming VoIP dial peer and terminated at the IPIPGW. The second call leg is reoriginated based on the outgoing VoIP dial peer.

Figure 18-1 illustrates the IPIPGW architecture, which is based on the back-to-back user agent (B2BUA), which is SIP, or the back-to-back gateway (B2BGW), which is H.323.

Figure 18-1. IPIPGW Architecture

The IPIPGW implementation leverages Cisco voice gateway architecture. The main difference between the voice gateway and the IPIPGW is that no telephony service provider interface (SPI) or telephony signaling stack exists in case of IPIPGW. The IPIPGW has two IP legs for a given voice call, whereas the TDM-IP gateway has one telephony and one IP leg for a given TDM-IP call.

When a VoIP call arrives at the IPIPGW, it is matched at the configured inbound dial peer. The particular VoIP SPI (such as H.323 or SIP) processes the call and informs the application, which in turn routes the call using the configured outbound dial peer. The two SPIs talk using the application layer for the signaling messages. For capability, media address, and port exchanges, the SPI communicates directly or by using the Call Control API (CCAPI) layer.

Each IP leg has a corresponding Real-Time Transport Protocol (RTP) instance that is associated with it for media flow-through. The media stream that is originating from the IPIPGW carries the IP address and the port number of the IPIPGW.

Note

The only changes in the media stream are the IP address and port number. For media flow around calls, media flows directly between endpoints; therefore, you will not see RTP instances on the IPIPGW.

 

Media-Handling Modes

You can handle the passing of media in two ways:

Figure 18-2 illustrates the media-handling modes that are supported on the IPIPGW.

Figure 18-2. Media Handling Modes

Protocol Support

The IPIPGW supports the following VoIP call combinations:

SIP Networks

For SIP networks, the Cisco IPIPGW functions as a B2BUA. It receives a SIP request, reformulates the request, and then sends it as a new request. The responses that the terminating endpoint sends to the request are also reformulated and sent back in the opposite direction. Therefore, the Cisco IPIPGW can sit between two SIP networks without either party knowing the uniform resource identifier (URI), IP address, or any other information of the other party.

To achieve this, the B2BUA reformulates a request with entirely new From, Via, Contact, Call ID, and Session Description Protocol (SDP) media information. The B2BUA also removes any other SIP header fields that might contain information about the calling party. When the B2BUA returns a response, it also changes the contact and SDP media information from the called party. The modified SDP points to the B2BUA, which then forwards RTP media packets from the called party to the calling party and vice versa. Thus, neither endpoint learns any identifying information about the other party during the session establishment.

H.323 Networks

In H.323 networks, the Cisco IPIPGW also functions as a B2BGW, or a terminator and reoriginator of voice, fax, or video calls. No DSPs are required for calls using the same codec, which provides better quality voice calls because hardly any delay is added for the RTP stream. DSPs are required only if you need to transcode between two codecs, such as G.711ulaw and G.729r8.

Protocol Interworking

Because the Cisco IPIPGW terminates and reoriginates VoIP calls, it can handle different VoIP protocols on each leg. This provides a valuable capability when protocol-disparate networks need to talk to one another. The Cisco Multiservice IPIPGW does protocol interworking between H.323 and SIP for voice and fax calls.

This provides flexibility to customers who are connecting their Cisco CallManager H.323 network to a VoIP service provider who offers SIP services. It also enables customers who want to migrate from H.323-based networks to SIP-based networks. With the media flowing through the gateway, complete network hiding for both signaling and media is achieved. Also, if the enterprise is using one codec, such as G.711ulaw, and the SIP VoIP service provider is using G.729r8, transcoding between these codecs is supported for the protocol interworking scenarios. Supplementary services between H.323 trunks of the Cisco CallManager and SIP service provider are supported. The H.323 trunk needs to configure a media termination point (MTP) so that services such as call hold/resume, call transfer, and so on can be used.

Related

Категории