Leg SDP Mediation

Feature execution scripts are found on the [PLATFORM_OPERATOR_NAME]_FeatureExecutionScriptTable profile table. The actual value of PLATFORM_OPERATOR_NAME depends on your deployment, but is often set to Metaswitch.

Execution scripts should be checked, and any instance of run SequentialForkedSDPMediation should be replaced with run LegSDPMediation.

SequentialForkedSDPMediation feature configuration is found on the SequentialForkedSDPMediationConfigProfileTable profile table. There is only a single attribute on this table: Mediate183ToUpdate.

The LegSDPMediation feature is configured on the LegSDPMediationConfigProfileTable. This table has different attributes, but can be configured to match the behaviour of the old feature according to the following mapping:

Initially, the feature monitors messages that are sent and received on the upstream leg of the call. If it sees an SDP bearing reliable provisional response being sent upstream, it prepares itself to mediate further SDP negotiations. If a subsequent SDP bearing 18x or 2xx response is seen, mediation behaviour is triggered.

When it decides to mediate, the feature will first suppress forwarding of the 18x or 2xx response upstream. In place of the response, it will generate an UPDATE request on the upstream leg. The UPDATE will contain the SDP from the original response, but the origin session and version updated to be consistent with the previous SDP sent on the upstream leg.

If a 2xx response to the UPDATE is received from upstream:

If a 491 response to the UPDATE is received from upstream, the feature will attempt to retry the UPDATE after a short delay. Only one retry will be attempted and if it is also rejected, the call will be terminated.

Any other error response for the UPDATE will end the call.

As the UPDATE sent upstream is considered a new SDP offer, the response may contain new modifications to the SDP that need to be sent downstream. This is particularly likely if the SDP negotiations include preconditions.

If this is the case, after handling any required PRACK exchange, the feature will generate a new UPDATE request on the downstream leg containing the updated SDP from upstream.

As with the original UPDATE, the feature will retry the UPDATE once if it receives a 491 response, and end the call if it receives any other error response.

The SDP in the UPDATE response from downstream may also be modified. The feature will continue alternating between new upstream and downstream UPDATE requests until both sides of the call are in agreement on the SDP.

If the session is modified mid-call with a new SDP in an UPDATE or re-INVITE request, the feature will ensure the origin session and version are updated to be consistent with previous SDP.

When using Sentinel VoLTE, origin session and version information will also be handled appropriately during SRVCC handover.

There are two types of forking to be aware of: parallel and sequential.

Sequential forking is where the downstream leg is replaced by Sentinel during call setup. A typical example of this would be call diversion, when the target of the call is changed. This is the main use case for this feature, so that the different SDP negotiations on each downstream leg do not require forking the upstream leg.

Parallel forking is where multiple downstream legs are being used simultaneously. An example of this could be where the called party has multiple devices that we want to alert simultaneously. In this case, multiple upstream legs are required as the feature will not attempt to mediate SDP negotiations between the parallel forks. However, each downstream parallel fork could still be sequentially replaced during call setup, in which case the feature will mediate SDP negotiations on the affected fork. This can work simultaneously and independently on each parallel fork.

Forced mediation is a service provided by this feature that may be invoked by other features when they want to force SDP to be re-negotiated on an upstream leg. Other features invoke this service by adding the name of the relevant SIP leg to the ForceMediationLegs field in session state.

When this feature sees an entry in the ForceMediationLegs field matching a current upstream leg, it will generate an UPDATE request on that leg containing the committed SDP from the linked downstream leg. From there the feature will proceed with mediation as if it had seen a reliable provisional response from the downstream leg, excluding the need to generate a PRACK after the upstream UPDATE is accepted.