A.2 Default messages for Call Setup

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

A.2.1 INVITE for MO Call Setup

Header/param	Cond	Value/remark	Rel	Reference
Request-Line
Method		INVITE		RFC 3261 [15]
Request-URI	NOT A5 AND NOT A32	px_IMS_CalleeUri px_IMS_CalleeURI may be either SIP or Tel URI. It may contain a dialstring and phone-context parameter, when calling to dialstring. When calling to dialstring SIP URI must also contain user=phone or user=dialstring parameter. The dialstring, if used, may be global, home local number or geo-local number. For home local numbers the value of phone-context parameter must equal the home domain name i.e. px_IMS_HomeDomainName. For geo-local numbers the home domain name must be prefixed by string “geo-local.” or access technology specific prefix, if the UE supports that option. Note: The way how the UE determines whether numbers in a non-international format are geo-local, home-local or relating to another network, is UE implementation specific. For instance the UE might have a UI setting		TS 24.229 [10] cl 5.1.2A.1.3, 5.1.2A.1.5, 7.2A.10
	A5 OR A32	MO call has been established: px_IMS_CalleeContactUri MT call has been established: address of the remote UE as sent in the Contact header field of the dialog creating MT INVITE in the preamble
	A6, A7 AND NOT (A20 OR A21)	emergency service URN beginning with urn:service:sos		RFC 5031 [97]
	A20 AND (NOT A25)	urn:service:sos.ecall.manual	Rel-14	RFC 8147 [149]
	A21 AND (NOT A25)	urn:service:sos:ecall.automatic	Rel-14	RFC 8147 [149]
	A25	The Test URI as per the generic “eCall test URI” which uses EF_SDNURI from table 4.9.3.5-1 for “eCall capable” UEs or EF_FDNURIfrom table 4.9.3.5-2 for “eCall only” UEs as specified in 3GPP TS 36.508 [94]	Rel-14	RFC 8147 [149]
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by	A1,A7	IP address or FQDN and protected server port of the UE
	A2,A19	IP address or FQDN, port (optional) and not checked
	A6	IP address and, when using UDP, unprotected server port of the UE
	A17	IP address and unprotected server port of the UE
response-port	A6	rport (when using UDP)		RFC 3581 [96]
via-branch		value starting with ‘z9hG4bK’
Route		order of the parameters in this header must be like in the respective rows		RFC 3261 [15]
route-param	A1	<sip:SS P-CSCF address: protected server port of SS;lr>, <sip:scscf.3gpp.org;lr>
	A2,A17	<sip:SS P-CSCF address: unprotected server port of SS (optional);lr>, <sip:scscf.3gpp.orgf;lr
	A5 OR A32	MO call has been established: URIs of the Record-Route header of 183 response in reverse order (or any other response creating the dialog according to RFC 3261 clause 12.1 [15]) MT call has been established: same value as defined for the Record-Route header in A.2.9
	A6,A19	<sip:SS P-CSCF address: unprotected server port of SS;lr>
	A7	<sip:SS P-CSCF address: protected server port of SS;lr>
From				RFC 3261 [15]
addr-spec	A6	Any SIP URI with display name as “Anonymous” or anonymous
	A7,A19	emergency public user identity (NOTE 3)
	A4	any SIP URI being subscribed and registered as listed in the XML body of the NOTIFY request; additionally when there is a P-Preferred-Identity header within the INVITE request the SIP URI shall match the URI within the P‑Preferred-Identity header
tag	A4	must be present, value not checked
addr-spec	A5 OR A32	local SIP URI of the UE as used in any previous request in the same dialog (In the earlier requests within the same dialog this URI appears in From header within requests sent by the UE and in To header within requests sent by the SS)
tag	A5 OR A32	local tag of the dialog ID (In the earlier requests within the same dialog this tag appears in From header within requests sent by the UE and in To header within requests sent by the SS)
To				RFC 3261 [15]
addr-spec	A6, A7 AND NOT (A20 OR A21)	emergency service URN beginning as urn:service:sos		RFC 5031 [97]
	A20 AND (NOT A25)	urn:service:sos.ecall.manual	Rel-14	RFC 8147 [149]
	A21 AND (NOT A25)	urn:service:sos:ecall:automatic	Rel-14	RFC 8147 [149]
	A25	The Test URI as per the generic “eCall test URI” which uses EF_SDNURI from table 4.9.3.5-1 for “eCall capable” UEs or EF_FDNURIfrom table 4.9.3.5-2 for “eCall only” UEs as specified in 3GPP TS 36.508 [94]	Rel-14	RFC 8147 [149]
	A4	px_IMS_CalleeUri
tag	A4	not present
addr-spec	A5 OR A32	remote SIP URI of SS (i.e. the remote UE) as used in any previous request in the same dialog (In the earlier requests within the same dialog this URI appears in To header within requests sent by the UE and in From header within requests sent by the SS)
tag	A5 OR A32	remote tag of the dialog ID (In the earlier requests within the same dialog this tag appears in To header within requests sent by the UE and in From header within requests sent by the SS)
Call-ID				RFC 3261 [15]
callid	A4	value different to that received in REGISTER message
	A5 OR A32	value of Call-ID as in any previous request in the same dialog
Call-Info	A20,A21		Rel-14	RFC 8147 [149]
cid URL		any URL
purpose		EmergencyCallData.eCall.MSD
CSeq				RFC 3261 [15]
value	A4	must be present, value not checked
	A5 OR A32	value of CSeq sent by the UE within its previous request in the same dialog but increased by one
method		INVITE
Supported		The option tags defined below shall be included additionally to any option tags defined in any specific message content, unless specified otherwise in this specific message content.		RFC 3261 [15]
option-tag	A4 OR A5	100rel
	A13 OR A14	norefersub	Rel-11	RFC 4488 [126]
	A4 AND A26 AND NOT (A6 OR A7 OR A19 OR A20 OR A21)	timer		RFC 4028 [146]
P-Early-Media	A16 AND NOT (A5 OR A32)			RFC 5009 [138] IR.92 [133]
em-param		supported
Geolocation	A8		Rel-9	RFC 6442 [98]
locationURI		cid-url indicating the Content-Id of the PIDF-LO within the multipart MIME body of INVITE request. (Note that location-by-reference URI is not allowed as the SS does not provide any external storage for location info for the UE to refer.)
Geolocation	NOT A8	not present	Rel-9	RFC 6442 [98]
Geolocation-Routing	A8	“yes”	Rel-9	RFC 6442 [98]
Geolocation-Routing	NOT A8	not present	Rel-9	RFC 6442 [98]
Require	A1,A7			RFC 3261 [15]
	A6	not present
option-tag	A1,A7	sec-agree		RFC 3329 [21]
Proxy-Require	A1,A7			RFC 3261 [15] RFC 3329 [21]
	A6	not present
option-tag	A1,A7	sec-agree
Security-Verify	A1,A7			RFC 3329 [21]
	A2,A6	not present
sec-mechanism	A1,A7	same value as Security-Server header sent by SS
Contact				RFC 3261 [15]
addr-spec	(A1 OR A7) AND NOT A15	SIP URI with IP address or FQDN and protected server port of UE
	(A2 OR A19) AND NOT A15	SIP URI with IP address or FQDN and unprotected server port of UE
	A15 AND NOT A6	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response		RFC 5627 [61]
	A6	SIP URI with IP address and unprotected server port of UE
c-p-instance	A6	+sip.instance="<urn:gsma:imei: (gsma-specifier-defined-substring)>” where gsma-specifier-defined-substring shall be the IMEI code of the UE, coded as specified in RFC 7254 [122], without optional parameters	Rel-10	RFC 5626 [109] RFC 7254 [122]
	A3,A17,A29	+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" (see NOTE 2, 4)
feature-param	A10,A31	video		RFC 3840 [63]
	A12	+g.3gpp.srvcc-alerting		RFC 3840 [63]
	A30 OR (A22 AND (A23 OR A24))	audio		RFC 3840 [63]
	A18 AND NOT (A5 OR A32)	+g.3gpp.ps2cs-srvcc-orig-pre-alerting		RFC 3840 [63]
Max-Forwards				RFC 3261 [15]
value		non-zero value
P-Access-Network-Info	NOT A2			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A1 AND A27	access network information and, if applicable, the cell ID
	A28	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
P-Access-Network-Info	A2(o)	header optional
access-net-spec		access network information and, if applicable, the cell ID
Accept	NOT (A5 OR A32)		Rel-7	RFC 3261 [15]
	A5(o) , A32(o)	header optional
media-range	A4	application/sdp,application/3gpp-ims+xml (additional medias can be added in any order)
	A13	application/vnd.3gpp.mid-call+xml	Rel-11
	A14	application/vnd.3gpp.state-and-event-info+xml	Rel-11
	A20,A21,A25	application/EmergencyCallData.Control+xml	Rel-14	RFC 8147 [149]
P-Preferred-Service				RFC 6050 [68]
Service-ID	A3 AND A4	urn:urn-7:3gpp-service.ims.icsi.mmtel
P-Preferred-Identity				RFC 3325 [89]
PPreferredID-value	A7	emergency public user identity (NOTE 3)
Recv-Info				RFC 6086 [139]
Info-package-type	A14	g.3gpp.state-and-event
	A20,A21	EmergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Accept-Contact				RFC 3841 [64]
ac-value	A3 AND A4	+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" (see NOTE 2, 4)		TS 24.173 [65]
	A10 AND A11	video		IR.94 [134] NG.114 [157]
Proxy-Authorization	A17			RFC 2617 [16] RFC 3310 [17]
username	A17	preconfigured in the UE
realm	A17	same value as received in the realm directive in the Proxy-Authorization header sent by SS
nonce	A17	same value as in Proxy-Authorization header sent by SS
digest-uri	A17	preconfigured in the UE
qop-value	A17	auth
cnonce-value	A17	value assigned by UE affecting the response calculation
nonce-count	A17	counter to indicate how many times UE has sent the same value of nonce within successive INVITESs, initial value shall be 1
response	A17	response calculated by UE
algorithm	A17	MD5
Content-Type				RFC 3261 [15]
media-type	NOT A8 AND NOT A20 AND NOT A21 AND NOT A25	application/sdp
	A8, A20, A21, A25	multipart/mixed;boundary=any value		RFC 6442 [98] RFC 8147 [149]
Content-Length		header shall be present if UE uses TCP to send this message and if there is a message body		RFC 3261 [15]
Value		length of message-body
Message-body		consists of one or several parts as indicated by Content-Type, and each part having actual contents as follows (SDP contents, if any, is specified in dedicated sections)
	A8	a PIDF-LO element mapped to the same Content-ID which can be found from the Geolocation header The PIDF-LO shall contain at least the following elements: – One or more ‘geopriv’ elements, each containing: – One ‘location-info’ element describing the location of the UE; and – One ‘usage-rules’ element describing the limitations of the usage of the location info
	A20 OR A21 OR A25	–boundary value (as provided in SIP hdr Content-Type) Content-Type: application/EmergencyCallData.eCall.MSD Content-ID: same URL as in Call-Info header Content-Disposition: by-reference;handling=optional MSD in ASN.1 PER encoding –boundary value (as provided in SIP hdr Content-Type)	Rel-14	RFC 8147 [149]

Condition			Explanation
A1			IMS security (A.6a/2 3GPP TS 34.229-2 [5])
A2			GIBA (A.6a/1 3GPP TS 34.229-2 [5])
A3			UE supports MTSI (A.3A/50 3GPP TS 34.229-2 [5])
A4			INVITE creating a dialog
A5			re-INVITE within a dialog for session modification
A6			INVITE for creating an emergency session in case of no registration
A7			INVITE for creating an emergency session within an emergency registration using IMS security
A8			UE is capable of obtaining location information, has obtained its location and is setting up an emergency session
A9			Void
A10			UE supports video feature tag (A.12/32 3GPP TS 34.229-2 [5])
A11			INVITE for creating a video call
A12			INVITE for creating a voice or video call and UE supports g.3gpp.srvcc-alerting media feature tag (A.12/34 3GPP TS 34.229-2 [5])
A13			INVITE for creating a voice call during rSRVCC and UE CS to PS SRVCC with the MSC assisted mid-call feature (A.12/42 3GPP TS 34.229-2 [5])
A14			INVITE for creating a voice call and UE supports CS to PS SRVCC for calls in alerting phase (A.12/41 3GPP TS 34.229-2 [5])
A15			obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])
A16			UE supports early media (A.12/45 3GPP TS 34.229-2 [5])
A17			SIP Digest without TLS for Fixed Broadband Access (SIP Digest without TLS, A.6a/5 3GPP TS 34.229-2 [5])
A18			UE indicates g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag in INVITE request (A.12/36 3GPP TS 34.229-2 [5])
A19			INVITE for creating an emergency session within an emergency registration using GIBA
A20			INVITE for creating an eCall over IMS session manually
A21			INVITE for creating an eCall over IMS session automatically
A22			UE supports audio media feature tag (A.12/56 3GPP TS 34.229-2 [5])
A23			UE uses E-UTRAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.301 [150], clauses 8.2.1 and 9.9.3.12A
A24			UE uses UTRAN/GERAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.008 [12], clauses 9.4.2 and 10.5.5.23
A25			INVITE for creating a test eCall over IMS session
A26			UE supports Session Timer (A.12/57 3GPP TS 34.229-2 [5])
A27			UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A28			UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])
A29			UE includes mmtel ICSI value as per NG.114 V1.0 [157] (A.22/1 3GPP TS 34.229-2 [5])
A30			UE includes audio feature tag as per NG.114 V1.0 [157] (A.22/2 3GPP TS 34.229-2 [5])
A31			UE includes video feature tag as per NG.114 V1.0 [157] (A.22/3 3GPP TS 34.229-2 [5])
A32			re-INVITE within a dialog for purposes other than session modification

NOTE 1: All choices for applicable conditions are described for each header.

NOTE 2: The “=” may include optional linear white spaces according to the EQUAL definition in chapter 25.1, RFC 3261 [15].

NOTE 3: According to TS 24.229 clause 5.1.1.1A and 5.1.6.2 [10] when the UE is using ISIM the emergency public user identity is the first public user identity in the list stored in the ISIM; when there is no ISIM it is the default public user id if the UE registered or the temporary user id (derived from IMSI) else.

NOTE 4: URN is the outcome of URL encoding (“Percent-Encoding” according to RFC 3986 [129]) of urn:urn-7:3gpp-service.ims.icsi.mmtel.

A.2.2 100 Trying for INVITE

Header/param	Cond	Value/remark	Reference
Status-Line			RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		100
Reason-Phrase		Trying
Via			RFC 3261 [15]
via-parm		same value as received in INVITE message
From			RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag		same value as received in INVITE message
To			RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag	A1	not present
tag	A2	may be present, not checked
Call-ID			RFC 3261 [15]
callid		same value as received in INVITE message
CSeq			RFC 3261 [15]
value		same value as received in INVITE message
Content-Length	A1		RFC 3261 [15]
value		0

Condition	Explanation
A1	100 Trying sent from SS
A2	100 Trying sent from UE

A.2.3 183 Session Progress for INVITE

Header/param	Cond	Value/remark	Reference
Status-Line			RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		183
Reason-Phrase		Session Progress
Record-Route		order of the parameters in this header must be like in the respective rows	RFC 3261 [15]
rec-route	A1	<sip:pcscf.other.com;lr>, <sip:scscf.other.com;lr>, <sip:orig@scscf.3gpp.org;lr>, <sip:SS P-CSCF address: protected server port of SS;lr>
	A3	<sip:pcscf.other.com;lr>, <sip:scscf.other.com;lr>, <sip:orig@scscf.3gpp.org;lr>, <sip:SS P-CSCF address: unprotected server port of SS (optional);lr>
	A2	same value as received in INVITE
	A4	same value as received in INVITE
	A5	<sip:orig@ecscf.other.com;lr>, <sip:SS P-CSCF address:protected server port of SS;lr>
	A1 AND A15	not present
	A2 AND A15	any value if present
Via			RFC 3261 [15]
via-parm		same value as received in INVITE message
Require		The option tags defined below shall be included additionally to any option tags defined in any specific message content, unless specified otherwise in this specific message content.	RFC 3261 [15]
option-tag		100rel
From			RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag		same value as received in INVITE message
To			RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag	A1,A3, A5,A6	common to-tag (invite)
	A2,A4	any value
P-Asserted-Identity	A5		RFC 3325 [89]
addr-spec		A tel URI that can be recognized as valid emergency numbers if dialled by the user are specified in 3GPP TS 22.101 [39]. The emergency numbers 112 and 911 are stored on the ME, in accordance with 3GPP TS 22.101 [39]
uri-parameter		lr
Contact			RFC 3261 [15]
addr-spec	A1,A3	px_IMS_CalleeContactUri
	A2 AND NOT A9	SIP URI with IP address or FQDN and protected server port of UE
	A4 AND NOT A9	SIP URI with IP address or FQDN and unprotected server port of UE
	A2 AND A9	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response	RFC 5627 [61]
	A4 AND A9	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response	RFC 5627 [61]
	A1 AND A15	MO call has been established: px_IMS_CalleeContactUri MT call has been established: contact address sent by SS in dialog creating INVITE
	A2 AND A15	MO call has been established: contact address sent by UE in dialog creating INVITE MT call has been established: contact address sent by UE in response to dialog creating INVITE (NOTE : The ‘transport’ url parameter may change, url parameters are not checked)
feature-param		+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"(see NOTE 2, 3)
	A6	video
	A10	audio
	A11 AND A12 AND (A13 OR A14)	audio
Rseq			RFC 3262 [33]
response-num	A2,A4	any value
	A1,A3	121 (arbitrarily selected)
Call-ID			RFC 3261 [15]
callid		same value as received in INVITE message
CSeq			RFC 3261 [15]
value		same value as received in INVITE message
Feature-Caps			RFC 6809 [125]
feature-param	A8	+g.3gpp.ps2cs-srvcc-orig-pre-alerting	TS 24.237 [110]
Content-Type			RFC 3261 [15]
media-type		application/sdp
Content-Length	A1,A3		RFC 3261 [15]
value		length of message-body

Condition	Explanation
A1	183 sent by the SS (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A2	183 sent by the UE (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A3	183 sent by the SS (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A4	183 sent by the UE (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A5	183 sent by the SS for INVITE for a non-UE detectable emergency call
A6	UE supports video media feature tag (A.12/32 3GPP TS 34.229-2 [5])
A7	Void
A8	183 sent by the SS for a voice call and UE supports pre-alerting media feature tag (A.12/36 3GPP TS 34.229-2 [5])
A9	obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])
A10	Void
A11	Void
A12	UE supports audio media feature tag (A.12/56 3GPP TS 34.229-2 [5])
A13	UE uses E-UTRAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.301 [150], clauses 8.2.1 and 9.9.3.12A.
A14	UE uses UTRAN/GERAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.008 [12], clauses 9.4.2 and 10.5.5.23.
A15	183 sent for re-INVITE within an established dialog

NOTE1: All choices for applicable conditions are described for each header.

NOTE 2: The “=” may include optional linear white spaces according to the EQUAL definition in chapter 25.1, RFC 3261 [15].

NOTE 3: URN is the outcome of the URL encoding (“Percent-Encoding” according to RFC 3986 [129]) of urn:urn-7:3gpp-service.ims.icsi.mmtel.

A.2.4 PRACK

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		PRACK
Request-URI		same URI value as the recipient of PRACK has earlier sent in its Contact header within the same dialog
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by		same value as in preceding INVITE message
via-branch		value starting with ‘z9hG4bK’ (NOTE 1)
Route	A1,A2			RFC 3261 [15]
route-param		MO call (dialog creating INVITE sent by the UE): URIs of the Record-Route header field as specified in A.2.3 (183 Session Progress) for condition A1 and A3 in reverse order. MT call (dialog creating INVITE sent by the SS): URIs of the Record-Route header field as specified in A.2.9 (INVITE for MT Call) for conditions A1, A2 and A4.
From				RFC 3261 [15]
addr-spec		SIP URI of the UE when PRACK is sent by the UE, but SIP URI of the SS when PRACK is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.
tag		local tag of the dialog ID
To				RFC 3261 [15]
addr-spec		SIP URI of the SS when PRACK is sent by the UE, but SIP URI of the UE when PRACK is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.
tag		remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid		same value as received in INVITE message
CSeq				RFC 3261 [15]
value		value of CSeq sent by the endpoint within its previous request in the same dialog but increased by one
method		PRACK
Max-Forwards				RFC 3261 [15]
value		non-zero value
RAck				RFC 3262 [33]
response-num		same value as in RSeq header of the reliable response
cseq-num		same value as in CSeq of the reliable response
method		same value as in CSeq of the reliable response
P-Access-Network-Info	A1,A2(o)			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A6	access network information and, if applicable, the cell ID
	A7	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
Proxy-Authorization	A5			RFC 2617 [16] RFC 3310 [17]
username	A5	preconfigured in the UE
realm	A5	same value as received in the realm directive in the Proxy-Authorization header sent by SS
nonce	A5	same value as in Proxy-Authorization header sent by SS
digest-uri	A5	preconfigured in the UE
qop-value	A5	auth
cnonce-value	A5	value assigned by UE affecting the response calculation
nonce-count	A5	counter to indicate how many times UE has sent the same value of nonce within successive INVITEs, initial value shall be 1
response	A5	response calculated by UE
algorithm	A5	MD5
Content-Type		header shall be present only if there is SDP in Message-body		RFC 3261 [15]
media-type		application/sdp
Content-Length				RFC 3261 [15]
value		length of Message-body
Message-body		Optional SDP body. If included then the contents of the SDP shall be checked as described in the Test requirements section of the test case.		RFC 4566 [27] RFC 3264 [30] RFC 3312 [31]

Condition	Explanation
A1	PRACK sent by the UE (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A2	PRACK sent by the UE (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A3	PRACK sent by the SS (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A4	PRACK sent by the SS (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A5	SIP Digest without TLS for Fixed Broadband Access (SIP Digest without TLS, A.6a/5 3GPP TS 34.229-2 [5])
A6	UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A7	UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])

NOTE 1: Branch parameter values sent by SS are different within a test case execution.

A.2.5 UPDATE

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		UPDATE
Request-URI		same URI value as the recipient of UPDATE has earlier sent in its Contact header within the same dialog
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by	A1,A2	MO call: same value as in INVITE message MT call: as defined in A.2.1
	A3,A4	as defined in A.2.9 (There is more than one value)
via-branch		value starting with ‘z9hG4bK’ (NOTE 2)
Route	A1,A2			RFC 3261 [15]
route-param		MO call (dialog creating INVITE sent by the UE): URIs of the Record-Route header field as specified in A.2.3 (183 Session Progress) for condition A1 and A3 in reverse order. MT call (dialog creating INVITE sent by the SS): URIs of the Record-Route header field as specified in A.2.9 (INVITE for MT Call) for conditions A1, A2 and A4.
From
addr-spec		SIP URI of the UE when UPDATE is sent by the UE, but SIP URI of the SS when UPDATE is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.		RFC 3261 [15]
tag		local tag of the dialog ID
To				RFC 3261 [15]
addr-spec		SIP URI of the SS when UPDATE is sent by the UE, but SIP URI of the UE when UPDATE is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.
tag		remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid		same value as received in INVITE message
Contact	A1,A2	Must be present, value not checked		RFC 3261 [15] RFC 3311 [137]
	A3,A4	MO call: same Contact header as sent by SS in this dialog (e.g. in a 183 or 180 response) MT call: same value as used in MT INVITE
CSeq				RFC 3261 [15]
value		value of CSeq sent by the endpoint within its previous request in the same dialog but increased by one
method		UPDATE
Require	A1			RFC 3261 [15] RFC 3329 [21]
option-tag	A1	sec-agree
Proxy-Require	A1			RFC 3261 [15] RFC 3329 [21]
option-tag	A1	sec-agree
Max-Forwards				RFC 3261 [15]
value		non-zero value
Security-Verify	A1			RFC 3329 [21]
sec-mechanism		same value as Security-Server header sent by SS
Security-Verify	A2	not present		RFC 3329 [21]
sec-mechanism
P-Access-Network-Info	A1,A2(o)			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A5	access network information and, if applicable, the cell ID
	A6	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
Content-Type				RFC 3261 [15]
media-type		application/sdp
Content-Length	A3,A4			RFC 3261 [15]
value		length of message-body
Message-body		Contents of the SDP body shall be checked as described in the Test requirements section of the test case.		RFC 4566 [27] RFC 3264 [30] RFC 3312 [31]

Condition	Explanation
A1	UPDATE sent by the UE (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A2	UPDATE sent by the UE (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A3	UPDATE sent by the SS (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A4	UPDATE sent by the SS (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A5	UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A6	UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])

NOTE 1: All choices for applicable conditions are described for each header.

NOTE 2: Branch parameter values sent by SS are different within a test case execution.

A.2.6 180 Ringing for INVITE

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		180
Reason-Phrase		Ringing
Record-Route				RFC 3261 [15]
rec-route		as defined for the common 183 response, see A.2.3
	A7	<sip:orig@ecscf.other.com;lr>, <sip:SS P-CSCF address:unprotected server port of SS;lr>
	A8	<sip:orig@ecscf.other.com;lr>, <sip:SS P-CSCF address:protected server port of SS;lr>
Via				RFC 3261 [15]
via-parm		same value as received in INVITE message
Require		The option tags defined below shall be included additionally to any option tags defined in any specific message content, unless specified otherwise in this specific message content.		RFC 3261 [15]
option-tag	A3	100rel
From				RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag		same value as received in INVITE message
To				RFC 3261 [15]
addr-spec		same value as received in INVITE message
tag		as defined for the common 183 response, see A.2.3
P-Asserted-Identity	A4			RFC 3325 [89]
addr-spec		A tel URI that can be recognized as valid emergency numbers if dialled by the user are specified in 3GPP TS 22.101 [39]. The emergency numbers 112 and 911 are stored on the ME, in accordance with 3GPP TS 22.101 [39]
uri-parameter		lr
Contact				RFC 3261 [15]
addr-spec		as defined for the common 183 response, see A.2.3
feature-param	A5	+g.3gpp.srvcc-alerting
	A1	audio
	A2 AND A9 AND (A10 OR A11)	audio
RSeq				RFC 3262 [33]
response-num	A3 AND NOT A12	previous RSeq number sent in the same direction incremented by one
	A1 AND A12	122
	A2 AND A12	any value
Call-ID				RFC 3261 [15]
callid		same value as received in INVITE message
CSeq				RFC 3261 [15]
value		same value as received in INVITE message
P-Access-Network-Info	A2			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A13	access network information and, if applicable, the cell ID
	A14	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
P-Access-Network-Info	A1	not present
Feature-Caps
feature-param	A6	+g.3gpp.srvcc-alerting
Content-Length	A1			RFC 3261 [15]
value		length of message-body

Condition	Explanation
A1	180 sent by the SS
A2	180 sent by the UE
A3	Response sent reliably (e.g. always when it contains an SDP body)
A4	180 sent by the SS when setting up an emergency call or a non-UE detectable emergency call
A5	180 sent by the UE for a voice or video call and UE supports g.3gpp.srvcc-alerting media feature tag (A.12/34 3GPP TS 34.229-2 [5])
A6	180 sent by the SS for a voice or video call and UE supports g.3gpp.srvcc-alerting media feature tag (A.12/34 3GPP TS 34.229-2 [5])
A7	Response sent by SS for emergency call without emergency registration
A8	Response sent by SS for emergency call with emergency registration or a non-UE detectable emergency call
A9	UE supports audio media feature tag (A.12/56 3GPP TS 34.229-2 [5])
A10	UE uses E-UTRAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.301 [150], clauses 8.2.1 and 9.9.3.12A.
A11	UE uses UTRAN/GERAN access and has received IMS voice over PS Session Supported Indication in the NAS ATTACH ACCEPT message as described in TS 24.008 [12], clauses 9.4.2 and 10.5.5.23.
A12	180 Ringing is first provisional response sent reliably in this dialog
A13	UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A14	UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])

A.2.7 ACK

Header/param	Cond	Value/remark	Reference
Request-Line			RFC 3261 [15]
Method		ACK
Request-URI	NOT A4	same URI value as the recipient of ACK sent earlier in its Contact header within the same dialog
	A4	same value as in INVITE message
SIP-Version		SIP/2.0
Via			RFC 3261 [15]
sent-protocol	A1	SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
	A2	same value as in INVITE message
sent-by		same value as in INVITE message
via-branch	A3	value starting with ‘z9hG4bk’
	A4	same value as received in INVITE
Route			RFC 3261 [15]
route-param	A1 AND A3 AND (NOT A5)	URIs of the Record-Route header sent to the UE in 183, 180 or 200 response (whichever response used for INVITE to be acknowledged and contained Record-Route header) in reverse order
	A1 AND A4 AND (NOT A5)	Contents shall be the same as Route header sent in INVITE
	A1 AND A5	Contents shall be the same as Route header in re-INVITE
From			RFC 3261 [15]
addr-spec	A1	SIP URI of the UE as received in INVITE.
	A2	SIP URI of the SS as sent in INVITE
tag		local tag of the dialog ID (same as from-tag in the INVITE message)
To			RFC 3261 [15]
addr-spec	A1	SIP URI of the SS as received in INVITE.
	A2	SIP URI of the UE as sent in INVITE
tag		remote tag of the dialog ID (as chosen in an earlier response of the dialog)
Call-ID			RFC 3261 [15]
callid		same value as in INVITE message
CSeq			RFC 3261 [15]
value		same value as in INVITE message
method		ACK
Max-Forwards			RFC 3261 [15]
value		non-zero value
Content-Length	A2		RFC 3261 [15]
value		0

Condition	Explanation
A1	ACK sent by the UE
A2	ACK sent by the SS
A3	ACK for 2xx response
A4	ACK for non-2xx response
A5	ACK for re-INVITE

A.2.8 BYE

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		BYE
Request-URI		same URI value as the recipient of BYE has earlier sent in its Contact header within the same dialog
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by	A1,A2	MO Call has been established: same value as in INVITE message MT Call has been established: as defined in A.2.1
	A3,A4	as defined in A.2.9 (There is more than one value)
via-branch		value starting with ‘z9hG4bK’ (NOTE 1)
Route				RFC 3261 [15]
route-param	A1,A2	MO Call has been established: URIs of the Record-Route header of 183 response in reverse order (or any other response creating the dialog according to RFC 3261 clause 12.1 [15]) MT Call has been established: value of Record-Route header as defined in A.2.9
Route	A3,A4	not present
From				RFC 3261 [15]
addr-spec		SIP URI of the UE when BYE is sent by the UE. SIP URI of the SS when BYE is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.
tag		local tag of the dialog ID
To				RFC 3261 [15]
addr-spec		SIP URI of the SS when BYE is sent by the UE. SIP URI of the UE when BYE is sent by the SS. URI must be the same as used for the endpoint in the earlier requests within the dialog.
tag		remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid		same value as sent or received in INVITE message
CSeq				RFC 3261 [15]
value		value of CSeq sent by the endpoint within its previous request in the same dialog but increased by one
method		BYE
Require	(A1 OR A5) AND NOT A6			RFC 3261 [15] RFC 3329 [21]
option-tag	A1,A5	sec-agree
Require	A2, A6	not present
Proxy-Require	(A1 OR A5) AND NOT A6			RFC 3261 [15] RFC 3329 [21]
option-tag	A1,A5	sec-agree
Proxy-Require	A2,A6	not present
Security-Verify	(A1 OR A5) AND NOT A6			RFC 3329 [21]
sec-mechanism	A1,A5	same value as Security-Server header sent by SS
Security-Verify	A2,A6	not present
Max-Forwards				RFC 3261 [15]
value		non-zero value
P-Access-Network-Info	A1,A2(o)			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A7	access network information and, if applicable, the cell ID
	A8	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
Proxy-Authorization	A5			RFC 2617 [16] RFC 3310 [17]
username	A5	preconfigured in the UE
realm	A5	same value as received in the realm directive in the Proxy-Authorization header sent by SS
nonce	A5	same value as in Proxy-Authorization header sent by SS
digest-uri	A5	preconfigured in the UE
qop-value	A5	auth
cnonce-value	A5	value assigned by UE affecting the response calculation
nonce-count	A5	counter to indicate how many times UE has sent the same value of nonce within successive INVITESs, initial value shall be 1
response	A5	response calculated by UE
algorithm	A5	MD5
Content-Length	A3,A4			RFC 3261 [15]
value		length of message body

Condition	Explanation
A1	BYE sent by the UE (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A2	BYE sent by the UE (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A3	BYE sent by the SS (IMS security, A.6a/2 3GPP TS 34.229-2 [5])
A4	BYE sent by the SS (GIBA, A.6a/1 3GPP TS 34.229-2 [5])
A5	SIP Digest without TLS for Fixed Broadband Access (SIP Digest without TLS, A.6a/5 3GPP TS 34.229-2 [5])
A6	BYE for emergency call with no registration
A7	UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A8	UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])

NOTE 1: Branch parameter values sent by SS are different within a test case execution.

A.2.9 INVITE for MT Call

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		INVITE
Request-URI	A4	UE’s registered contact address in SIP URI form, as provided in the Contact header of the REGISTER message
	A5	UE’s contact address in SIP URI form, as provided in the Contact header within any response or request within the dialog
	A10	UE’s registered contact address in SIP URI form, as provided in the Contact header of the REGISTER message with the tag user = phone
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by	A1	The SS P-CSCF address and the SS protected server port
	A2	The SS P-CSCF address and the SS unprotected server port (optional)
via-branch		Value starting with ‘z9hG4bK’
Via		In addition to the via-parm entry for the SS, the following via-parm entries are included:		RFC 3261 [15]
via-parm		SIP/2.0/UDP scscf1.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP scscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP pcscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP caller.3gpp.org:6543;branch=z9hG4bK… (NOTE 2)
Record-Route				RFC 3261 [15]
rec-route	A1 AND A4	<sip: SS P-CSCF address: protected server port of SS ;lr>
	A2 AND A4	<sip: SS P-CSCF address: unprotected server port of SS (optional);lr>
Record-Route		In addition to the rec-route entry for the SS, the following rec-route entries are included:		RFC 3261 [15]
rec-route		<sip:term@scscf1.3gpp.org;lr>, <sip:orig@scscf2.3gpp.org;lr>, <sip:pcscf2.3gpp.org;lr>
Record-Route				RFC 3261 [15]
rec-route	A1 AND A5	MO call established: same value as in 183 Session Progress for INVITE, condition A1, in reverse order MT call established: <sip: SS P-CSCF address: protected server port of SS ;lr>
Record-Route				RFC 3261 [15]
rec-route	A2 AND A5	MO call established: same value as in 183 Session Progress for INVITE, condition A3, in reverse order MT call established: <sip: SS P-CSCF address: unprotected server port of SS (optional);lr>
From				RFC 3261 [15]
addr-spec	A4	SIP URI of the SS representing the calling UE
tag	A4	any value
addr-spec	A5	SIP URI of the SS representing the calling UE as used in any previous request in the same dialog (In the earlier requests within the same dialog this URI appears in To header within requests sent by the UE and in From header within requests sent by the SS)
tag	A5	local tag of the dialog ID
To				RFC 3261 [15]
addr-spec	A4	SIP URI of the UE’s default public user id
tag	A4	not present
addr-spec	A5	SIP URI of the UE as used in any previous request in the same dialog (In the earlier requests within the same dialog this URI appears in From header within requests sent by the UE and in To header within requests sent by the SS)
tag	A5	remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid	A4	a random text string generated by the SS
	A5	value of Call-ID as in any previous request in the same dialog
CSeq				RFC 3261 [15]
value	A4	any value (e.g. 4711)
	A5	value of CSeq sent by the SS within its previous request in the same dialog but increased by one
method		INVITE
Supported		The option tags defined below shall be included additionally to any option tags defined in any specific message content, unless specified otherwise in this specific message content.		RFC 3261 [15]
option-tag		100rel
		timer		RFC 4028 [146]
P-Called-Party-ID		One of the UE’s registered, non-barred public ID		RFC 7315 [132]
Contact				RFC 3261 [15]
addr-spec	A1	SIP URI with IP address or FQDN and protected server port of the calling UE, for example “sip:caller@3gpp.org:6543”
	A2	SIP URI with IP address or FQDN and unprotected server port of the calling UE
	A5	same contact information for the SS as used before in this dialog
feature-param	A3	+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" (NOTE 1)
	A7	video
		audio
Feature-Caps
feature-param	A9	g.3gpp.srvcc-alerting
Max-Forwards				RFC 3261 [15]
value		non-zero value
Accept			Rel-7	RFC 3261 [15]
media-range	A4	application/sdp, application/3gpp-ims+xml
P-Asserted-Service				RFC 6050 [68]
Service-ID	A3 AND A4	urn:urn-7:3gpp-service.ims.icsi.mmtel
Accept-Contact				RFC 3841 [64]
ac-value	A3 AND A4	*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel" (NOTE 1)		TS 24.173 [65]
ac-value	A8	video		IR.94 [134] NG.114 [157]
Content-Type				RFC 3261 [15]
media-type		application/sdp
Content-Length				RFC 3261 [15]
value		length of message-body

Condition	Explanation
A1	IMS security (A.6a/2 3GPP TS 34.229-2 [5])
A2	GIBA (A.6a/1 3GPP TS 34.229-2 [5])
A3	UE supports MTSI (A.3A/50 3GPP TS 34.229-2 [5])
A4	INVITE creating a dialog
A5	re-INVITE within a dialog
A6	Void
A7	UE supports video feature tag (A.12/32 3GPP TS 34.229-2 [5])
A8	INVITE for creating a video call and UE supports video media feature tag (A.12/32 3GPP TS 34.229-2 [5])
A9	INVITE for creating a voice or video call and UE supports g.3gpp.srvcc-alerting media feature tag (A.12/34 3GPP TS 34.229-2 [5])
A10	SIP Digest without TLS for Fixed Broadband Access (SIP Digest without TLS, A.6a/5 3GPP TS 34.229-2 [5])

NOTE 1: URN is the outcome of the URL encoding (“Percent-Encoding” according to RFC 3986 [129]) of urn:urn-7:3gpp-service.ims.icsi.mmtel.

NOTE 2: Branch parameter values sent by SS are different within a test case execution.

A.2.10 MO REFER

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		REFER
Request-URI		same URI value as the SS has earlier sent in its Contact header within the same dialog
SIP-Version		SIP/2.0
Via				RFC 3261 [15]
sent-protocol		SIP/2.0/UDP (when using UDP) or SIP/2.0/TCP (when using TCP)
sent-by	A1	IP address or FQDN and protected server port of the UE
	A2	IP address or FQDN and unprotected server port of the UE
via-branch		value starting with ‘z9hG4bK’
Route		order of the parameters in this header must be like in this table		RFC 3261 [15]
route-param	A1	URIs of the Record-Route header of 183 response in reverse order
	A2	URIs of the Record-Route header of 183 response in reverse order
From				RFC 3261 [15]
addr-spec		local SIP URI of the UE which must be the same URI as used for the UE in the earlier requests within the dialog
tag		local tag of the dialog ID
To				RFC 3261 [15]
addr-spec		SIP URI of the SS which must be the same URI as used by the UE in earlier requests within the dialog
tag		remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid		same value as in the first INVITE during the call setup
CSeq				RFC 3261 [15]
value		value of CSeq sent by the UE within its previous request in the same dialog but increased by one
method		REFER
Require	A1			RFC 3261 [15] RFC 3312 [31]
option-tag		sec-agree		RFC 3329 [21]

Proxy-Require	A1			RFC 3261 [15]
option-tag		sec-agree		RFC 3329 [21]
Security-Verify	A1			RFC 3329 [21]
sec-mechanism		same value as Security-Server header sent by SS
Security-Verify	A2	not present		RFC 3329 [21]
Contact				RFC 3261 [15] RFC 5627 [61]
addr-spec	A1	SIP URI with IP address or FQDN and protected server port of UE
	A2	SIP URI with IP address or FQDN and unprotected server port of UE
	A3	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response
Refer-To				RFC 3515 [72]
addr-spec		SIP or Tel URI of the transfer target (Note 1)
Max-Forwards				RFC 3261 [15]
value		non-zero value
P-Access-Network-Info	A1,A2(o)			RFC 7315 [132] RFC 7913 [154]
access-net-spec	A4	access network information and, if applicable, the cell ID
	A5	access network information for NR, containing access-class parameter with value "3GPP-NR" or access-type parameter with value "3GPP-NR-FDD" or "3GPP-NR-TDD", and also containing the cell ID	Rel-15
Content-Length		header shall be present if UE uses TCP to send this request and if there is a message-body		RFC 3261 [15]
value		length of message-body

Condition	Explanation
A1	IMS security (A.6a/2 3GPP TS 34.229-2 [5])
A2	GIBA (A.6a/1 3GPP TS 34.229-2 [5])
A3	obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])
A4	UE uses E-UTRAN access (A.18/1 3GPP TS 34.229-2 [5])
A5	UE uses NR access (A.18/5 3GPP TS 34.229-2 [5])

NOTE 1: The SIP URI may contain a "Replaces" header referring to the dialog ID which has been established before.

A.2.11 MT NOTIFY for refer package

Header/param	Cond	Value/remark	Reference
Request-Line			RFC 3261 [15]
Method		NOTIFY
Request-URI		same URI value which the UE sent in its Contact header within the REFER request
SIP-Version		SIP/2.0
Via		order of the parameters in this header must be like in this table	RFC 3261 [15]
via-parm1:
sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	A1	IP address and protected server port of SS
sent-by	A2	IP address and unprotected server port of SS (optional)
via-branch		value starting with ‘z9hG4bK’ (NOTE 1)
via-parm2:		In addition to the via-parm entry for the SS, the following via-parm entries are included:
		SIP/2.0/UDP scscf1.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP scscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP pcscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP uas.3gpp.org:6543;branch=z9hG4bK… (NOTE 1)
From			RFC 3261 [15]
addr-spec		SIP URI of the SS which must be the same URI as used for the SS in the earlier requests within the dialog
tag		local tag of the dialog ID
To			RFC 3261 [15]
addr-spec		SIP URI of the UE which must be the same as used for the UE in the earlier requests within the dialog.
tag		remote tag of the dialog ID
Call-ID			RFC 3261 [15]
callid		same value as in the INVITE (and REFER) message
CSeq	A1,A2		RFC 3261 [15]
value		value of CSeq sent by the SS within its previous request in the same dialog but increased by one
method		NOTIFY
Contact			RFC 3261 [15]
addr-spec	A1	SIP URI with IP address or FQDN and protected server port of the SS (transferee)
addr-spec	A2	SIP URI with IP address or FQDN and unprotected server port of the SS (transferee)
Event	A1,A2		RFC 6665 [140] RFC 3515 [72]
event-type		refer
Max-Forwards			RFC 3261 [15]
value		69
Subscription-State			RFC 6665 [140]
substate-value		active
expires		300
Content-Type			RFC 3261 [15] RFC 3680 [22]
media-type		message/sipfrag
Content-Length			RFC 3261 [15] RFC 3680 [22]
value		length of message-body

Condition	Explanation
A1	IMS security (A.6a/2 3GPP TS 34.229-2 [5])
A2	GIBA (A.6a/1 3GPP TS 34.229-2 [5])

NOTE 1: Branch parameter values sent by SS are different within a test case execution.

A.2.12 MT REFER

Header/param	Cond	Value/remark	Reference
Request-Line			RFC 3261 [15]
Method		REFER
Request-URI		same URI value as that which the UE has earlier sent in its Contact header within the dialog created by the INVITE sent by the UE when initiating the call to be transferred
SIP-Version		SIP/2.0
Via		order of the parameters in this header must be like in this table	RFC 3261 [15]
via-parm1:
sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	A1	IP address and protected server port of SS
sent-by	A2	IP address and unprotected server port of SS (optional)
via-branch		value starting with ‘z9hG4bK’
via-parm2:		In addition to the via-parm entry for the SS, the following via-parm entries are included:
		SIP/2.0/UDP scscf1.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP scscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP pcscf2.3gpp.org;branch=z9hG4bK…, SIP/2.0/UDP uas.3gpp.org:6543;branch=z9hG4bK… (NOTE 1)
From			RFC 3261 [15]
addr-spec		SIP URI of the SS which must be the same URI as used for the SS in the earlier requests within the dialog created by the INVITE sent by the UE when initiating the call to be transferred
tag		local tag of the dialog ID
To			RFC 3261 [15]
addr-spec		SIP URI of the UE which must be the same URI as used for UE in the earlier requests within the dialog created by the INVITE sent by the UE when initiating the call to be transferred
tag		remote tag of the dialog ID
Call-ID			RFC 3261 [15]
callid		same value as in the first INVITE sent by the UE during setup of the call to be transferred
CSeq			RFC 3261 [15]
value		value of CSeq sent by the SS within its previous request in the dialog created by the INVITE sent by the UE when initiating the call to be transferred, but increased by one
method		REFER
Contact			RFC 3261 [15]
addr-spec	A1	SIP URI with IP address or FQDN and protected server port of the SS (transferor)
	A2	SIP URI with IP address or FQDN and unprotected server port of the SS (transferor)
Refer-To			RFC 3515 [72]
addr-spec		SIP or Tel URI of the transfer target
Max-Forwards			RFC 3261 [15]
value		non-zero value
Content-Length			RFC 3261 [15]
value		length of message-body

Condition	Explanation
A1	IMS security (A.6a/2 TS 34.229-2 [5])
A2	GIBA (A.6a/1 TS 34.229-2 [5])

NOTE 1: Branch parameter values sent by SS are different within a test case execution.

A.2.13 MO NOTIFY for refer package

Header/param	Cond	Value/remark	Reference
Request-Line			RFC 3261 [15]
Method		NOTIFY
Request-URI		same URI value which the SS sent in its Contact header within the REFER request
SIP-Version		SIP/2.0
Via			RFC 3261 [15]
sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	A1	IP address or FQDN and protected server port of the UE
	A2	IP address or FQDN and unprotected server port of UE
via-branch		value starting with ‘z9hG4bK’
Route		order of the parameters in this header must be like in the respective rows	RFC 3261 [15]
route-param	A1	<sip:SS P-CSCF address: protected server port of SS ;lr>, <sip:scscf.3gpp.org;lr>
	A2	<sip:SS P-CSCF address: unprotected server port of SS (optional);lr>, <sip:scscf.3gpp.org;lr
From			RFC 3261 [15]
addr-spec		Local SIP URI of the UE which must be the same URI as used for the UE in the earlier requests within the dialog created by the INVITE sent by the UE when initiating the call to be transferred
tag		local tag of the dialog ID
To			RFC 3261 [15]
addr-spec		Remote SIP URI of the SS which must be the same as used for the SS in the earlier requests within the dialog created by the INVITE sent by the UE when initiating the call to be transferred.
tag		remote tag of the dialog ID
Call-ID			RFC 3261 [15]
callid		same value as in the INVITE (and REFER) message
CSeq	A1,A2		RFC 3261 [15]
value		value of CSeq sent by the SS within its previous request in the dialog created by the INVITE sent by the UE when initiating the call to be transferred, but increased by one
method		NOTIFY
Contact			RFC 3261 [15] RFC 5627 [61]
addr-spec	A1	SIP URI with IP address or FQDN and protected server port of the UE or GRUU as returned by the SS in registration
	A2	SIP URI with IP address or FQDN and unprotected server port of UE or GRUU as returned by the SS in registration
	A3	Public GRUU as obtained during registration as pub-gruu contact parameter of the 200 OK for REGISTER response
Event	A1,A2		RFC 6665 [140] RFC 3515 [72]
event-type		refer
Max-Forwards			RFC 3261 [15]
value		non-zero value
Subscription-State			RFC 6665 [140]
substate-value		active
expires		non-zero value
Content-Type			RFC 3261 [15]
media-type		message/sipfrag	RFC 3680 [22]
Content-Length		header shall be present if UE uses TCP to send this request and if there is a message-body	RFC 3261 [15] RFC 3680 [22]
value		length of message-body

Condition	Explanation
A1	IMS security (A.6a/2 TS 34.229-2 [5])
A2	GIBA (A.6a/1 TS 34.229-2 [5])
A3	obtaining and using GRUUs in the Session Initiation Protocol (SIP) (A.4/53 3GPP TS 34.229-2 [5])

A.2.14 181 Call is being forwarded

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	181
Reason-Phrase	Call is being forwarded
Via		RFC 3261 [15]
via-parm	same value as received in INVITE message
From		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	local tag of the dialog ID
To		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	remote tag of the dialog ID
History-Info		RFC 7044 [83]
hi-targeted-to-uri	<sip:user@company.com>
hi-index	1
Call-ID		RFC 3261 [15]
callid	same value as received in INVITE message
CSeq		RFC 3261 [15]
value	same value as received in INVITE message
Content-Length		RFC 3261 [15]
value	0

A.2.15 CANCEL

Header/param	Value/remark	Reference
Request-Line		RFC 3261 [15]
Method	CANCEL
Request-URI	same value as in the INVITE being cancelled
SIP-Version	SIP/2.0
Via		RFC 3261 [15]
via-parm	same value as in the INVITE being cancelled
From		RFC 3261 [15]
addr-spec	same value as in the INVITE being cancelled
tag	same value as in the INVITE being cancelled
To		RFC 3261 [15]
addr-spec	same value as in the INVITE being cancelled
Call-ID		RFC 3261 [15]
callid	same value as in the INVITE being cancelled
CSeq		RFC 3261 [15]
value	same value as received in INVITE message
method	CANCEL
Content-Length		RFC 3261 [15]
value	0

A.2.16 487 Request Terminated

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	487
Reason-Phrase	Request Terminated
Via		RFC 3261 [15]
via-parm	same value as received in INVITE message
From		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as received in INVITE message
To		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as in 200 OK for the corresponding CANCEL request
Call-ID		RFC 3261 [15]
callid	same value as received in INVITE message
CSeq		RFC 3261 [15]
value	same value as received in INVITE message
Content-Length	optional when sent by UE	RFC 3261 [15]
value	0

A.2.17 404 Not Found

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	404
Reason-Phrase	Not Found
Via		RFC 3261 [15]
via-parm	same value as received in INVITE message
From		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as received in INVITE message
To		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as in an earlier responses sent to the UE for this dialog
Call-ID		RFC 3261 [15]
callid	same value as received in INVITE message
CSeq		RFC 3261 [15]
value	same value as received in INVITE message
Content-Length		RFC 3261 [15]
value	0

A.2.18 481 Call/Transaction Does Not Exist

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	481
Reason-Phrase	Call/Transaction Does Not Exist
Via		RFC 3261 [15]
via-parm	same value as received in request
From		RFC 3261 [15]
addr-spec	same value as received in request
tag	same value as received in request
To		RFC 3261 [15]
addr-spec	same value as received in request
tag	any arbitrary tag value added
Call-ID		RFC 3261 [15]
callid	same value as received in request
CSeq		RFC 3261 [15]
value	same value as received in request
Content-Length		RFC 3261 [15]
value	0

A.2.19 MO INFO for eCall over IMS

Header/param	Cond	Value/remark	Rel	Reference
Request-Line				RFC 3261 [15]
Method		INFO		RFC 6086 [139]
Request-URI		same URI as SS sent in its Contact header before when it sent 200 OK for INVITE
SIP-Version		SIP/2.0
Via		order of the parameters in this header must be like in this table		RFC 3261 [15] RFC 3581 [96]
sent-protocol		SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by		IP address or FQDN and protected server port of the UE
via-branch		value starting with ‘z9hG4bK’
From				RFC 3261 [15]
addr-spec		SIP URI of the UE		TS 24.229 [10]
tag		local tag of the dialog ID
To				RFC 3261 [15]
addr-spec	A1	urn:service:sos.ecall.manual	Rel-14	TS 24.229 [10] RFC 8147 [149]
	A2	urn:service:sos.ecall.automatic	Rel-14	TS 24.229 [10] RFC 8147 [149]
tag		remote tag of the dialog ID
Call-ID				RFC 3261 [15]
callid		same as value received in INVITE message
CSeq				RFC 3261 [15]
value		value of CSeq sent by the UE within its previous request in the same dialog but increased by one
method		INFO
Call-Info
cid URL		any URL	Rel-14	RFC 8147 [149]
purpose	A3	EmergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
	A4	EmergencyCallData.Control	Rel-14	RFC 8147 [149]
Info-Package		EmergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Content-Type				RFC 3261 [15]
media-type		multipart/mixed;boundary=any value		TS 24.229 [10]
Content-Length				RFC 3261 [15]
value		length of message-body
Content-Disposition				RFC 3261 [15]
disp-type		Info-Package	Rel-14	RFC 8147 [149]
Message-body
	A3	–boundary value (as provided in Content-Type) Content-Type: application/EmergencyCallData.eCall.MSD Content-ID: same cid as in Call-Info header Content-Disposition: by-reference MSD in ASN.1 PER encoding –boundary value (as provided in Content-Type)	Rel-14	RFC 8147 [149]
	A4	–boundary value (as provided in Content-Type) Content-Type: application/EmergencyCallData.Control+xml Content-ID: same cid as in Call-Info header Content-Disposition: by-reference <?xml version=”1.0” encoding=”UTF-8”?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <ack ref=cid of the body part of corresponding INFO request from SS> <actionResult action=”send-data” success=”false” reason=any value/> </ack> </EmergencyCallData.Control> –boundary value (as provided in Content-Type)	Rel-14	RFC 8147 [149]

Condition	Explanation
A1	eCall over IMS was started manually
A2	eCall over IMS was started automatically
A3	UE able to provide an updated MSD
A4	UE not able to provide an updated MSD

A.2.20 MT INFO for eCall over IMS

Header/param	Value/remark	Rel	Reference
Request-Line			RFC 3261 [15]
Method	INFO		RFC 6086 [139]
Request-URI	same URI as UE sent in Contact header of INVITE		RFC 8147 [149]
SIP-Version	SIP/2.0
Via	order of the parameters in this header must be like in this table		RFC 3261 [15] RFC 3581 [96]
via-parm1:
sent-protocol	SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	IP address and protected server port of SS
via-branch	value starting with ‘z9hG4bK’
via-parm2:
sent-protocol	SIP/2.0/UDP when using UDP or SIP/2.0/TCP when using TCP
sent-by	psap.3gpp.org
via-branch	value starting with ‘z9hG4bK’
From			RFC 3261 [15]
addr-spec	SIP URI of PSAP		TS 24.229 [10] RFC 8147 [149]
tag	remote tag of the dialog ID
To			RFC 3261 [15]
addr-spec	SIP URI of UE		TS 24.229 [10] RFC 8147 [149]
tag	local tag of the dialog ID
Call-ID			RFC 3261 [15]
callid	same as value received in INVITE message
CSeq			RFC 3261 [15]
value	value of CSeq sent by the SS within its previous request in the same dialog but increased by one. If this is first request sent by SS, any value is used (e.g. 4711).
method	INFO
Call-Info
cid URL	<cid:test-info@3gpp.org>	Rel-14	RFC 8147 [149]
purpose	EmergencyCallData.Control	Rel-14	RFC 8147 [149]
Info-Package	EmergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Content-Type			RFC 3261 [15]
media-type	multipart/mixed;boundary=boundaryXXX	Rel-14	TS 24.229 [10]
Content-Length
value	length of message-body
Content-Disposition
disp-type	Info-Package	Rel-14	RFC 8147 [149]
Message-body	–boundaryXXX Content-Type: application/EmergencyCallData.Control+xml Content-ID: <test-info@3gpp.org> Content-Disposition: by-reference <?xml version="1.0" encoding="UTF-8"?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <request action="send-data" datatype="eCall.MSD"/> </EmergencyCallData.Control> –boundaryXXX	Rel-14	RFC 8147 [149]

A.2.21 486 Busy Here

Header/param	Cond	Value/remark	Reference
Status-Line			RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		486
Reason-Phrase		Busy Here
Via			RFC 3261 [15]
via-parm		same value as received in request
From			RFC 3261 [15]
addr-spec		same value as received in request
tag		same value as received in request
To			RFC 3261 [15]
addr-spec		same value as received in request
tag		any arbitrary tag value added
Call-ID			RFC 3261 [15]
callid		same value as received in request
CSeq			RFC 3261 [15]
value		same value as received in request
Recv-Info	A1
Info-package-type		emergencyCallData.eCall.MSD	RFC 8147 [149]
Call-Info	A1
cid URL		<cid:test-486@3gpp.org>	RFC 8147 [149]
purpose		EmergencyCallData.eCall.Control	RFC 8147 [149]
Accept	A1
media-range		application/sdp, application/pidf+xml, application/EmergencyCallData.Control+xml, application/emergencyCallData.eCall.MSD	RFC 8147 [149]
Content-Type	A1
media-type		multipart/mixed;boundary=boundary1	RFC 8147 [149]
Content-Length			RFC 3261 [15]
value		length of message body
Message-body	A1	—boundary1 Content-Type: application/EmergencyCallData.eCall.Control+xml Content-ID: <test-486@3gpp.org> Content-Disposition: by-reference <?xml version="1.0" encoding="UTF-8"?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <ack received="true" ref="addr-spec of the Content-ID of MIME body part containing the MSD sent by the UE in INVITE”/> </EmergencyCallData.Control> –boundary1	RFC 8147 [149]

Condition	Explanation
A1	Response sent by SS for INVITE for eCall over IMS

A.2.22 600 Busy Everywhere

Header/param	Cond	Value/remark	Rel	Reference
Status-Line				RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		600
Reason-Phrase		Busy Everywhere
Via				RFC 3261 [15]
via-parm		same value as received in request
From				RFC 3261 [15]
addr-spec		same value as received in request
tag		same value as received in request
To				RFC 3261 [15]
addr-spec		same value as received in request
tag		any arbitrary tag value added
Call-ID				RFC 3261 [15]
callid		same value as received in request
CSeq				RFC 3261 [15]
value		same value as received in request
Recv-Info	A1
Info-package-type		emergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Call-Info	A1
cid URL		<cid:test-600@3gpp.org>
purpose		EmergencyCallData.eCall.Control	Rel-14	RFC 8147 [149]
Accept	A1
media-range		application/sdp, application/pidf+xml, application/EmergencyCallData.Control+xml, application/emergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Content-Type	A1
media-type		multipart/mixed;boundary=boundary1	Rel-14	RFC 8147 [149]
Content-Length				RFC 3261 [15]
value		length of message body
Message-body	A1	—boundary1 Content-Type: application/EmergencyCallData.eCall.Control+xml Content-ID: <test-600@3gpp.org> Content-Disposition: by-reference <?xml version="1.0" encoding="UTF-8"?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <ack received="true" ref="addr-spec of the Content-ID of MIME body part containing the MSD sent by the UE in INVITE”/> </EmergencyCallData.Control> –boundary1	Rel-14	RFC 8147 [149]

Condition	Explanation
A1	Response sent by SS for INVITE for eCall over IMS

A.2.23 603 Decline

Header/param	Cond	Value/remark	Rel	Reference
Status-Line				RFC 3261 [15]
SIP-Version		SIP/2.0
Status-Code		603
Reason-Phrase		Decline
Via				RFC 3261 [15]
via-parm		same value as received in request
From				RFC 3261 [15]
addr-spec		same value as received in request
tag		same value as received in request
To				RFC 3261 [15]
addr-spec		same value as received in request
tag		any arbitrary tag value added
Call-ID				RFC 3261 [15]
callid		same value as received in request
CSeq				RFC 3261 [15]
value		same value as received in request
Recv-Info				RFC 6086 [139]
Info-package-type	A1	emergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Call-Info
cid URL	A1	<cid:test-603@3gpp.org>	Rel-14
purpose	A1	EmergencyCallData.eCall.Control	Rel-14	RFC 8147 [149]
Accept
media-range		application/sdp, application/pidf+xml, application/EmergencyCallData.Control+xml, application/emergencyCallData.eCall.MSD	Rel-14	RFC 8147 [149]
Content-Type
media-type	A1	multipart/mixed;boundary=boundary1		RFC 8147 [149]
Content-Length				RFC 3261 [15]
value		length of message body
Message-body	A1	—boundary1 Content-Type: application/EmergencyCallData.eCall.Control+xml Content-ID: <test-603@3gpp.org> Content-Disposition: by-reference <?xml version="1.0" encoding="UTF-8"?> <EmergencyCallData.Control xmlns="urn:ietf:params:xml:ns:EmergencyCallData:control"> <ack received="true" ref="addr-spec of the Content-ID of MIME body part containing the MSD sent by the UE in INVITE”/> </EmergencyCallData.Control> –boundary1	Rel-14	RFC 8147 [149]

Condition	Explanation
A1	Response sent by SS for INVITE for eCall over IMS

A.2.24 422 Session Interval Too Small

Header/param	Value/remark	Rel	Reference
Status-Line		Rel-8	RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	422		RFC 4028 [146]
Reason-Phrase	Session Interval Too Small		RFC 4028 [146]
Via		Rel-8	RFC 3261 [15]
via-parm	same value as received in request
From		Rel-8	RFC 3261 [15]
addr-spec	same value as received in request
tag	same value as received in request
To		Rel-8	RFC 3261 [15]
addr-spec	same value as received in request
tag	any arbitrary tag value added
Call-ID		Rel-8	RFC 3261 [15]
callid	same value as received in request
CSeq		Rel-8	RFC 3261 [15]
value	same value as received in request
Min-SE		Rel-8	RFC 4028 [146]
delta-seconds	value shall be greater than or equal to 90
Content-Length		Rel-8	RFC 3261 [15]
value	0

A.2.25 420 Bad Extension for INVITE

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	420
Reason-Phrase	Bad Extension
Via		RFC 3261 [15]
via-parm	same value as received in INVITE message
From		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as received in INVITE message
To		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as received in INVITE message or any value added if missing from request
Call-ID		RFC 3261 [15]
callid	same value as received in INVITE message
CSeq		RFC 3261 [15]
value	same value as received in INVITE message
Unsupported		RFC 3261 [15]
option-tag	the unsupported option-tag(s) are test case specific

A.2.26 199 Early Dialog Terminated

Header/param	Value/remark	Reference
Status-Line		RFC 3261 [15]
SIP-Version	SIP/2.0
Status-Code	199
Reason-Phrase	Early Dialog Terminated
Via		RFC 3261 [15]
via-parm	same value as received in INVITE message
From		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	same value as received in INVITE message
To		RFC 3261 [15]
addr-spec	same value as received in INVITE message
tag	remote tag of the dialog
Call-ID		RFC 3261 [15]
callid	same value as received in INVITE message
CSeq		RFC 3261 [15]
value	same value as received in INVITE message