Pooled Transcoding

The term pooled transcoding refers to a deployment model for IMS environments involving two or more Oracle Communications Unified Session Managers. The first is an Oracle Communications Unified Session Manager acting as the P-CSCF, and the others are one or more Oracle Communications Unified Session Managers deployed with transcoding capabilities (referred to as T-SBCs). The T-SBC provides transcoding resources—a pool—that the Oracle Communications Unified Session Manager can invoke on-demand.

In the pooled transcoding model, the Oracle Communications Unified Session Manager sits between realms or between user endpoints that require transcoding between their preferred codecs to communicate. This deployment model conserves resources on both the Oracle Communications Unified Session Manager and the T-SBC. While the Oracle Communications Unified Session Manager 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 Oracle Communications Unified Session Manager positioned between an access UE and the IMS core. The Oracle Communications Unified Session Manager 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. If transcoding is required, the Oracle Communications Unified Session Manager invokes T-SBC’s services. Acting as a B2BUA, T-SBC uses information from the P-CSCF’s SIP messaging to transcode between the applicable codecs and then to route SIP signaling back to the P-CSCF on the egress.

When a call comes in, the system creates two ports for the caller and callee realms respectively. When the call needs pooled transcoding, Oracle Communications Unified Session Manager creates four ports on the pooled transcoded realm and two additional ports on the caller realm. All the ports are removed at the end of the call.

For example, 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 previous example, the OCUSM uses four ports on Net192 are for communicating with the transcoding OCUSM. The OCUSM 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: