17 Media use cases

34.229-13GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 1: Protocol conformance specificationRelease 16TSUser Equipment (UE) conformance specification

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

17.1 MO Speech, add video remove video

17.1.1 Definition

Test to verify that the UE is able to add a bidirectional video component to an ongoing IMS Multimedia telephony voice call. This process is described in 3GPP TS 24.229 [10], TS 24.173 [65] and TS 26.114 [66].

17.1.2 Conformance requirement

[TS 24.173, clause 5.2]:

IMS multimedia telephony communication service can support different types of media, including media types listed in 3GPP TS 22.173. The session control procedures for the different media types shall be in accordance with 3GPP TS 24.229 and 3GPP TS 24.247, with the following addition:

a) Multimedia telephony is an IMS communication service and the P-Preferred-Service and P-Asserted-Service headers shall be treated as described in 3GPP TS 24.229. The coding of the ICSI value in the P-Preferred-Service and P-Asserted-Service headers shall be according to subclause 5.1.

[TS 24.229, clause 5.1.2A.1]:

If this is a request within an existing dialog, and the request includes a Contact header field, then the UE should insert the previously used Contact header field.

…

After the dialog is established the UE may change the dialog capabilities (e.g. add a media or request a supplementary service) if defined for the IMS communication service as identified by the ICSI value using the same dialog. Otherwise, the UE shall initiate a new initial request to the other user.

[TS 24.229, clause 5.1.3]:

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.

The precondition mechanism should be supported by the originating UE.

The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource reservation.

NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application requirements, current access network capabilities, local configuration, etc.

In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition mechanism should make use of the precondition mechanism, even if it does not require local resource reservation.

Upon generating an initial INVITE request using the precondition mechanism, the UE shall:

– indicate the support for reliable provisional responses and specify it using the Supported header mechanism; and

– indicate the support for the preconditions mechanism and specify it using the Supported header mechanism.

Upon generating an initial INVITE request using the precondition mechanism, the UE should not indicate the requirement for the precondition mechanism by using the Require header mechanism.

NOTE 2: If an UE chooses to require the precondition mechanism, i.e. if it indicates the "precondition" option tag within the Require header, the interworking with a remote UE, that does not support the precondition mechanism, is not described in this specification.

NOTE 3: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261. The UE can accept or reject any of the forked responses, for example, if the UE is capable of supporting a limited number of simultaneous transactions or early dialogs.

Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see subclause 6.1.2) within the next SIP request.

NOTE 4: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request. In case of the precondition mechanism not being supported on one or both sides, alternatively a reINVITE request can be used for this confirmation after a 200 (OK) response has been received for the initial INVITE request, in case the terminating UE does not support the PRACK request (as described in RFC 3262) and does not support the UPDATE request (as described in RFC 3311).

[TS 24.229 Rel-13, clause 5.1.4A.1]:

If the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, the UE shall indicate support of the precondition mechanism during a session modification. If the precondition mechanism was not used during the session establishment, the UE shall not indicate support of the precondition mechanism during a session modification.

In order to indicate support of the precondition mechanism during a session modification, upon generating a re-INVITE request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the UE shall:

a) indicate the support for the precondition mechanism using the Supported header field mechanism;

b) not indicate the requirement for the precondition mechanism using the Require header field mechanism; and

c) if a re-INVITE request is being generated, indicate the support for reliable provisional responses using the Supported header field mechanism.

[TS 24.229, clause 6.1]:

The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032.

In order to authorize the media streams, the P-CSCF and S-CSCF have to be able to inspect the SDP payloads. Hence, the UE shall not encrypt the SDP payloads.

During session establishment procedure, SIP messages shall only contain SDP payload if that is intended to modify the session description, or when the SDP payload must be included in the message because of SIP rules described in RFC 3261.

…

For "video" and "audio" media types that utilize the RTP/RTCP, the UE shall specify the proposed bandwidth for each media stream utilizing the "b=" media descriptor and the "AS" bandwidth modifier in the SDP.

…

If the media line in the SDP indicates the usage of RTP/RTCP, and if the UE is configured to request an RTCP bandwidth level for the session is different than the default RTCP bandwidth as specified in RFC 3556, then in addition to the "AS" bandwidth modifier in the media-level "b=" line, the UE shall include two media-level "b=" lines, one with the "RS" bandwidth modifier and the other with the "RR" bandwidth modifier as described in RFC 3556 to specify the required bandwidth allocation for RTCP. The bandwidth-value in the b=RS: and b=RR: lines may include transport overhead as described in subclause 6.1 of RFC 3890.

For other media streams the "b=" media descriptor may be included. The value or absence of the "b=" parameter will affect the assigned QoS which is defined in 3GPP TS 29.208.

NOTE 1: In a two-party session where both participants are active, the RTCP receiver reports are not sent, therefore, the RR bandwidth modifier will typically get the value of zero.

The UE shall include the MIME subtype "telephone-event" in the "m=" media descriptor in the SDP for audio media flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 4733.

The UE shall inspect the SDP contained in any SIP request or response, looking for possible indications of grouping of media streams according to RFC 3524 and perform the appropriate actions for IP-CAN bearer establishment for media according to IP-CAN specific procedures (see subclause B.2.2.5 for IP-CAN implemented using GPRS).

If resource reservation is needed, the UE shall start reserving its local resources whenever it has sufficient information about the media streams, media authorization and used codecs available.

NOTE 2: Based on this resource reservation can, in certain cases, be initiated immediately after the sending or receiving of the initial SDP offer.

In order to fulfil the QoS requirements of one or more media streams, the UE may re-use previously reserved resources. In this case the local preconditions related to the media stream, for which resources are re-used, shall be indicated as met.

[TS 24.229, clause 6.1.2]:

An INVITE request generated by a UE shall contain a SDP offer and at least one media description. The SDP offer shall reflect the calling user’s terminal capabilities and user preferences for the session.

If the desired QoS resources for one or more media streams have not been reserved at the UE when constructing the SDP offer, the UE shall:

– indicate the related local preconditions for QoS as not met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1); and,

– set the related media streams to inactive, by including an "a=inactive" line, according to the procedures described in RFC 4566, unless the UE knows that the precondition mechanism is supported by the remote UE.

NOTE 1: When setting the media streams to the inactive mode, the UE can include in the first SDP offer the proper values for the RS and RR modifiers and associate bandwidths to prevent the receiving of the RTCP packets, and not send any RTCP packets.

If the desired QoS resources for one or more media streams are available at the UE when the initial SDP offer is sent, the UE shall indicate the related local preconditions as met, using the segmented status type, as defined in RFC 3312 and RFC 4032, as well as the strength-tag value "mandatory" for the local segment and the strength-tag value "optional" for the remote segment, if the UE supports the precondition mechanism (see subclause 5.1.3.1).

NOTE 2: If the originating UE does not support the precondition mechanism it will not include any precondition information in SDP.

…

Upon generating the SDP offer for an INVITE request generated after receiving a 488 (Not Acceptable Here) response, as described in subclause 5.1.3.1, the UE shall include SDP payload containing a subset of the allowed media types, codecs and other parameters from the SDP payload of all 488 (Not Acceptable Here) responses related to the same session establishment attempt (i.e. a set of INVITE requests used for the same session establishment). The UE shall order the codecs in the SDP payload according to the order of the codecs in the SDP payload of the 488 (Not Acceptable Here) response.

NOTE 3: The UE can attempt a session establishment through multiple networks with different policies and potentially can need to send multiple INVITE requests and receive multiple 488 (Not Acceptable Here) responses from different CSCF nodes. The UE therefore takes into account the SDP contents of all the 488 (Not Acceptable Here) responses received related to the same session establishment when building a new INVITE request.

Upon confirming successful local resource reservation, the UE shall create a SDP offer in which:

– the related local preconditions are set to met, using the segmented status type, as defined in RFC 3312 and RFC 4032; and

– the media streams previously set to inactive mode are set to active (sendrecv, sendonly or recvonly) mode.

Upon receiving an SDP answer, which includes more than one codec for one or more media streams, the UE shall send an SDP offer at the first possible time, selecting only one codec per media stream.

[TS 26.114 Rel-8, clause 5.2.2]:

MTSI terminals offering video communication shall support:

ITU-T Recommendation H.263 Profile 0 Level 45.

In addition they should support:

ITU-T Recommendation H.263 Profile 3 Level 45;

MPEG-4 (Part 2) Visual Simple Profile Level 3with the following constraints:

– Number of Visual Objects supported shall be limited to 1.

– The maximum frame rate shall be 30 frames per second.

– The maximum f_code shall be 2.

– The intra_dc_vlc_threshold shall be 0.

– The maximum horizontal luminance pixel resolution shall be 352 pels/line.

– The maximum vertical luminance pixel resolution shall be 288 pels/VOP.

– If AC prediction is used, the following restriction applies: QP value shall not be changed within a VOP (or within a video packet if video packets are used in a VOP). If AC prediction is not used, there are no restrictions to changing QP value.

– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC Baseline Profile Level 1.1 with constraint_set1_flag=1 and without requirements on output timing conformance (annex C of H.264). Each sequence parameter set of H.264 (AVC) shall contain the vui_parameters syntax structure including the num_reorder_frames syntax element set equal to 0.

[TS 26.114 Rel-10, clause 5.2.2]

MTSI clients in terminals offering video communication shall support:

– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile (CBP) Level 1.2.

In addition they should support:

– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile Level 3.1.

In addition they may support:

– ITU-T Recommendation H.263 [22] Profile 0 Level 45.

[TS 26.114 Rel-8, clause 6.2.1]:

The session setup for RTP transported media shall determine for each media: IP address(es), RTP profile, UDP port number(s); codec(s); RTP Payload Type number(s), RTP Payload Format(s) and any additional session parameters.

[TS 26.114 Rel-8, clause 6.2.1a.1]

MTSI clients should support SDPCapNeg to be able to negotiate RTP profiles for all media types where AVPF is supported. MTSI clients supporting SDPCapNeg shall support the complete SDPCapNeg framework.

SDPCapNeg is described in [69]. This clause only describes the SDPCapNeg attributes that are directly applicable for the RTP profile negotiation, i.e. the tcap, pcfg and acfg attributes. TS 24.229 [7] may outline further requirements needed for supporting SDPCapNeg in SDP messages.

NOTE: This clause describes only how to use the SDPCapNeg framework for RTP profile negotiation using the tcap, pcfg and acfg attributes. Implementers may therefore (incorrectly) assume that it is sufficient to implement only those specific parts of the framework that are needed for RTP profile negotiation. Doing so would however not be future proof since future versions may use other parts of the framework and there are currently no mechanisms for declaring that only a subset of the framework is supported. Hence, MTSI clients are required to support the complete framework.

[TS 26.114 Rel-8, clause 6.2.1a.2]

For voice and real-time text, SDPCapNeg shall be used when offering AVPF the first time for a new media type in the session since the support for AVPF in the answering client is not known at this stage. For video, an MTSI client shall either offer AVPF and AVP together using SDPCapNeg, or the MTSI client shall offer only AVPF, without using SDPCapNeg. If an MTSI client has offered only AVPF for video, and then receives as response either an SDP answer where the video media component has been rejected, or an SIP 488 or 606 failure response with an SDP body indicating that only AVP is supported for video media, the MTSI client should send a new SDP offer with AVP as transport for video. Subsequent SDP offers, in a re-INVITE or UPDATE, may offer AVPF without SDPCapNeg if it is known from an earlier re-INVITE or UPDATE that the answering client supports this RTP profile. If the offer includes only AVP then SDPCapNeg does not need to be used, which can occur for: text; speech if RTCP is not used; and in re-INVITEs or UPDATEs where the RTP profile has already been negotiated for the session in a preceding INVITE or UPDATE.

When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:

– The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall be preferred over AVP.

– At least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.

[TS 26.114, clause 6.2.3]:

If video is used in a session, the session setup shall determine the bandwidth, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in should be supported.

An MTSI terminal shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as described in clause 6.2.1a.

[TS 26.114, clause 6.2.5]:

The SDP shall include bandwidth information for each media stream and also for the session in total. The bandwidth information for each media stream and for the session is defined by the Application Specific (AS) bandwidth modifier as defined in RFC 4566.

[TS 26.114, clause 6.3]:

During session renegotiation for adding or removing media components, the SDP offeror should continue to use the same media (m=) line(s) from the previously negotiated SDP for the media components that are not being added or removed.

[TS 26.114, clause 7.3.1]

The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level, as specified by RFC 3556. Therefore, an MTSIclient shall include the "b=RS:" and "b=RR:" fields in SDP, and shall be able to interpret them.

Reference(s)

3GPP TS 24.229 [10], clauses 5.1.2A.1, 5.1.3, 5.1.4A.1 and 6.1, TS 24.173 [65] clause 5.2 and TS 26.114 [66], clauses 5.2.2, 6.2.1, 6.2.1a.1, 6.2.1a.2, 6.2.3, 6.2.5, 6.3 and 7.3.1.

17.1.3 Test purpose

1) To verify that when adding a video component to an ongoing IMS Multimedia Telephony voice call the UE performs correct exchange of SIP protocol signalling messages; and

2) To verify that within SIP signalling the UE performs correct SDP offer/answer exchanges for negotiating media and indicating preconditions for resource reservation (as described by 3GPP TS 24.229 [10], clause 6.1); and

3) To verify that when removing the video component from the IMS Multimedia Telephony call the UE performs correct exchange of SIP and SDP protocol messages.

17.1.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF, registered to IMS services and set up the MO call, by executing annex C.21.

SS is configured with the shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE. SS has performed AKAv1-MD5 authentication with the UE and accepted the registration and MO call.

Test procedure

1) Adding video to the voice call is initiated on the UE.

2-10) UE executes the procedure described in TS 36.508 [94] table 4.5A.11.3-1, steps 2 to 7. In detail the following steps are done in IMS.

2) UE to sends a re-INVITE request to the SS.

3) SS responds to the re-INVITE request with a 100 Trying response.

4) SS responds to the re-INVITE request with a 183 Session Progress response.

5) SS waits for the UE to send a PRACK request possibly containing the second SDP offer for update of precondition state.

6) SS responds to the PRACK request with a valid 200 OK response.

7) SS waits for the UE to optionally send an UPDATE request containing the final SDP offer. UE will not send the UPDATE request if the PRACK in step 4 already contained the final offer with preconditions met.

8) SS responds to the UPDATE request (if UE sent one) with a valid 200 OK response.

9) SS responds to the re-INVITE request with a valid 200 OK response.

10) SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for INVITE.

10A) The UE is triggered to remove the video stream from the multimedia call

11) SS waits the UE to send a re-INVITE request with a SDP offer indicating the removal of the video stream.

12) SS responds to the re-INVITE request with a 100 Trying response.

12A) SS deactivates the EPS bearer corresponding to the video stream and releases the associated radio resources by applying the procedure described in TS 36.508 [94] clause 4.5A.15

13) SS responds to the re-INVITE request with a valid 200 OK response.

14) SS waits for the UE to send an ACK to acknowledge receipt of the 200 OK for re-INVITE.

15-19) MO Call release according to procedure C.32.

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1			Make UE add video to the voice call.
2	🡪		INVITE	UE sends re-INVITE with an SDP offer containing media lines for both voice and video
3	🡨		100 Trying	The SS responds with a 100 Trying provisional response
4	🡨		183 Session in Progress	SS responds with an SDP answer indicating that SS has not reserved its resources for video.
5	🡪		PRACK	UE acknowledges the receipt of 183 response with PRACK and optionally offers second SDP to indicate the changed precondition status.
6	🡨		200 OK	The SS responds PRACK with 200 OK and answers the second SDP (if any) with mirroring its contents.
7	🡪		UPDATE	UE sends an UPDATE after having reserved the resources for video if meeting the preconditions was not already indicated in step 2 or 5.
8	🡨		200 OK	The SS responds UPDATE, if received, with 200 OK and indicates having reserved the resources
9	🡨		200 OK	The SS responds re-INVITE with 200 OK
10	🡪		ACK	The UE acknowledges the receipt of 200 OK for re-INVITE
10A			Make UE release video from the media call
11	🡪		INVITE	UE sends re-INVITE with a SDP offer indicating that the video component is removed from the call
12	🡨		100 Trying	The SS responds with a 100 Trying provisional response
12A			SS deactivates the EPS bearer for video
13	🡨		200 OK	The SS responds re-INVITE with 200 OK
14	🡪		ACK	The UE acknowledges the receipt of 200 OK for re-INVITE
15-19			Steps defined in annex C.32	MO Call release

NOTE: The default messages contents in annex A are used with condition “IMS security“ or “GIBA” when applicable

Specific Message Contents

INVITE (Step 2)

Use the default message “INVITE for MO Call” in annex A.2.1 with condition A5 (re-INVITE within a dialog) and the following exceptions:

Header/param	Value/Remark
Supported
option-tag	precondition
Message-body	The following SDP types and values. Session description: – v=0 – o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 4] – s=(session name) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) Time description: – t= (start-time) (stop-time) Media description: – m=audio (transport port) RTP/AVP (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=rtpmap: (payload type) AMR-WB/16000 [Note 3] – a=fmtp: (format) Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv Media description: – m=video (transport port) RTP/AVPF (fmt) or RTP/AVP (fmt) [Note 2] – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=tcap:1 RTP/AVPF [Note 2] – a=pcfg:1 t=1 [Note 2] – a=rtpmap: (payload type) H264/90000 – a=fmtp: (format) profile-level-id= (att-field) Attributes for preconditions: – a=curr:qos local none – a=curr:qos remote none – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv Note 1: At least one "c=" field shall be present. Note 2: The tcap/pcfg attributes are present if RTP/AVP is present on the m line. Note 3: The AMR channel number shall be “/1” or omitted. Note 4: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one.

183 Session Progress (Step 4)

Use the default message "183 Session Progress" in annex A.2.3 with the following exceptions:

Header/param	Value/Remark
Require
option-tag	precondition
Message-body	The following SDP types and values. Session description: – v=0 – "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one – s=- – c=IN (addrtype) (connection-address for SS) – b=AS:30 Time description: – t=0 0 Media description: – m=audio (transport port) RTP/AVP (fmt) [Note 1] – b=AS: (bandwidth-value) [Note 1] – b=RS: (bandwidth-value) [Note 1] – b=RR: (bandwidth-value) [Note 1] Attributes for media: – a=rtpmap: (payload type) AMR-WB/16000/1 [Note 1] – a=fmtp: (format) mode-change-capability=2; max-red=220 [Note 1] – a=ptime:20 – a=maxptime:240 Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv Media description: – m=video (transport port) RTP/AVPF (fmt) [Note 1] – b=AS: (bandwidth-value) [Note 1] – b=RS: (bandwidth-value) [Note 1] – b=RR: (bandwidth-value) [Note 1] Attributes for media: – a=acfg:1 t=1 [Note 2] – a=rtpmap: (payload type) H264/90000 [Note 1] – a=fmtp: (format) (format specific parameters) [Note 1] Attributes for preconditions: – a=curr:qos local none – a=curr:qos remote none – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv – a=conf:qos remote sendrecv Note 1: The value for fmt, bandwidth, payload type, format and format specific parameters copied from step 2. Note 2: Present if tcap/pcfg attributes were included in step 2.

PRACK (Step 5)

Use the default message “PRACK” in annex A.2.4 with the exceptions:

Header/param

Value/Remark

Supported

option-tag

precondition [Note 4]

Message-body

Header optional

Contents if present: The following SDP types and values shall be present.

Session description:

– v=0

– o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 2]

– s=(session name)

– c=IN (addrtype) (connection-address for UE) [Note 1]

– b=AS: (bandwidth-value)

Time description:

– t=0 0

Media description:

– m=audio (transport port) RTP/AVP (fmt)

– c=IN (addrtype) (connection-address for UE) [Note 1]

– b=AS: (bandwidth-value)

– b=RS: (bandwidth-value)

– b=RR: (bandwidth-value)

Attributes for media:

– a=rtpmap: (payload type) AMR-WB/16000 [Note 3]

– a=fmtp: (format)

Attributes for preconditions:

– a=curr:qos local sendrecv

– a=curr:qos remote sendrecv

– a=des:qos mandatory local sendrecv

– a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv

Media description:

– m=video (transport port) RTP/AVPF (fmt)

– c=IN (addrtype) (connection-address for UE) [Note 1]

– b=AS: (bandwidth-value)

– b=RS: (bandwidth-value)

– b=RR: (bandwidth-value)

Attributes for media:

– a=rtpmap: (payload type) H264/90000

– a=fmtp: (format) profile-level-id= (att-field)

Attributes for preconditions:

– a=curr:qos local sendrecv

– a=curr:qos remote none

– a=des:qos mandatory local sendrecv

– a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv

Note 1: At least one "c=" field shall be present.

Note 2: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one.

Note 3: The AMR channel number shall be “/1” or omitted.

Note 4: Shall be present if message-body present.

200 OK for PRACK (Step 6)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition (shall be present if SDP message-body present)
Content-Type	Header optional Contents if present:
media-type	application/sdp
Content-Length	Contents if header Content-Type is present:
Value	length of message-body
Message-body	Header present if Prack (step 5) contained SDP. Contents if present: SDP body of the 200 response copied from the received PRACK and modified as follows: – "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one – IP address on "c=" line and transport port on "m=" lines changed to indicate to which IP address and port the UE should start sending the media; Attributes for preconditions (video): – a=curr:qos remote sendrecv

UPDATE (Step 7)

Use the default message “UPDATE” in annex A.2.5 with the following exceptions:

Header/param	Value/remark
Supported	Same contents as specified in step 5.
Message-body	Same contents as specified in step 5.

200 OK for UPDATE (Step 8)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition (shall be present if SDP message-body present)
Content-Type	Header optional Contents if present:
media-type	application/sdp
Content-Length	Contents if header Content-Type is present:
Value	length of message-body
Message-body	SDP body of the 200 response copied from the received UPDATE and modified as follows: – "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one – IP address on "c=" line and transport port on "m=" lines changed to indicate to which IP address and port the UE should start sending the media; Attributes for preconditions (video): – a=curr:qos remote sendrecv

INVITE (Step 11)

Use the default message “INVITE for MO Call” in annex A.2.1 with condition A5 (re-INVITE within a dialog) and the following exceptions:

Header/param	Value/Remark
Supported
option-tag	precondition
Message-body	The following SDP types and values. Session description: – v=0 – o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 2] – s=(session name) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) Time description: – t= (start-time) (stop-time) Media description: – m=audio (transport port) RTP/AVP (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR:(bandwidth-value) Attributes for media: – a=rtpmap: (payload type) AMR-WB/16000 [Note 3] – a=fmtp: (format) Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv Media description: – m=video 0 RTP/AVPF (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] Attributes for media: – a=rtpmap: (payload type) – a=fmtp: (format) Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv or a=des:qos mandatory remote sendrecv Note 1: At least one "c=" field shall be present. Note 2: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one. Note 3: The AMR channel number shall be “/1” or omitted.

200 OK (Step 13)

Use the default message “200 OK for other requests than REGISTER or SUBSCRIBE” in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition
Content-Type
media-type	application/sdp
Content-Length
Value	length of message-body
Message-body	SDP body of the 200 response copied from the received INVITE and modified as follows: – "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one – IP address on "c=" line and, for audio, transport port on "m=" line changed to indicate to which IP address and port the UE should start sending the media;

17.1.5 Test requirements

The UE shall send requests and responses as described in clause 17.1.4

17.2 MT Speech, add video remove video

17.2.1 Definition

Test to verify that the UE correctly adds and removes media video to a mobile terminated speech session video when using IMS Multimedia Telephony. This process is described in 3GPP TS 24.229 [10], clause 5.1.2A.2, TS 24.173 [65] and TS 26.114 [66].

17.2.2 Conformance requirement

[TS 24.229, clause 5.1.2A.2]

[TS 24.229 Rel-13, clause 5.1.4A.2]

Upon receiving a re-INVITE request, an UPDATE request, or a PRACK request that indicates support for the precondition mechanism, using the Supported header field or the Require header field, the UE shall:

a) if the precondition mechanism was used during the session establishment, as described in subclause 5.1.3.1 or 5.1.4.1, use the precondition mechanism;

…

If the precondition mechanism is used for the session modification, the UE shall indicate support for the preconditions mechanism, using the Require header field mechanism, in responses that include an SDP body, to the session modification request.

[TS 24.229 release 9 start, clause 6.1.1]

During the session establishment procedure, and during session modification procedures, SIP messages shall only contain SDP payload if that is intended to modify the session description, or when the SDP payload must be included in the message because of SIP rules described in RFC 3261.

[TS 24.229 release 9 end]

[TS 26.114, clause 5.2.1]

MTSI terminals offering speech communication shall support:

– AMR speech codec (3GPP TS 26.071, 3GPP TS 26.090, 3GPP TS 26.073 and 3GPP TS 26.104) including all 8 modes and source controlled rate operation ‎3GPP TS 26.093. The terminal shall be capable of operating with any subset of these 8 codec modes.

[TS 26.11 Rel-84, clause 5.2.2]

MTSI terminals offering video communication shall support:

ITU-T Recommendation H.263 Profile 0 Level 45.

In addition they should support:

ITU-T Recommendation H.263 Profile 3 Level 45;

MPEG-4 (Part 2) Visual Simple Profile Level 3with the following constraints:

– Number of Visual Objects supported shall be limited to 1.

– The maximum frame rate shall be 30 frames per second.

– The maximum f_code shall be 2.

– The intra_dc_vlc_threshold shall be 0.

– The maximum horizontal luminance pixel resolution shall be 352 pels/line.

– The maximum vertical luminance pixel resolution shall be 288 pels/VOP.

[TS 26.114 Rel-10, clause 5.2.2]

MTSI clients in terminals offering video communication shall support:

– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile (CBP) Level 1.2.

In addition they should support:

– ITU-T Recommendation H.264 / MPEG-4 (Part 10) AVC [24] Constrained Baseline Profile Level 3.1.

In addition they may support:

– ITU-T Recommendation H.263 [22] Profile 0 Level 45.

[TS 26.114, clause 6.2.1a.1]

[TS 26.114, clause 6.2.1a.2]

When offering AVP and AVPF using SDPCapNeg, the MTSI client shall offer AVP on the media (m=) line and shall offer AVPF using SDPCapNeg mechanisms. The SDPCapNeg mechanisms are used as follows:

– The support for AVPF is indicated in an attribute (a=) line using the transport capability attribute ‘tcap’. AVPF shall be preferred over AVP.

– At least one configuration using AVPF shall be listed using the attribute for potential configurations ‘pcfg’.

[TS 26.114, clause 6.2.3]

If video is used in a session, the session setup shall determine the bandwidth, RTP profile, video codec, profile and level. The "imageattr" attribute as specified in [76] should be supported.

An MTSI client shall offer AVPF for all media streams containing video. RTP profile negotiation shall be done as described in clause 6.2.1a.

[TS 26.114, clause 6.2.5]

[TS 26.114, clause 6.3]

[TS 26.114, clause 7.3.1]

…

The bandwidth for RTCP traffic shall be described using the "RS" and "RR" SDP bandwidth modifiers at media level, as specified by RFC 3556.

…

Reference(s)

3GPP TS 24.229 [10] clauses 5.1.2A.2, 5.1.4A.2 and 6.1.1 (release 9), TS 26.114 [66] clauses 5.2.1, 5.2.2, 6.2.1a.1, 6.2.1a.2, 6.2.3, 6.2.5, 6.3 and 7.3.1.

NOTE 1: Reference to a specific release is used when a corrected requirement is not updated in earlier releases of the core specifications but applies to these earlier releases.

17.2.3 Test purpose

1) To verify that media video can be added and removed when an MT MTSI speech call is established.

2) To verify that within SIP signalling the UE performs the correct exchange of SIP header and parameter contents.

3) To verify that within SIP signalling the UE performs the correct exchange of SDP contents.

4) To verify that the UE is able to release the call.

17.2.4 Method of test

Initial conditions

UE contains either ISIM and USIM applications or only USIM application on UICC. UE has discovered P-CSCF, registered to IMS services and established an MT MTSI speech call, by executing the generic test procedure in Annex C.11 steps 1 to 13.

Test procedure applicable for a UE with E-UTRA support (TS 34.229-2 [5] A.18/1)

1-9) UE executes the procedures described in TS 36.508 [94] table 4.5A.12.3-1, steps 1 to 12. In detail the following steps are done in IMS:

1) SS sends a re-INVITE request to the UE.

2) Void

2a) SS may receive 100 Trying from the UE.

3) SS receives 183 Session Progress from the UE.

4) SS sends PRACK to the UE to acknowledge the 183 Session Progress.

5) SS receives 200 OK for PRACK from the UE.

6) SS sends UPDATE to the UE, with SDP indicating that precondition is met on the server side.

7) SS receives 200 OK for UPDATE from the UE.

7A) The UE accepts the session invite.

8) SS expects and receives 200 OK for re-INVITE from the UE.

9) SS sends ACK to the UE.

10) SS sends a re-INVITE to the UE with a SDP offer indicating that the video component is removed from the call.

11) SS expects and receives 200 OK for re-INVITE from the UE.

11A) SS deactivates the EPS bearer corresponding to the video stream and releases the associated radio resources by applying the procedure described in TS 36.508 [94] clause 4.5A.15

12) SS sends ACK to the UE.

13-16) MT Call release according to procedure C.33

Expected sequence

NOTE: Only the IMS procedure relevant to the test purpose is described below.

Step	Direction		Message	Comment
	UE	SS
1	🡨		INVITE	SS sends re-INVITE with second SDP offer to add video.
2				Void.
2a	🡪		100 Trying	(Optional) The UE responds with a 100 Trying provisional response.
3	🡪		183 Session Progress	The UE responds to re-INVITE by sending 183 response reliably with the SDP answer
4	🡨		PRACK	SS acknowledges the receipt of 183 response from the UE
5	🡪		200 OK	The UE acknowledges the PRACK with 200 OK.
6	🡨		UPDATE	SS sends an UPDATE with SDP offer indicating SS reserved resources.
7	🡪		200 OK	The UE acknowledges the UPDATE with 200 OK and includes SDP answer to acknowledge its current precondition status.
7A				Make UE accept the speech and video offer.
8	🡪		200 OK	The UE responds to the re-INVITE with a 200 OK final response.
9	🡨		ACK	The SS acknowledges the receipt of 200 OK for the re-INVITE.
10	🡨		INVITE	SS sends a re-INVITE with a SDP offer indicating that the video component is removed from the call
10A	🡪		100 Trying	(Optional) The UE responds with a 100 Trying provisional response.
11	🡪		200 OK	The UE responds to the re-INVITE with a 200 OK final response.
11A			SS deactivates the EPS bearer for video
12	🡨		ACK	The SS acknowledges the receipt of 200 OK for the re-INVITE.
13				Void
14-16			Steps defined in annex C.33	MT Call release

NOTE: The default messages contents in annex A are used with condition “IMS security“or “GIBA” when applicable

Specific Message Content

INVITE (Step 1)

Use the default message “INVITE for MT Call” in annex A.2.9 with condition A5 (re-INVITE within a dialog) and the following exceptions:

Header/param	Value/remark
Supported
option-tag	precondition
Message-body	The following SDP types and values. Session description: – v=0 – "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one – s=- – c=IN (addrtype) (connection-address for SS) – b=AS:352 Time description: – t=0 0 Media description: – m=audio (transport port) RTP/AVP 97 – b=AS: 37 – b=RS: 0 – b=RR: 2000 Attributes for media: – a=rtpmap: 97 AMR-WB/16000/1 – a=fmtp: 97 mode-change-capability=2; max-red=220 – a=ptime:20 – a=maxptime:240 Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv Media description: – m=video (transport port) RTP/AVPF 101 – b=AS: 315 – b=RS: 0 – b=RR: 2500 Attributes for media: – a=rtpmap: 101 H264/90000 – a=fmtp: 101 packetization-mode=0;profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== – a=rtcp-fb: trr-int 5000* – a=rtcp-fb: nack* – a=rtcp-fb: nack pli* – a=rtcp-fb: ccm fir* – a=rtcp-fb: ccm tmmbr* Attributes for preconditions: – a=curr:qos local none – a=curr:qos remote none – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv

183 Session Progress (step 3)

Use the default message "183 Session Progress" in annex A.2.3 with the following exceptions:

Header/param	Value/remark
Status-Line
Reason-Phrase	Not checked
Require
option-tag	precondition
Message-body	The following SDP types and values shall be present. Session description: – v=0 – o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 3] – s=(session name) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) Time description: – t=0 0 Media description: – m=audio (transport port) RTP/AVP (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=rtpmap:(payload type) AMR-WB/16000 [Note 2] – a=fmtp:(format) Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv Media description: – m=video (transport port) RTP/AVPF (fmt) – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=rtpmap: (payload type) H264/90000 – a=fmtp: (format) packetization-mode=0;profile-level-id= (att-field); \ Attributes for preconditions: – a=curr:qos local none or a=curr:qos local sendrecv – a=curr:qos remote none – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv – a=conf:qos remote sendrecv Note 1: At least one "c=" field shall be present. Note 2: The AMR channel number shall be “/1” or omitted. Note 3: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one.

PRACK (step 4)

Use the default message "PRACK" in annex A.2.4. No content body is included in this PRACK message.

200 OK (step 5)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1.

UPDATE (step 6)

Use the default message "UPDATE" in annex A.2.5 with the following exceptions:

Header/param

Value/remark

Supported

option-tag

precondition

Message-body

The following SDP types and values.

Session description:

– v=0

– "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one

– s=-

– c=IN (addrtype) (connection-address for SS)

– b=AS:352

Time description:

-t=0 0

Media description:

– m=audio (transport port) RTP/AVP 97

– b=AS: 37

– b=RS: 0

– b=RR: 2000

Attributes for media:

– a=rtpmap:97 AMR-WB/16000/1

– a=fmtp:97 mode-change-capability=2; max-red=220

Attributes for preconditions:

– a=curr:qos local sendrecv

– a=curr:qos remote sendrecv

– a=des:qos mandatory local sendrecv

– a=des:qos mandatory remote sendrecv

Media description:

– m=video (transport port) RTP/AVPF 101

– b=AS: 315

– b=RS: 0

– b=RR: 2500

Attributes for media:

– a=rtpmap: 101 H264/90000

– a=fmtp: 101 packetization-mode=0;profile-level-id=42e00c; \

sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA==

– a=rtcp-fb:* trr-int 5000

– a=rtcp-fb:* nack

– a=rtcp-fb:* nack pli

– a=rtcp-fb:* ccm fir

– a=rtcp-fb:* ccm tmmbr

Attributes for preconditions:

– a=curr:qos local sendrecv

– a=curr:qos remote none or curr:qos remote sendrecv [Note 1]

– a=des:qos mandatory local sendrecv

– a=des:qos mandatory remote sendrecv

Note 1: Use the value (none/sendrecv) received from 183 Session Progress and attribute a=curr:qos local.

200 OK (step 7)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition
Content-Type
media-type	application/sdp
Content-Length	header shall be present if UE uses TCP to send this message and if there is a message body
value	length of message-body
Message-body	The following SDP types and values shall be present. Session description: – v=0 – o=(username) (sess-id) (sess-version) IN (addrtype) (unicast-address for UE) [Note 3] – s=(session name) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) Time description: – t=0 0 Media description: – m=audio (transport port) RTP/AVP (fmt) – c=IN (addrtype) (connection-address for UE) [Note 1] – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=rtpmap:(payload type) AMR-WB/16000 [Note 2] – a=fmtp:(format) Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv Media description: – m=video (transport port) RTP/AVPF (fmt) – b=AS: (bandwidth-value) – b=RS: (bandwidth-value) – b=RR: (bandwidth-value) Attributes for media: – a=rtpmap: (payload type) H264/90000 – a=fmtp: (format) packetization-mode=0;profile-level-id= (att-field); \ Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos mandatory remote sendrecv Note 1: At least one "c=" field shall be present. Note 2: The AMR channel number shall be “/1” or omitted. Note 3: "o=" line identical to previous SDP sent by UE except that sess-version is incremented by one

200 OK (Step 8)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1.

ACK (step 9)

Use the default message "ACK" in annex A.2.7.

INVITE (step 10)

Use the default message “INVITE for MT Call” in annex A.2.9 with condition A5 (re-INVITE within a dialog) and the following exceptions:

Header/param	Value/remark
Supported
option-tag	precondition
Message-body	The following SDP types and values. Session description: v=0 "o=" line identical to previous SDP sent by SS except that sess-version is incremented by one s=- c=IN (addrtype) (connection-address for SS) b=AS:37 Time description: t=0 0 Media description: m=audio (transport port) RTP/AVP 97 b=AS: 37 b=RS: 0 b=RR: 2000 Attributes for media: a=rtpmap:97 AMR-WB/16000/1 a=fmtp:97 mode-change-capability=2; max-red=220 a=ptime:20 a=maxptime:240 Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv Media description: – m=video 0 RTP/AVPF 101 – b=AS: 315 – b=RS: 0 – b=RR: 2500 Attributes for media: – a=rtpmap: 101 H264/90000 – a=fmtp: 101 packetization-mode=0;profile-level-id=42e00c; \ sprop-parameter-sets=J0LgDJWgUH6Af1A=,KM46gA== Attributes for preconditions: – a=curr:qos local sendrecv – a=curr:qos remote sendrecv – a=des:qos mandatory local sendrecv – a=des:qos optional remote sendrecv

100 Trying (step 10A)

Use the default message "100 Trying for INVITE" in annex A.2.2.

200 OK (step 11)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1 with the following exceptions:

Header/param	Value/remark
Require option-tag	precondition
Content-Type
media-type	application/sdp
Content-Length	header shall be present if UE uses TCP to send this message and if there is a message body
value	length of message-body
Message-body	SDP body not checked.

ACK (step 12)

Use the default message "ACK" in annex A.2.7.

BYE (step 14)

Use the default message "BYE" in annex A.2.8.

200 OK (step 15)

Use the default message "200 OK for other requests than REGISTER or SUBSCRIBE" in annex A.3.1.

17.2.5 Test requirements

The UE shall send requests and responses as described in clause 17.2.4

17.1 MO Speech, add video remove video

17.1.1 Definition

17.1.2 Conformance requirement

17.1.3 Test purpose

17.1.4 Method of test

17.1.5 Test requirements

17.2 MT Speech, add video remove video

17.2.1 Definition

17.2.2 Conformance requirement

17.2.3 Test purpose

17.2.4 Method of test

17.2.5 Test requirements

17.3 to 17.18 Void