OLN Lannion/no Wide-band Transcoding WB-AMR (96) <> G722 (9). (Doc ID 2387530.1)

Last updated on AUGUST 23, 2023

Applies to:

Symptoms

Conditional Codec Policy is not taken into account on ingress policy

Customer currently running a POC around preconditions interworking at the interconnect border.

They are interworking a VoLTE environment (AMR, AMR-WB codecs) & a fixed IMS environment (PCMA, G729, G722 codecs).

They are trying to favor G722<>AMR-WB transcoding & (PCMA/G729)<>AMR transcoding combinations, by ordering the codecs in a way that puts at the
first position the most desirable codec.

The interconnect border involves one realm on each side, with the
corresponding codec policies:

On VoLTE side (codecs AMR,AMR-WB are expected):

codec-policy
        name                                    volteSide
        allow-codecs                            * PCMA:no G722:no G729:no
        add-codecs-on-egress                    AMR AMR-WB
        order-codecs                            AMR-WB:(G722|AMR-WB) AMR *
        packetization-time                      20
        force-ptime                             disabled
        dtmf-in-audio                           disabled

On fixed IMS side (codecs PCMA,G729,G722 are expected):

codec-policy
        name                                    fixeside
        allow-codecs                            * AMR-WB:no AMR:no
        add-codecs-on-egress                    PCMA G729 G722
        order-codecs                            G722:(AMR-WB|G722) PCMA G729
*
        packetization-time                      20
        force-ptime                             disabled
        dtmf-in-audio                           disabled

Each call going through the SBC uses both codec-policy (ingress+egress).

Their two requirements:
For Fixed -> VoLTE calls, they wish to have AMR-WB first if G722 was in the
initial offer.
For VoLTE -> Fixed calls, they wish to have G722 first if AMR-WB was in the
initial offer.

They have ended up adding a logical OR in the conditional policy (ex:
G722|AMR-WB), because they got an unwanted side effect on the SDP answers.

As per customer statement, the conditional ordering policy will work OK if it is on the egress realm, and will be
ignored if on the ingress realm side (in other words, the red part below is ignored when executed as an ingress codec-policy).


Is this expected that an ingress codec-policy does not accept conditional statements within order-codecs ?

The fact that ingress policy is not operating fully is generating them an issue for the locally generated 183 SP, for a VoLTE to Fixed IMS
precondition IWF call. The SBC is applying wrong codecs reordering to the offer, and uses the result to build the local 183 SP.

Changes

 According to the config guide, the processing of conditional codec-policies is different for add-codecs-on-egress and order codecs.

 In case of add-codecs-on-egress:

{noformat}

Codecs contained in the condition can be wildcarded. For example,

ORACLE(codec-policy)# add-codecs-on-egress AMR::ONE:(AMR::*)

which can be interpreted as add AMR::ONE if any AMR codec is in the offer after ingress codec policy

processing.

{noformat}



In case of order-codecs the parsing of param is the opposite . Please see the example below:


{noformat}

An example of using order-codecs is:

ORACLE(codec-policy)# order-codecs (PCMU:(PCMU) *)

which can be interpreted as ¿ set the codec order to PCMU followed by the list after ingress codec policy processing

if PCMU is not present. When the system adds a codec, the codec goes to the end of the offered list. This conditional

format may be used to place an added codec at the front of list.


{noformat}


The codec-policy you have provided in the reproduced logs is different from what the customer is working with.

Also we do not apply codec-policy on response, if that`s what you are looking for.

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.