Implementation Details

From the Oracle Communications Unified Session Manager (P-CSCF) perspective, the T-SBC is represented as a transcoding agent whose services the P-CSCF can invoke when offer-answer exchanges reveal transcoding is required. Once that determination is made, the P-CSCF initiates communication with the T-SBC. The P-CSCF uses its public SIP interface and a corresponding realm reserved for communication with a T-SBC, which is configured as a transcoding agent on the P-CSCF. Multiple transcoding agents can be configured, and can be IP addresses, session agents, or session agent groups (SAGs).

If there is more than one transcoding agent for the P-CSCF to choose from, the P-CSCF bases its selection on the order in which the transcoding agents were entered in the list. When conditions call for it, the P-CSCF will try each transcoding agent listed one by one until it:

• Receives a 2xx response from a transcoding agent,
• The list is exhausted, or
• The original transaction times out.

If the transcoding agents are session agents with hostnames, the P-CSCF uses DNS to resolve the hostnames and then tries the hosts in order. In the case when transcoding agents are SAGs, the P-CSCF selects the session agent according to the selection strategy configured for the SAG. The P-CSCF will recurse through all members of the SAG when SAG recursing is enabled. Whenever session agents and SAGs do not have ports or transport protocols specified, the defaults are 5060 and UDP respectively.

Once it identifies a transcoding agent, the P-CSCF sends an INVITE to which the transcoding agent—the T-SBC—responds with a 2xx message. Configuring the P-CSCFs as a session agent and disabling dialog transparency (in global SIP configuration) on the T-SBC allows it to accept SIP messages from the P-CSCF. Then the T-SBC acts as a B2BUA, using the information received in the P-CSCF’s INVITEs to invoke transcoding and to route SIP signaling back to the P-CSCF on the egress.