1. ACLI Configuration Guide
  2. Transcoding
  3. Transcoding Processing Overview

Transcoding Processing Overview

Transcoding processing is viewed in terms of the ingress and egress realms. The ingress realm is where the SDP offer is received by the Oracle® Enterprise Session Border Controller. The egress realm is where the SDP offer is sent, and where the SDP answer is expected to be received from (i.e., the answerer's realm). A call is defined as transcodable if an egress or ingress policy exists for the session and if the session is not subject to media release, as specified in the realm configuration.

To understand the details of transcoding processing, refer to the following diagram. An SDP offer, O0, is received by the Oracle® Enterprise Session Border Controller in the ingress realm. The ingress codec policy is applied here and the SDP offer is transformed into O1. O1 is then passed to and processed by the egress codec policy. This SDP message is then forwarded to the answerer as O2. The answerer replies with A0 to the Oracle® Enterprise Session Border Controller, which is subjected to the egress codec policy again and transformed into A1.

When policy dictates not to transcode the call, the Result SDP sent back to the offerer is based on the common codecs shared between A1 and O1. The Oracle® Enterprise Session Border Controller first constructs the list of codecs that are present in both in O1 and A1. Then, the Oracle® Enterprise Session Border Controller maintains the codec order from A1 for the Result as it is sent to the offerer.

When policy dictates to transcode the call, the top transcodable codec in O1 is used in the ingress realm and the top non-signaling codec in A1 is used in the egress realm.

This illustration shows the ingres and egress flow of call traffic from an offerer to an answerer across the SBC.

Unoffered Codec Reordering

According to RFC 3264, the answerer can add codecs that were not offered to the Answer. The answerer may add new codecs as a means of advertising capabilities. RFC 3264 stipulates that these unoffered codecs must not be used. The RFC does not dictate where in the m= line these codecs can appear and it is valid that they may appear as the most preferred codecs.

In order to simplify the answer processing, the Oracle® Enterprise Session Border Controller moves all unoffered codecs in A0 to the back of the SDP answer before any other answer processing is applied.

Non-transcoded Call

The decision to transcode is based on the top non-signaling codec in A1. If the top A1 codec is present in O1, the call proceeds, non-transcoded. This is the rule for non-signaling codecs (i.e., not RFC 2833 nor FAX).

Transcoded Call

The following two conditions must then be met to transcode the call’s non-signaling media:

  • The top A1 codec is not present in the O1 m= line
  • The top A1 codec was added by the egress policy

If these rule are met, the Oracle® Enterprise Session Border Controller will transcode between the top A1 codec and the top transcodable, non-signaling O1 codec.

Post Processing

If any errors are encountered during the Ingress and Egress policy application, or other violations of RFC3264 occur, the call is rejected. If O2 does not contain any enabled m= lines at the conclusion of the initial call setup, the call is rejected. If O2 does not contain any enabled m= lines at the conclusion of a reINVITE, the reINVITE is rejected and the call reverts back to its previous state.

Voice Transcoding

The following examples use the ingress and egress codec policies listed at the top of each scenario. The examples use changing SDP offers and answers, which contribute to unique results, per example. The effects of the SDP offers and answers are explained in each example.

Voice Scenario 1

The following ingress and egress policies are used for scenario 1.

Ingress Policy Ingress Policy Egress Policy Egress Policy
allow-codecs PCMU GSM allow-codecs G729 GSM G722
add-codecs-on-egress PCMU add-codecs-on-egress G729
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A

Note:

The codec in the ingress policy’s add-codecs-on-egress parameter has no effect in the following examples. Its presence would have an effect if a reINVITE was initiated from egress realm, effectively reversing the roles of the codec policies.
  1. In the following diagram, PCMU and G729 are offered. Ingress policy removes G729 and allows PCMU. The egress policy adds G729 and strips PCMU from offered SDP and forwards it on to the answerer (ptime is also removed because the last codec was removed).

    The SDP answer agreed to use G729 and adds PCMA. The egress policy then strips PCMA from the SDP answer. At this point, the top codec in A1, G729 is checked against O1. Since G729 is not present in O1, it is transcoded to PCMU.

    The PCMU and G729 Offer diagram is described above.
  2. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds G729 and retains ptime from GSM and sends this to the answerer as O2.

    The SDP answer agrees to use G729 and GSM, but prioritizes GSM. The egress policy allows both codecs through, unchanged. Because A1 and O1 both have GSM, it is used for the non-transcoded call. Ptime is copied from A0 to the result.

    The GSM with G729 diagram is described above.
  3. In the following diagram, G729 in the original SDP offer. Because once G729 is removed, no non-signaling are left in O1, thus the call is rejected.
    The SDP with G729 diagram is described above.
  4. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds G729 and retains ptime from O1 and sends this to the answerer as O2.

    The SDP answer states that the answerer wants to use PCMU. This is a violation of the RFC3264. Therefore the call is rejected.

    The SDP with GSM diagram is described above.

    In this example, when the negotiation fails, the Oracle® Enterprise Session Border Controller sends a 500 message to the offerer and a BYE message to the answerer.

  5. In the following diagram, GSM is in the original SDP offer. It is then passed through to O1. Egress policy adds G729 and retains ptime from O1 and sends this to the answerer as O2.

    The SDP answer replies with G722 G729 GSM and PCMU. PCMU is stripped by policy, G722 is moved to the back of the answer because it was not offered. The top A1 codec was not in O1, and was added by egress policy, therefore the call is transcoded between GSM and G729.

    The SDP with GSM diagram is described above.

Voice Scenario 2

The following ingress and egress policies are used for scenario 2.

Ingress Policy Ingress Policy Egress Policy Egress Policy
allow-codecs Video:no PCMU:force * PCMA:force allow-codecs * PCMA:no
add-codecs-on-egress N/A add-codecs-on-egress iLBC G726-16
order-codecs N/A order-codecs G726-16 * PCMU
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
  1. In the following diagram, a video m= line is offered. The ingress policy disables the video m= lines. With no enabled m= lines left, the call is rejected.
    The Video m= line offer diagram is described above.
  2. In the following diagram, G729 and video are offered to the Oracle® Enterprise Session Border Controller. Ingress policy allows G729 and disables the video m= line. The egress policy adds iLBC and G726-16, and then orders the codecs according to the order-codecs parameter. The ptime is maintained between O0 and O2. Both added codecs are allocated dynamic payload types in the order they appear in their m= line. A disabled Video m= line is passed on to the answerer.

    The SDP answer agreed to use iLBC, G729, and adds PCMU, and reorders them as stated. The disabled video m= line is maintained. At this point, the top codec in A1, iLBC is used and transcoded with the top codec in O1, G729.

    The G729 and Video Offer diagram is described above.
  3. In the following diagram, G729 and video are offered to the Oracle® Enterprise Session Border Controller. Ingress policy allows G729 and disables the video m= line. The egress policy adds iLBC and G726-16, and then orders the codecs according to the order-codecs parameter. The ptime is maintained between O0 and O2. Both added codecs are allocated dynamic payload types in the order they appear in their m= line.

    The SDP answer only wants to use PCMU and PCMA. The egress policy removes PCMA and passes only PCMU to the offerer. Because PCMU was in O1 and is now the only codec in A1, it is used, and no transcoding is used between the endpoints.

    The G729 and Video Offer diagram is described above.
  4. In the following diagram, G726-16 and telephone-event are offered to the Oracle® Enterprise Session Border Controller. Ingress policy allows both codecs. The egress policy adds iLBC, and then orders the codecs according to the order-codecs parameter.

    The SDP answer agreed to use all codecs, but reorders them with G726-16 in the top position. Because G726-16 is the top codec in A1, and it is also present in O1, it is used for this call without any transcoding.

    The G726-16 and Telephone-Event Offer diagram is described above.

Voice Scenario 3

Voice scenario 3 involves reINVITEs. The following ingress and egress policies are used for scenario 3.

Ingress Policy Egress Policy
allow-codecs PCMU G729 allow-codecs *
add-codecs-on-egress N/A add-codecs-on-egress PCMA
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
  1. In the following diagram, the answerer sends a reINVITE after a previous transcoding session was established. The original offerer and answerer swap roles. The new offerer rejects the SDP offer and the call reverts to the state negotiated in the original SDP negotiation.
    The reINVITE diagram is described above.

RFC 2833 Transcoding

RFC 2833 defines an RTP payload that functions interchangeably with DTMF Digits, Telephony Tones and Telephony Signals. The Oracle® Enterprise Session Border Controller can monitor audio stream for in-band DTMF tones and then can convert them to data-based telephone-events, as sent in RFC2833 packets. This section explains how the Oracle® Enterprise Session Border Controller transcodes between these RTP-based telephone events and in-band DTMF tones carried by G711. DTMF tones can only be transported in non compressed codecs. The Oracle® Enterprise Session Border Controller supports two DTMFable non-compressed codecs: PCMU (G711µ) and PCMA (G711A).

Note:

The following line is added to SDP whenever telephone-event is added on egress: a=fmtp:101 0-15

The following two scenarios describe when telephone-event to DTMF transcoding takes place:

RFC 2833 Scenario 1

The following ingress and egress policies are used for scenario 1.

Ingress Policy Egress Policy
allow-codecs * telephone-event:no allow-codecs * PCMA:no
add-codecs-on-egress N/A add-codecs-on-egress telephone-event
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
dtmf-in-audio preferred dtmf-in-audio preferred
  1. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-event was not added by the egress policy because the remaining audio codec in O1 was not DTMFable. G729 was the only codec forwarded on to the answerer.

    The SDP answer agreed to use the remaining audio codec, G729. A0 is unaltered by egress policy, and forwarded as the Result to the offerer. Therefore, G729 is used in both the ingress and egress realms, the call does not support RFC 2833, and the call is not transcoded.

    The Telephone Event Offer Response diagram is described above.
  2. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-event was added by the egress policy because the remaining audio codec in O1 was DTMFable. PCMU and telephone-event are then forwarded on to the answerer. Note that the telephone-event payload type is added with the lowest available dynamic type number.
    The Telephone Event Stripped by Ingress Policy diagram is described above.

    This case illustrates when the answerer supports audio and RFC 2833, but the offerer supports audio with inband DTMF. The Oracle® Enterprise Session Border Controller transcodes between RFC2833 in the egress realm to in-band DTMF on the ingress realm.

  3. In the following diagram, telephone event was offered by the offerer but was stripped by ingress policy. telephone-event is added by the egress policy because the remaining audio codec in O1 was DTMFable. PCMU and telephone-event are then forwarded on to the answerer. Note that the telephone-event payload type is added with the lowest available dynamic type number.
    The Telephone Event Offer Stripped by Ingress Policy diagram is described above.

    The SDP answer only agreed to use PCMU. When A0 reaches the egress policy, it is passed along through the Oracle® Enterprise Session Border Controller to the offerer. Because telephone-event was not answered by the answerer and not supported in O1, it can’t be used. Transcoding is therefore not used for this call.

  4. In the following diagram, telephone event was offered by the offerer and was stripped by ingress policy. Since PCMA was also stripped by the egress policy, leaving no non-signaling codecs, the call is rejected. A 500 message is sent back to the offerer.
    The Telephone Event Offer Stripped by Ingress Policy diagram is described above.

RFC 2833 Scenario 2

The following ingress and egress policies are used for RFC2833 scenario 2.

Ingress Policy Egress Policy
allow-codecs * allow-codecs *
add-codecs-on-egress telephone-event add-codecs-on-egress PCMU
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
dtmf-in-audio preferred dtmf-in-audio preferred
  1. In the following diagram, telephone event and PCMU are offered by the offerer. They are both passed to O1, and PCMA is added as it is sent to the answerer. The SDP answer, A0 disables all codecs but PCMU.
    The Telephone Event and PCMU Offer diagram are described above.

    The Oracle® Enterprise Session Border Controller adds telephone-event to the result because it is listed on the ingress policy’s add-codecs-on-egress parameter and present in the offerer’s SDP.

    Note:

    This is the only time the add list of an ingress policy is utilized as a check.

    The result SDP includes PCMU and telephone-event in the ingress realm, which is transcoded to PCMU with in-band DTMF in the egress realm.

  2. In the following diagram, telephone event and PCMU are offered by the offerer. They are both passed to O1, and PCMA is added as it is sent to the answerer. The SDP answer supports all three codecs offered, with PCMA added on top.
    The Telephone Event and PCMU Offer Response diagram is described above.

    The answerer responds with PCMA as the preferred codec in A0. The Oracle® Enterprise Session Border Controller compares A1 to O1 to make the transcoding decision. PCMA is the top codec in A1 and is transcoded to PCMU, the top codec in O1. Also, because telephone-event is supported by both sides of the call, it is passed through without any transcoding necessary.

    This case illustrates when both endpoints are capable of sending and receiving telephone-event. Regardless of whether the audio portion of the call is transcoded, the telephone-event messages are passed through the system untouched, thus not requiring transcoding resources. This is known as telephone-event pass-through.

FAX Transcoding

FAXes are transmitted in a call as either T.30 or T.38 media. T.30 FAX is binary in-band media carried over G.711. The Oracle® Enterprise Session Border Controller (E-SBC) can transcode between T.38 and a faxable codec. The supported faxable codecs are PCMU and PCMA.

T.30 can be transported only in non-compressed codecs. The two non-compressed codecs supported by the E-SBC are PCMU (G711µ) and PCMA (G711A). If a transcoding realm does not support an uncompressed codec, T.30 cannot be supported in that realm. Alternatively, G711FB may be allowed specifically for FAX only.

The E-SBC uses an internal codec called G711FB (G711 - Fall Back) that is an umbrella codec of all FAXable codecs. G711FB will default to PCMU for the purpose of offering a faxable codec. You can re-map G711FB to PCMA by configuring the media-profile for it appropriately. G711FB’s only use is for FAX transcoding.

FAX transcoding is triggered when you configure the add on egress parameter with either T.38 or G711FB. In a FAX scenario, when the codec policy adds either T.38 or G711FB, a new m= line is added to the SDP. When adding T.38, the new m= line specifies the T.38 codec. When adding G711FB, the new m= line specifies PCMU (or alternatively PCMA).

When added, m= lines cannot be deleted in the context of a call. The E-SBC maintains all m= lines between itself and an endpoint throughout the course of call. All m= lines not in use can be disabled by setting their receive port to 0, but they cannot be removed from the SDP.

Defining G711FB

G711 Fall Back (G711FB) is an internal codec that encompasses PCMU and PCMA for carrying fax information in FAXable codecs. You must configure the G711FB codec for either PCMU or PCMA for when the Oracle® Enterprise Session Border Controller inserts a FAXable codec in SDP. G711FB is used only for FAX transcoding scenarios.

To define G711 FB, create a media profile configuration element named g711fb and set the payload-type to 0 or 8.

Codec (supported bit rates) RTP Payload Type Default Ptime (ms) Supported Ptime (ms)
T.38 N/A 30 10, 20, 30
G711FB (64 kbps) 0, 8 30 10, 20, 30

FAX Scenario 1

The following ingress and egress policies are used for this FAX scenario.

Ingress Policy Egress Policy
allow-codecs * allow-codecs T.38:no
add-codecs-on-egress N/A add-codecs-on-egress G711FB
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
  1. In the following diagram, there are three offer-answer exchanges. Initially a PCMU-to-PCMU session is negotiated. Next, a T.38 to PCMU session is negotiated. Finally, the session reverts to non-transcoded PCMU to PCMU state.
    The FAX Example diagram is described above.

FAX Scenario 2

The following ingress and egress policies are used for this FAX scenario.

Ingress Policy Egress Policy
allow-codecs * allow-codecs *
add-codecs-on-egress N/A add-codecs-on-egress G711FB
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
  1. In the following diagram, T.38 is offered to the Oracle® Enterprise Session Border Controller. A second m= line was added to O1 that included a G711FB codec (PCMU).

    The SDP answer agreed to PCMU, but disabled T.38. When the Oracle® Enterprise Session Border Controller forwarded the SDP in A1 to the answerer, it stripped the second m= line. Because A1 rejects T.38 m= line, but accepts the PCMU m= line, FAX transcoding is enabled.

    The T.38 Offer diagram is described above.
  2. In the following diagram, T.38 is offered to the Oracle® Enterprise Session Border Controller. A second m= line was added to O1 that included a G711FB codec (PCMU).

    The SDP answer agreed to PCMU and T.38. Because both O1 and A1 support T.38, the call proceeds without transcoding.

    The T.38 Offer diagram is described above.

FAX Scenario 3

The following ingress and egress policies are used for this FAX scenario.

Ingress Policy Egress Policy
allow-codecs * allow-codecs *
add-codecs-on-egress N/A add-codecs-on-egress PCMU, G729 ,T.38
order-codecs N/A order-codecs N/A
force-ptime disabled force-ptime disabled
packetization-time N/A packetization-time N/A
  1. In the following diagram, PCMU and telephone-event codecs are received by Oracle® Enterprise Session Border Controller .The egress codec policy has PCMU, G729 and T.38 add-codecs-on-egress.
    Since there is a faxable codec in the SDP offer and T.38 in add-on-egress, the non-faxable codec G729 is stripped and T.38 is added to egress offer.

    In the A0 answer the audio m-line is zero indicating disabled and the port for the image m-line is non-zero (20000) so the called party has selected T.38. Hence PCMU in realm A is transcoded to T.38 in realm B.

  2. In the following diagram, PCMU and T38 are received by the Oracle® Enterprise Session Border Controller. The egress codec policy has PCMU, G729, and T.38 add-codecs-on-egress.

    T.38 is present in the O0 offer, and therefore will not be explicitly added by the egress codec policy to the O2 Offer. The logic to remove non-faxable codecs is only invoked when T.38 is added by the add-codecs-on-egress parameter. In this example, T.38 is not added since is already present in SDP. With PCMU and T.38 received, G729 as a non-faxable codec is not removed. Therefore, PCMU, T.38, and G729 are all present in the O2 SDP offer sent to the answerer.

    In the A0 answer, the audio m-line port is 0 indicating that audio is disabled, and the port for the image m-line is nonzero (20000), thus the called party has selected T.38. In the A1 answer the OCSBC send the audio m-line port as 0 indicating that audio is disabled, and the port for the image m-line is nonzero (20000). This set-up results in a non-transcoded T.38 -OCSBC -T.38 fax call.

Transrating

The Oracle® Enterprise Session Border Controller can transrate media as it exits the Oracle® Enterprise Session Border Controller into the network. Transrating is also known as forced packetization time (ptime), and is used to enforce a configured ptime within a realm. Transrating is often desirable when devices in a realm can only accept media with a specific ptime, or to optimize bandwidth.

If this feature is configured, the media portion of a call is transrated regardless of which codecs are ultimately chosen for each realm as long as they are transcodable. This allows realms that have devices that can only use a single packetization interval to interwork with devices that may or may not have the same packetization capabilities.

You must enable force-ptime in the egress codec policy and then specify the packetization time to force. When force ptime is enabled, it implicitly masks all codecs not of the specified packetization time that are listed in that codec policy’s allow codecs and add codecs on egress parameters. For example, if force ptime is enabled with a packetization time of 20 ms, then no G723 codecs (which are only available at 30, 60, and 90 ms) may be active via codec policy in that realm.

Transrating occurs when forced-ptime is enabled and the offered and answered ptimes do not match and the top non-Signaling codec of A1 and top non Signaling codec of O1 are Transcodable.

Note:

Answered ptime A1 does not have to be equal to the ptime inserted into the outgoing offer O2, it just has to be different than the offer the Oracle® Enterprise Session Border Controller received (O1).

Transrating Scenario 1

The following ingress and egress policies are used for this FAX scenario.

Ingress Policy Egress Policy
allow-codecs * allow-codecs *
add-codecs-on-egress N/A add-codecs-on-egress PCMA
order-codecs G723 * order-codecs N/A
force-ptime disabled force-ptime enabled
packetization-time N/A packetization-time 40
  1. In the following diagram, PCMU is offered in the ingress realm with 30ms ptime, and the egress realm is forced to use 40ms ptime. PCMA is added as the top codec for the egress realm.

    The Oracle® Enterprise Session Border Controller enables transcoding between the ingress realm (PCMU) and the egress realm (PCMA) and the ptimes as negotiated are also maintained.

    The Ingress Realm PCMU Offer diagram is described above.
  2. In the following diagram, PCMU is offered in the ingress realm with a ptime of 30ms, and forced to 40 ms in the egress realm by policy.

    The answerer chooses to use PCMU with a 20 ms ptime. Thus the call is not transcoded, but it is transrated from 30ms in the ingress realm to 20ms in the egress realm.

    The Ingress Realm PCMU Offer diagram is described above.
  3. In the following diagram, PCMU and G723 are offered in Realm A. The top codec’s ptime (30ms) is implied as the one for the ingress realm. The Oracle® Enterprise Session Border Controller adds PCMA to the SDP offer with a 40ms ptime.

    The answerer chooses to use PCMU with a 40 ms ptime. Thus the call is transrated from 30ms in the ingress realm to 40ms in the egress realm.

    The Realm A PCMU and G723 Offer diagram is described above.

Reactive Transcoding

When setting up transcoded calls the Oracle® Enterprise Session Border Controller (E-SBC) reserves a Digital Signaling Processor (DSP) resource for the incoming SDP offers that need transcoding. The default behavior is to pre-book the DSP resource and use it when the system's egress policy qualifies the SDP offer for transcoding.

Alternatively, the E-SBC offers a reactive-transcoding option where the DSP resource is reserved after the SDP answer is received. Reactive transcoding is enabled by setting media-manager-config, reactive-transcoding to enabled. The advantage of this process is for every call that comes in the DSPs need not be pre-booked and instead can be dynamically reserved. The ideal situation for this behavior is when only a few calls need transcoding and the network traffic pattern is well known.

The E-SBC does not perform reactive transcoding on all transcoding call flows. When you configure support for the following features, the E-SBC reserves DSP resources:

  • Pooled-transcoding
  • dtmf-in-audio detection
  • 140-Baudot transcode
  • Fax call
  • RTCP generation
  • FAX tone detection
This process diagram contrasts the OCSBC process with and without reactive transcoding enabled.
The figure below illustrates the transcoding process when reactive-transcoding is enabled.
This diagram shows the OCSBC reserving resources when reactive transcoding is enabled.

Note:

The DSPs will be reserved only for the call currently being transcoded. This avoids DSP exhaustion when there are multiple incoming offers.

Reactive Transcoding Examples

Scenario 1: Current Call : Transcoded, New offer: Transcoded

When a new offer is processed, the Oracle® Enterprise Session Border Controller checks if the call is transcoded. Oracle® Enterprise Session Border Controller pre-books DSP resources while processing new a SDP offer. After getting the SDP answer if the Oracle® Enterprise Session Border Controller finds that the call still needs transcoding, it continues to keep the DSP resources.

Reactive Transcoding Example - Currently transcoded call, new SDP offer for another transcoded call.

Scenario 2: Current Call : Transcoded, New offer: Non-Transcoded

When a Re-INVITE offer is processed, the Oracle® Enterprise Session Border Controller checks if the call is already transcoded. Oracle® Enterprise Session Border Controllerpre-books DSP resources during SDP offer of re-invite to avoid failure to grab DSP after SDP answer during DSP exhaustion case. After getting the SDP answer, if the Oracle® Enterprise Session Border Controller finds that the call does not need transcoding any more, it releases the DSP resources.

Reactive Transcoding Example - Currently transcoded call, new SDP offer for non-transcoded call.

Scenario 3: Current Call : Non-Transcoded, New offer: Transcoded

If a Re-INVITE is received when the reactive-transcoding mode is enabled, it will be handled as a regular offer. The DSP resource will only be reserved after receiving the SDP answer, as necessary.

Reactive Transcoding Example - Currently transcoded call, new SDP offer for transcoded call.

Reactive Transcoding Mode Configuration

This procedure is used to configure the Oracle® Enterprise Session Border Controller to dynamically reserve DSPs:

  1. Access the media-manager-config configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#
  2. Type select to begin editing. 
    ORACLE(media-manager-config)# select

ORACLE(media-manager-config)#
  3. reactive-transcoding— Set this parameter to enabled for the SBC to perform reactive transcoding. 
    ORACLE(media-manager-config)#reactive-transcoding enabled
  4. Type done to save your configuration.