OLN Lannion/no Wide-band Transcoding WB-AMR (96) <> G722 (9).
(Doc ID 2387530.1)
Last updated on APRIL 30, 2018
Applies to:Acme Packet 6300 - Version S-Cz7.4.0 and later
Information in this document applies to any platform.
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):
allow-codecs * PCMA:no G722:no G729:no
add-codecs-on-egress AMR AMR-WB
order-codecs AMR-WB:(G722|AMR-WB) AMR *
On fixed IMS side (codecs PCMA,G729,G722 are expected):
allow-codecs * AMR-WB:no AMR:no
add-codecs-on-egress PCMA G729 G722
order-codecs G722:(AMR-WB|G722) PCMA G729
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
For VoLTE -> Fixed calls, they wish to have G722 first if AMR-WB was in the
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.
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:
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
In case of order-codecs the parsing of param is the opposite . Please see the example below:
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.
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.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!