SIP Preconditions

Landslide IMS, PGW, MME, SGW and Wifi Offload Gateway Nodal test cases support preconditions and it is mandatory for a UE that is connected to IMS Network. IMS Node also supports preconditions.

NOTE:

If a customer DUT that does not support preconditions may use the VoLTE.
IP Application Node does not support preconditions. It emulates SIP Subscriber that is an IP network node and not a mobile subscriber.

Overview

SIP Preconditions ensure network resources are reserved for a SIP session using pre-defined reservation mechanisms before beginning a session.

SIP/SDP preconditions mechanism allows a UE to delay completion of a SIP session establishment until one or both ends have successfully completed their resource reservation process. This ensures that resources for the SIP session are reserved before the called party is alerted. This extension to SIP and SDP is mandatory, and is supported by every UE connecting to the IMS network.

A precondition is a set of constraints of the SIP session introduced in the SDP offer. The recipient of the offer generates an answer, but does not alert the user or proceed with session establishment. The session establishment process occurs only when the preconditions are met. A local event such as SIP UPDATE message confirms a resource reservation.

The precondition mechanism is a part of SDP protocol and is based on two states that affect a particular media stream: current status and desired status. A SIP session establishment stops until the current status reaches the desired status. Once this threshold is reached the session establishment resumes.

IMS Nodal, MME Nodal, PGW, SGW Nodal, Wifi Offload Gateway and IMS Node Test Cases

The following shows the test cases and settings to support preconditions. The MME, PGW, SGW and Wifi Offload Gateway Nodal Test Cases (VoLTE) emulates SIP subscribers that are connected to IMS network. Hence, it is mandatory that preconditions mechanism be supported for VoLTE in the test cases (MME, PGW, SGW and Wifi Offload Gateway Nodal). In IMS Nodal, Preconditions is supported when Mw or ISC interface is selected.

MME/PGW/SGW/Wifi Offload Gateway Nodal – IMS Node/Proxy (Mobile-to-Mobile)

VoLTE in MME/PGW/SGW/Wifi Offload Gateway Nodal: SIP subscribers support preconditions mechanism.
In IMS Nodal (SIP VoIP tab) when Mw or ISC interface is enabled.
The IMS Node/Proxy is transparent from SDP point of view, hence, responsible for forwarding SDP.
The IMS Node/AF application includes additional processes, two more AAR/AAA iterations are included during call establishment phase.

NOTE: The illustration below shows a simplified flow chart for Mobile-to-Mobile SIP call. User Agents A and B reside in MME, PGW, SGW and Wifi Offload Gateway Nodal Test Cases, IMS Node is set to Proxy mode, and Rx interface is enabled.

MME/PGW/SGW/Wifi Offload Gateway Nodal – IMS Node/Endpoint

VoLTE in MME/PGW/SGW/Wifi Offload Gateway Nodal: SIP subscribers support preconditions mechanism.
In IMS Nodal (SIP VoIP tab) when Mw or ISC interface is enabled.
IMS Node/Endpoint emulates SIP Endpoints that are connected to IMS Network; hence, precondition mechanism is mandatory on IMS Node/Endpoint.

NOTE: The illustration below shows the MME/PGW/SGW/Wifi Offload Gateway Nodal – IMS Node/Endpoint, that is, either left (UE Originates SIP call) or right half (UE Terminates SIP call).

SDP Parameter Attributes for Preconditions

Overview

Preconditions are maintained per media type. In the case of multiple negotiated media types, SDP message includes multiple sets of preconditions attributes. The attributes are the same for voice and video media type.

The table below shows the supported preconditions attributes.

current-status	"a=curr:" precondition-type SP status-type SP direction-tag
desired-status	"a=des:" precondition-type SP strength-tag SP status-type SP direction-tag
confirm-status	"a=conf:" precondition-type SP status-type SP direction-tag
precondition-type	"qos" \| token
strength-tag	("mandatory" \| "optional" \| "none" \| "failure" \| "unknown")
status-type	("e2e" \| "local" \| "remote")
direction-tag	("none" \| "send" \| "recv" \| "sendrecv")

NOTE: The current implementation supports as follows:

Precondition Type = "qos"
Status Type: segmented => UA must generate 2 current status lines: “local” and “remote”.

SIP Messages

SDP Filler and description

SDP Offer (SIP: INVITE)

m=audio 6000 RTP/AVP 0

a=rtpmap:0 PCMU

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=curr:qos local none

a=curr:qos remote none

The above lines indicate that currently (curr) no (none) quality of service (qos)-related preconditions have been fulfilled by either the calling end (local) or the called end (remote).

a=des:qos mandatory local sendrecv

Indicates the desired (des) quality of service (qos) precondition at the calling user (local) end. The resources for the calling user need to be reserved in both the sending and receiving directions (sendrecv), as the audio stream is bidirectional (i.e., both users can talk to each other and hear what the other says). It also states that the session will not take place if the indicated resources cannot be reserved by the calling user (mandatory).

a=des:qos none remote sendrecv

Indicates the desired (des) quality of service (qos)-related preconditions at the called user (remote) end. As the calling and the called terminal are not directly connected to each other, the calling terminal is unaware of how the remote terminal is attached to the network. It might be that the remote terminal does not need to perform any resource reservation, as it is connected via a CS telephony network. Therefore, the calling end can only indicate that, if the remote end needs to reserve resources, then they should be reserved in both the sending and receiving directions (sendrecv); however, the calling end is currently unaware that this is really required in order to get a media session established (none).

SDP Answer (SIP: 183)

Now the called terminal is local and the calling terminal is remote.

m=audio 6000 RTP/AVP 0

a=rtpmap:0 PCMU

SDP Answer (SIP: 183)

a=conf:qos remote sendrecv

The calling terminal (remote) should send a confirmation (conf) at the moment the resources (qos) have been reserved in the sending and receiving directions (sendrecv). This is a new line that the called end adds to SDP. It is a necessary addition because the called terminal is not intended to ring the called user or to start sending media until both ends have reserved the resources.

SDP Offer (SIP: UPDATE)

m=audio 6000 RTP/AVP 0

a=rtpmap:0 PCMU

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

a=curr:qos local sendrecv

The calling terminal (local) notifies that resources have now been successfully reserved in both the sending and receiving directions.

SDP Answer (SIP: 200 OK for UPDATE)

m=audio 6000 RTP/AVP 0

a=rtpmap:0 PCMU

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

All the current states for resource reservation match the desired states; so, the preconditions negotiation has been successful and has completed.