8.36 MO Voice Call Explicit Communication Transfer / Consultative Call Transfer / 5GS

34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification

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

8.36.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and being configured to use preconditions and having established a voice call with A (the transferee) }

ensure that {

when { UE is being made to attempt Consultative Call Transfer }

then { UE puts A on hold and sets up voice call with B (the transfer target) and puts B on hold and sends REFER to the transferee }

}

(2)

with { UE having initiated consultative call transfer }

ensure that {

when { UE receives NOTIFY }

then { UE sends 200 OK response for NOTIFY }

}

(3)

with { UE having processed the NOTIFY exchange }

ensure that {

when { UE receives instruction to be put on hold by A }

then { UE processes call hold instruction and responds to it }

}

(4)

with { UE having been put on hold by A }

ensure that {

when { UE receives BYE from B }

then { UE sends 200 OK for BYE }

}

(5)

with { Call with B having ended }

ensure that {

when { UE receives NOTIFY from A }

then { UE sends 200 OK for NOTIFY and may send BYE }

}

8.36.2 Conformance Requirements

[TS 24.629, clause 4.5.2.1]:

A UE that has initiated an emergency call, shall not perform any transfer operation involving the dialog associated with the emergency call.

A UE that initiates a transfer operation shall if the Contact address of the transferee is a GRUU:

– issue a REFER outside an existing dialog as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16], where:

a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field:

b) the Refer-To header field shall indicate the public address of the transfer target;

c) in case of Consultative transfer, the transferor UE has a consultation communication with the transfer target, a Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter;

d) the Referred-By header field can be used to indicate the identity of the transferor. When privacy was required in the original communications dialog and a Referred-By header field is included, the UE shall include a Privacy header field set to "user"; and

e) the Target-Dialog header field identifies the dialog to be transferred;

otherwise the UE shall:

– issue a REFER request in the original communications dialog as specified in RFC 3515 [2], where:

a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field;

b) the Refer-To header field shall indicate the public address of the transfer target;

c) in case of consultative transfer, the transferor UE has a consultation communication with the transfer target, a Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter; and

If assured transfer is requested, the UE may include an Expires header field in the Refer-To URI of the REFER request.

NOTE 1: The value of the Expires header field indicates the maximum duration of the transfer attempt. If the transfer does not succeed within this duration, the UE will receive a NOTIFY request indicating the transfer failure.

After the REFER request is accepted by the other end with a 2xx response, the transferor UE gets notifications of how the transferee’s communication setup towards the transfer Target is progressing.

When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have successfully setup a communication, the transferor UE may terminate the original communication with the transferee UE, by sending a BYE request on the original dialog.

If an assured transfer attempt is not completed (i.e. the UE has not received a NOTIFY request with a "message/sipfrag" body’s status line containing a final response code indicating the end of the transfer operation), the UE may request to terminate the transfer attempt by:

– sending a REFER request in the same communications dialog as the previous REFER request as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16], where:

a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field; and

b) the Refer-To header field shall indicate the public address of the transfer target and shall contain the method parameter set to "CANCEL"; and

c) if applicable include a Target-Dialog header field that identifies the dialog under transfer.

If the UE receives a NOTIFY request indicating that the assured transfer attempt failed, followed by a re-INVITE or an UPDATE request taking the UE off HOLD the UE may decide to retrieve the original communication by sending a re-INVITE request in the original SIP dialog.

NOTE 2: If the user requests the retrieval of the original communication while the transfer attempt has not been completed, the UE needs to first request the termination of the transfer attempt before retrieving the original communication via a re-INVITE request.

Reference(s)

3GPP TS 24.629 [36], clause 4.5.2.1.

8.36.3 Test description

8.36.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is configured to register for IMS after switch on.

– UE is configured to use preconditions.

Preamble:

– The UE has registered to IMS and set up the MO call, by executing the generic test procedure in Annex A.2 up to the last step and thereafter executing the generic test procedure in A.4.1.

– The SS has accepted the UE’s MO call.

8.36.3.2 Test procedure sequence

Table 8.36.3.2-1: Main Behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	Make the UE put the call on hold (Note 1)	–	–	–	–
2	Check: Does the UE send INVITE or UPDATE with a SDP offer to hold the call with A by running step 1 of A.17 for MO Call Hold?	–>	INVITE or UPDATE	1	P
3-5	Remaining steps 2-4 of A.17 for MO Call Hold happen.	–	–	–	–
6	Void	–	–	–	–
7	Check: Does the UE initiate a voice call with B by exercising step 1 of Annex A.4.1?	–>	INVITE	1	P
8-11	Steps 2-5 of A.4.1 happen	–	–	–	–
–	EXCEPTION: Step 12-13 describes behaviour that takes place if the UE doesn’t include QOS confirmation in the PRACK message in step 10.	–	–	–	–
12	UE sends a second SDP offer in an UPDATE request. (Step 6 of Annex A.4.1)	–>	UPDATE	–	–
13	SS responds to UPDATE, including an SDP answer. (Step 7 of Annex A.4.1)	<–	200 OK	–	–
14-18	Steps 8-12 of A.4.1 are performed.	–	–	–	–
19	Void	–	–
19A	Make the UE confirm the Consultative Call Transfer (Note 2)
20	Check: Does the UE send INVITE or UPDATE with a SDP offer to hold the call with B by running step 1 of A.17 for MO Call Hold?	–>	INVITE or UPDATE	1	P
21-23	Remaining steps 2-4 of A.17 for MO Call Hold happen	–	–	–	–
24	Check: Does the UE send REFER to SS, simulating the transferee, referring to the transfer target	–>	REFER	1	P
25	The SS responds to REFER with 200 OK	<–	200 OK
26	The SS, simulating the transferee, sends initial NOTIFY for the implicit subscription created by the REFER request	<–	NOTIFY
27	The UE responds to NOTIFY with 200 OK	–>	200 OK	2	P
28-31	The SS, simulating the transferee, puts the UE on hold by executing the MT Call Hold procedure of Annex A.18, but setting the direction attribute to inactive.	–	–	3	P
32	The SS, simulating the transfer target, releases the call between UE and the transfer target with BYE	<–	BYE	–	–
33	The UE responds to BYE with 200 OK	–>	200 OK	4	P
34	The SS, simulating the transferee, sends a NOTIFY request to confirm that the call transfer has been completed	<–	NOTIFY	–	–
35	The UE responds to NOTIFY with 200 OK	–>	200 OK	–	–
36	Optional: UE may send a BYE request to release call with the transferee within 3s.	–>	BYE	–	–
37	If the UE has sent BYE in step 36 then SS sends 200 OK for BYE	<–	200 OK	5	P
Note1: This could be done by e.g. MMI or AT command (AT+CHLD=2). Note2: This could be done by e.g. MMI or AT command (AT+CHLD=4).

8.36.3.3 Specific message contents

Table 8.36.3.3-1: INVITE (step 7, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 1 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Request-Line
Request-URI		px_IMS_CalleeUri2
To
addr-spec		px_IMS_CalleeUri2

Table 8.36.3.3-2: 183 Session Progress (step 9, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 3 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Contact
addr-spec		px_IMS_CalleeContactUri2
Message-body		o=- 1111111112 1111111111 IN (addrtype) (unicast-address for SS)		RFC 4566 [38]

Table 8.36.3.3-3: 180 Ringing (step 14, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 8 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Contact
addr-spec		px_IMS_CalleeContactUri2

Table 8.36.3.3-4: 200 OK for INVITE (step 17, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 11 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Contact
addr-spec		px_IMS_CalleeContactUri2

Table 8.36.3.3-5: INVITE/UPDATE (step 20, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 1 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Request-Line
Request-URI		px_IMS_CalleeUri2

Table 8.36.3.3-6: REFER (step 24, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Step 1 in A.2.10
Header/param	Cond	Value/remark	Rel	Reference
Refer-To
value		<public address of transfer target?Replaces=(dialog id of the dialog between the UE and the transfer target)&Require=replaces>
Referred-By
value		same value as addr-spec field in From header in the first INVITE during initial call setup, if header present
Privacy
value		user (shall be included if privacy was required during original communication dialog and Referred-By header field is included)

Table 8.36.3.3-7: NOTIFY (step 26, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 1 in A.4.1
Header/param	Cond	Value/remark	Rel	Reference
Message-body		SIP/2.0 100 Trying

Table 8.36.3.3-8: 200 OK for NOTIFY (step 27, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A11 and A22

Table 8.36.3.3-9: INVITE (step 28, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 1 of A.19
Header/param	Cond	Value/remark	Rel	Reference
Message-body		Each media line carries direction attribute “a=inactive”

Table 8.36.3.3-10: 200 OK for re-INVITE (step 30, table 8.36.3.2-1)

Derivation Path: TS 34.229-5, Step 4 of A.19
Header/param	Cond	Value/remark	Rel	Reference
Message-body		Each media line carries direction attribute “a=inactive”

Table 8.36.3.3-11: NOTIFY (step 34, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.2.11
Header/param	Cond	Value/remark	Rel	Reference
Subscription-State
Substate-value		terminated
expires		omitted from request
reason		noresource
Message-body		SIP/2.0 200 OK

Table 8.36.3.3-12: 200 OK for NOTIFY (step 35, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Annex A.3.1, Conditions A11 and A22

Table 8.36.3.3-13: PRACK (step 10, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in annex A.2.4, Conditions A1 and A7
Header/param	Cond	Value/remark	Rel	Reference
Require		(present, if Message-Body is present)
option-tag		precondition
Message-body		(if present) Contents is copied from step 6 of annex A.4.1 with the following exceptions: 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		TS 24.229 [7]

Table 8.36.3.3-14: 200 OK (step 11, table 8.36.3.2-1)

Derivation Path: TS 34.229-1 [2], Table in annex A.3.1, Conditions A10 and A22
Header/param	Cond	Value/remark	Rel	Reference
To
tag		Same value as used in step 10
Require		(present, if Message-Body is present)
option-tag		precondition
Content-Type		(present, if content-type was present in PRACK at step 10)
media-type		application/sdp
Content-Length
value		length of message-body
Message-body		(present, if Message-Body was present in PRACK at step 10) SDP body of the 200 OK response copied from the received PRACK and modified as follows: – IP address on "c=" lines and transport port on "m=" lines changed to indicate to which IP address and port the UE should start sending the media; – "o=" line identical to previous SDP sent by SS except that sess-version is incremented; – Attributes for preconditions: a=curr:qos remote sendrecv.		TS 24.229 [7]