The SDP Comparison feature updates charging information with the OCS when the media streams of a session have changed.
Details
Feature script name |
SDPComparison |
---|---|
Applicable contexts |
SIP service |
SAS Support |
No |
Prerequisite features |
SDP Monitor |
Feature execution points |
|
Behaviour
This feature tracks changes in SDPs used to negotiate media streams, and triggers credit re-authorization if material changes have occurred. Materialness is determined by classifying the codec specified in the SDP into 'equivalence classes' (see Configuration).
If the difference between the previous and newly negotiated SDP is material from a rating condition perspective, then the feature will perform a client-initiated credit re-authorization towards the Online Charging System (OCS). The OCS will be notified that the reason is due to rating conditions changing. While the re-authorization is in progress, the outgoing message is suspended. On successful response from the OCS, the outbound message processing is resumed.
If the difference between the previous and newly negotiated SDP is immaterial, then no credit re-authorization will be performed. On session refresh, where the new SDP matches the previously negotiated SDP, no credit re-authorization will be performed.
If a codec is not mapped to an equivalence class, it will trigger a re-authorization when compared to any codec which does belong to a class. Two codecs, neither of which are mapped to a class, are consided equivalent and will not trigger a re-authorization. Another way to think of this is to consider that all codecs not specifically mapped are essentially mapped to their own class.
The following diagram gives some examples:
See SDP Comparison for an overview of the process
Session state inputs and outputs
Outputs
Name | Type | Format | Description |
---|---|---|---|
WriteCdrOnSDPChange |
boolean |
Indicates that a meaningful SDP change occurred on a monitored leg |
Written when an SDP change has been accepted by the other party. Used by the Interim CDR feature. |
Mappers
This feature uses two mappers:
-
The first is used to map an SDP match model to an SDP match model that has been adapted to contain code equivalence lookups. The default implementation is SdpMatchModelToSdpCcrMatchModelMapper
// a mapper that takes a {{SDPMatchModel}} and generates a {{SDPMatchModel}}. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), matchModel.getClass(), SdpMatchModel.class, mappingPoint);
-
The second mapper takes a DiffModel representing the total differences of two SDP and filters it to only show those differences relative to charging. The default implementation is SdpDiffToSdpCcrDiffMapper
// a mapper that takes a {{SDPDiffModel}} and generates a {{SDPDiffModel}}. final Mapper<SentinelSipSessionState> mapper = getMapperLibrary().findMapper( getSessionState().getSentinelSelectionKey(), arg.getClass(), SdpDiffModel.class, mappingPoint);
Configuration
The default configuration recognizes three equivalence classes - Audio8KHzSingleChannel, Audio16KHzSingleChannel, and Video90KHzSingleChannel. The codecs mapping to each class are as follows:
Equivalence Class |
EncodingName/ClockRate/Channels |
---|---|
Audio8KHzSingleChannel |
G726-40/8000/1 |
Audio16KHzSingleChannel |
DVI4/16000/1 |
Video90KHzSingleChannel |
MPV/90000/1 |
See SDP Comparison for Rating Condition Change Determination for details of configuring the SDP comparison.