Introduction

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.

Answer Processing and Examples

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.

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.

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.
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.
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.
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.

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.
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.

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

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.
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.
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.
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.

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

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.

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

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.
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.

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.
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 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.
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.

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

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 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.
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 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 and T.38 media. T.30 FAX is binary in-band media carried over G.711. The Oracle® Enterprise Session Border Controller can transcode between T.38 and a faxable codec. The supported faxable codecs are PCMU and PCMA.

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

The Oracle® Enterprise Session Border Controller 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 remap 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).

Once added, m= lines can not be deleted in the context of a call. The Oracle® Enterprise Session Border Controller maintain 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 can not be removed from the SDP.

Defining G711FB

G711 Fall Back (G711FB) is an internal codec that encompasses PCMU and PCMA for carrying fax information FAXable codecs. The G711FB codec must be configured either way for when the Oracle® Enterprise Session Border Controller inserts a FAXable codec in SDP. G711FB is only used 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

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.

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

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.
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.

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

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.
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).

Please refer to Transcodable Codecs for current list of ptimes per codec supported by the DSPs.

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

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.
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.
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.

Transcoding Hardware

A transcoding Network Interface Unit ( NIU) provides the DSP resources that enable transcoding on the Oracle® Enterprise Session Border Controller.

The Acme Packet 6300 and Acme Packet 4600 can accept 1-24 transcoding modules to provide increasing transcoding capacity.

Transcoding Capacity

Transcoding capacity depends on the following:

Codecs used for transcoding
Number of transcoding modules installed in the system. Capacity scales linearly with each extra transcoding module installed.

Transcodable Codecs

The following list shows the transcodable codecs that the Oracle® Enterprise Session Border Controller can add to SDP. These codecs all reflect default media profiles for their given names. Enter codecs in the configuration exactly as shown.

PCMU
PCMA
G729
G729A
iLBC
telephone-event
T.38
G711FB
G726
G726-16
G726-24
G726-32
G726-40
G722
G723
GSM
AMR
AMR-WB
EVRC0
EVRC
EVRC1
EVRCB0
EVRCB
EVRCB1

When creating an override media profile from a previously listed codec, the system ignores case sensitivity. Also, GSM = GSM-FR.

Transcodable Codec Details

The following table lists the supported codecs, bit rates, RTP payload type, default ptime, and supported ptimes.

Codec	Supported Bit Rate (kbps)	RTP Payload Type	Default Ptime (ms)	Supported Ptime (ms)
G.711 PCMU	64	0	20	10, 20, 30, 40, 50, 60
G.711 PCMA	64	8	20	10, 20, 30, 40, 50, 60
G.722	48, 56, 64	9	20	10, 20, 30, 40
G.723.1	5.3, 6.3	4	30	30, 60, 90
G.726	16, 24, 32, 40	2, 96-127	20	10, 20, 30, 40, 50
iLBC	13.33	96-127	20	20, 30, 40, 60
iLBC	15.2	96-127	30	20, 30, 40, 60
G.729/A/B	8	18	20	10, 20, 30, 40, 50, 60, 70, 80, 90
AMR	4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.2, 12.2	96-127	20	20, 40, 60, 80, 100
AMR-WB (G.722.2)	6.6, 8.85, 12.65, 14.25, 15.85, 18.25, 19.85, 23.05, 23.85	96-127	20	20, 40, 60, 80, 100
GSM FR	13	3	20	20
T.38	4.8, 9.6, 14.4	N/A		10, 20, 30

The following table lists the supported codecs, bit rates, RTP payload number, default ptime, and supported ptimes for codecs available only on the Oracle® Enterprise Session Border Controller 4600 and 6300.

Codec	Supported Bit Rate (kbps)	RTP Payload Type	Default Ptime (ms)	Supported Ptime (ms)
EVRC	0.8, 4.0, 8.55	96-127	20	20, 40, 60
EVRC0	0.8, 4.0, 8.55	96-127	20	20
EVRC1	4.0, 8.55	96-127	20	20, 40, 60, 80, 100
EVRCB	0.8, 2.0, 4.0, 8.55	96-127	20	20
EVRCB0	0.8, 2.0, 4.0, 8.55	96-127	20	20
EVRCB1	4.0, 8.55	96-127	20	20, 40, 60, 80, 100
Opus	48	104	20	10, 20, 40, 60, 80, 100
SILK	8, 16	103	20	20, 40, 60, 80, 100

T.38 FAX Support

This release supports T.38 FAX relay (Version 0) conversion to T.30 over G.711 and supports FAX modulation schemes up to 14400 kbps V.17. The initial release does not support V.34 modulation.

Software-based transcoding

The Oracle® Enterprise Session Border Controller supports media transcoding on virtual platforms. Refer to the Transcoding Support section of the Release Notes for the list of codecs which may be transcoded with software-based transcoding resources.

Transcoding is the process of converting voice audio streams from one encoding format (codec) to another. In addition to conversion between codecs, the Oracle® Enterprise Session Border Controller can also reframe compressed audio streams from one packet size to another (e.g. 10ms G.729 reframed to 30ms G.729) according to packetization times specified in session establishment. The Oracle® Enterprise Session Border Controller may then convert between any supported codecs and frame size combination to another supported codec and frame size combination.

Software-based transcoding is configured identically to hardware-based transcoding, and is invoked when codec policies are configured but no transcoding hardware is recognized in the system.

Software-based transcoding alarms and traps

SNMP Traps

The apSysMgmtGroupTrap trap is sent with the MIB OID apSysXCodeG729Capacity to alert you of high G.729 Royalty codec usage. This MIB object is defined in ap-smgmt.mib. It is sent when utilization rises above 95% of licensed capacity. It is cleared when utilization falls below 80% of licensed capacity. The MIB object appears as:

apSysXCodeG729Capacity OBJECT-TYPE
        SYNTAX          SysMgmtPercentage
        MAX-ACCESS      read-only
        STATUS          current
        DESCRIPTION	
                "The percentage of licensed G729 transcoding utilization"
        ::= { apSysMgmtMIBGeneralObjects 35 }

Alarms

The G729 transcoding utilization alarm is triggered when utilization rises above 95% of licensed capacity. It is cleared when utilization falls below 80% of licensed capacity. The alarm appears as follows on the ACLI:

ID      Task      Severity      First Occurred          Last Occurred
131159  527739792       6       2011-10-11 10:11:49     2011-10-11 10:11:49
Count   Description
1       G729 Transcoding capacity at  97 (over threshold of 95)

Debugging log files

The log.media log file records host based transcoding events based upon logging level.

Opus Codec Transcoding Support

Opus is an audio codec developed by the IETF that supports constant and variable bitrate encoding from 6 kbit/s to 510 kbit/s and sampling rates from 8 kHz (with 4 kHz bandwidth) to 48 kHz (with 20 kHz bandwidth, where the entire hearing range of the human auditory system can be reproduced). It incorporates technology from both Skype’s speech-oriented SILK codec and Xiph.Org’s low-latency CELT codec. This feature adds the Opus codec as well as support for transrating, transcoding, and pooled transcoding.

Opus can be adjusted seamlessly between high and low bit rates, and transitions internally between linear predictive coding at lower bit rates and transform coding at higher bit rates (as well as a hybrid for a short overlap). Opus has a very low algorithmic delay (26.5 ms by default), which is a necessity for use as part of a low audio latency communication link, which can permit natural conversation, networked music performances, or lip sync at live events. Opus permits trading-off quality or bit rate to achieve an even smaller algorithmic delay, down to 5 ms. Its delay is very low compared to well over 100 ms for popular music formats such as MP3, Ogg Vorbis, and HE-AAC; yet Opus performs very competitively with these formats in terms of quality across bit rates.

Opus Supported Options

Required SDP Parameters:

rate — Specifies the sampling frequency. This parameter is mapped to the RTP clock rate in “a=rtpmap”. The range is limited to and must be 48000 Hz.

Optional SDP Parameters:

maxplaybackrate — Specifies the maximum output sampling rate in Hz that the receiver is capable of rendering. The range is 8 kHz to 48 kHz; common values are 8, 12, 16, 24, and 48 kHz.
sprop-maxcapturerate — Specifies the maximum input sampling rate in Hz that the sender is likely to produce. The Vocallo OCT2224 DSP currently supports only 8000 and 16000 Hz for transcoding. The range is 8 kHz to 48 kHz; common values are 8, 12, 16, 24, and 48 kHz.
ptime — Specifies the packetization interval in milliseconds. The DSP supports packetization intervals of 10, 20, 40, 60, 80, and 100 ms. This parameter is mapped to “a=ptime” in the SDP. Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120. The default is 20 ms.
maxptime — Specifies the maximum packetization interval allowed. The default is 100 ms.
minptime — Specifies the minimum packetization interval allowed. The default is 20 ms.
maxaveragebitrate — Specifies the maximum average rate of bits received for a session in bits per second. Although the range is 6000 to 51000, only bit rates of 6000 to 30000 bps are transcodable by the DSP. A media profile configured with a value for maxaveragebitrate greater than 30000 is not transcodable and cannot be added on egress in the codec-policy element.
stereo — Specifies whether the decoder receives stereo or mono signals. The possible values are 0 (mono) and 1 (stereo). The default is 0.
sprop-stereo — Specifies whether the sender is likely to produce stereo audio. The possible values are 0 (mono) and 1 (stereo). The default is 0.
cbr — Specifies whether the decoder uses a constant or a variable bit rate. The possible values are 0 (variable bit rate) and 1 (constant bit rate). The default is 0.
useinbandfec — Specifies whether the Opus decoder supports Forward Error Correction (FEC). The possible values are 0 (no) and 1 (yes). The default is 1.
usedtx — Specifies whether the Opus decoder utilizes Discontinuous Transmission (DTX). The possible values are 0 (no) and 1 (yes). The default is 0.

The payload type is dynamic for this codec.

Sample media-profile configuration for adding Opus

Parameter	Value
name	opus
subname	WB
media-type	audio
payload-type	104
transport	RTP/AVP
clock-rate	48000
req-bandwidth	0
frames-per-packet	0
parameters	maxplaybackrate=16000 sprop-maxcapturerate=16000 usedtx=0
average-rate-limit	5000
peak-rate-limit	0
max-burst-size	0
sdp-rate-limit-headroom	0
sdp-bandwidth	enabled
police-rate	0
standard-pkt-rate	0

Monitoring and Debugging

CLI commands:

The show sipd codecs command is modified to add opus Count.

SNMP:

New SNMP OID apSysXCodeOPUSCapacity is added to transcoding utilization statistics as reported in the apSysMgmtGroupTrap. When utilization falls below 80%, the apSysMgmtGroupClearTrap is sent.

Opus realm statistic apCodecRealmCountOPUS is added to apCodecRealmStatsEntry.

Alarms:

Opus Transcoding Capacity Threshold Alarm — A warning level alarm that doesn't affect health is triggered when the Opus transcoding utilization exceeds 95% of capacity. The alarm is cleared when the Opus transcoding utilization falls below 80% of capacity.

SILK Codec Transcoding Support

SILK is an audio codec developed by Skype Limited that supports bit rates from 6 kbit/s to 40 kbit/s and sampling rates of 8, 12, 16, or 24 kHz. It can also use a low algorithmic delay of 25 ms (20 ms frame size + 5 ms look-ahead). This feature adds the SILK codec as well as support for transrating, transcoding, and pooled transcoding.

SILK Supported Options

Required SDP Parameters:

rate — Specifies the sampling frequency. SILK supports four different audio bandwidths – narrowband at 8 kHz, mediumband at 12 kHz, wideband at 16 kHz, and super wideband at 24 kHz. This parameter is mapped to the RTP clock rate in “a=rtpmap”. The DSP only supports audio sampling rates of 8 kHz and 16 kHz for transcoding; the 12 kHz and 24 kHz bandwidths are not transcodable.

Optional SDP Parameters:

ptime — Specifies the packetization interval in milliseconds. The DSP supports packetization intervals of 20, 40, 60, 80, and 100 ms. This parameter is mapped to “a=ptime” in the SDP. The default is 20 ms.
maxptime — Specifies the maximum packetization interval in milliseconds. The default is 100 ms.
minptime — Specifies the minimum packetization interval in milliseconds. The default is 20 ms.
maxaveragebitrate — Specifies the maximum average rate of bits received for a session in bits per second. Bit rates of 5000 to 30000 bps are transcodable by the DSP.
usedtx — Specifies whether the SILK decoder utilizes Discontinuous Transmission (DTX). The possible values are 0 (no) and 1 (yes). The default is 0.

The payload type is dynamic for this codec.

Sample media-profile configuration for adding SILK

Parameter	Value
name	SILK
subname	wideband
media-type	audio
payload-type	103
transport	RTP/AVP
clock-rate	16000
req-bandwidth	0
frames-per-packet	0
parameters	N/A
average-rate-limit	5000
peak-rate-limit	0
max-burst-size	0
sdp-rate-limit-headroom	0
sdp-bandwidth	enabled
police-rate	0
standard-pkt-rate	0

Monitoring and Debugging

CLI commands:

The show sipd codecs command is modified to add SILK Count.

SNMP:

New SNMP OID apSysXCodeSILKWBCapacity is added to transcoding utilization statistics as reported in the apSysMgmtGroupTrap. When utilization falls below 80%, the apSysMgmtGroupClearTrap is sent.

SILK realm statistic apCodecRealmCountSILK is added to the apCodecRealmStatsEntry table located in the ap-tc.mib.

Alarms:

SILK Transcoding Capacity Threshold Alarm — A warning level alarm that doesn't affect health is triggered when the SILK transcoding utilization exceeds 95% of capacity. The alarm is cleared when the SILK transcoding utilization falls below 80% of capacity.

Comfort Noise Transcoding

The Comfort Noise (CN) codec provides a means of encoding periods of silence that occur in an audio stream into a low-level sound that confirms to the listener that the call remains active. In a scenario where the endpoint does not support CN packets during periods of silence, the listener might think that the phone call disconnected. To avoid such a scenario, you can enable the Oracle® Enterprise Session Border Controller (E-SBC) to transcode the CN packet into in-band RTP packets of the voice codec resulting in low-level sound during silences in the audio stream.

Without CN transcoding enabled, the E-SBC forwards all of the CN packets through to the endpoint on ingress and back out again on egress. Also, without CN transcoding enabled, the E-SBC passes through all of the thousands of in-band RTP packets that make up the silences when the endpoint does not support CN. Passing thousands of RTP packets can use a large amount of bandwidth. To save bandwidth in scenarios where one endpoint supports CN and the other endpoint does not, you can set the codec policy to transcode a CN packet into in-band audio RTP packets containing silence. Such transcoding results in a lower transmission rate of RTP packets because the system sends only one CN packet on egress rather than the thousands of RTP packets that would otherwise pass through between ingress and egress.

To configure the E-SBC to transcode the CN codec, you must add "CN" to the add-codecs-on-egress list in the codec-policy configuration.

For transcoding comfort noise:

The side of the call that does not support CN, must use an audio codec that the SBC supports for transcoding. See "Transcodable Codecs."
The side of the call that supports CN, must use an audio codec that the SBC supports as interoperable with CN. Interoperable codecs: (non-signalling codecs) PCMA, PCMU, and G.726.

Be aware that enabling CN transcoding can generate periods when no RTP packets flow on the side of the call that sends and receives CN packets. Depending on the values set in the following guard timer parameters, the system might detect no flow and drop the call.

flow-time-limit
initial-guard-timer
subsq-guard-timer
tcp-flow-time-limit
tcp-initial-guard-timer
tcp-subsq-guard-timer

Setting the value for a guard timer parameter to zero disables the parameter. When you set the parameters to zero, the system does not terminate any calls due to lack of RTP packets. Set the guard timers in the media-manager-config object.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#

Supported and Unsupported Platforms and Behavior

Comfort Noise transcoding supports:

the Acme Packet 1100, Acme Packet 3900, Acme Packet 4600, and the Acme Packet 6300.
simultaneous transcoding of comfort noise and telephone event (RFC 2833) to and from in-band DTMF.
using either the comfort-noise-generate SPL or comfort noise transcoding. The system cannot support both methods at the same time.
High Availability (HA) as currently implemented, regarding the configuration and media flows.

Comfort Noise transcoding does not support:

the Acme Packet 6100, Server Edition, and VMWare.
scenarios involving H.323 call signaling and IWF (SIP<->H.323).
hairpin scenarios.
dynamically defined payload types.

Troubleshooting

Inspect the SDP m= and a= lines for correct modifications as a result of the codec policy.
When you enable SIP debug, the sipmsg.log shows "CN-XCODE-GEN-Enabled" for the flow that you enabled to generate CN.

System Behavior Without Comfort Noise Transcoding

The following scenarios describe how the Oracle® Enterprise Session Border Controller (E-SBC) handles Comfort Noise (CN) packets without transcoding enabled.

Both sides offer and answer support for CN

CN packets pass through the E-SBC from the Offerer to the Answerer and from the Answerer to the Offerer.

Neither side offers or answers support for CN

Any silence in the audio stream passes through the E-SBC in the RTP audio packets.

One side supports CN, and the other side does not

The Offerer does not send CN packets because the Answerer advertises no support for CN. Any silence in the audio stream passes through the E-SBC in the RTP audio packets.

System Behavior With Comfort Noise Transcoding

The following scenarios show how the Oracle® Enterprise Session Border Controller (E-SBC) handles Comfort Noise (CN) packets with transcoding enabled.

General Behavior in the Scenarios

When the SDP produced by the ingress codec-policy O¹ contains an audio codec that interoperates with CN (PCMA, PCMU, and G.726), and the egress codec-policy allows the interoperable codec and is configured to add CN, the E-SBC adds the default payload type of 13 to the SDP m= line.

When the SDP produced by the ingress codec-policy O¹ does not contain a codec that interoperates with CN, and the egress codec-policy is configured to add an interoperable audio codec plus the CN codec, the E-SBC adds the default payload type of 13 to the SDP m= line.

When the E-SBC adds the CN codec, the system adds the following default a= line to the SDP:

a=rtpmap:13 CN/8000

For more information about the concepts and terms used in the scenarios, see "Transcoding Processing Overview."

Comfort Noise Transcoded Scenario

In a typical scenario with CN transcoding enabled, the E-SBC transcodes the ingress audio codec for the media stream to PCMA. The DSP detects silence in the media stream from the Offerer, translates the silence into a CN packet, and sends the packet to the Answerer. The Answerer sends a CN packet to the DSP, which translates the packet into silence in the media stream and sends the packet to the Offerer. The result is silence on egress.

Ingress codec policy	Setting	Egress codec policy	Setting
allow codecs	*	allow codecs	*
add codecs on egress	N/A	add codecs on egress	PCMA CN
order codecs	N/A	order codecs	N/A

The comfort noise transcoded call flow is described below.

The side of the call that does not support CN, must use an audio codec that the E-SBC supports as transcodable, represented by "x" in the call flow.

The side of the call that supports CN, must use an audio codec that the E-SBC supports as interoperable with CN, represented by PCMA in the call flow.

Audio Codec Not Transcoded - Comfort Noise Codec Transcoded Scenario

In the following scenario, the ingress codec policy and the egress codec policy both allow all offered codecs. The setting for add-codecs-on-egress is CN.

The Offerer sends an offer O° to the E-SBC with an SDP m-line for an audio codec PCMU, but with no CN signaling codec
The codec-policy for the ingress realm allows the audio codec, PCMU, and outputs O¹ which contains PCMU.
The E-SBC egress codec-policy takes O¹ as input and adds CN after checking that at least one of the audio codecs in O¹ interoperates with CN, resulting in PCMU and CN in output O².
The Answerer responds with the answer in Aº containing the PCMU audio codec and the signaling codec CN, indicating the Answerer supports comfort noise. The egress codec-policy produces answer A¹ with no changes.
The E-SBC removes CN from A¹ because it was not offered by the Offerer. The result contains only the audio codec PCMU.

Even with CN transcoding enabled, the E-SBC does not transcode the audio codec (PCMU). The E-SBC transcodes silence detection and generation, as well as CN packet detection and generation.

Ingress codec policy	Setting	Egress codec policy	Setting
allow codecs	*	allow codecs	*
add codecs on egress	N/A	add codecs on egress	CN
order codecs	N/A	order codecs	N/A

The Audio Codec not Transcoded call flow is described above.

Comfort Noise and Telephone Event Codecs Both Transcoded Scenario

In the following scenario, the E-SBC transcodes both Comfort Noise (CN) and telephone event codecs.

The Offerer sends an offer (O°) with an SDP m-line for an audio codec PCMU to the E-SBC, and includes both CN and telephone-event signaling codecs.
The codec-policy for the ingress realm allows all codecs and outputs O¹. The E-SBC egress codec-policy takes O¹ as input, allows all codecs, and produces output O².
The Answerer responds with the answer in A° containing the PCMU audio codec. The egress codec-policy produces answer A¹ with no changes.
The E-SBC applies the add-codecs-on-egress parameter from the ingress codec-policy to add CN and telephone-event to A¹. The result contains the audio codec PCMU and the CN and telephone-event signaling codecs because the E-SBC excepts signalling codecs from the rule that the system can apply the add-codecs-on-egress parameter only by the egress codec policy.

Even with CN transcoding enabled, the E-SBC does not transcode the audio codec (PCMU). The E-SBC transcodes silence detection and generation, as well as CN packet detection and generation. The E-SBC transcodes telephone-events to in-band DTMF audio.

Ingress codec policy	Settings	Egress codec policy	Settings
allow codecs	*	allow codecs	*
add codecs on egress	CN telephone event	add codecs on egress	N/A
order codecs	N/A	order codecs	N/A
dtmf-in-audio	preferred	dtmf-in-audio	preferred

The Comfort Noise and Telephone Event Transcoded call flow is described above.