Sentinel VoLTE may need to manipulate SDP (Session Description Protocol — RFC 4566) content in SIP message bodies to resolve conflicts. This section explains why SDP conflict management is required in some cases, and how it is implemented in Sentinel VoLTE.
SDP conflict management overview
The Sentinel VoLTE SCC-AS may detect SDP conflicts when forwarding SDP between a pair of legs on a session.
This capability is currently only enabled in access transfer features.
Other features may also access it through the sentinel-sip-spi API,
see Using SDP conflict management in a feature below.
Conflicts arise when there is an existing media session established, and the SCC-AS receives an SDP offer from another source, that must replace the existing media.
The new SDP offer must use the correct session ID and version, as well as having the same number of media (m=) lines that the previous offer had, otherwise the new offer will be rejected.
If the new offer comes from a different entity to the previous offer, then there will almost certainly be a conflict.
This situation occurs in many access transfer scenarios.
The conflict management system is defined in terms of source and destination legs:
-
The destination leg is the established leg between the SCC-AS and another entity, typically a UE. A previous SDP offer has been sent on this leg, so all subsequent offers must follow the same sequence of session ID and version, as well as matching the previous number of media streams.
-
The source leg is a new leg that the SCC-AS has received an offer on. This offer is intended to be sent out on the destination leg, after appropriate changes to the SDP.
When a feature detects that SDP conflict management is required, it sets up an SDP rewriting association between the source and destination legs. Classification of source and destination is up to the feature, but for access transfer cases, "source" means the new access leg, and "destination" means the remote leg.
When the SDP association is created, Sentinel VoLTE determines a set of transformations that apply the appropriate changes to the SDP, based on the previous and new SDP offers. The possible types of transformations are described in SDP conflict types below. From this point, for the remainder of the session, SDP rewriting is performed in both directions automatically, by the SDPRewriter system feature.
Access transfer example
When performing access transfer, it is sometimes necessary for the SCC-AS to send a new SDP offer so that the remote party can handle the new media streams, enabling session continuity. The SCC-AS must ensure that any new SDP offer is compatible with previous SDP offers sent to the remote party. If not, the remote party UE will reject the new offer, and the access transfer will fail.
The figure below shows an example call between UEs A and B, with the call anchored in the originating SCC-AS. UE-A initially requests audio and video streams. For brevity assume both streams are accepted by UE-B (SDP answer not shown).
UE-A moves out of coverage range, triggering a PS-CS access transfer. The access transfer INVITE sent by the ATCF has different content to the previous SDP offer from A. This may be because the media was not anchored in the ATGW, so the ATCF must send a completely new SDP offer to the SCC-AS.
The SCC-AS can see that the new offer is different to the previous one; the session IDs and versions differ, and also there is only one media description (no video). The SCC-AS must perform a remote update re-INVITE with UE-B, so that UE-B knows about the media change.
If the SCC-AS just sent the new SDP offer to UE-B verbatim, UE-B would have to reject it, because the offer uses a different session ID (45678, not 12345), and the version is out of sequence.
UE-B would expect the next offer to have session ID 12345 and version 12346 (incremented by one from the previous SDP offer 1).
To resolve this conflict, the SCC-AS adjusts the SDP offer so that it uses the correct session ID and version,
and also sets the video media description’s port to zero so that UE-B knows it is no longer in use
(media (m=) lines in SDP cannot be removed during a session, only changed or added).
With the adjusted SDP offer 2a, UE-B can process it correctly, switching to the new audio stream and stopping the video stream. Conversely when the SDP answer 2a arrives at the SCC-AS, the disabled video media description must be removed. This is so that the number of media descriptions in the answer matches what was in the ATCF’s original SDP offer 2.
The new media is now established between UE-A and UE-B, so the call can continue, with audio at least.
SDP conflict types
The Sentinel VoLTE SCC-AS handles most types of SDP conflicts that may occur when using access transfer, as described below.
|
The SDP content shown below is abbreviated to just show the relevant lines. |
Session ID and version
In cases where the media was not anchored via an ATGW, the new source SDP offer will have a different session ID and version to the previous SDP offer sent on the destination leg.
When the new offer is forwarded to the destination, the SCC-AS rewrites the origin (o=) line so that the session ID and version are consistent with the previous offer:
-
The session ID will be replaced with the previous offer’s session ID
-
The session version will be replaced with the previous offer’s version + 1
| Previous SDP offer to destination | New SDP offer from source | Output SDP offer to destination |
|---|---|---|
o=- 100000 100000 IN IP4 10.0.0.1 |
o=- 45678 45678 IN IP4 172.16.4.2 |
o=- 100000 100001 IN IP4 172.16.4.2 Use session ID and version + 1 from previous offer. |
Subsequent offers arriving on the source leg get the same treatment, so the destination leg always sees the same session ID and monotonically increasing sequence of session versions.
In the reverse direction (destination → source), SDP offers and answers do not need their session IDs and versions rewritten; these are all generated by the destination UE which has not changed.
Media descriptions removed
This is when the new source SDP offer has fewer media descriptions than the previous offer sent to the destination.
Before the new offer is sent to the destination, the SCC-AS must zero the media lines that are no longer used.
| Previous SDP offer to destination | New SDP offer from source | Output SDP offer to destination |
|---|---|---|
m=audio 32500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 32600 RTP/AVP 98 a=rtpmap:98 H263/90000 Original media with audio & video. |
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 New media after access transfer has audio only. |
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 Copy new audio description and disable previous video description. |
When an SDP answer or subsequent offer forwarded in the reverse direction (destination → source), the disabled media descriptions are removed.
| Original SDP offer from source | SDP answer from destination | Output SDP answer to source |
|---|---|---|
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 New media from source leg was audio only. |
m=audio 36900 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 Destination answers, accepting audio stream and leaving video disabled. |
m=audio 36900 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 Disabled video description removed in answer to source. |
Media descriptions added
This is when the new source SDP offer has more media descriptions than the previous offer sent to the destination.
Before the new offer is sent to the destination, the SCC-AS must copy the new media descriptions into the next available positions in the output.
| Previous SDP offer to destination | New SDP offer from source | Output SDP offer to destination |
|---|---|---|
m=audio 32500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 |
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 40600 RTP/AVP 98 a=rtpmap:98 H263/90000 New source offer adds a video description. |
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 40600 RTP/AVP 98 a=rtpmap:98 H263/90000 Both media descriptions copied into offer sent to destination. |
When an SDP answer or subsequent offer is forwarded in the reverse direction (destination → source), the new media descriptions are copied across.
| Original SDP offer from source | SDP answer from destination | Output SDP answer to source |
|---|---|---|
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 40600 RTP/AVP 98 a=rtpmap:98 H263/90000 |
m=audio 56700 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 56800 RTP/AVP 98 a=rtpmap:98 H263/90000 |
m=audio 56700 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 56800 RTP/AVP 98 a=rtpmap:98 H263/90000 Both media descriptions copied into answer sent to source. |
Reusing a media description that was previously set to zero
In the media descriptions removed case above, the SCC-AS adds a disabled media description to the output SDP. When the other party sends SDP in the other direction, this description would normally be removed. However, it’s possible that the other party reuses this disabled description’s position for a new media stream. In this case the SCC-AS has to copy the new media description rather than removing it.
| Previous SDP offer to destination | New SDP offer from destination | Output SDP offer to source |
|---|---|---|
m=audio 40500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 0 RTP/AVP 98 Video line was disabled by previous media descriptions removed interaction. |
m=audio 56000 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 57000 RTP/AVP 100 a=rtpmap:100 H264/90000 New video media reuses same position as previously disabled stream. |
m=audio 56000 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 57000 RTP/AVP 100 a=rtpmap:100 H264/90000 Existing and new media descriptions are copied to output. |
From this point when SDP is forwarded in the reverse direction (source → destination), the new media descriptions are copied across.
Payload type conflicts
Payload type conflicts occur when a new media description in the same position tries to map the same dynamic RTP payload type number to a different codec. If the new media description was just copied across to the destination, the media stream would fail because the destination UE will already be using a different codec.
The SCC-AS has two methods of dealing with this conflict:
Method 1: Disabling the conflicting media description
The default method is that the SCC-AS disables the original media description (sets its port to zero), and copies the new media description to the next available position in the output SDP.
| Previous SDP offer to destination | New SDP offer from source | Output SDP offer to destination |
|---|---|---|
m=audio 32500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 32600 RTP/AVP 98 a=rtpmap:98 H263/90000 Previously the audio payload type |
m=audio 40500 RTP/AVP 97 98 a=rtpmap:97 AMR-WB/16000/1 a=rtpmap:98 AMR/9000/1 m=video 40600 RTP/AVP 101 a=rtpmap:101 H263/90000 The new offer maps payload type |
m=audio 0 RTP/AVP 97 m=video 40600 RTP/AVP 101 a=rtpmap:101 H263/90000 m=audio 40500 RTP/AVP 97 98 a=rtpmap:97 AMR-WB/16000/1 a=rtpmap:98 AMR/9000/1 In the rewritten offer, zero the conflicting media description, add its replacement to the end. |
When an SDP answer or subsequent offer is forwarded in the reverse direction (destination → source), the new media descriptions are copied back to their original positions, and the disabled media description is removed.
| Original SDP offer from source | SDP answer from destination | Output SDP answer to source |
|---|---|---|
m=audio 40500 RTP/AVP 97 98 a=rtpmap:97 AMR-WB/16000/1 a=rtpmap:98 AMR/9000/1 m=video 40600 RTP/AVP 101 a=rtpmap:101 H263/90000 Offer has audio in position 1, video in position 2. |
m=audio 0 RTP/AVP 97 m=video 39700 RTP/AVP 101 a=rtpmap:101 H263/90000 m=audio 39800 RTP/AVP 97 a=rtpmap:97 AMR-WB/16000/1 Due to payload type conflict above, answer has video in position 2, audio in position 3. |
m=audio 39800 RTP/AVP 97 a=rtpmap:97 AMR-WB/16000/1 m=video 39700 RTP/AVP 101 a=rtpmap:101 H263/90000 Transformed answer copies audio from position 3 to position 1; video from position 2 to position 2. Disabled audio in position 1 is removed. |
Method 2: Dropping the conflicting payload types
The alternative method - used when the EnableCodecDroppingOnClash attribute of the SCCConfHandlingConfigProfileTable is set to true - is to drop the conflicting payload types from the outgoing media description.
| Previous SDP offer to destination | New SDP offer from source | Output SDP offer to destination |
|---|---|---|
m=audio 32500 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 m=video 32600 RTP/AVP 98 a=rtpmap:98 H263/90000 Previously the audio payload type |
m=audio 40500 RTP/AVP 97 98 a=rtpmap:97 AMR-WB/16000/1 a=rtpmap:98 AMR/9000/1 m=video 40600 RTP/AVP 101 a=rtpmap:101 H263/90000 The new offer maps payload type |
m=audio 40500 RTP/AVP 98 a=rtpmap:98 AMR/9000/1 m=video 40600 RTP/AVP 101 a=rtpmap:101 H263/90000 In the rewritten offer, remove the conflicting payload type from the offer from source. |
When an SDP answer or subsequent offer is forwarded in the reverse direction (destination → source), there are no further actions needed as the SDP answer from the destination will already have the conflicting payload types removed. This can be sent to the source without further modification.
Note: if all payload types are in conflict with the previous media description, then the SCC-AS will revert back to the default method of disabling the original media description.
Using SDP conflict management in a feature
A feature may enable SDP conflict management for a pair of legs using the SdpRewriting class from sentinel-sip-spi:
import com.opencloud.sentinel.sdp.SdpRewriting;
...
SdpRewriting sdpRewriting = new SdpRewriting(tracer, sessionState);
sdpRewriting.startSdpRewritingForLegs(newAccessLegName, remoteLegName, newSourceSDP, previousDestSDP);This sets up the SDP association between the legs named newAccessLegName and remoteLegName.
This association is persisted in session state, and includes the set of transformations to correctly update the SDP in both directions.
The feature does not need to do any more work; the actual processing of the SDP is performed by the SDPRewriter system feature, after user features have run. Over the lifetime of the session, either party may change the set of media descriptions. The SDPRewriter system feature ensures that the SDP transformations are updated accordingly to account for new and updated media descriptions.
SDP encoding issues and workarounds
Number of ports in media lines
The port field in a media (m=) line may include a "number of ports" suffix, if the media uses several ports.
For example, RTP media with port 31700/2 means the media uses 2 ports.
Media that uses one port may be encoded as either 31700 or 31700/1, which are equivalent.
The SDP implementation in Sentinel VoLTE (NIST SDP) uses the former, omitting the /1 suffix by default.
The formatting of SDP received from other systems will be preserved, so if the /1 suffix was present
in an incoming SDP media field, it will not be removed.
Conversely if the /1 suffix was absent, it will not be added.
SDP media fields created by Sentinel VoLTE features (using javax.sdp.SdpFactory) will not add the /1 suffix by default.
If necessary this can be overridden, to always use /1, by setting the system property
-Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false on the JVM command line.
In the Rhino SDK, add -Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false to the file $RHINO/config/jvm_args.
In a production Rhino node, add the following to $RHINO/node-xxx/read-config-variables:
OPTIONS="$OPTIONS -Dgov.nist.javax.sdp.fields.mediafield.encodenportsonlyge1=false"
