Pooled Transcoding

Pooled transcoding refers to a deployment model involving two or more Oracle Communications Session Border Controllers (OCSBC). The first OCSBC is an access SBC (referred to as an A-SBC) acting as the P-CSCF, and the others are one or more OCSBCs equipped with transcoding hardware (referred to as a T-SBC). The T-SBC provides transcoding resources—a pool—that the A-SBC can invoke on-demand.

In the pooled transcoding model, the A-SBC sits between realms or between user endpoints that require transcoding between their preferred codecs. This deployment model conserves resources on both the A-SBC and the T-SBC. While the A-SBC serves as the access function with encryption support, the T-SBC supports transcoding in a tunneling gateway (TG) configuration to meet high-density transcoding requirements.

The following diagram shows an A-SBC positioned between an access UE and the IMS core. The A-SBC compares SDP offers and answers from the elements it sits between, and uses the results to determine whether or not a given session requires transcoding. When a session requires transcoding, the A-SBC invokes the services of the T-SBC. Acting as a B2BUA, the T-SBC uses information from the A-SBC's SIP message to transcode the applicable codecs and then to route SIP signaling back to the A-SBC on the egress.

Figure 18-16 Pooled Transcoding within IMS

When a call comes in, the system temporarily creates two ports for the caller and callee realms respectively. When the call requires pooled transcoding, the OCSBC creates four ports on the pooled transcoding realm and two additional ports on the caller realm. The system removes the added ports at the end of the call.

The following example shows the ports before, during, and after for a call between the realms net172 (Offer) and net145 (Answer):

Before pooled transcoding	During pooled transcoding	After pooled transcoding
Net172 -> 2 Ports Net145 -> 2 Ports Net192 (Transcoding Realm) -> 0 Ports	Net172 -> 4 Ports Net145 -> 2 Ports Net192 (Transcoding Realm) -> 4 Ports	Net172 -> 2 Ports Net145 -> 2 Ports Net192 (Transcoding Realm) -> 0 Ports

In the preceding example, the OCSBC uses four ports on Net192 for communicating with the transcoding OCSBC. The OCSBC uses the two newly created ports on Net172 for RTP communication, while the original two ports are not used.

The following diagram shows what a call flow between entities in such a deployment model looks like:

Figure 18-17 Setting Up Pooled Transocoding

Note:

The A-SBC and the T-SBC do not need to be on the same version of the hardware and the software.