The Sequential Forked SDP Mediation Feature is used to mediate 183 and 2xx messages into UPDATE’s if multiple 183 messages with SDP content have been received due to a sequential fork.

The first 183 is sent through unchanged. When a subsequent 183 message or 2xx with SDP is received the feature will transform this into an UPDATE to be sent upstream. If a 2xx with SDP is mediated to an UPDATE, a 2xx without SDP is sent to the upstream party once the UPDATE has been responded to by the upstream party.

The one change that is made to the SDP is the session version number in the origin line, the feature ensures this value is always bigger than the previously sent version number if the SDP has changed.

The feature also runs on mid session messages such as a re-INVITE from downstream to ensure that the upstream party always receives SDP origin session version numbers that are bigger than have been previously sent if the SDP has changed.

If while an unreliable 183 is being mediated, a 2xx with SDP is received then the 2xx with SDP is cached until the UPDATE triggered by unreliable 183 is responded to and the 2xx is then mediated.

The Feature configuration allows users to change the behaviour of the feature. The default setting is ALLOWS_UPDATE, this means the feature will look at the allow header of the INVITE message to determine whether or not the UE supports UPDATE messages. If there is no UPDATE value present then the messages will simply be passed on, but if the INVITE did contain UPDATE in its allow list then any subsequent 183’s and 2xx with SDP will be changed into UPDATE messages. The other values of this config override the allow header, if set to ON then the feature will ignore the allow list and always behave as if the UE supports UPDATE messages. If OFF then the feature will not change 183’s or 2xx’s to UPDATEs.


Feature script name


Applicable contexts

SIP service

SAS Support


Prerequisite features


Feature execution points


SipAccess_PartyResponse SipMidSession_PartyRequest SipMidSession_PartyResponse

Session state inputs and outputs


Name Type Format Description Behaviour if null/invalid



selection key
for example, <platform>::::

For selecting configuration data

Increment InputParameterErrors,
common cleanup actions

Feature responses

Response Reason


No feature configuration could be loaded


Feature has finished

Feature configuration

Parameter Type Description



Determines behaviour of feature, valid value are ON, OFF, and ALLOWS_UPDATE


Name Description


Incremented when the UE indicates that is supports UPDATE messages


Incremented when the UE indicates no support for UPDATE messages


Incremented when the feature modifies the outgoing SDP


Incremented when the feature changes a 183 message into an UPDATE

Example Flow

sequential update preconditions

Previous page Next page
Sentinel Express Version 4.1