7.2.3 SIP-ISUP protocol interworking

29.1633GPPInterworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networksTS

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

When a coding of a parameter value is omitted it implies that it is not affected by the interworking and the values are assigned by normal protocol procedures.

7.2.3.1 Incoming call interworking from SIP to ISUP at I-MGCF

7.2.3.1.1 Sending of IAM

On reception of a SIP INVITE requesting a session, the I‑MGCF shall send an IAM message. The allowed sessions are given in clause 7.2.3.1.2.5.

An I-MGCF shall support both incoming INVITE requests containing SIP preconditions and 100rel extensions in the SIP Supported or Require header fields, and INVITE requests not containing these extensions, unless the Note below applies.

NOTE: If the I-MGCF is deployed in an IMS network that by local configuration serves no user requiring preconditions, the MGCF may not support incoming requests requiring preconditions.

The I-MGCF shall interwork forked INVITE requests with different request URIs.

If the SIP precondition extension is not included in the Supported or Require header field, the I-MGCF shall send an IAM immediately after the reception of the INVITE, as shown in figure 3. The I-MGCF shall set the continuity indicators to "Continuity check not required".

If a Continuity Check procedure is supported in the ISUP network and SIP precondition extension are included in the SIP Supported or Require header field, the I-MGCF shall send the IAM immediately after the reception of the INVITE, as shown in figure 3. If the received SDP indicates that precondition is fulfilled the I-MGCF shall set the continuity indicators to "continuity check is not required". If the received SDP indicates that precondition is not fulfilled the I-MGCF shall set the continuity indicators to "continuity check performed on a previous circuit". The procedure in figure 3 applies when the value of the continuity indicator is either set to "continuity check required", "continuity check performed on a previous circuit" or "continuity check not required". If the continuity indicator is set to "continuity check required" the corresponding procedures at the Mn interface described in clause 9.2.2.3 also apply.

Figure 3: Receipt of an INVITE request (continuity procedure supported in the ISUP network)

If Continuity Check procedure is not supported in the ISUP network, and the SDP in the received INVITE request contains preconditions not met, the I-MGCF shall delay sending the IAM until the SIP preconditions are met and set the continuity indicators in the resulting IAM to "Continuity check not required".

Figure 4: Receipt of an INVITE request (continuity procedure not supported in the ISUP network)

The I-MGCF shall reject an INVITE request for a session only containing unsupported media types by sending a status code 488 "Not Acceptable Here". If several media streams are contained in a single INVITE request, and if the I-MGCF does not support multimedia interworking according to Annex E, then the I-MGCF shall select one of the supported media streams, reserve the codec(s) for that media stream, and reject the other media streams and unselected codecs in the SDP answer, as detailed in IETF RFC 3264 [36]. If supported audio media stream(s) and supported non-audio media stream(s) are contained in a single INVITE request, an audio stream should be selected.

The I-MGCF shall include a To tag in the first backward non-100 provisional response, in order to establish an early dialog as described in IETF RFC 3261 [19].

If an MGCF discovers an emergency call it shall, depending on national requirements, map that to appropriate indication in ISUP.

According to IETF RFC 3261 [19] and IETF RFC 3264 [36], if an INVITE message is received without an SDP offer, then the I-MGCF sends an SDP offer in the first reliable non-failure message.

7.2.3.1.2 Coding of the IAM

7.2.3.1.2.0 General

The following ISDN user part parameters description can be found in ITU-T Recommendation Q.763 [4].

7.2.3.1.2.1 Called party number

The E.164 address encoded in the Request-URI shall be mapped to the called party number parameter of the IAM message.

Table 2: Coding of the called party number

INVITE

IAM

Request-URI

Called Party Number

E.164 address

(format +CC NDC SN)

(e.g. as User info portion of a SIP URI with user=phone, or as tel URI)

Address Signal:

Analyse the information contained in received E.164 address.

If CC is country code of the network in which the next hop terminates, then remove "+CC" and use the remaining digits to fill the Address signals.

If CC is not the country code of the network in which the next hop terminates, then remove "+" and use the remaining digits to fill the Address signals.
(NOTE 2)

Odd/even indicator: set as required

Nature of address indicator:

Analyse the information contained in received E.164 address.

If CC is country code of the network in which the next hop terminates, then set Nature of Address indicator to "National (significant) number.

If CC is not the country code of the network in which the next hop terminates, then set Nature of Address indicator to "International number".

(NOTE 1)

Internal Network Number Indicator:

1 routing to internal network number not allowed

Numbering plan Indicator:

001 ISDN (Telephony) numbering plan (Rec. E.164)

national operator option for service numbers:

Non E.164 numbers

(as a local-number with a phone-context in the User Info portion in a SIP URI with user=phone, or as a local number with a phone-context in a tel URI)

(NOTE 3)

Address Signal:

use received non E.164 number to fill the Address signals with national significant number.

Odd/even indicator: set as required

Nature of address indicator:

"National (significant) number". (NOTE 1)

Internal Network Number Indicator:

1 routing to internal network number not allowed

Numbering plan Indicator:

001 ISDN (Telephony) numbering plan (Rec. E.164)

(NOTE 3)

Address Signal:

Use received non E.164 number to fill the Address signals.

Odd/even indicator: set as required

Nature of address indicator:

set Nature of Address indicator to "network-specific number" or to "reserved for national use".

Internal Network Number Indicator:

1 routing to internal network number not allowed

Numbering plan Indicator:

Based on operator policy other numbering plan indicators than "001 ISDN (Telephony) numbering plan (Rec. E.164)" can be used e.g. depending on phone context value.

NOTE 1: The usage of "nature of address indicator" value "unknown" is allowed but the mapping is not specified in the present specification.

NOTE 2: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN XML sendingCompleteIndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) in the address signals field of the Called Party Number parameter.

NOTE 3: Depending on configuration, network-specific numbers (identified by phone context according to operator policy) should be translated into "ISDN (Telephony) numbering plan numbers (Rec. E.164)" unless such a mapping is not possible and local operator’s policy requires keeping them in local format.

7.2.3.1.2.2 Nature of connection indicators

bits BA Satellite indicator

0 0 no satellite circuit in the connection

bits DC Continuity check indicator

0 0 continuity check not required, if the continuity check procedure is not supported in the succeeding network (figure 4).

0 1 continuity check required, if a continuity check shall be carried out on the succeeding circuit.
(figure 3)

1 0 continuity check performed on a previous circuit otherwise, if the continuity check procedure is supported in the succeeding network, but shall not be carried out on the succeeding circuit otherwise. (figure 3)

bit E Echo control device indicator

1 outgoing echo control device included, for speech calls, e.g., TMR is "3.1KHz audio".

0 outgoing echo control device not included, for known data calls, e.g., TMR "64 kBit/s unrestricted" or HLC "Facsimile Group 2/3".

7.2.3.1.2.3 Forward call indicators

bits CB End-to-end method indicator

0 0 no end-to-end method available (only link-by-link method available)

bit D Interworking indicator

1 interworking encountered

As a network operator option, the value D = 0 "No interworking encountered" is used if the TMR = 64 kBit/s unrestricted is used.

NOTE: This avoids sending of a progress indicator with progress information 0 0 0 0 0 0 1 "Call is not end-to-end ISDN; further call progress information may be available in‑band", so the call will not be released for that reason by an ISDN terminal.

bit E End-to-end information indicator (national use)

0 no end-to-end information available

bit F ISDN user part/BICC indicator

0 ISDN user part/BICC not used all the way

As a network operator option, the value F = 1 "ISDN user part/BICC used all the way" is used if the TMR = 64 kBit/s unrestricted is used.

bits HG ISDN user part/BICC preference indicator

if any used supplementary service requires ISUP or BICC all the way, depending on operator policy:

0 0 ISDN user part/BICC preferred all the way, or

1 0 ISDN user part/BICC required all the way;

Otherwise:

0 1 ISDN user part/BICC not required all the way

bit I ISDN access indicator

0 originating access non-ISDN

As a network operator option, the value I = 1 "originating access ISDN" is used if the TMR = 64 kBit/s unrestricted is used.

NOTE: This avoids sending of a progress indicator with progress information 0 0 0 0 1 1 "Originating access is non-ISDN", so the call will not be released for that reason by an ISDN terminal.

bits KJ SCCP method indicator

0 0 no indication

If the PSTN XML is supported as a network option, the Forward Call indicators derived as shown in Table 02a shall take precedence.

Table 02a: Mapping of PSTN XML elements to Forward call indicators parameter

INVITE 	IAM 
PSTN XML	Forward call indicators parameter
PSTN XML with Progress indicator with Progress Description value 6 (Meaning: originating access ISDN)	bit D Interworking Indicator 0 "no interworking encountered (No. 7 signalling all the way)" bit F ISDN User Part indicator 1 "ISDN User Part used all the way" bit I ISDN access indicator 1 "originating access ISDN"
NOTE: Progress Indicator with Progress Description value "6" shall not be included in an ATP within the IAM.

7.2.3.1.2.4 Calling party’s category

See ANNEX C for the normative interworking of the CPC parameter.

7.2.3.1.2.4A Originating Line Information

The ISUP Originating Line Information parameter is defined by ANSI Standard ATIS-1000113 [117], Chapter 3.

See Annex H for the normative interworking of the OLI parameter as a network option.

7.2.3.1.2.5 Transmission medium requirement

The I-MGCF may either transcode the selected codec(s) to the codec on the PSTN side or it may attempt to interwork the media without transcoding. If the I-MGCF transcodes, it shall select the TMR parameter to "3.1 kHz audio". If the I-MGCF does not transcode, it should map the TMR, USI and Access Transport parameters from the selected codec according to Table 2a. However, if the I-MGCF supports the PSTN XML body as a network option, and if a PSTN XML body is received in the INVITE request and the I-MGCF selects media encoded in any of the formats in table 2a (G.711, Clearmode or t38) among the offered media, the I-MGCF shall derive these parameters from the XML body instead, as detailed in table 2b. The I-MGCF should only apply the mapping in table 2b if the TMR and USI values derived from the selected codec according to table 2a are equivalent with the values within the first Bearer Capability element in the PSTN XML, and otherwise the I-MGCF should apply the mapping according to table 2a.

The support of any of the media listed in table 2a is optional.

If no SDP is received from the remote peer (as described in clause 7.2.3.1.1), then the TMR parameter should be set to "3.1 kHz audio". Transcoding shall be applied as required.

Table 2a: Coding of TMR/USI/HLC from SDP: SIP to ISUP

	m= line		b= line (NOTE 4)	a= line	TMR parameter	USI parameter (optional) (NOTE 1)		HLC IE in the ATP parameter (optional)
<media>	<transport>	<fmt-list>	<modifier>:<bandwidth-value> (NOTE 5)	rtpmap:<dynamic-PT> <encoding name> <clock rate>[<encoding parameters>]	TMR codes	Information Transfer Capability	User Information Layer 1 Protocol Indicator	High Layer Characteristics Identification
audio	RTP/AVP	0	N/A or AS: up to (64 kbit/s + RTP/UDP/IP overhead)	N/A	"3.1KHz audio"			(NOTE 3)
audio	RTP/AVP	Dynamic PT	N/A or AS: up to (64 kbit/s + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> PCMU/8000	"3.1KHz audio"			(NOTE 3)
audio	RTP/AVP	8	N/A or AS: up to (64 kbit/s+ RTP/UDP/IP overhead)	N/A	"3.1KHz audio"			(NOTE 3)
audio	RTP/AVP	Dynamic PT	N/A or AS: up to (64 kbit/s + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> PCMA/8000	"3.1KHz audio"			(NOTE 3)
audio	RTP/AVP	Dynamic PT	AS: (64 kbit/s+ RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> CLEARMODE/8000 (NOTE 2)	"64 kbit/s unrestricted" or "64 kbit/s preferred" (NOTE 7)	"Unrestricted digital information" (NOTE 6)
image	Udptl [73]	t38 [73]	N/A or AS: up to (64 kbit/s + UDP/IP overhead)	Based on ITU-T T.38 [72] (NOTE 8)	"3.1 KHz audio"	"3.1 KHz audio"		"Facsímile Group 2/3"
image	tcp	t38 [73]	N/A or AS: up to (64 kbit/s + TCP/IP overhead)	Based on ITU-T T.38 [72]	"3.1 KHz audio"	"3.1 KHz audio"		"Facsímile Group 2/3"
NOTE 1: In this table the codec G.711 is used only as an example. Other codecs are possible. NOTE 2: CLEARMODE is specified in RFC4040 [69]. NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 indicates that this would normally be accompanied by a value of "Speech" for the Information Transfer Capability element. NOTE 4: The MGCF should return an b:AS bandwidth modifier with a bandwidth of 64kbit/s + RTP/UDP/IP overhead in the SDP answer to request that the peer does not send with a higher bandwidth. If the received b=line indicates a bandwidth greater than 64kbit/s + RTP/UDP/IP overhead, the MGCF should also accept the incoming call. NOTE 5: <bandwidth value> for <modifier> of AS is in units of kbit/s. NOTE 6: In the case where the Clearmode codec appears together with speech codecs in the same m-line, the value "Unrestricted digital inf. w/tones/ann" is applicable but is mapped into the USI prime parameter (see clause 7.2.3.1.2.5a). NOTE 7: The value "64 k/bits preferred" should only be used if the Clearmode codec appears together with speech codecs in the same m-line and two PSTN XML Bearer Capability elements appear in the initial INVITE request as described in the clause 7.2.3.1.2.5a. NOTE 8: Annex K describes recommended values.

Table 2b: Mapping of PSTN XML elements into ISUP Parameters

INVITE 		IAM 
PSTN XML	Value	ISUP Parameter	Content
HighLayerCompatibility		Access Transport Parameter	High layer compatibility (NOTE 1)
LowLayerCompatibility			Low layer compatibility
BearerCapability (NOTE 2)		User Service Information
HighLayerCompatibility		User Tele Service	High layer compatibility
BearerCapability (InformationTransferCapability) (NOTE 2)	Speech	TMR	Speech
	3.1 kHz audio		3.1 kHz audio
	Unrestricted digital information		64 kbit/s unrestricted
	Unrestricted digital information with tones/announcements		64 kbit/s unrestricted
NOTE 1: If two high layer compatibility information elements are received, they shall be transferred in the same order as received in the PSTN XML body in the INVITE message. NOTE 2: If there are two BCs present, see clause 7.2.3.1.2.5a. NOTE 3: The above mapping assumes that there is only a single BearerCapability present.

7.2.3.1.2.5a Transmission medium requirement prime and USI prime (optional)

The procedures to support UDI-TA Fallback mechanism described in the present clause shall only apply if two PSTN XML Bearer Capability elements appear within the INVITE Request and the MGCF supports the PSTN XML body as a network option.

When all the following conditions apply:

– The INVITE request includes SDP with one m-line with at least two formats, and with the coding of the first two formats appearing in table 2a;

– the TMR and USI prime values derived from the first format in the m-line according to table 2a are equivalent with the values within the second Bearer Capability element in the PSTN XML;

– the TMR prime and USI values derived from the second format in the m-line according to table 2a are equivalent with the values within the first Bearer Capability element in the PSTN XML; and.

– the I-MGCF supports forwarding fallback signalling.

Then the I-MGCF shall

– if TMR "64 kBit/s preferred" is supported at the succeeding trunk:

– map the first XML Bearer Capability element into the "USI" within the IAM;

– map the the first PSTN XML BearerCapability (InformationTransferCapability) into the "TMR prime" within the IAM, applying the same mapping rules as specified for the mapping into the "TMR" in table 2b;

– map the second XML Bearer Capability element (InformationTransferCapability) into the USI prime within the IAM;

– set the TMR within the IAM to "64 kBit/s preferred";

– configure the IM-MGW; and

– store those values;

– if TMR "64 kBit/s preferred" is not supported at the succeeding trunk:

– apply the procedures as described within clause 7.2.3.1.2.5, using the first Bearer Capability element in the PSTN XMLand the second format in the m-line;

discard the second Bearer Capability element in the PSTN XML;

– select the second format in the m-line within the SDP answer; and

– configure the IM-MGW.

Otherwise (i.e. if some Bearer Capability element in the PSTN XML did not match the SDP), the I-MGCF shall:

– discard the XML Bearer Capability elements;

– if the I-MGCF received at least two formats within the m-line, select one of those formats, exept for the CLEARMODE codec, within the SDP answer;

– apply the mapping for the selected format according to table 2a; and

– configure the IM-MGW accordingly

7.2.3.1.2.6 Calling party number

The SIP "Privacy" header field is defined within IETF RFC 3323 [40]. The SIP "P-Asserted-Identity" header field is defined in IETF RFC 3325 [41].

Table 3: Mapping of SIP From/P-Asserted-Identity/Privacy headers to CLI parameters

Has a "P-Asserted-Identity" header field (NOTE 2, NOTE 5, NOTE 6) been received?	Has a "From" header field (NOTE 3) containing a URI that encodes an E.164 address been received (NOTE 6)?	Calling Party Number parameter Address signals	Calling Party Number parameter APRI	Generic Number (additional calling party number) address signals	Generic Number parameter APRI
No	No	Network option to either include a network provided E.164 number (See table 4) or omit the Address signals.	Network option to set APRI to "presentation restricted" or "presentation allowed" (NOTE 4) (See table 5) As a network option the APRI "presentation restricted by network" (NOTE 7) can be used instead of the APRI "presentation restricted"	Parameter not included	Not applicable
No	Yes	Network option to either include a network provided E.164 number (See table 4) or omit the Address signals.	Network option to set APRI to "presentation restricted" or "presentation allowed" (NOTE 4) (See table 5) As a network option the APRI "presentation restricted by network" (NOTE 7) can be used instead of the APRI "presentation restricted"	Network option to either omit the parameter (if CgPN has been omitted) or derive from the "From" header (NOTE 1) (See table 6)	APRI = "presentation restricted" or "presentation allowed" depending on SIP Privacy header. (See table 6)
Yes	No	Derived from P-Asserted-Identity (See table 5)	APRI = "presentation restricted" or "presentation allowed" depending on SIP Privacy header. (See table 5)	Not included	Not applicable
Yes	Yes	Derived from P-Asserted-Identity (See table 5)	APRI = "presentation restricted" or "presentation allowed" depending on SIP Privacy header. (See table 5)	Network option to either omit the parameter or derive from the "From" header (NOTE 1) (See table 6)	APRI = "presentation restricted" or "presentation allowed" depending on SIP Privacy header. (see table 6)
NOTE 1: This mapping effectively gives the equivalent of Special Arrangement to all SIP UAC with access to the I‑MGCF. NOTE 2: It is possible that the P-Asserted-Identity header field includes both a tel URI and a SIP URI. In this case, either the tel URI or the SIP URI with user="phone" and a specific host portion, as selected by operator policy, may be used. NOTE 3: The "From" header may contain an "Anonymous User Identity". An "Anonymous User Identity" includes information that does not point to the calling party. IETF RFC 3261 recommends that the display-name component contain "Anonymous". That the Anonymous User Identity will take the form defined in TS 23.003 [74]. The Anonymous User Identity indicates that the calling party desired anonymity. The From header may also contain an Unavailable User Identity as defined in TS 23.003 [74], that indicates that the calling party is unknown. NOTE 4: A national option exists to set the APRI to "Address not available". NOTE 5: TS 24.229 [9] guarantees that the received number is an E.164 number formatted as an international number, with a "+" sign as prefix. NOTE 6: The E.164 numbers considered within the present document are composed by a Country Code (CC), followed by a National Destination Code (NDC), followed by a Subscriber Number (SN). On the IMS side, the numbers are international public telecommunication numbers ("CC"+"NDC"+"SN") and are prefixed by a "+" sign. On the CS side, it is a network option to omit the CC. NOTE 7: This is an ETSI specific value described within ETSI EN 300 356-1 [70].

Table 4: Setting of the network-provided BICC/ISUP calling party number parameter with a CLI (network option)

BICC/ISUP CgPN Parameter field	Value
Screening Indicator	"network provided"
Number Incomplete Indicator	"complete"
Number Plan Indicator	ISDN/Telephony (E.164)
Address Presentation Restricted Indicator	Presentation allowed/restricted As a network option the APRI value "presentation restricted by network" (NOTE) can be used instead of the APRI value "presentation restricted"
Nature of Address Indicator	If next BICC/ISUP node is located in the same country set to "National (Significant) number" else set to "International number"
Address signals	If NOA is "national (significant) number" no country code should be included. If NOA is "international number", then the country code of the network-provided number should be included.
NOTE: This is an ETSI specific value described within ETSI EN 300 356-1 [70]

Table 5: Mapping of P-Asserted-Identity and privacy headers to the ISUP/BICC calling party number parameter

SIP Component	Value	BICC/ISUP Parameter / field	Value
P-Asserted-Identity header field (NOTE 1)	E.164 number	Calling Party Number
		Number incomplete indicator	"Complete"
		Numbering Plan Indicator	"ISDN/Telephony (E.164)"
		Nature of Address Indicator	If CC encoded in the URI is equal to the CC of the country where MGCF is located AND the next BICC/ISUP node is located in the same country then set to "national (significant) number" else set to "international number"
		Screening indicator (NOTE 2)	Network Provided
Addr-spec	"CC" "NDC" "SN" from the URI	Address signal	If NOA is "national (significant) number" then set to "NDC" + "SN" If NOA is "international number" then set to "CC"+"NDC"+"SN"
Privacy header field is not present		APRI	"presentation allowed"
Privacy header field (IETF RFC 3323 [40])	priv-value	APRI	If the Privacy header field contains the values "id" (see IETF RFC 3325 [41]) and/or "header", the APRI shall be set to "presentation restricted". Otherwise, the APRI shall be set to "presentation allowed".
NOTE 1: It is possible that a P-Asserted-Identity header field includes both a tel URI and a SIP URI. In this case, either the tel URI or the SIP URI with user="phone" and a specific host portion, as selected by operator policy, may be used. NOTE 2: As a network option, the MGCF may support "Calling number verification using signature verification and attestation information " feature as described in IETF RFC 8224 [153] and 3GPP TS 24.229 [9]. If the I-MGCF received a "verstat" tel URI parameter (defined in 3GPP TS 24.229 [9] clause 7.2A.20) in the P-Asserted-Identity header filed the I-MGCF may map the "verstat" tel URI parameter to the Screening Indicator field as follows: – the value "No-TN-Validation" to the value "user provided, not verified"; – the value "TN-Validation-Passed" to the value "user provided, verified and passed"; and – the value "TN-Validation-Failed" to the value "user provided, verified and failed".

7.2.3.1.2.7 Generic number

Table 6: Mapping of SIP from header field to BICC/ISUP generic number (additional calling party number) parameter (network option)

SIP component	Value	BICC/ISUP parameter / field	Value
From header field	name-addr or addr-spec	Generic number Number Qualifier Indicator	"additional calling party number"
		Nature of Address Indicator	If CC encoded in the URI is equal to the CC of the country where MGCF is located AND the next BICC/ISUP node is located in the same country then set to "national (significant) number" else set to "international number"
		National operator option for local numbers (NOTE 2): Nature of Address Indicator	Based on the received local number and phone-context set to "subscriber number" or "unknown". (NOTE 3)
		Number incomplete indicator	"Complete"
		Numbering Plan Indicator	"ISDN/Telephony (E.164)"
		Screening indicator (NOTE 1)	"user provided not verified"
Addr-spec	E.164 address (format "+" "CC" "NDC" "SN") from the URI	Address signal	If NOA is "national (significant) number" then set to "NDC" + "SN" If NOA is "international number" then set to "CC"+"NDC"+"SN"
Addr-spec	National operator option for local numbers (NOTE 2): non E.164 address (NOTE 4)	Address signal	Use received non E.164 number to fill the Address signals.
Privacy header field is not present		APRI	"presentation allowed"
Privacy header field (IETF RFC 3323 [40])	priv-value	APRI	If the Privacy header field contains the value "user", the APRI shall be set to "presentation restricted". Otherwise, the APRI shall be set to "presentation allowed".
NOTE 1: As a network option, the MGCF may support "Calling number verification using signature verification and attestation information" feature as described in IETF RFC 8224 [153] and 3GPP TS 24.229 [9]. If the I-MGCF received a "verstat" tel URI parameter (defined in 3GPP TS 24.229 [9] clause 7.2A.20) in the From header filed the I-MGCF may map the "verstat" tel URI parameter to the Screening Indicator field as follows: – the value "No-TN-Validation" to the value "user provided, not verified"; – the value "TN-Validation-Passed" to the value "user provided, verified and passed"; and – the value "TN-Validation-Failed" to the value "user provided, verified and failed". NOTE 2: Local numbers can e.g. be national service numbers, business trunking numbers, or private numbers. NOTE 3: Mapping between phone-context values and "Nature of Address Indicator" values is provisioned in the MGCF. Setting the values of "Nature of Address Indicator" is dependent on local operator’s policies. NOTE 4: A non E.164 address can either be present as a local number with a phone-context parameter in the user portion of a SIP URI with "user=phone" or as a local number with a phone-context parameter in a tel URI.

7.2.3.1.2.8 User service information

For coding of the USI see 7.2.3.1.2.5.

7.2.3.1.2.9 Hop Counter (National option)

The I-MGCF shall perform the following interworking procedure if the Hop Counter procedure is supported in the CS network.

At the I‑MGCF the Max-Forwards SIP header shall be used to derive the Hop Counter parameter if applicable. Due to the different default values (that are based on network demands/provisions) of the SIP Max-Forwards header and the Hop Counter, a factor shall be used to adapt the Max Forwards to the Hop Counter at the I‑MGCF. For example, the following guidelines could be applied:

1) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP entity, regardless of intervening interworking, and similarly for Hop Counter.

2) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the maximum number of hops that may be expected of a validly routed call.

Table 7 shows the principle of the mapping:

Table 7: Max forwards – hop counter

Max-Forwards	= X	Hop Counter	= INTEGER part of (X /Factor) =Y
NOTE: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism.

The Principle of adoption could be implemented on a basis of the network provision, trust domain rules and bilateral agreement.

7.2.3.1.2.10 Progress Indicator

If the I-MGCF supports the PSTN XML body as a network option and an INVITE containing a PSTN XML body is received, an available "ProgressIndicator" element in the PSTN XML body shall be mapped into a Progress Indicator in the Access Transport Parameter of the sent IAM as shown in table 7.2.3.1.2.10.1.

Table 7.2.3.1.2.10.1: Contents of the Access Transport Parameter

INVITE 	IAM
PSTN XML	Access Transport Parameter
Progress indicator	Progress indicator (NOTE)
NOTE: A ProgressIndicator with Progress Description value 6 shall not be included into the ISUP ATP, and is mapped instead to Forward call indicators parameter according to table 02a.

7.2.3.1.2.11 Location Number

Location Number is defined in clause 3.30 of ITU-T Q.763 [4].

If the received INVITE message contains:

1) only one P-Access-Network-Info header field and the P-Access-Network-Info header contains only one access network specific component then:

a) if an access-type field with the value "GSTN" is received:

i) if an access-info field with the value "gstn-location" is present and the value "operator-specific-GI" is not present, the I-MGCF shall include an ISUP Location Number parameter in the outgoing IAM set as shown in table 7.2.3.1.2.11.1; or

ii) as a network option:

– if an access-info field with the value "operator-specific-GI" is present and the value "gstn-location" is not present, the I-MGCF shall include an ISUP Location Number parameter in the outgoing IAM set as shown in table 7.2.3.1.2.11.3; or

– if both values "gstn-location" and "operator-specific-GI" are present, the I-MGCF shall include an ISUP Location Number parameter in the outgoing IAM set as shown in table 7.2.3.1.2.11.1 or table 7.2.3.1.2.11.3, based on local policy; or

b) as a network option, if an access-type field with a value different from than"GSTN" and an access-info field with the value "operator-specific-GI" are received, the I-MGCF shall include an ISUP Location Number parameter in the outgoing IAM as shown in table 7.2.3.1.2.11.3; or

2) more P-Access-Network-Info header fields or the P-Access-Network-Info header field contains more access network specific components then the I-MGCF shall select the access network specific component which contains a "network-provided" parameter and shall perform the mapping to an ISUP Location Number parameter as described in bullet 1).

NOTE 1: According to 3GPP TS 24.229 [9] two P-Access-Network-Info header fields (or one P-Access-Network-Info header field with two access network specific components) can be received but only one access network specific component can contain the "network-provided" parameter.

NOTE 2: A UE will not create the P-Access-Network-Info header field with the access-type field value "GSTN" and the "gstn-location" parameter, as specified in subclause 7.2A.4.2 of 3GPP TS 24.229 [9]. However the access-type field value "GSTN" without the "network-provided" parameter can be received in interworking cases when the IMS network is used between two CS networks and the P-Access-Network-Info header field was created by the O-MGCF in accordance to subclause 7.2.3.2.2.9. Based on local policy, the I-MGCF can select the P-Access-Network-Info header field with the access-type field value "GSTN" and without the "network-provided" parameter.

Table 7.2.3.1.2.11.1: Contents of the location number parameter

INVITE 	IAM
	Location Number parameter
P-Access-Network-Info with access-type="GSTN" and gstn-location parameter	Binary value derived from the gstn-location parameter of the P-Access-Network-Info
NOTE: The binary value shall be obtained by removing the quotes and converting each pair of consecutive character strings into an octet that has the equivalent hexadecimal representation

Table 7.2.3.1.2.11.2: Mapping of P-Access-Network-Info to Location Number

INVITE

IAM

P-Access-Network-Info

Location Number

access type="GSTN"

gstn-location=value

Address Signal:

Copied from octet 3 to n of the binary representation of the gstn-location field

Odd/even indicator:

Copied from bit 8 octet 1 of the binary representation of the gstn-location field

Nature of address indicator:

Copied from bit 7 to 1 of octet 1 of the binary representation of the gstn-location field

Internal Network Number Indicator:

Copied from bit 8 of octet 2 of the binary representation of the gstn-location field

Numbering plan Indicator:

Copied from bit 7 to 5 of octet 2 of the binary representation of the gstn-location field

Address presentation restricted indicator:

If the SIP Privacy header field = header, APRI is set to "01 (presentation restricted)" otherwise APRI is copied from bit 4 and 3 of octet 2 of the binary representation of the gstn-location field

Screening indicator:

If the "network-provided" parameter is present in the P-Access-Network-Info header field, set to "11 (network provided)" otherwise set from bit 2 and 1 of octet 2 of the binary representation of the gstn-location field

Table 7.2.3.1.2.11.3: Mapping of P-Access-Network-Info operator-specific-GI to Location Number

INVITE 

IAM

Location Number parameter

P-Access-Network-Info with

access-info="operator-specific-GI"

and operator-specific-GI parameter

P-Access-Network-Info

Location Number

access-info="operator-specific-GI"

operator-specific-GI=value

Address Signal :

Copy the digits set by 2 digits per byte. In case of an odd number of address signals, the filler code 0000 is inserted after the last address signal.

Odd/even indicator:

Set as required

Nature of address indicator:

Set from an operator-configured value

Internal Network Number Indicator:

1 routing to internal network number not allowed

Numbering plan Indicator:

Set from an operator-configured value

Address presentation restricted indicator:

If the SIP Privacy header field = header, APRI is set to "01 (presentation restricted)"

Screening indicator:

If the "network-provided" parameter is present in the P-Access-Network-Info header field, set to "11 (network provided)"

NOTE: This mapping is only possible if the operator-specific-GI field of the P-Access-Network-Info header filed contains a sequence of digits.

7.2.3.1.2.12 Support of ICS call

If the received initial INVITE request contains a Feature Caps header field, defined in IETF RFC 6809 [142] with a "+g.3gpp.ics" header field parameter as specified in clause B.4 of 3GPP TS 24.292 [141] then according to operator policy the I-MGCF may mark a call as an "ICS call".

For the call marked as the "ICS call" the I-MGCF shall include in the outgoing IAM message a redirection information parameter field set as shown in table 7.2.3.1.2.12.1.

Table 7.2.3.1.2.12.1: Contents of the redirection information parameter field

INVITE 	IAM
Feature‑Caps header field with g.3gpp.ics feature‑capability indicator	Redirection information parameter field
	Redirecting indicator	Call diverted, all redirection info presentation restricted
	Original redirection reason	Unknown/not available
	Redirecting reason	Unknown/not available
	Redirection counter	set to maximum value (NOTE)
NOTE: For instance, in ISUP ITU-T Q.763 [4], the Redirection counter parameter cannot exceed 5.

7.2.3.1.2.13 UID capability indicators (National option)

UID capability indicators parameter is defined in ITU-T Recommendation Q.763 [4].

When a both-way media path is available, then it is possible to support user interactive dialogs prior to answer through the use of the P-Early-Media header field authorizing both‑way media.

If the received initial INVITE request contains a P-Early-Media header field with the "supported" value and either the SDP in the INVITE request allows a send/receive media path or the INVITE request does not contain an SDP body then the UID capability indicators parameter in the outgoing IAM message may be set as shown in table 7.2.3.1.2.13.1.

Table 7.2.3.1.2.13.1: Contents of the UID capability indicators parameter

INVITE 	IAM
P-Early-Media with "supported" and either SDP with "sendrecv" (explicit or implied) or no SDP present	UID capability indicators parameter
	Through-connection indicator	1 "through-connection modification possible"
	T9 timer indicator	0 "no indication"

7.2.3.1.2.14 Called IN number and original called IN number (optional)

See Annex L for the normative interworking of the called IN number and original called IN number parameters.

7.2.3.1.2A Coding of the IAM when Number Portability is supported

This clause describes optional coding procedures when Number Portability is supported.

7.2.3.1.2A.1 Coding of the IAM when a Number Portability Routing Number is available

ITU-T Q.769.1 [92] describes three possible addressing methods for signalling of the Called Party E.164 address and Number Portability Routing Number (ITU-T Q.769.1 [92] uses the terms directory number and network routing number respectively). The choice of these methods is based on network operator and national requirements.

The following clauses describe how the IAM is populated, based on these methods, when a Number Portability Routing Number is available in the Request URI in the form of a Tel URI "rn=" parameter.

When the optional Number Portability Routing Number is available and supported, these procedures take precedence over procedures for coding of the Called Party Number described in clause 7.2.3.1.2.1.

If the Number Portability Database Dip Indicator is present within the Request-URI the procedures described in clause 7.2.3.1.2A.2 apply. When a Number Portability Routing Number is not available, the Called Party Number parameter is populated as described in clause 7.2.3.1.2.1.

7.2.3.1.2A.1.1 Separate Directory Number Addressing Method

Table 7a.0a: Coding of the called party number and called directory number with Number Portability Separate Directory Number Addressing Method

INVITE

IAM

Request-URI

Called Party Number

Called Directory Number

Called Party E.164 address

(format +CC NDC SN)

(e.g. as User info in SIP URI with user=phone, or as tel URL) plus Number Portability Routing Number (format +CC NDC SN) (e.g. as Tel URI rn= parameter) plus Number Portability Database Dip Indicator as defined in IETF RFC 4694 [93] (e.g. as Tel URI npdi parameter)

Address Signal:

Analyse the information contained in received Number Portability Routing Number. If the Number Portability Routing number contains an E.164 address, then remove "+CC" and use the remaining digits to fill the Address signal. Otherwise, use the digits of the Number Portability Routing number to fill the Address signal.

(NOTE)

Address Signal:

Remove "+CC" from the Called Party E.164 address and use the remaining digits to fill the Address signals.

Odd/even indicator: set as required

Nature of address indicator:

Set Nature of Address indicator to "Network routing number in national (significant) number format". "National (significant) number" and "Network routing number in network specific number format" may alternately be chosen as described in ITU-T Q.769.1 [92]

Nature of address indicator:

Set Nature of Address indicator to "National (significant) number".

Internal Network Number Indicator:

1 routing to internal network number not allowed

Internal Network Number Indicator:

1 routing to internal network number not allowed

Numbering plan Indicator:

001 ISDN (Telephony) numbering plan (Rec. E.164)

Numbering plan Indicator:

001 ISDN (Telephony) numbering plan (Rec. E.164)

NOTE: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN XML sendingCompleteIndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) in the address signals field of the Called Party Number parameter.

7.2.3.1.2A.1.2 Concatenated Addressing Method

Table 7a.0b: Coding of the called party number with Number Portability Concatenated Addressing Method

INVITE	IAM
Request-URI	Called Party Number
Called Party E.164 address (format +CC NDC SN) (e.g. as User info in SIP URI with user=phone, or as tel URL) plus Number Portability Routing Number (format +CC NDC SN) (e.g. as Tel URI rn= parameter) plus Number Portability Database Dip Indicator as defined in IETF RFC 4694 [93] (e.g. as Tel URI npdi parameter)	Address Signal: Analyse the information contained in received Number Portability Routing Number. If the Number Portability Routing number contains an E.164 address, then remove "+CC" and use the remaining digits to fill the Address signal. Otherwise, use the digits of the Number Portability Routing number to fill the Address signal. Remove the "+CC" from the Called Party E.164 address and append the remaining digits to the Address signal. (NOTE)
	Odd/even indicator: set as required
	Nature of address indicator: set Nature of Address indicator to "Network routing number concatenated with called directory number" or "National (significant) number" as described in ITU-T Q.769.1 [92]
	Internal Network Number Indicator: 1 routing to internal network number not allowed
	Numbering plan Indicator: 001 ISDN (Telephony) numbering plan (Rec. E.164)
NOTE: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN XML sendingCompleteIndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) in the address signals field of the Called Party Number parameter.

7.2.3.1.2A.1.3 Separate Network Routing Number Addressing Method

Table 7a.0c: Coding of the network routing number and called party number with Number Portability Separate Network Routing Number Addressing Method

INVITE	IAM
Request-URI	Network Routing Number	Called Party Number
Called Party E.164 address (format +CC NDC SN) (e.g. as User info in SIP URI with user=phone, or as tel URL) plus Number Portability Routing Number (format +CC NDC SN) (e.g. as Tel URI rn= parameter) plus Number Portability Database Dip Indicator as defined in IETF RFC 4694 [93] (e.g. as Tel URI npdi parameter)	Address Signal: Analyse the information contained in received Number Portability Routing Number. If the Number Portability Routing number contains an E.164 address, then remove "+CC" and use the remaining digits to fill the Address signal. Otherwise, use the digits of the Number Portability Routing number to fill the Address signal.	Address Signal: Remove "+CC" from the Called Party E.164 address and use the remaining digits to fill the Address signals. (NOTE)
	Odd/even indicator: set as required	Odd/even indicator: set as required
	Nature of address indicator: Set Nature of Address indicator to "Network routing number in national (significant) number format". "Network routing number in network specific number format" may alternately be chosen as described in ITU-T Q.769.1 [92]	Nature of address indicator: Set Nature of Address indicator to "National (significant) number".
	Numbering plan Indicator: 001 ISDN (Telephony) numbering plan (Rec. E.164)	Internal Network Number Indicator: 1 routing to internal network number not allowed
		Numbering plan Indicator: 001 ISDN (Telephony) numbering plan (Rec. E.164)
NOTE: If PSTN XML and ISUP Sending Terminated (ST) signal are supported as a network option, then the PSTN XML sendingCompleteIndication, if present, is mapped to the sending terminated digit (hexadecimal digit F) in the address signals field of the Called Party Number parameter.

7.2.3.1.2A.2 Number Portability Forward Information

Network Operator or National policy may allow forward transfer of number portability status information, as described in ITU-T Q.769.1 [92]. In this case, the following coding applies.

Table 7a.0d: Coding of the number portability forward information

INVITE

IAM

Request-URI

Number Portability Forward Information

Called Party E.164 address

(format +CC NDC SN)

If the Number Portability Database Dip Indicator is present, and there is no Number Portability Routing Number, set to "number portability query done for called number, non-ported called subscriber".

If the Number Portability Database Dip Indicator is present, and a Number Portability Routing Number is present, set to "number portability query done for called number, ported called subscriber".

If there is no Number Portability Database Dip Indicator, set to "number portability query not done for called number"

7.2.3.1.2B Coding of the IAM for Carrier Routeing

This clause describes optional coding procedures for carrier-based routeing. The interworking of the CIC parameter is defined.

7.2.3.1.2B.1 Coding of the IAM when a Carrier Identification Code (CIC) is present

The procedures followed in clause 7.2.3.1.2.1 apply with the following addition.

Based on network configuration, if the tel-URI parameter in a tel-URI or the userinfo part of a SIP URI with user=phone in the Request-URI of an initial INVITE request, contains a "cic=" parameter, as defined in IETF RFC 4694 [93], the I-MGCF may extract the carrier identification code from the "cic=" field for routeing the call. If the outgoing IAM message contains the Transit Network Selection (TNS) parameter, as defined in ITU-T Q.763 [4], based on network configuration the TNS may be populated using the carrier identification code from the "cic=" field. The format of the "cic" parameter (e.g. global-cic and local-cic) shall be compliant to IETF RFC 4694 [93].

7.2.3.1.2B.2 Void

7.2.3.1.3 Sending of COT

Figure 5: Sending of COT

If the IAM has already been sent, the Continuity message shall be sent indicating "continuity check successful", when all of the following conditions have been met:

– The requested remote preconditions (if any) in the IMS network have been met.

– The media stream previously set to inactive mode is set to active (as specified in IETF RFC 4566 [56]).

– Local preconditions have been fulfilled.

– A possible outstanding continuity check procedure is successfully performed on the outgoing circuit.

7.2.3.1.3A Sending of SAM

7.2.3.1.3A.1 General

The procedures in the present clause are only applicable if the I-MGCF supports the network option of overlap signalling, using either the in-dialog method or the multiple INVITEs method. Within one IMS only a single of those methods shall be used.

After the ISUP IAM message has been sent the I-MGCF can receive additional digits. The additional digits may either, as a network option, be received in:

– in-dialog SIP INFO requests ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086 [133]), in-dialog method as specified in clause 7.2.3.1.3A.2 or

– in additional SIP INVITE requests, multiple INVITEs method as specified in 7.2.3.1.3A.3.

Figure 5a: Sending of SAM

7.2.3.1.3A.2 Additional digits received in in-dialog SIP INFO requests

If interworking of overlap signalling using the in-dialog method is supported by the I-MGCF, the ISUP IAM message has already been sent, but no ISUP ACM or REL message has been received, and a SIP INFO request carrying additional digits is received, then the I-MGCF shall generate a SAM and pass it to outgoing BICC/ISUP procedures. The SAM shall contain in its Subsequent Number parameter only the additional digits received in this SIP INFO request.

7.2.3.1.3A.3 Additional digits received in SIP INVITE requests

If interworking of overlap signalling using the multiple INVITEs method is supported by the I-MGCF, the ISUP IAM message has already been sent, but no ISUP ACM or REL message has been received, and the I-MGCF receives an INVITE with the same Call‑ID and From tag as a previous INVITE which was associated with a BICC/ISUP call/bearer control instance currently existing on the BICC/ISUP side, then:

a) If the number of digits in the Request‑URI is greater than the number of digits already received for the communication, the I-MGCF shall generate a SAM and pass it to outgoing BICC/ISUP procedures. The SAM shall contain in its Subsequent Number parameter only the additional digits received in this Request‑URI compared with the digits already received for the communication. The I-MGCF shall reply to any earlier INVITE with a 484 Address Incomplete response if this has not already been done.

b) If the number of digits in the Request‑URI is equal or less than the number of digits already received for the communication, then the I-MGCF shall immediately send a 484 Address Incomplete response for this INVITE. In this case, no SAM shall be sent to BICC/ISUP procedures.

Figure 5b: Receipt of subsequent INVITE for multiple INVITEs method overlap signalling

On sending of a 484 Address Incomplete message for an INVITE transaction, the I-MGCF considers any offer/answer exchange initiated by the INVITE to be terminated. The new INVITE initiates a new offer/answer exchange. However, if resources have already been reserved and they can be reused within the new offer/answer exchange, the precondition signalling shall reflect the current status of the affected preconditions.

7.2.3.1.4 Sending of 180 ringing

7.2.3.1.4.0 General

The I-MGCF shall send the SIP 180 Ringing response when receiving any of the following messages:

– ACM with Called party’s status indicator set to subscriber free.

NOTE: Whether the P-Early-Media header field is included depends on whether the received INVITE contains a P-Early-Media header field with the "supported" parameter as described in IETF RFC 5009 [89] or based on local policy.

Figure 6: The receipt of ACM

– CPG with Event indicator set to alerting

Figure 7: Receipt of CPG (Alerting)

For a speech call that is not identified as an "ICS call" as specified in clause 7.2.3.1.2.12, if the INVITE request includes the P-Early-Media header field, the I-MGCF shall include in the SIP 180 Ringing response a P-Early-Media header field authorizing backward early media, except when

– the I-MGCF has already sent a reliable provisional response (see IETF RFC 3262 [54]) including a P-Early-Media header, as defined in IETF RFC 5009 [89], and

– the most recently sent P-Early-Media header field authorized backward early media.

NOTE: If the I-MGCF signals the P-Early-Media header field authorizing backward early media, then the IMS can expect tones or announcements to the calling party to flow from the CS network via an MGW controlled by the I-MGCF. In particular, once the I-MGCF sends the 180 Ringing response, ringback is expected in media from the CS network.

If the INVITE request doesn’t include the P-Early-Media header field with the "supported" parameter and if the speech call is not identified as the "ICS call" as specified in clause 7.2.3.1.2.12, then as a network option the I-MGCF may include in the SIP 180 Ringing response a P-Early-Media header field authorizing backward early media.

As a network option, an I-MGCF may generate a Call-Info header field, or an Alert-Info header field according to rules and procedures of IETF RFC 3261 [19] to provide media instead of the in-band media received from the PSTN.

For the speech call identified as the "ICS call" as specified in clause 7.2.3.1.2.12, if the I-MGCF has received the P-Early-Media header field in the initial INVITE request, the I-MGCF shall include in the SIP 180 Ringing response the P-Early-Media header field indicating the backward early media is not authorised, except when:

– the I-MGCF has already sent a reliable provisional response (see IETF RFC 3262 [54]) including a P-Early-Media header, as defined in IETF RFC 5009 [89]; and

– the most recently sent P-Early-Media header field did not authorize the backward early media.

If the P-Early-Media header field with the "supported" parameter was not included in the initial INVITE request, then as a network option the I-MGCF may include in the SIP 180 Ringing response the P-Early-Media header field indicating the backward early media is not authorised for the "ICS call".

7.2.3.1.4.0a PSTN XML body

The procedures in the present clause apply only if the I-MGCF supports the PSTN XML body as a network option. The I-MGCF shall map the Access Transport parameter received in the CPG or ACM into PSTN XML elements as shown in table 7a.0f and include this PSTN XML body in the 180 Ringing.

Table 7a.0f: Mapping of ISUP ATP Parameter into PSTN XML elements

18x	CPG or ACM
PSTN XML	ISUP Parameter	Content
ProgressIndicator	Access Transport Parameter	Progress indicator
HighLayerCompatibility (NOTE 2)		High layer compatibility
LowLayerCompatibility (NOTE 2)		Low layer compatibility
BearerCapability (NOTE 1, NOTE 2)		Bearer Capability
BearerCapability (NOTE 1, NOTE 2)	Transmission medium used parameter (NOTE 1)
NOTE 1: see clause 7.2.3.1.4.1 Transmission Medium Used parameter (TMU) NOTE 2: The I-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a (G.711, Clearmode, or t38) without transcoding. If both TMU and a BC in the ATP have been received, the BC in the ATP shall be mapped.

The I-MGCF shall map a possibly available "ProgressIndicator" element in the ATP parameter within the ACM or CPG into a Progress Indicator in the PSTN XML body of the 180 Ringing. In addition, the I-MGCF shall map the Backward call indicators parameter and the Optional backward call indicators parameter (if present) within the ACM or CPG into other ProgressIndicator(s) in the PSTN XML body of the 180 Ringing as shown in table 7a.0g.

NOTE: The order of ProgressIndicators within the same PSTN XML body is irrelevant.

Table 7a.0g: Mapping of ISUP BCI and optional BCI parameters into PSTN XML ProgressIndicator

 180 Ringing

ACM or CPG

PSTN XML body with ProgressIndicator with "Progress Description" value No (Value of PI)

Backward call indicators parameter

Optional backward call indicators parameter

No. 1

("Call is not end-to-end ISDN: further call progress information may be available in-band")

Backward call indicators parameter

ISDN User Part indicator

0 "ISDN User Part not used all the way"

No. 2

("Destination address is non-ISDN")

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

0 "Terminating access non-ISDN"

No. 7

("Terminating access ISDN")

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

1 "Terminating access ISDN"

No. 8

("In-band information or an appropriate pattern is now available")

Optional backward call indicators parameter

In-band information indicator

"in-band information or an appropriate pattern is now available"

NOTE: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)".

7.2.3.1.4.0b Fallback by I-MGCF

If the I-MGCF supports the PSTN XML body as a network option and the I-MGCF received two PSTN XML Bearer Capability elements within the INVITE Request, but the succeeding trunk does not support TMR "64 kBit/s preferred" (as described in clause 7.2.3.1.2.5a), and if no corresponding elements were received in the Access Transport Parameter (see table 7a.0f), then the I-MGCF shall create a PSTN XML body containing the following elements, and include it in the 18x Response :

– a BearerCapability element, which shall be copied from the first BearerCapability element received in the PSTN XML in the INVITE;

– if two HighLayerCompatibility elements were present in the PSTN XML body in the INVITE, then a HighLayerCompatibility element, which shall be copied from the first HighLayerCompatibility element received in the PSTN XML in the INVITE; and

– a ProgressIndicator element with "Progress Description" value 5 ("Interworking has occurred and has resulted in a telecommunication service change"),"Coding Standard" value "00 (ITU-T standardized coding)", and default value "0011 (Transit Network)" for the "Location" parameter.

7.2.3.1.4.1 Fallback in a succeeding network: Transmission Medium Used parameter (TMU) received

The procedures in the present clause apply only if the I-MGCF supports the PSTN XML body as a network option and receives a Transmission Medium Used parameter (TMU).

NOTE: The I-MGCF will only receive a TMU parameter if it has applied the Fallback related procedures in clause 7.2.3.1.2.5a, including both a TMR and TMR Prime in the IAM, and fallback to the bearer capability identified in TMR Prime and USI occurred in a succeeding network.

If the I-MGCF receives a Transmission Medium Used parameter (TMU) , the I-MGCF shall:

– If an BC is not available in the ATP in the Address Complete Message (ACM) or Call Progress Message (CPG), map the TMU value (Speech or 3.1 kHz audio) to the PSTN XML BearerCapability;

– If an BC is available in the ATP in the Address Complete Message (ACM) or Call Progress Message (CPG), include the received BC value in the PSTN XML BearerCapability;

– configure the IM-MGW to use the second format in the m-line in the SDP that has been received in the INVITE as codec at the IMS termination; and

– send SDP selecting the second format in the m-line of the SDP that has been received in the INVITE as soon as allowed according to SIP rules.

Table 7.2.3.1.4.1.1: Sending of BC fallback indication

 180 Ringing or 183 Session Progress	ACM/CPG
PSTN XML BearerCapability = "Speech"	TMU "Speech" ATP No BC
PSTN XML BearerCapability = "3.1 kHz audio"	TMU "3.1 kHz audio" ATP No BC
PSTN XML BearerCapability received in the ATP ("speech" or "3.1 kHz audio")	TMU "Speech or 3.1 kHz audio" ATP BC ("speech" or "3.1 kHz audio")

7.2.3.1.4A Sending of 183 Session Progress for early media scenarios

If SIP preconditions are used, the first 183 Session Progress will be sent after the reception of the INVITE request, before any ISUP message has been received from the CS network. The I-MGCF shall not include the P-Early-Media header field in any SIP message before it receives an ISUP ACM.

For a speech call, which is not identified as an "ICS call" as specified in clause 7.2.3.1.2.12, upon receipt of one of the following messages and if the I-MGCF has received the P-Early-Media header field in the INVITE request, and has not already sent a provisional response including a P-Early-Media header field with parameters indicating authorization of early media with the same directionality as determined by table 7.2.3.1.4A.1 or table 7.2.3.1.4A.2, then the I-MGCF shall send the 183 Session Progress response with a P-Early-Media header field authorizing early media as indicated:

– ACM with the value of the called party’s status indicator "no indication" and one of the options described in table 7.2.3.1.4A.1 If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map parameters within the ACM into the PSTN XML body within the 183 as indicated in table 7.2.3.1.4A.1. Based on local configuration, the I-MGCF may also send a 183 Session Progress response with a P-Early-Media header field authorizing early media if it receives an ACM with other parameters than described in table 7.2.3.1.4A.1.

Figure 7c: Receipt of ACM "No indication"

Table 7.2.3.1.4A.1: ACM Parameters that trigger the 183 Session Progress response

 183 Session Progress

 ACM

P-Early-Media header field authorizing backward early media, if not already sent (NOTE 2)

PSTN XML with ProgressIndicator with "Progress Description" value No. 8

("In-band information or appropriate pattern is now available") (NOTE 1)

Optional backward call indicators parameter

In-band information indicator

1 "In-band info or an appropriate pattern is
now available"

PSTN XML with ProgressIndicator with "Progress Description" value No. 1

("Call is not end-to-end ISDN: further call progress information may be available in-band") (NOTE 1)

Backward call indicators parameter

ISDN User Part indicator

0 "ISDN User Part not used all the way"

PSTN XML with ProgressIndicator with "Progress Description" value No. 2 ("Destination address is non-ISDN") (NOTE 1)

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

0 "Terminating access non-ISDN"

PSTN XML with ProgressIndicator with "Progress Description" value No. 7

("Terminating access ISDN") (NOTE 1)

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

1 "Terminating access ISDN"

P-Early-Media header field authorizing both-way early media, if not already sent (NOTE 2)

UID action indicators parameter

Through-connection instruction indicator

1 "through-connect in both directions"

NOTE 1: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)".

NOTE 2: Setting of the P-Early-Media header field based on the UID action indicators parameter value of "through-connect in both directions" takes precedence over setting based on the Optional backward call indicators parameter value of "In-band info or an appropriate pattern is now available".

NOTE 1: As a network option the I-MGCF can also map ACM into 183 in other cases than those described in table 7.2.3.1.4A.1.

– CPG message, when:

1. Event indicator is set to "in-band information or an appropriate pattern is now available", or

2. Event indicator is set to "Progress" and one of the options described in table 7.2.3.1.4A.2.

Figure 7d: Receipt of CPG (in-band information available)

Table 7.2.3.1.4A.2: CPG Parameters that trigger the 183 Session Progress response

183 Session Progress	CPG
P-Early-Media header field authorizing backward early media, if not already sent (NOTE 4) PSTN XML with ProgressIndicator with "Progress Description" value No. 8 ("In-band information or appropriate pattern is now available") (NOTE 3)	Event indicator 000 0010 (progress) Optional backward call indicators parameter In-band information indicator 1 "In-band info or an appropriate pattern is now available"
PSTN XML with ProgressIndicator with "Progress Description" value No. 1 (Call is not end-to-end ISDN: further progress information may be available in-band") (NOTE 3)	Event indicator 000 0010 (progress) Backward call indicators parameter ISDN User Part indicator 0 "ISDN User Part not used all the way"
PSTN XML with ProgressIndicator with "Progress Description" value No. 2 ("Destination address is non-ISDN") (NOTE 3)	Backward call indicators parameter ISDN User Part indicator 1 "ISDN User Part used all the way" ISDN access indicator 0 "Terminating access non-ISDN"
PSTN XML with ProgressIndicator with "Progress Description" value No. 7 ("Terminating access ISDN") (NOTE 3)	Backward call indicators parameter ISDN User Part indicator 1 "ISDN User Part used all the way" ISDN access indicator 1 "Terminating access ISDN"
P-Early-Media header field authorizing both-way early media, if not already sent (NOTE 4)	UID action indicators parameter Through-connection instruction indicator 1 "through-connect in both directions"
NOTE 1: The mapping of the contents in the CPG message is only relevant if the information received in the message is different compared to earlier received information, e.g., in the ACM message or a CPG message received prior to this message. NOTE 2: 183 Session Progress message including a P-Early-Media header authorizing early media may only be sent for a speech call. NOTE 3: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)". NOTE 4: Setting of the P-Early-Media header field based on the UID action indicators parameter value of "through-connect in both directions" takes precedence over setting based on the Optional backward call indicators parameter value of "In-band info or an appropriate pattern is now available".

183 Session Progress

CPG

P-Early-Media header field authorizing backward early media, if not already sent (NOTE 4)

PSTN XML with ProgressIndicator with "Progress Description" value No. 8

("In-band information or appropriate pattern is now available") (NOTE 3)

Event indicator

000 0010 (progress)

Optional backward call indicators parameter

In-band information indicator

1 "In-band info or an appropriate pattern is now
available"

PSTN XML with ProgressIndicator with "Progress Description" value No. 1

(Call is not end-to-end ISDN: further progress information may be available in-band") (NOTE 3)

Event indicator

000 0010 (progress)

Backward call indicators parameter
ISDN User Part indicator

0 "ISDN User Part not used all the way"

PSTN XML with ProgressIndicator with "Progress Description" value No. 2 ("Destination address is non-ISDN") (NOTE 3)

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

0 "Terminating access non-ISDN"

PSTN XML with ProgressIndicator with "Progress Description" value No. 7

("Terminating access ISDN") (NOTE 3)

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

1 "Terminating access ISDN"

P-Early-Media header field authorizing both-way early media, if not already sent (NOTE 4)

UID action indicators parameter

Through-connection instruction indicator

1 "through-connect in both directions"

NOTE 1: The mapping of the contents in the CPG message is only relevant if the information received in the message is different compared to earlier received information, e.g., in the ACM message or a CPG message received prior to this message.

NOTE 2: 183 Session Progress message including a P-Early-Media header authorizing early media may only be sent for a speech call.

NOTE 3: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)".

NOTE 4: Setting of the P-Early-Media header field based on the UID action indicators parameter value of "through-connect in both directions" takes precedence over setting based on the Optional backward call indicators parameter value of "In-band info or an appropriate pattern is now available".

NOTE 2: As a network option the I-MGCF can also map CPG into 183 in other cases than those described in table 7.2.3.1.4A.1.

If the INVITE request doesn’t include the P-Early-Media header field with the "supported" parameter, then as a network option the I-MGCF may include in the SIP 180 Ringing response a P-Early-Media header field authorizing early media.

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport Parameter received in the CPG or ACM into PSTN XML elements as shown in table 7a.0f and include this XML body in the 183 Session Progress. The I-MGCF shall include both a ProgressIndicator mapped from possibly received Progress indicator element in the Access Transport Parameter and ProgressIndicators derived according to table 7.2.3.1.4A.1 or table 7.2.3.1.4A.2 in the PSTN XML body.

NOTE 3: The order of ProgressIndicators within the same PSTN XML body is irrelevant.

If the I-MGCF has applied UDI-TA fallback related procedures in clause 7.2.3.1.2.5a, the I-MGCF shall also apply the procedures in clauses 7.2.3.1.4.0b and 7.2.3.1.4.1, including the PSTN XML body in the 183 Session Progress.

If the ACM or CPG contains an ISUP Cause, the MGCF may add a Reason header field containing the received Cause Value to the SIP 183 Session Progress provisional response as a network option. The mapping of the Cause Indicators parameter to the Reason header as shown in table 9a shall be applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116].

7.2.3.1.4B Sending of 181Call is being forwarded

The I-MGCF shall send the SIP 181 Call is being forwarded when receiving any of the following messages:

– ACM with call diversion information not indicating that presentation is not allowed and optional backward call indicators indicate that in-band information is available.

NOTE 1: Whether the P-Early-Media header field is included depends on whether the received INVITE contains a P-Early-Media header field with the "supported" parameter as described in IETF RFC 5009 [89] or based on local policy.

Figure 7c: The receipt of ACM (call diversion information)

– CPG with call diversion information not indicating that presentation is not allowed and optional backward call indicators indicate that in-band information is available.

NOTE 1: Whether the P-Early-Media header field is included if the received INVITE contains a P-Early-Media header field with the "supported" parameter as described in IETF RFC 5009 [89] or based on local policy.

Figure 7d: Receipt of CPG (Call diversion information)

For a speech call, and if the INVITE request includes the P-Early-Media header, the I-MGCF shall include in the SIP 181 Call is being forwarded response a P‑Early-Media header authorizing early media, except when

– the I-MGCF has already sent a reliable provisional response including a P-Early-Media header field, as defined in IETF RFC 5009 [89], or a 180 Ringing response; and

– the most recently sent P-Early-Media header field authorized early media.

NOTE: If the I-MGCF signals the P-Early-Media header field authorizing early media, then the IMS can expect tones or announcements to the calling party to flow from the CS network via an MGW controlled by the I‑MGCF.

7.2.3.1.4C Sending of 183 Session Progress for overlap signalling using the in-dialog method

If the I-MGCF supports the network option of overlap signalling using the in-dialog method, and the SIP INVITE request contained an indication that the 100rel extension is supported or required, the I-MGCF shall send a reliable 183 (Session Progress) response immediately after the reception of an INVITE request.

NOTE: If the INVITE request does not contain an indication that the 100rel extension is supported or required, it is assumed that overlap is not used, and that no further digits will be received.

7.2.3.1.4D Sending of 183 Session Progress to carry ISUP Cause

If the I-MGCF receives an ACM or CPG message containing an ISUP Cause, and if the I-MGCF does not send any SIP provisional response due to interworking procedures described in clauses 7.2.3.1.4A, for the ACM or CPG message, the I-MGCF may send a SIP 183 Session Progress with a Reason header field containing the received Cause Value as a network option. The mapping of the Cause Indicators parameter to the Reason header as shown in table 9a shall be applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116].

Figure 7.2.3.1.4D.1: The receipt of ACM or CPG with ISUP Cause

7.2.3.1.4E Sending of 183 Session Progress for ICS call

For a speech call identified as an "ICS call" as specified in clause 7.2.3.1.12 if the I‑MGCF has received:

– ACM message with the value of the called party’s status indicator "no indication" and the optional backward call indicators parameter field with the in-band information indicator set to "in-band information or an appropriate pattern is now available"; or

– CPG message with the event indicator of the event information parameter field set to:

1 "in-band information or an appropriate pattern is now available"; or

2 "progress" and the optional backward call indicators parameter field with the in-band information indicator set to "in-band information or an appropriate pattern is now available"; and

– if the received ACM or CPG message does not contain the cause indicators parameter field then:

a) if the I‑MGCF has received a P‑Early‑Media header field in the initial INVITE request; and

b) the I‑MGCF has not already sent a provisional response including the P‑Early‑Media header field with parameters indicating that a backward early media is not authorised;

the I‑MGCF shall send the 183 Session Progress response with the P‑Early‑Media header field indicating the backward early media is not authorised. If the I‑MGCF supports a PSTN XML body as a network option, the I‑MGCF shall map parameters within the ACM or CPG message into the PSTN XML body within the 183 Session Progress response as indicated in clause 7.2.3.1.4A; or

– otherwise if the received ACM or CPG message contains the cause indicators parameter field the I‑MGCF shall send a final response to the initial INVITE request according to table 9 in clause 7.2.3.1.8 with a Reason header field containing the received (Q.850) cause value. The mapping of the cause indicators parameter field to the Reason header field as shown in table 9a shall be applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC3326 [116].

7.2.3.1.5 Sending of the 200 OK (INVITE)

The following cases are possible trigger conditions for sending the 200 OK (INVITE):

– The reception of the ANM.

Figure 8: Receipt of ANM

– The reception of the CON message.

Figure 9: Receipt of CON

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport Parameter received in the ANM or CON into PSTN XML elements as shown in table 7.2.3.1.5.1 and include this PSTN XML body in the 200 OK (INVITE).

On receipt of an ANM/CON message containing the ATP including the Bearer Capability set to "unrestricted digital information with tones/announcement" without TMU parameter the 200 OK message shall contain the PSTN XML Bearer Capability "unrestricted digital information with tones/announcement".

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map an available BCI element in the ANM or CON into a ProgressIndicator in the PSTN XML body as shown in table 7.2.3.1.5.2; the I-MGCF shall include both a ProgressIndicator mapped from possibly received Progress indicator element in the Access Transport Parameter and ProgressIndicators derived according to table 7.2.3.1.5.2 in the PSTN XML.

NOTE 1: The order of ProgressIndicators within the same PSTN XML body is irrelevant.

Table 7.2.3.1.5.1: Mapping of ISUP ATP Parameter into PSTN XML elements

200 OK	ANM or CON
PSTN XML	ISUP Parameter	Content
ProgressIndicator	Access Transport Parameter	Progress indicator
HighLayerCompatibility (NOTE 2)		High layer compatibility
LowLayerCompatibility (NOTE 2)		Low layer compatibility
BearerCapability (NOTE 1, NOTE 2)		Bearer Capability
BearerCapability (NOTE 1, NOTE 2)	Transmission medium used parameter (NOTE 1)
NOTE 1: see clause 7.2.3.1.4.1 Transmission Medium Used parameter (TMU) NOTE 2: The I-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a (G.711, Clearmode, or t38) without transcoding. If both TMU and a BC in the ATP have been received, the BC in the ATP shall be mapped.

Table 7.2.3.1.5.2: Mapping of ISUP BCI and optional BCI parameters into PSTN XML ProgressIndicator

 200 OK

ANM or CON

PSTN XML body with ProgressIndicator with "Progress Description" value No (Value of PI) (NOTE)

Content

Backward call indicators parameter

Optional backward call indicators parameter

No. 1

("Call is not end-to-end ISDN: further call progress information may be available in-band")

Backward call indicators parameter

ISDN User Part indicator

0 "ISDN User Part not used all the way"

No. 2

("Destination address is non-ISDN")

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

0 "Terminating access non-ISDN"

No. 7

("Terminating access ISDN")

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

1 "Terminating access ISDN"

No. 8

("In-band information or an appropriate pattern is now available")

Optional backward call indicators parameter

In-band information indicator

1 "in-band information or an appropriate
pattern is now available"

NOTE: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)".

If the I-MGCF supports the PSTN XML body and receives a Transmission Medium Used (TMU) parameter,

NOTE 2: The I-MGCF will only receive a TMU parameter if it has applied the Fallback related procedures in clause 7.2.3.1.2.5a, including both a USI and TMR Prime parameter in the IAM, and fallback to the bearer capability identified in USI and TMR Prime occurred at the terminating side.

Then the I-MGCF shall:

– if a BC is not available in the ATP in the ANM or CON, map the TMU value (Speech or 3.1 kHz audio) to the PSTN XML BearerCapability element;

– if a BC is available in the ATP in the ANM or CON, include the received BC in the PSTN XML BearerCapability element;

– configure the IM-MGW to use the second format in the m-line in the SDP that has been received in the INVITE as codec at the IMS termination; and

– send SDP selecting the second format in the m-line of the SDP that has been received in the INVITE as soon as allowed according to SIP rules.

If the I-MGCF supports the PSTN XML body, has applied the Fallback related procedures in clause 7.2.3.1.2.5a, including both a TMR and TMR Prime in the IAM, and did not receive TMU in the ANM, CON, or any previous ISUP message,

NOTE 3: Fallback to the bearer capability identified in TMR did not occurre at the terminating side.

Then the I-MGCF shall:

– configure the IM-MGW to use the first format in the m-line in the SDP offer that has been received in the INVITE as codec at the IMS termination; and

– send SDP selecting the first format in the m-line in the SDP offer at the first possibility according to SIP rules.

7.2.3.1.6 Sending of the Release message (REL)

The following are possible triggers for sending the Release message:

– Receipt of the BYE method

Figure 10: Receipt of the Bye method

– Receipt of the CANCEL method

Figure 11: Receipt of Cancel method

Additional triggers are contained in table 10.

7.2.3.1.7 Coding of the REL

Coding of the REL message depends on the Reason header field (specified in IETF RFC 3326 [116]) contained in the BYE or CANCEL request.

If the Reason header field is missing or does not contain a cause parameter then the ISUP Cause Value in the REL message shall be coded as shown in table 8.

If the Reason header field contains a protocol header field parameter set to "Q.850" then the ISUP Cause Value shall be coded as shown in table 8a.

If the Reason header field contains a protocol header field parameter set to "SIP" then, as a network option, the ISUP Cause Value may be coded as shown in table 8aa.

The Location Field shall be set to "network beyond interworking point". If, as a network option, the I-MGCF supports the location header field parameter as described in IETF RFC 8606 [155], the I-MGCF shall instead derive the ISUP cause location from the location parameter in the SIP Reason header field as shown in table 8c.

Table 8: Coding of REL

SIP Message 	REL 
Request	cause indicators parameter
BYE	Cause value No. 16 (Normal call clearing)
CANCEL	Cause value No. 16 (Normal call clearing)

Table 8a: Mapping of SIP Reason header field
into Cause Indicators parameter – Q.850 protocol case

Component of SIP Reason header field	Component value	BICC/ISUP Parameter field	Value
Protocol	"Q.850"	Cause Indicators parameter	–
protocol‑cause	"cause = XX" (NOTE 1)	Cause Value	"XX" (NOTE 1)
–	–	Location	"network beyond interworking point"
NOTE: "XX" is the Cause Value as defined in ITU-T Recommendation Q.850 [38].

Table 8aa: Mapping of SIP Reason header field into Cause Indicators parameter – SIP protocol case

Component of SIP Reason header field	Component value	BICC/ISUP Parameter field	Value (NOTE 2)
Protocol	"SIP"	Cause Indicators parameter	–
protocol‑cause	"cause = 200" (NOTE 1)	Cause Value	"13" (Call completed elsewhere)
–	–	Location	"network beyond interworking point"
NOTE 1: The usage of SIP response codes such as "200" is specified in 3GPP TS 24.229 [9]. NOTE 2: The ISUP Cause Value in the REL message shall be coded as shown in table 8 if the connected CS network is other operator’s network, except when a bilateral agreement for use of the cause value(s) exists between the operators.

NOTE: The mapping of reason headers towards the ISDN can be misused due to possible user creation of the reason header since there is no screening in IMS.

If the I-MGCF supports this PSTN XML body as a network option and the I-MGCF interworks media encoded in any of the formats in table 2a (G.711, Clearmode or t38) without transcoding, and if a PSTN XML body is received in the BYE or CANCEL request, the I-MGCF shall derive the Access Transport Parameter in the REL message from the PSTN XML body as shown in table 8b.

Table 8b: Mapping of PSTN XML elements into ISUP Parameters

BYE or CANCEL 	REL 
PSTN XML	ISUP Parameter	Content
HighLayerCompatibility	Access Transport Parameter	High layer compatibility
LowLayerCompatibility	Access Transport Parameter	Low layer compatibility

Table 8c: Mapping of SIP Reason header field location parameter
into Cause Indicator Location parameter

Component of SIP Reason header field	Component value	BICC/ISUP Parameter field	Value
location	U	Location	user
	LPN		private network serving the local user
	LN		public network serving the local user
	TN		transit network
	RLN		public network serving the remote user
	RPN		private network serving the remote user
	LOC-6		network beyond interworking point
	INTL		international network
	LOC-8		network beyond interworking point
	LOC-9		network beyond interworking point
	BI		network beyond interworking point
	LOC-11		network beyond interworking point
	LOC-12		network beyond interworking point
	LOC-13		network beyond interworking point
	LOC-14		network beyond interworking point
	LOC-15		network beyond interworking point
NOTE: The interworking of the location value as described in this table is a network option.

7.2.3.1.8 Receipt of the Release Message

If the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall send a BYE message.

NOTE: According to SIP procedures, in the case that the REL message is received and a final response (e.g. 200 OK (INVITE)) has already been sent (but no ACK request has been received) on the incoming side of the I-MGCF then the I-MGCF does not send a 487 Request terminated response and instead waits until the ACK request is received before sending a BYE message.

If the REL message is received and the final response (i.e. 200 OK (INVITE)) has not already been sent, the I-MGCF shall send a Status-Code 4xx (Client Error), 5xx (Server Error) or 6xx (Global Failure) response. The Status code to be sent is determined by examining the Cause value received in the REL message. Table 9 specifies the mapping of the cause values, as defined in ITU-T Recommendation Q.850 [38], to SIP response status codes. Cause values not appearing in the table shall have the same mapping as the appropriate class defaults according to ITU-T Recommendation Q.850 [38].

Table 9: Receipt of the Release message (REL)

SIP Message	 REL
Status code	Cause indicators parameter
404 Not Found	Cause value No 1 (Unallocated (unassigned) number)
604 Does not exist anywhere	Cause value No 2 (No route to specified transit network)
604 Does not exist anywhere	Cause value No 3 (No route to destination)
500 Server Internal error	Cause value No 4 (Send special information tone)
404 Not Found	Cause value No 5 (Misdialled trunk prefix)
486 Busy Here	Cause value No 17 (User busy)
408 Request Timeout IF "ICS call" (NOTE 4) ELSE 480 Temporarily unavailable	Cause value No 18 (No user responding)
480 Temporarily unavailable	Cause value No 19 (No answer from user (user alerted))
408 Request Timeout IF "ICS call" (NOTE 4) ELSE 480 Temporarily unavailable	Cause value No 20 (Subscriber absent)
603 Decline IF location field is set to user ELSE 403 Forbidden	Cause value No 21 (Call rejected)
410 Gone	Cause value No 22 (Number changed)
410 Gone	Cause value No 23 (Redirection to new destination)
433 Anonymity Disallowed (NOTE 1)	Cause value No 24 (Call rejected due to feature at the destination)
483 Too Many Hops	Cause value No 25 (Exchange routing error)
480 Temporarily unavailable	Cause value No 26 (Non-selected user clearing)
502 Bad Gateway	Cause value No 27 (Destination out of order)
484 Address Incomplete	Cause value No 28 (Invalid number format (address incomplete))
501 Not Implemented	Cause value No 29 (Facility rejected)
480 Temporarily unavailable	Cause value No 31 (Normal, unspecified) (class default) (NOTE 2)
486 Busy here if Diagnostics indicator includes the (CCBS indicator = CCBS possible) else 503 Service Unavailable (NOTE 3)	Cause value No 34 (No circuit/channel available)
500 Server Internal error	Cause value No 38 (Network out of order)
503 Service Unavailable (NOTE 3)	Cause value No 41 (Temporary failure)
503 Service Unavailable (NOTE 3)	Cause value No 42 (Switching equipment congestion)
500 Server Internal error	Cause value No 43 (Access information discarded)
503 Service Unavailable (NOTE 3)	Cause value No 44 (Requested channel not available)
500 Server Internal error	Cause value No 46 (Precedence call blocked)
503 Service Unavailable (NOTE 3)	Cause value No 47 (Resource unavailable, unspecified) (class default)
488 Not acceptable here	Cause value No 50 (Requested facility not subscribed)
603 Decline	Cause value No 55 (Incoming class barred within Closed User Group (CUG))
603 Decline	Cause value No 57 (Bearer capability not authorised)
503 Service Unavailable (NOTE 3)	Cause value No 58 (Bearer capability not presently available)
501 Not Implemented	Cause value No 63 (Service option not available, unspecified) (class default)
500 Server Internal error	Cause value No 65 (Bearer capability not implemented)
501 Not Implemented	Cause value No 69 (Requested facility not implemented)
501 Not Implemented	Cause value No 70 (Only restricted digital information capability is available)
501 Not Implemented	Cause value No 79 (Service or option not implemented, unspecified) (class default)
403 Forbidden	Cause value No 87 (User not member of Closed User Group (CUG))
606 Not Acceptable	Cause value No 88 (Incompatible destination)
403 Forbidden	Cause value No 90 (Non existing Closed User Group (CUG))
500 Server Internal error	Cause value No 91 (Invalid transit network selection)
513 Message too large	Cause value No 95 (Invalid message, unspecified) (class default)
501 Not Implemented	Cause value No 97 (Message type non-existent or not implemented)
501 Not Implemented	Cause value No 98 (Message not compatible with call state or message type non-existent or not implemented)
501 Not Implemented	Cause value No 99 (Information element/parameter non-existent or not implemented)
504 Server timeout	Cause value No 102 (Recovery on timer expiry)
501 Not Implemented	Cause value No 103 (Parameter non-existent or not implemented, passed on)
501 Not Implemented	Cause value No 110 (Message with unrecognised parameter, discarded)
400 Bad Request	Cause value No 111 (Protocol error, unspecified) (class default)
500 Server Internal error	Cause value No 127 (Interworking, unspecified) (class default)
NOTE 1: Anonymity Disallowed, IETF RFC 5079 [77] refers NOTE 2: Class 0 and class 1 have the same default value. NOTE 3: No Retry-After header field shall be included. NOTE 4: The I‑MGCF identifies a call as an "ICS call" as specified in clause 7.2.3.1.2.12.

A Reason header field containing the received (Q.850) Cause Value of the REL shall be added to the SIP final response or BYE request sent as a result of this subclause. The mapping of the Cause Indicators parameter to the Reason header is shown in table 9a. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116]. If, as a network option, the I-MGCF supports the location header field parameter as described in IETF RFC 8606 [155], the I-MGCF shall map the ISUP cause location to the location parameter in the SIP Reason header field as shown in table 9a.

Table 9a: Mapping of Cause Indicators parameter into SIP Reason header fields

Cause indicators parameter field	Value of parameter field	component of SIP Reason header field	component value
–	–	protocol	"Q.850"
Cause Value	"XX" (NOTE 1)	protocol‑cause	"cause = XX" (NOTE 1)
–	–	reason‑text	Should be filled with the definition text as stated in ITU-T Recommendation Q.850 [38]. (NOTE 2)
Location (NOTE 3)	user	location	U
	private network serving the local user		LPN
	public network serving the local user		LN
	transit network		TN
	public network serving the remote user		RLN
	private network serving the remote user		RPN
	international network		INTL
	network beyond interworking point		BI
NOTE 1: "XX" is the Cause Value as defined in ITU-T Recommendation Q.850 [38]. NOTE 2: Due to the fact that the Cause Indicators parameter does not include the definition text as defined in table 1/Q.850 [38], this is based on provisioning in the I-MGCF. NOTE 3: The mapping of the cause location is a network option.

As a network option, an I-MGCF may generate an Error-Info header field according to rules and procedures of IETF RFC 3261 [19] to provide media instead of the in-band media received from the PSTN.

If the I-MGCF supports the PSTN XML body as a network option, the I-MGCF shall map the Access Transport Parameter received in the REL into PSTN XML elements as shown in table 9aa and include this PSTN XML body in the SIP final response or BYE.

Table 9aa: Mapping of ISUP Parameters into PSTN XML elements

4xx,5xx,6xx or BYE	REL
PSTN XML	ISUP Parameter	Content
ProgressIndicator	Access Transport Parameter	Progress indicator
HighLayerCompatibility (NOTE)		High layer compatibility
LowLayerCompatibility (NOTE)		Low layer compatibility
NOTE: The I-MGCF shall only provide this IE if it interworks media encoded in any of the formats in table 2a (G.711, Clearmode, or t38) without transcoding,

7.2.3.1.9 Receipt of RSC, GRS or CGB (H/W oriented)

Upon receipt of a RSC, GRS or CGB (H/W oriented) message the following applies independently for each affected circuit:

NOTE: For the RSC message, the circuit identified by the CIC is affected.
For the GRS message, the affected circuits are identified by the CIC and the Range subfield of the Range and Status parameter.
For the CGB message, the affected circuits are identified by the CIC and the Range and Status parameter.

If an initial address message has been sent for the affected circuit and after at least one backward message relating to that call has been received then:

– If the final response (i.e. 200 OK (INVITE)) has already been sent, the I-MGCF shall send a BYE message.

– If the final response (i.e. 200 OK (INVITE)) has not already been sent, the I-MGCF shall send a SIP response with Status-Code 480 Temporarily Unavailable.

A Reason header field containing the (Q.850) Cause Value of the REL message generated by the ISUP procedures shall be added to the SIP message (BYE or 480 response) to be sent by the SIP side of the I‑MGCF.

7.2.3.1.9a Receipt of REFER

Figure 11a: Receipt of REFER method

Upon receipt of a REFER request at the MGCF, the default behaviour of the I-MGCF is to reject the REFER request with a 403 Forbidden response.

NOTE: The I-MGCF may also decide for example to execute the REFER request as specified in IETF RFC 3515 [75] as an operator option, but such handling is outside of the scope of the present document.

7.2.3.1.10 Autonomous Release at I-MGCF

Table 10 shows the trigger events at the MGCF and the release initiated by the MGCF when the call is traversing from SIP to ISUP/BICC.

A Reason header field containing the (Q.850) Cause Value of the REL message sent by the I‑MGCF shall be added to the SIP Message (BYE request or final response) sent by the SIP side of the I‑MGCF.

Table 10: Autonomous Release at I‑MGCF

 SIP Response	Trigger event	REL 
 SIP Response		cause parameter
484 Address Incomplete	Determination that insufficient digits received.	Not sent.
480 Temporarily Unavailable	Congestion at the MGCF/Call is not routable.	Not sent.
BYE	ISUP/BICC procedures result in release after answer	According to ISUP/BICC procedures.
BYE	SIP procedures result in release after answer.	127 (Interworking unspecified)
500 Server Internal error	Call release due to the ISUP/BICC compatibility procedure (NOTE)	According to ISUP/BICC procedures.
484 Address Incomplete	Call release due to expiry of T7 within the ISUP/BICC procedures	According to ISUP/BICC procedures.
480 Temporarily Unavailable	Call release due to expiry of T9 within the BICC/ISUP procedures	According to BICC/ISUP procedures.
480 Temporarily Unavailable.	Other BICC/ISUP procedures result in release before answer.	According to BICC/ISUP procedures.
NOTE: MGCF receives unrecognized ISUP or BICC signalling information and determines that the call needs to be released based on the coding of the compatibility indicators, refer to ITU-T Recommendation Q.764 [4] and ITU-T Q.1902.4 [30].

7.2.3.1.11 Internal through connection of the bearer path

The through connection procedure is described in clause 9.2.2.3.5.

7.2.3.2 Outgoing Call Interworking from ISUP to SIP at O-MGCF

7.2.3.2.1 Sending of INVITE

7.2.3.2.1.1 General

Figure 11b: Receipt of an IAM

Upon reception of an IAM message, the O-MGCF shall send a SIP INVITE request, as further detailed in the clauses below.

An O-MGCF shall support both the SIP preconditions and 100rel extensions and indicate the support of the SIP preconditions and 100rel extensions in the INVITE request, unless the Note below applies.

NOTE: If the O-MGCF is deployed in an IMS network that by local configuration serves no user requiring preconditions, it may send the INVITE request without indicating support of preconditions.

7.2.3.2.1.2 Interaction with continuity check

If the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming IAM is set to indicate either "continuity check required on this circuit" or "continuity check performed on previous circuit", the O-MGCF should defer sending the INVITE request until receiving a COT message.

NOTE: If the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming IAM is set to indicate either "continuity check required on this circuit" or "continuity check performed on previous circuit" and the O-MGCF sends the INVITE request before receiving a COT message, the following considerations apply: If the receiving terminal is not supporting the SIP precondition and the SIP UPDATE method, clipping may occur. Furthermore, if the MGCF sets the SDP "inactive" attribute in the initial INVITE request and the receiving terminal is not supporting the SIP precondition, the interworking procedures within the present specification do not describe all necessary signalling interactions required to set up a call, in particular with respect to the sending of the re-INVITE that may also cause additional delay in the call setup. In addition, the interworking of the ringing indication might not be possible if the peer sends the ringing indication only as response to a re-INVITE.

NOTE: Waiting for the COT is recommended, if the Continuity Check indicator in the Nature of Connection Indicators parameter in the incoming IAM is set to indicate either "continuity check required on this circuit" or "continuity check performed on previous circuit"

Figure 12: Receipt of an IAM (Waiting for the COT message)

7.2.3.2.1.3 IAM without calling party number

If no calling party number is received in the incoming IAM message, as a network option, the O-MGCF may send an INR message to request the calling party number and not send the INVITE request until receiving an INF message with calling party number. If no calling party number is received in the INF message, O-MGCF may reject or continue the call based on local configuration.

Figure 12a: Receipt of an IAM (Request for calling party number)

7.2.3.2.1.4 Terminating overlap signalling at MGCF

Figure 13: Receipt of an IAM (Overlap signalling in CS network)

After initiating the normal incoming BICC/ISUP call establishment procedures, determining the end of address signalling and selecting to route the call to the IMS domain, the O‑MGCF shall send the initial INVITE.

The end of address signalling shall be determined by the earlier of the following criteria:

a) by receipt of an end-of-pulsing (ST) signal; or

b) by receipt of the maximum number of digits used in the national numbering plan; or

c) by analysis of the called party number to indicate that a sufficient number of digits has been received to route the call to the called party; or

d) by observing that timer Ti/w1 has expired after the receipt of the latest address message and the minimum number of digits required for routing the call have been received.

If the end of the address signalling is determined in accordance with criteria a) b) or c), the timer Ti/w2 is started when INVITE is sent. Also, if the PSTN XML body is supported as a network option, the O-MGCF shall insert the PSTN XML sendingCompleteIndication.

7.2.3.2.1.5 Fallback (optional)

The Fallback mechanism described in the present clause shall only apply if the O-MGCF supports the PSTN XML body as a network option, and propagates UDI-TA fallback signalling into the IMS as a network option.

NOTE: If the Fallback related signalling is not forwarded according to the procedures in the present sublause by the O-MGCF, the O-MGCF will apply the ISUP Fallback procedures when the IAM includes a TMR and a TMR prime parameter and a USI and USI Prime parameter.

When the IAM includes a TMR and a TMR prime parameter and a USI and USI Prime parameter then the O-MGCF shall:

– map the "USI Prime" into the "InformationTransferCapability" of the second BearerCapability element in the PSTN XML body;

– include SDP with one m-line of "audio" media type in the INVITE;

– map the "TMR" and "USI Prime" into a first offerered format in the SDP m-line according to table 10b;

– map the "USI" into the first Bearer Capability element in the PSTN XML body;

– map the "TMR prime" into the "InformationTransferCapability" of the first BearerCapability element in the PSTN XML body; and

– map the TMR prime and USI into a second offerered format in the SDP m-line according to table 10b.

7.2.3.2.1a Sending of INVITE without determining the end of address signalling

7.2.3.2.1a.1 General

As a network option, the O-MGCF is not required to determine the end of address signalling. In this case the O-MGCF shall send an initial INVITE when a preconfigured number of digits has been reached.

When the MGCF receives ISUP SAM messages the additional digits received in the SAMs may either be sent using the in-dialog overlap method as specified in clause 7.2.3.2.1a.2 or using the multiple INVITEs overlap method as specified in 7.2.3.2.1a.3. It depends on the network configuration which of these methods is applied. However, within one IMS only a single method shall be used.

7.2.3.2.1a.2 Additional digits sent with in-dialog overlap method

Figure 14: Overlap signalling using in-dialog INFOs in CS an IMS network

If the O-MGCF sends an initial SIP INVITE request before the end of address signalling is determined, the O-MGCF shall:

– use the SIP precondition extension within the SIP INVITE request;

– start timer Ti/w2;

– be prepared to process SAM as described below;

– be prepared to handle incoming SIP 18x provisional responses, establishing early dialogs; and

– be prepared to handle incoming SIP 404 or 484 error responses as detailed in clause 7.2.3.2.12.1.

NOTE 1: A SIP INVITE request with incomplete address information can be rejected with a SIP 404 or 484 error response.

On receipt of a SAM from the BICC/ISUP side, unless the O-MGCF has received a SIP 180 (Ringing) response for the call, the following O-MGCF procedures apply:

– The O-MGCF shall stop timer Ti/w3 (if it is running).

– If no response has been received for the previous INVITE request of the same call, the O-MGCF shall wait for the response and then apply the procedures in the next bullets to transfer the digits received in the SAM. If additional SAMs are received while the O-MGCF is waiting for the response for the previous SIP INVITE request, the digits within shall be combined with the digits of the previous SAMs.

– If an early dialog has not been established, and a SIP 404 or 484 error response has been received for the last previous SIP INVITE request for the same call, the O-MGCF shall send a SIP INVITE request complying to the following:

– The SIP INVITE request shall use the SIP preconditions extension.

– The SIP INVITE request shall include all digits received so far for this call in the Request‑URI.

– The SIP INVITE request shall include the same Call‑ID and From tag as the previous SIP INVITE request for the call.

– If an early dialog has been established, and a response has been received for any previously sent SIP INFO request ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086 [133]), the O-MGCF shall send an in-dialog SIP INFO request complying the following:

– The SIP INFO request shall only include the digits received since the previous SIP request with digits was sent (see Note).

– If no response has been received for the previous SIP INFO request, the O-MGCF shall wait for the response and then apply the procedures in the previous bullet to transfer digits received in the SAM. If additional SAMs are received while the O-MGCF is waiting for the response for the previous SIP INFO request, the digits within shall be combined with the digits of the previous SAMs.

– Restart Ti/w2.

If timer Ti/w2 has expired, or the O-MGCF has received a SIP 180 (Ringing) response for the call, the O‑MGCF shall ignore subsequent SAMs received.

NOTE 2: The encoding of the digits within the SIP INFO request is described in clause 7.2.3.2.20.2.

7.2.3.2.1a.3 Additional digits sent using the multiple INVITEs overlap method

Figure 14a: Overlap signalling using multiple INVITEs in CS an IMS network

If the O-MGCF sends an SIP INVITE request before the end of address signalling is determined, the O-MGCF shall:

– use the SIP precondition extension within the SIP INVITE request;

– start timer Ti/w2; and

– be prepared to process SAM as described below; and

– be prepared to handle incoming SIP 404 or 484 error responses as detailed in clause 7.2.3.2.12.1.

NOTE: An SIP INVITE request with incomplete address information will be rejected with a SIP 404 or 484 error response.

On receipt of a SAM from the BICC/ISUP side, unless the O-MGCF has received a SIP 180 (Ringing) response for the call, the O‑MGCF shall:

– stop timer Ti/w3 (if it is running);

– send an INVITE request complying to the following:

– The SIP INVITE request shall use the SIP preconditions extension.

– The SIP INVITE request shall include all digits received so far for this call in the Request‑URI.

– The SIP INVITE request shall include the same Call‑ID and From tag as the previous SIP INVITE request for the call.

– restart Ti/w2;

If timer Ti/w2 has expired, or the O-MGCF has received a SIP 180 (Ringing) response for the call, the O‑MGCF shall ignore subsequent SAMs received.

7.2.3.2.2 Coding of the INVITE

7.2.3.2.2.0 Overview

Table 10aa provides a summary of how the header fields within the outgoing INVITE message are populated.

Table 10aa: Interworked contents of the INVITE message

IAM	INVITE
Called Party Number	Request-URI To History-Info
Calling Party Number	P-Asserted-Identity
	Privacy
	From
	Attestation-Info
	Origination-Id
Generic Number ("additional calling party number")	From
	Privacy
	Attestation-Info
	Origination-Id
Called IN number	History-Info
Original called IN number	History-Info
Hop Counter	Max-Forwards
TMR/USI	Message Body (application/SDP)
Location Number	P-Access-Network-Info

7.2.3.2.2.1 Request-URI and To header field

The called party number parameter of the IAM message is used to derive Request-URI of the INVITE request. The Request-URI is a tel URI or SIP URI with "user=phone" and shall contain:

– an E.164 International public telecommunication number prefixed by a "+" sign (e.g. tel:+4911231234567) , or

– a non E.164 number (national operator option for service numbers), expressed as a local number as per IETF RFC 3966 [97].

Table 10a: Mapping ISUP Called Party Number to
SIP Request-URI and To header field

IAM		INVITE
BICC/ISUP Parameter / field	Value	SIP component	Value
Called Party Number (NOTE 3)		Request-URI and To header field	display-name (optional) and addr-spec derived from Called Party Number parameter address signals
Nature of Address Indicator (NOTE 2) (NOTE 6)	"national (significant) number"	Tel URI or SIP URI	Insert "+CC" before the Address signals (NOTE 1)
	"international number"		Insert "+" before the Address signals
	"Network-specific number" or "reserved for national use"		according to local policies should either be: – a global number (+CC), if the called party number may be converted into an E.164 address OR, depending on operator’s requirements may be converted into – local number (with a phone-context parameter) (NOTE 4) (NOTE 5)
NOTE 1: CC = Country Code of the network in which the O-MGCF is located. NOTE 2: The usage of "Nature of address indicator" value "unknown" is allowed but the mapping is not specified in the present specification. NOTE 3: If the address signals received in the ISUP Called Party Number contain a sending terminated signal (hexadecimal digit F), then this shall be discarded or if the O-MGCF supports the PSTN XML body as a network option then the PSTN XML sendingCompleteIndication shall be set. NOTE 4: Mapping between nature of address indicator values and phone-context values is provisioned in the MGCF. Setting of value of phone-context is depending on local operator’s policies. NOTE 5: Network-specific number or reserved for national use shall be translated into E.164 format numbers except if local operator’s policy requires keeping in local format (e.g. for national reasons E.164 numbers cannot be used for such purpose). In the later case the mapping shall be done as indicated in the table. NOTE 6: The values "Network routing number in national (significant) number format", "Network routing number in network specific number format" or "Network routing number concatenated with called directory number" are used when number portability is supported. For the mapping see clause 7.2.3.2.2A.

7.2.3.2.2.2 SDP Media Description

If the O-MGCF indicates support of the SIP preconditions in the initial INVITE request and local preconditions have not been met, the SDP media description shall contain precondition information as per 3GPP TS 24.229 [9]. Depending on the coding of the continuity indicators different precondition information (IETF RFC 3312 [37]) is included. If the continuity indicator indicates "continuity performed on a previous circuit" or "continuity required on this circuit", and the INVITE is sent before receiving a COT, message (which is not recommended according to clause 7.2.3.2.1.1), then the O-MGCF shall indicate that the preconditions are not met. Otherwise the O-MGCF shall indicate whether the preconditions are met, dependent on thestatus of the local resource reservation.

If the O-MGCF determines that a speech call is incoming, the O-MGCF shall include the AMR codec transported according to IETF RFC 4867 [23] with the options listed in clause 12.3.1 of 3GPP TS 26.114 [104] in the SDP offer, unless the Note below applies. Within the SDP offer, the O-MGCF should also provide SDP RR and RS bandwidth modifiers specified in IETF RFC 3556 [59] as detailed in clause 7.3.1 of 3GPP TS 26.114 [104]. The O-MGCF may include other codecs according to operator policy.

NOTE: If the O-MGCF is deployed in an IMS network that by local configuration serves no user equipment that implements the AMR codec, then the AMR codec may be excluded from the SDP offer.

To avoid transcoding or to support non-speech services, the O-MGCF may add media derived from the incoming ISUP information according to table 10b. The support of the media listed in table 10b is optional. If the O-MGCF supports the PSTN XML body as a network option and adds media derived from the incoming ISUP information according to table 10b, the O-MGCF shall also map the media related ISUP information into the XML body as shown in table 7.2.3.2.2.7.1.

Table 10b: Coding of SDP media description lines from TMR/USI: ISUP to SIP

TMR parameter	USI parameter (Optional)		HLC IE in ATP (Optional)	m= line			b= line	a= line
TMR codes	Information Transfer-Capability	User Information Layer 1 Protocol Indicator	High Layer Characteristics Identification	<media>	<transport>	<fmt-list>	<modifier>: <bandwidth-value>	rtpmap:<dynamic-PT> <encoding name>/<clock rate>[/encoding parameters>
"speech"	"Speech"	"G.711 μ-law"	Ignore	audio	RTP/AVP	0 (and possibly 8) (NOTE 1)	AS: (64 + RTP/UDP/IP overhead)	rtpmap:0 PCMU/8000 (and possibly rtpmap:8 PCMA/8000) (NOTE 1)
"speech"	"Speech"	"G.711 μ-law"	Ignore	audio	RTP/AVP	Dynamic PT (and possibly a second Dynamic PT) (NOTE 1)	AS: (64 + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> PCMU/8000 (and possibly rtpmap:<dynamic-PT> PCMA/8000) (NOTE 1)
"speech"	"Speech"	"G.711 A-law"	Ignore	audio	RTP/AVP	8	AS: (64 + RTP/UDP/IP overhead)	rtpmap:8 PCMA/8000
"speech"	"Speech"	"G.711 A-law"	Ignore	audio	RTP/AVP	Dynamic PT	AS: (64 + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> PCMA/8000
"3.1 KHz audio"	USI Absent		Ignore	audio	RTP/AVP	8	AS: (64 + RTP/UDP/IP overhead)	rtpmap:8 PCMA/8000
"3.1 KHz audio"	"3.1 KHz audio"	"G.711 μ-law"	(NOTE 3)	audio	RTP/AVP	0 (and possibly 8) (NOTE 1)	AS: (64 + RTP/UDP/IP overhead)	rtpmap:0 PCMU/8000 (and possibly rtpmap:8 PCMA/8000) (NOTE 1)
"3.1 KHz audio"	"3.1 KHz audio"	"G.711 A-law"	(NOTE 3)	audio	RTP/AVP	8	AS: (64 + RTP/UDP/IP overhead)	rtpmap:8 PCMA/8000
"3.1 KHz audio"	"3.1 KHz audio"		"Facsimile Group 2/3"	image (NOTE 9)	Udptl [73]	t38[73]	AS: (64 + UDP/IP overhead)	Based on ITU-T T.38 [72]. (NOTE 8)
"3.1 KHz audio"	"3.1 KHz audio"		"Facsimile Group 2/3"	image (NOTE 9)	Tcp (NOTE 7)	t38[73]	AS: (64 + TCP/IP overhead)	Based on ITU-T T.38 [72]. (NOTE 8)
"3.1 KHz audio"	"3.1 KHz audio"		"Facsimile Group 2/3"	Audio (NOTE 9)	RTP/AVP	0, 8, or <dynamic-PT>	AS: (64 + RTP/UDP/IP overhead)	rtpmap:0 PCMA/8000 or rtpmap:8 PCMU/8000 or rtpmap:<dynamic-PT> PCMA/8000 or rtpmap:<dynamic-PT> PCMU/8000
"64 kbit/s preferred"	"Speech/ 3.1KHz audio" (NOTE 6)	N/A	Ignore	audio	RTP/AVP	Dynamic PT	AS: (64 + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> CLEARMODE/8000 (NOTE 2)(NOTE 4)
"64 kbit/s unrestricted"	"Unrestricted digital information"	N/A	Ignore	audio	RTP/AVP	Dynamic PT	AS: (64 + RTP/UDP/IP overhead)	rtpmap:<dynamic-PT> CLEARMODE/8000 (NOTE 2)(NOTE 5)
NOTE 1: Both PCMA and PCMU could be required. NOTE 2: CLEARMODE is specified in IETF RFC 4040 [69]. NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/ITU-T Q.939 indicates that this would normally be accompanied by a value of "Speech" for the Information Transfer Capability element. NOTE 4: After the CLEARMODE codec, additional speech codecs such as AMR and/or G.722 and/or G.711 available via transcoding or reframing should be offered in the same m-line. NOTE 5: As alternative or in addition to the m-line containing the CLEARMODE codec, an MGCF supporting the multimedia interworking detailed in Annex E may add an m-line for speech codecs and an m-line for video codecs as detailed in this Annex. NOTE 6: In this case, the USI prime parameter will also be present and will indicate "Unrestricted Digital Information with tones/announcements". NOTE 7: This value is not recommended in a network supporting MTSI clients as it is not supported by an MTSI client (see TS 24.173 [88]). NOTE 8: Annex K describes recommended values. NOTE 9: FAX can either be transported according to ITU-T recommendation T.38 [72] using the "image" media type or as inband Voice band data over IP using the "audio" media type.

7.2.3.2.2.3 P-Asserted-Identity, From and Privacy header fields

Table 12: Mapping BICC/ISUP CLI parameters to SIP header fields

Has a Calling Party Number parameter with complete E.164 number, and with Screening Indicator = UPVP or NP (NOTE 1) been received?	Calling Party Number APRI	Has a Generic Number (AcgPN) with a complete E.164 number and with Screening Indicator = UPNV been received?	Generic Number APRI	P-Asserted-Identity header field	From header field	Privacy header field
N	–	N	–	Header field not included or if included SIP URI with addr-spec of Unavailable User Identity (NOTE 11)	SIP URI with addr-spec of Unavailable User Identity (NOTE 2) (NOTE 6) (NOTE 12)	Header field not included (NOTE 11)
N	–	Y (NOTE 3)	"presentation allowed"	Header field not included or if included SIP URI with addr-spec of Unavailable User Identity (NOTE 11)	addr-spec derived from Generic Number (AcgPN) address signals or network provided value (NOTE 6)	Header field not included (NOTE 11)
N	–	Y (NOTE 3)	"presentation restricted"	Header field not included or if included SIP URI with addr-spec of Unavailable User Identity (NOTE 11)	SIP URI with addr-spec of Unavailable User Identity (NOTE 2) (NOTE 6)	Header field not included (NOTE 11)
N	–	Y (NOTE 3)	"presentation restricted"		Derived from the Generic Number parameter address signals (see table 13) (NOTE 6) (NOTE 8)	priv-value =: "user" (See table 16).
Y	"presentation allowed"	N	–	Derived from Calling Party Number parameter address signals (See table 14)	Tel URI or SIP URI derived from Calling Party Number parameter address signals (See table 15) (NOTE 6) (NOTE 12)	Privacy header is not included or if included, "id" and "header" are not included (See table 16)
Y	"presentation allowed"	Y	"presentation allowed"	Derived from Calling Party Number parameter address signals (See table 14)	Derived from Generic Number (AcgPN) address signals (See table 13) (NOTE 6)	Privacy header is not included or if included, "id", "header" and "user" are not included (See table 16).
Y	"presentation allowed"	Y	"presentation restricted"	Derived from Calling Party Number parameter address signals (See table 14)	Tel URI or SIP URI derived from Calling Party Number parameter address signals (See table 15) (NOTE 6) (NOTE 9)	Privacy header is not included or if included, "id" and "header" are not included (See table 16).
					SIP URI with addr-spec of Anonymous URI (NOTE 6) (NOTE 7) (NOTE 10)	Privacy header is not included or if included, "id" and "header" are not included (See table 16).
					Derived from the Generic Number parameter address signals (see table 13) (NOTE 6) (NOTE 8)	priv-value =: "user". "id" and "header" are not included (See table 16).
Y	"presentation restricted"	N	–	Derived from Calling Party Number parameter address signals (See table 14)	SIP URI with addr-spec of Unavailable User Identity (NOTE 2) (NOTE 6) (NOTE 12)	priv-value =: "id". (See table 16)
Y	"presentation restricted"	Y	"presentation allowed"	Derived from Calling Party Number parameter address signals (See table 14)	Derived from Generic Number (AcgPN) address signals (See table 13) (NOTE 6)	priv-value =: "id".
Y	"presentation restricted"	Y	"presentation restricted"	Derived from Calling Party Number parameter address signals (See table 14)	SIP URI with addr-spec of Anonymous URI (NOTE 6) (NOTE 7) (NOTE 10)	priv-value =: "id"
Y	"presentation restricted"	Y	"presentation restricted"		Derived from the Generic Number parameter address signals (see table 13) (NOTE 6) (NOTE 8)	priv-value =: "id", "user". (See table 16).
Y	"presentation restricted by network" (NOTE 4)	N	–	Header field not included.	Addr-spec is set to "unavailable@hostportion" (NOTE 5) (NOTE 6) (NOTE 12)	Privacy header is not included or if included, "id" and "header" are not included (See table 16)
Y	"presentation restricted by network"	Y	"presentation allowed"	Header field not included.	Derived from Generic Number (AcgPN) address signals (See table 13) (NOTE 6)	Privacy header is not included or if included, "id", "header" and "user" are not included (See table 16).
Y	"presentation restricted by network"	Y	"presentation restricted"	Header field not included.	Addr-spec is set to Anonymous URI (NOTE 6) (NOTE 7)	Privacy header is not included or if included, "id" and "header" are not included (See table 16).
Y	"presentation restricted by network"	Y	"presentation restricted"	Header field not included.	Derived from the Generic Number parameter address signals (see table 13) (NOTE 6) (NOTE 8)	priv-value =: "user". "id" and "header" are not included (See table 16).
NOTE 1: A Network Provided CLI in the CgPN parameter may occur on a call to IMS. Therefore in order to allow the "display" of this Network Provided CLI at a SIP UAS it shall be mapped into the SIP From header. It is also considered suitable to map into the P-Asserted-Identity header since in this context it is a fully authenticated CLI related exclusively to the calling line, and therefore as valid as a User Provided Verified and Passed CLI for this purpose. NOTE 2: The "From" header may contain an "Unavailable User Identity". An "Unavailable User Identity" includes information that does not point to the calling party and indicates that the caller’s identity is unknown. The encoding of the "Unavailable User Identity" shall be as defined in 3GPP TS 23.003 [74]. NOTE 3: This combination of CgPN and AcgPN is an error case but is shown here to ensure consistent mapping across different implementations. NOTE 4: This is an ETSI specific value described within ETSI EN 300 356-1 [70]. NOTE 5: The setting of the hostportion is according to operator policy. NOTE 6: In accordance with IETF RFC 3261 [19] procedures, a tag shall be added to the "From" header. NOTE 7: The "From" header may contain an "Anonymous User Identity". An "Anonymous User Identity" includes information that does not point to the calling party and indicates that the caller has withheld their identity. The encoding of the "Anonymous User Identity" shall be as defined in 3GPP TS 23.003 [74]. NOTE 8: As a network option, the "From" header may be derived from the Generic Number parameter address signals (see table 13). This option is only recommended to use within a trusted domain where an entity such as a TAS is configured to be inserted into the call path that is able to change the "From" Header content to an anonymous user identity (NOTE 7). NOTE 9: As a network option, the "From" header may be derived from the Calling Party Number parameter address signals (see table 15). This option is only recommended to use within a trusted domain where an entity such as a TAS is configured to be inserted into the call path that is able to change the "From" Header content to an anonymous user identity (NOTE 7). NOTE 10: Network option. NOTE 11: As a network option, the P-Asserted-Identity header field may be included. The URI of the P-Asserted-Identity header field is "Unavailable User Identity" defined in 3GPP TS 23.003 [74]. When populating the P-Asserted-Identity header field containing the "Unavailable User Identity" into a SIP request, the MGCF may populate the Privacy header field set to "id" into the SIP request in order to avoid this identity to be displayed to user. NOTE 12: As a network option, for calls where a Generic Number (ACgPN) with the "Nature of Address Indicator" values" subscriber number" or "unknown" is received, the nature of address indicator and address signals may instead be mapped into the SIP From header field as specified in Table 13.

Table 13: Mapping of generic number (additional calling party number) to SIP From header field

BICC/ISUP parameter / field	Value	SIP component	Value
Generic Number Number Qualifier Indicator	"additional calling party number"	From header field	display-name (optional) and addr-spec
Nature of Address Indicator	"national (significant) number"	Tel URI or SIP URI	Add CC (of the country where the MGCF is located) to GN address signals to construct E.164 number in URI. Prefix number with "+".
	"international number"		Map complete GN address signals to E.164 number in URI. Prefix number with "+".
	"subscriber number" or "unknown" (NOTE 1)		Map complete GN address signals. Add phone-context URI parameter (NOTE 2)
Address signal	if NOA is "national (significant) number" then the format of the address signals is: NDC+ SN If NOA is "international number" then the format of the address signals is: CC + NDC + SN
		Tel URI or SIP URI	CC+NDC+SN as E.164 number in URI. Prefix number with "+".
	If NOA is "subscriber number" (NOTE 1), then the format of the address signals is: SN		Map subscriber number as local number with a phone-context URI parameter (NOTE 2)
	If NOA is "unknown" (NOTE 1), then the format of the address signals is determined by the operator.		Map address signals with a phone-context URI parameter (NOTE 2)
	If NOA is "subscriber number" (NOTE 1), then the format of the address signals is: SN		Map subscriber number as local number with a phone-context URI parameter (NOTE 2)
	If NOA is "unknown" (NOTE 1), then the format of the address signals is determined by the operator.		Map address signals with a phone-context URI parameter (NOTE 2)
NOTE 1: The usage and the interworking of the "Nature of Address Indicator" values "subscriber number" and "unknown" is a national operator option. NOTE 2: Mapping between "Nature of Address Indicator" values and phone-context values is provisioned in the MGCF. Setting the values of phone-context is dependent on local operator’s policies.

Table 14: Mapping of calling party number parameter to SIP P-Asserted-Identity header fields

BICC/ISUP Parameter / field	Value	SIP component	Value
Calling Party Number		P-Asserted-Identity header field	addr-spec and optionally display-name (NOTE 1)
Nature of Address Indicator	"national (significant) number"	Tel URI or SIP URI (NOTE 2)	Add CC (of the country where the MGCF is located) to CgPN address signals to construct E.164 number in URI. Prefix number with "+".
Nature of Address Indicator	"international number"	Tel URI or SIP URI (NOTE 2)	Map complete CgPN address signals to E.164 number in URI. Prefix number with "+".
Address signal	If NOA is "national (significant) number" then the format of the address signals is: NDC + SN If NOA is "international number" then the format of the address signals is: CC + NDC + SN	Tel URI or SIP URI (NOTE 2)	CC+NDC+SN as E.164 number in URI. Prefix number with "+"
NOTE 1: The display-name may be mapped from the corresponding telephone number if possible and allowed by network operator policies. NOTE 2: A tel URI or a SIP URI with "user=phone" is used according to operator policy.

Table 15: Mapping of BICC/ISUP Calling Party Number parameter to SIP From header field

BICC/ISUP parameter / field	Value	SIP component	Value
Calling Party Number		From header field
Nature of Address Indicator	"national (significant) number"	Tel URI or SIP URI (NOTE)	Add CC (of the country where the MGCF is located) to CgPN address signals then map to construct E.164 number in URI. Prefix number with "+".
Nature of Address Indicator	"international number"	Tel URI or SIP URI (NOTE)	Map complete CgPN address signals to construct E.164 number in URI. Prefix number with "+".
Address signal	If NOA is "national (significant) number" then the format of the address signals is: NDC + SN If NOA is "international number" then the format of the address signals is: CC + NDC + SN	Tel URI or SIP URI (NOTE)	CC+NDC+SN as E.164 number in URI. Prefix number with "+".
NOTE: A tel URI or a SIP URI with "user=phone" is used according to operator policy.

Table 16: Mapping of BICC/ISUP APRIs into SIP Privacy header fields

BICC/ISUP parameter / field	Value	SIP component	Value
Calling Party Number		Privacy header field	priv-value
APRI	"presentation restricted"	Priv-value	"id" ("id" included only if the P-Asserted-Identity header is included in the SIP INVITE)
APRI	"presentation allowed" or "presentation restricted by network"	Priv-value	omit Privacy header or Privacy header without "id" and "header" if other privacy service is needed
Generic Number (ACgPN)		Privacy header field	priv-value
APRI (NOTE)	"presentation restricted"	Priv-value	"user"
APRI (NOTE)	"presentation allowed"	Priv-value	omit Privacy header or Privacy header without "user" if other privacy service is needed
NOTE: Mapping of Generic Number APRI is only applicable, if the Generic Number is mapped to the "From" header field (see table 12).

If, as a network option, the MGCF supports "Calling number verification using signature verification and attestation information" feature as described in IETF RFC 8224 [153] and 3GPP TS 24.229 [9], the MGCF shall:

– include in the initial INVITE request:

a) attestation level in the Attestation-Info header field defined in 3GPP TS 24.229 [9]; and

b) the origination identifier in the Origination-Id header field defined in 3GPP TS 24.229 [9]; and

– if the MGCF performed mapping of Calling party number parameter to the P-Asserted-Identity header field as defined in table 14 and the MGCF received the Calling party number with the Screening indicator set to value "user provided, verified and passed":

a) set the value of the Attestation-Info header field to "B" (Partial Attestation) as described in 3GPP TS 24.229 [9]; and

b) use own address or identifier for creation of the Origination-Id header field as described in 3GPP TS 24.229 [9]; or

– otherwise, for all other mapping cases defined in table 12:

a) set the value of the Attestation-Info header field to "C" (Gateway Attestation) as described in 3GPP TS 24.229 [9]; and

b) use the received Circuit identification field (i.e. Circuit identification code) for creation of the Origination-Id header field as described in 3GPP TS 24.229 [9].

7.2.3.2.2.3A "cpc" URI Parameter in P-Asserted-Identity Header

See Annex C for normative interworking of a Calling party’s category to a "cpc" URI parameter within P-Asserted-Identity header field.

7.2.3.2.2.3B "oli" URI Parameter in P-Asserted-Identity Header

See Annex H for normative interworking of the "oli" URI parameter as a network option.

7.2.3.2.2.4 Max Forwards header

If the Hop Counter procedure is supported in the CS network, the O‑MGCF shall use the Hop Counter parameter to derive the Max-Forwards SIP header. Due to the different default values (that are based on network demands/provisions) of the SIP Max-Forwards header and the Hop Counter, an adaptation mechanism shall be used to adopt the Hop Counter to the Max Forwards at the O‑MGCF. For example, the following guidelines could be applied.

a) Max-Forwards for a given message should be monotone decreasing with each successive visit to a SIP entity, regardless of intervening interworking, and similarly for Hop Counter.

b) The initial and successively mapped values of Max-Forwards should be large enough to accommodate the maximum number of hops that may be expected of a validly routed call.

The table 17 shows the principle of the mapping:

Table 17: Hop counter-Max forwards

Hop Counter	= X	Max-Forwards	= Y = Integer part of (X * Factor)
NOTE: The Mapping of value X to Y should be done with the used (implemented) adaptation mechanism.

The factor used to map from Hop Counter to Max‑Forwards for a given call will depend on call origin, and will be provisioned at the O‑MGCF based on network topology, trust domain rules, and bilateral agreement.

The Principle of adaptation could be implemented on a basis of the network provision, trust domain rules and bilateral agreement.

7.2.3.2.2.5 IMS Communication Service Identifier

For speech and video calls, the O-MGCF shall insert an IMS Communication Service Identifier, indicating the IMS Multimedia Telephony Communication Service.

The IMS Communication Service Identifier for the IMS Multimedia Telephony Communication Service is defined in 3GPP TS 24.173 [88].

7.2.3.2.2.6 P-Early-Media header field

For a speech call the O-MGCF may include the P-Early-Media header field with the "supported" parameter as described in IETF RFC 5009 [89] in each outgoing INVITE request.

NOTE: The P-Early-Media header with the "supported" parameter can be ignored by terminating devices when not supporting the procedures described in IETF RFC 5009 [89].

7.2.3.2.2.7 PSTN XML elements

If the O-MGCF supports the PSTN XML body as a network option, the O-MGCF shall map ISUP information into the XML body as shown in table 7.2.3.2.2.7.1 and 7.2.3.2.2.8.1.

Table 7.2.3.2.2.7.1: Mapping of ISUP Parameters with PSTN XML elements

IAM 		INVITE 
ISUP Parameter	Content	PSTN XML
Access Transport Parameter	High layer compatibility	HighLayerCompatibility (NOTE 1, NOTE 2, NOTE 3)
Access Transport Parameter	Low layer compatibility	LowLayerCompatibility (NOTE 3)
User Service Information		Bearer Capability (NOTE 3, NOTE 4)
User Teleservice Information	High layer compatibility	HighLayerCompatibility (NOTE 2, NOTE 3)
Called Party Number	Sending terminated signal (hexadecimal digit F)	sendingCompleteIndication
NOTE 1: If two high layer compatibility information elements are received in the ATP of the IAM, they shall be transferred in the same order as received into the PSTN XML body within the INVITE. NOTE 2: In the normal case, the High layer compatibility information in the ATP is equal to the High layer compatibility in the User Teleservice Information parameter. In the PSTN XML body, no two identical High layer compatibility information shall be present. If an HLC is available both in the ATP and in the User Teleservice information, the HLC from the ATP should be mapped. NOTE 3: The O-MGCF shall only map this information element if the O-MGCF offers media formats which can be transferred by the IM-MGW without transcoding and are derived from the incoming ISUP information according to table 10b. NOTE 4: See clause 7.2.3.2.1.5.

7.2.3.2.2.8 Progress indicator

If the O-MGCF supports the PSTN XML body as a network option, the Forward call indicators parameter and an available "Progress indicator" element in the IAM shall be mapped into a ProgressIndicator in the PSTN XML body of the INVITE as shown in table 7.2.3.2.2.8.

Table 7.2.3.2.2.8: Coding of PSTN XML ProgressIndicator

IAM			INVITE 
Forward call indicators parameter		Access transport parameter	PSTN XML body with ProgressIndicator with "Progress Description" value No. (Value of PI)
ISDN User Part indicator	ISDN access indicator
0 ("ISDN User Part not used all the way")	Value non-significant	Value non-significant	No. 1 (NOTE 1)
1 ("ISDN User Part used all the way")	0 ("originating access non – ISDN")	Value non-significant	No. 3 (NOTE 1)
1 ("ISDN User Part used all the way")	1 ("originating access ISDN")	Progress indicator No. (Value of PI)	ProgressIndicator mapped from Progress indicator received in the ATP (NOTE 2) and additional ProgressIndicator with "Progress Description" value No.6 (NOTE 1, NOTE 3)
1 ("ISDN User Part used all the way")	1 ("originating access ISDN")	Not present	No. 6 (NOTE 1)
NOTE 1: The ProgressIndicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the ProgressIndicator "Location" parameter is "0011 (Transit Network)". NOTE 2: The entire Progress indicator, including the "Progress Description", "Coding Standard" and "Location" parameters shall be copied. NOTE 3: The order of ProgressIndicators within PSTN XML body is irrelevant.

7.2.3.2.2.9 P-Access-Network-Info

If the IAM message includes a location number ISDN user part parameter, the O-MGCF shall include a P-Access-Network-Info header. The P-Access-Network-Info shall be populated as shown in table 7.2.3.2.2.9.1.

Table 7.2.3.2.2.9.1: Coding of the P-Access-Network-Info header fields

BICC/ISUP parameter / field	SIP component	Value
Location Number	access-type	"GSTN"
	gstn-location (NOTE)	value of Location Number, in quotes
NOTE: Alternatively, as a network option, the value of the Location Number can populate the operator-specific-GI parameter. In this case, the operator-specific-GI is set to the text string between quotes with the sequence of digits found in octet 3 to N (except the filler) starting with the 1^st digit. The access-info parameter is set to "operator-specific-GI"

Table 7.2.3.2.2.9.2: Mapping ISUP Location Number to SIP P-Access-Network-Info

IAM	INVITE
Location Number	P-Access-Network-Info
Parameter name	not mapped
Parameter length	not mapped
Parameter content	gstn-location set to the hexadecimal representation of the ISUP parameter content, encoded as a text string between quotes
NOTE 1: As specified in ITU-T Q.763 [4], the parameter content includes both the header fields (octets 1 and 2) and the address signals. NOTE 2: The parameter content includes the address presentation restricted indicator. This field is not mapped to the Privacy header field. It is upon network operator responsibility to remove the P-Access-Network-Info header field when leaving the trust domain, as specified in 3GPP TS 24.229 [9]. NOTE 3: If the screening indicator is set to network provided, a "network-provided" parameter is added to the P-Access-Network-Info header field value.

7.2.3.2.2A Coding of the INVITE when Number Portability is supported

This clause describes optional coding procedures when Number Portability is supported.

7.2.3.2.2A.1 Request-URI and To header field

When Number Portability is supported, the method used for signalling of the Called Party E.164 address and the Number Portability Routing Number determines the parameters of the IAM message used to derive the Request-URI of the INVITE request.

The number portability information (rn and npdi) shall not be mapped into the To header field.

The following clauses describe how the Request-URI and To header field are populated, based on these methods, when a Number Portability Routing Number is available in the IAM.

When the optional Number Portability Routing Number is available and supported, these procedures take precedence over procedures for coding of the Request-URI and To header field described in clause 7.2.3.2.2.1.

When a Number Portability Routing Number is not available, the Request-URI and To header field are populated as described in clause 7.2.3.2.2.1, with the following addition: If a Number Portability Forward Information parameter is present in the IAM, containing a value of "number portability query done for called number, non-ported called subscriber", a tel URI npdi parameter [93] is added.

For the following clauses, the Request-URI is a tel URI or SIP URI with "user=phone" and shall contain an E.164 International public telecommunication number prefixed by a "+" sign (e.g. tel:+4911231234567).

7.2.3.2.2A.1.1 Separate Directory Number Addressing Method

Table 17a: Mapping ISUP to SIP Request-URI and To header field with Number Portability Separate Directory Number Addressing Method

IAM		INVITE
Called Party Number	Called Directory Number	Request-URI and To Header Field
Address Signal: Nature of address indicator: "Network routing number in national (significant) number format" or "National (significant) number" or "Network routing number in network specific number format" as described in ITU-T Q.769.1 [92] (NOTE 2)	Address Signal: Nature of address indicator: "National (significant) number".	The "telephone-subscriber" is populated from the Called Directory Number as follows: Insert "+CC" before the Address signals (NOTE 1) The Tel URI rn= parameter is populated from the Called Party Number as follows: Insert "+CC" before the Address signals (NOTE 1) and is added only to the Request-URI. Use of the local form of the rn= parameter is out of the scope of the present specification. Tel URI npdi parameter as defined in IETF RFC 4694 [93] is added only to the Request-URI.
NOTE 1: CC = Country Code of the network in which the O-MGCF is located. NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal (hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the sendingCompleteIndication shall be included.

7.2.3.2.2A.1.2 Concatenated Addressing Method

Table 17b: Mapping ISUP to SIP Request-URI and To header field with Number Portability Concatenated Number Addressing Method

IAM	INVITE
Called Party Number	Request-URI and To Header Field
Address Signal: Nature of address indicator: "Network routing number concatenated with called directory number" or "National (significant) number" as described in ITU-T Q.769.1 [92] (NOTE 2)	The "telephone-subscriber" is populated from the Called Party Number as follows: Remove the prefix representing the Number Portability Routing Number or the prefix prior to the directory number (NOTE3). Insert "+CC" before the Address signals (NOTE 1). The Tel URI rn= parameter is populated from the Called Party Number as follows and is added only to the Request-URI: Use all address digits contained within the Called Party Number or remove the digits that follow the prefix representing the Number Portability Routing Number Insert "+CC" before the Address signals (NOTE 1) Use of the local form of the rn= parameter is out of the scope of the present specification. Tel URI npdi parameter as defined in IETF RFC 4694 [93] is added only to the Request-URI.
NOTE 1: CC = Country Code of the network in which the O-MGCF is located. NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal (hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the sendingCompleteIndication shall be included. NOTE 3: Based on national policy the whole Number Portability Routing number includes the Called Party Number and a prefix. In such cases only the Prefix has to be removed. Normally the Nature of address indicator indicates if the Number Portability Routing Number contains a Called Party Number and a prefix.

7.2.3.2.2A.1.3 Separate Network Routing Number Addressing Method

Table 17c: Mapping ISUP to SIP Request-URI and To header field with Number Portability Separate Network Routing Number Addressing Method

IAM		INVITE
Network Routing Number	Called Party Number	Request-URI and To Header Field
Address Signal: Nature of address indicator: "Network routing number in national (significant) number format" or "Network routing number in network specific number format" as described in ITU-T Q.769.1 [92] (NOTE 2)	Address Signal: Nature of address indicator: "National (significant) number".	The "telephone-subscriber" is populated from the Called Party Number as follows: Insert "+CC" before the Address signals (NOTE 1) The Tel URI rn= parameter is populated from the Network Routing Number as follows and is added only to the Request-URI: Insert "+CC" before the Address signals (NOTE 1) Use of the local form of the rn= parameter is out of the scope of the present specification. Tel URI npdi parameter as defined in IETF RFC 4694 [93] is added only to the Request-URI.
NOTE 1: CC = Country Code of the network in which the O-MGCF is located. NOTE 2: If the address signals received in the ISUP Called Party Number contain a sending terminated signal (hexadecimal digit F), then this shall be discarded or if the PSTN XML is supported then the sendingCompleteIndication shall be included.

7.2.3.2.2B Coding of the INVITE for Carrier Routeing

This clause describes optional coding procedures for carrier-based routeing.

7.2.3.2.2B.1 Mapping of "cic" in Request-URI

The procedures followed in clause 7.2.3.2.2.1 apply with the following addition.

If the Transit Network Selection parameter, defined according to ITU-T Q.761 [4], is included in the IAM message the O-MGCF, based on network configuration, may send the transit network selection information to the SIP network. In such a case the "cic=" parameter as defined in IETF RFC 4694 [93] is included in the Request-URI and configured according to the table below.

Table 17d: Mapping of ISUP "Transit Network Selection" (TNS) to SIP "Carrier Identification Code" (CIC)

ISUP parameter/field	Value	SIP Component	Value
Transit Network Selection	Digits	Carrier id code in Userinfo of Request-URI	"cic=carrier ID code" as defined in IETF RFC 4694 [93]

7.2.3.2.2B.2 Void

7.2.3.2.2C Coding of INVITE with instance-id in form of IMEI URN

An Emergency Access Transfer Function (EATF) that provides IMS-based mechanisms for enabling service continuity of IMS emergency sessions is described in 3GPP TS 23.237 [118]. A correlation of the call legs at the EATF is based on the equipment identifier.

A Mobile Equipment Identifier (MEI) parameter of the Mobile Service Transport (MST) Application Transport Parameter is defined in 3GPP TS 29.205 [14].

An instance-id is a SIP Contact header field parameter defined in IETF RFC 5626 [119]. When an IMEI is available, the instance-id shall take the form of an International Mobile station Equipment Identity (IMEI) URN as specified in IETF RFC 7254 [120].

When an O-MGCF receives the Mobile Service Transport (MST) Application Transport Parameter containing the Mobile Equipment Identifier (MEI) parameter within the IAM the O-MGCF shall perform the mapping to the "+sip.instance" Contact header field parameter according to table 7.2.3.2.2C.1.

Table 7.2.3.2.2C.1: Mapping of ISUP/BICC to SIP

 IAM		 INVITE
ISUP Parameter	Value	SIP Component	Value
MST Application Transport Parameter	Mobile Equipment Identifier: IMEI	Contact header containing "+sip.instance" parameter in the form of IMEI URN	gmsa urn set to "imei" namespace NOTE 1 NOTE 2
MST Application Transport Parameter	Mobile Equipment Identifier: IMEISV		gmsa urn set to "imei" namespace NOTE 1 NOTE 2
NOTE 1: The gsma-specifier "imei" is generated as: urn:gsma:imei:tac-snr-spare where "tac" represents 8 digits type allocation code (TAC), "snr" represents 4 digits serial number (SNR), and "spare" represents spare decimal digit as specified in TS 23.003 [74]. NOTE 2: The Software Version Number is not interworked and thus the "svn" parameter is not included within the gsma urn.

7.2.3.2.2.10 PSAP Call-back indication

If the O-MGCF based on the operator policy has determined that the received IAM message is a for the purpose of a PSAP call-back, then the O-MGCF shall include in the initial INVITE request a Priority header field with a "psap-callback" header field value as specified in IETF RFC 7090 [139]. The operator policy decision may be based the PSAP call-back indication in the received IAM message and/or any other information made available at O-MGCF.

NOTE: The PSAP call-back indication in the received IAM message depends on the national regulatory requirements applicable for the emergency services (e.g. calling party’s category parameter indicating priority/emergency call, pre-defined prefix in front of the called party number) and is outside the scope of this specification.

7.2.3.2.2.11 History-Info header field (optional)

See Annex L for the normative interworking of the History-Info header field into the called IN number and original called IN number parameters.

7.2.3.2.3 Receipt of CONTINUITY

This clause only applies if the O-MGCF has sent the INVITE request without waiting for an outstanding COT message (see clause 7.2.3.2.1).

Figure 14a: Receipt of COT (success)

When the requested local preconditions (if any) have been met and if possible outstanding continuity procedures have successfully been completed (COT with the Continuity Indicators parameter set to "continuity check successful" is received), a SDP offer (e.g. a SIP UPDATE request, as defined in IETF RFC 3311 [55]) shall be sent for each early SIP dialogue for which the received provisional response indicated support of preconditions confirming that all the required local preconditions have been met.

NOTE: This procedure applies regardless of whether the early SIP dialog existed prior to the preconditions being fulfilled or is subsequently created.

7.2.3.2.4 Sending of ACM and awaiting answer indication

If the Address Complete Message (ACM) has not yet been sent, the following cases are possible trigger conditions that shall lead to the sending the address complete message (ACM):

– the detection of end of address signalling by the expiry of Timer T i/w₁ or,

Figure 15: Sending of ACM T i/w1 elapses

– the reception of the first 180 Ringing. An O-MGCF initiates the sending of an awaiting answer indication only if according to IETF RFC 5009 [89] backward early media is not authorized (the most recently received P-Early-Media header field is received does not authorize the backward early media or the P-Early-Media header field has not yet been received).

Figure 16: Sending of ACM (Receipt of first 180 Ringing and backward early media is not authorized)

Based on local knowledge that the call is transited to a PSTN network, the O-MGCF may decide not to generate the awaiting answer indication when receiving the 180 Ringing message and backward early media is not authorized according to IETF RFC 5009 [89].

Figure 16a: Sending of ACM (Receipt of first 180 Ringing and backward early media is authorized)

– the reception of the first 181 Call is Being Forwarded.

Figure 16b: Sending of ACM (Receipt of first 181 Call is Being Forwarded and backward early media is not authorized)

Figure 16c: Sending of ACM (Receipt of first 181 Call is Being Forwarded that includes authorization of early media)

– At an O-MGCF once all the following sub-conditions have been met: {1} the reception of the first 183 Session Progress that includes a P-Early-Media header field authorizing backward early media, and {2} SDP preconditions are not used, or applicable SDP preconditions have been met.

Figure 16d: Sending of ACM (Receipt of first 183 Session Progress that includes authorization of early media)

– As a network option, reception of 183 containing a SIP reason header with an Q.850 Cause Value.

Figure 16e: Sending of ACM (Receipt of 183 Session Progress containing SIP Reason header)

– Ti/w 2 expires after the initial INVITE is sent.

Figure 17: Sending of ACM (Ti/w2 elapses)

The sending of an awaiting answer indication is described in clause 9.2.3.3.

When a 180 (Ringing) response is received with the Alert-Info header field at an O-MGCF supporting capabilities associated with the Alert-Info header field an O-MGCF may instruct the IM-MGW to play out early media available at the associated URL to the PSTN leg of the communication.

If the O-MGCF receives a 18x response with a P-Early-Media header field that changes the authorization of early media, the O-MGCF terminates the sending of the awaiting answer indication if the header field authorizes backward early media, and initiates the sending of the awaiting answer indication if the header field removes authorization of backward early media and if the O-MGCF has received the 180 Ringing response.

7.2.3.2.5 Coding of the ACM

7.2.3.2.5.0 General

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4].

7.2.3.2.5.1 Backward call indicators

bits AB Charge indicator Contributors

1 0 charge

bits DC Called party’s status indicator

01 subscriber free if the 180 Ringing has been received.

00 no indication otherwise

bits FE Called party’s category indicator

0 0 no indication

bits HG End-to-end method indicator

0 0 no end-to-end method available

bit I Interworking indicator

1 interworking encountered

As a network operator option, the value I = 0 "no interworking encountered" is used for TMR = 64 kBit/s unrestricted

NOTE: This avoids sending of a progress indicator with Progress information 0 0 0 0 0 0 1 "Call is not end-to-end ISDN; further call progress information may be available in‑band", so the call will not be released for that reason by an ISDN terminal.

bit J End-to-end information indicator

0 no end-to-end information available

bit K ISDN user part/BICC indicator

0 ISDN user part not used all the way

As a network operator option, the value K = 1 "ISDN user part/BICC used all the way" is used for TMR = 64 kBit/s unrestricted

bit L Holding indicator (national use)

0 holding not requested

bit M ISDN access indicator

0 terminating access non-ISDN

As a network operator option, the value M = 1 "terminating access ISDN" is used for TMR = 64 kBit/s unrestricted.

NOTE: This avoids sending of a progress indicator with progress information 0 0 0 0 0 1 0 "Destination access is non-ISDN", so the call will not be released for that reason by an ISDN terminal.

bit N Echo control device indicator

1 incoming echo control device included, for speech calls, e.g., TMR is "3.1KHz audio".

0 incoming echo control device not included, for known data calls, e.g., TMR "64 kBit/s unrestricted" or HLC "Facsimile Group 2/3".

If the PSTN XML body is supported as a network option, the Backward Call indicators parameters derived as shown in table 7.2.3.2.5.1.1 shall take precedence over the above Backward Call indicators parameter setting.

Table 7.2.3.2.5.1.1: Derivation of Backward Call Indicators from PSTN XML body

ACM

 180 Ringing or 183 Session Progress

Backward call indicators parameter

Optional backward call indicators parameter

PSTN XML body with Progress indicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" No (Value of PI)

Backward call indicators parameter

ISDN User Part indicator

0 "ISDN User Part not used all the way"

No. 1

("Call is not end-to-end ISDN: further call progress information may be available in-band")

Backward call indicators parameter

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

0 "Terminating access non-ISDN"

No. 2
("Destination address is non-ISDN")

Backward call indicators parameter

Interworking indicator

0 "no interworking encountered"

ISDN User Part indicator

1 "ISDN User Part used all the way"

ISDN access indicator

1 "Terminating access ISDN"

No. 7

("Terminating user ISDN")

Optional backward call indicators parameter

In-band information indicator

1 "in-band information or an appropriate pattern is
now available"

No. 8

("In-band information or an appropriate pattern is now available")

7.2.3.2.5.2 Optional Backward call indicators

Bit A 1 "in-band information or an appropriate pattern is now available" shall be set if 183 Session Progress or
181 Call is Being Forwarded response is received and according to IETF RFC 5009 [89] backward early
media is authorized.

Table 7a0.4: Sending criteria of Optional backward call indicators parameter

ACM

 183 Session Progress or
181 Call is Being Forwarded

Optional backward call indicators parameter

In-band information indicator

in-band information or an appropriate pattern is now available

P-Early-Media header authorizing backward early media

7.2.3.2.5.3 Access Transport Parameter, Transmission medium used parameter

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 180 ringing or 183 session progress, the O-MGCF shall store the received PSTN XML elements, replacing any previously stored PSTN XML elements on that dialog.

NOTE: Multiple 18x responses can be received, both within a single dialog and in multiple dialogs. The PSTN XML bodies are stored on a per-dialog basis to be mapped to the ATP/TMU parameters on receipt of the 200 OK (see clause 7.2.3.2.9.2).

Table 7.2.3.2.5.3.1: Void

7.2.3.2.5.4 Progress indicator

If the O-MGCF supports the PSTN XML body as a network option and receives it in the 180 or 183, the O-MGCF shall store a "ProgressIndicator" element from the PSTN XML body on a per dialog basis and shall add itionaly map it into a Progress Indicator in the ACM as shown in table 7.2.3.2.5.4.1.

Table 7.2.3.2.5.4.1: Handling of the progress indicator

ACM	180/183
Access transport parameter	PSTN XML body with Progress indicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" No. (Value of PI)
Progress indicator (NOTE)	Progress indicator No. 1 / 2
Progress indicator (NOTE)	Progress indicator No. 8
NOTE: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" parameters shall be copied.

Table 7.2.3.2.5.4.2: Void

7.2.3.2.5.5 Cause Value

If the O-MGCF sends the ACM upon reception of a SIP 183 provisional response containing a SIP reason header with a Q.850 Cause value, the O-MGCF may include the received Cause value within the ACM as a network option. The mapping of the Cause Indicators parameter to the Reason header as shown in table 8a shall be applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116].

If, as a network option, the O-MGCF supports the location header field parameter as described in IETF RFC 8606 [155], the O-MGCF shall derive the ISUP cause location from the location parameter in the SIP Reason header field as shown in table 8c (see subclause 7.2.3.1.7).

7.2.3.2.6 Sending of the Call Progress message (CPG)

7.2.3.2.6.0 General

If the Address Complete Message (ACM) has already been sent, the O-MGCF shall send the Call Progress message (CPG) in the following cases:

– Upon receipt of the SIP 180 Ringing provisional response. An O-MGCF should initiate the sending of an awaiting answer indication only if according to IETF RFC 5009 [89] backward early media is not authorized (the most recently received P-Early-Media header field does not authorize the backward early media or the P-Early-Media header field has not yet been received).

Figure 18: Sending of CPG(Alerting) (Receipt of 180 Ringing response and backward early media is not authorized)

Figure 18a: Sending of CPG(Alerting) (Receipt of 180 Ringing response with authorization of early media)

– At an O-MGCF upon receipt of a 183 Session Progress that includes the first P-Early-Media header field authorizing backward early media.

Figure 18b: Sending of CPG(in-band information available)

– Upon receipt of the 181 Call is Being Forwarded provisional response.

Figure 18c: Sending of CPG(Progress)

– As a network option, reception of 183 containing a SIP reason header with a Q.850 Cause Value.

Figure 18d: Sending of CPG (Receipt of 183 Session Progress containing SIP Reason header)

If the O-MGCF receives a 18x response with P-Early-Media header that changes the authorization of early media, the O-MGCF terminates the sending of the awaiting answer indication if the header authorizes backward early media and initiates the sending of the awaiting answer indication if the header removes authorization of backward early media and if the O-MGCF has received the 180 Ringing response.

7.2.3.2.6.1 Handling of the progress indicator

If the O-MGCF supports the PSTN XML body as a network option and receives it in the 180 or 183, any "ProgressIndicator" element in the PSTN XML body shall be stored on a per-dialog basis as well as mapped as shown in tables 7.2.3.2.6.1.1 and 7.2.3.2.6.1.3.

Table 7.2.3.2.6.1.1: Mapping of progress indicator in PSTN XML body into ATP

CPG	180/183
Access transport parameter	PSTN XML body with Progress indicator X
Progress indicator (NOTE 1, NOTE 3)	Progress indicator No. 1 / 2
Progress indicator (NOTE 2, NOTE 3)	Progress indicator No. 4
Progress indicator No. 4 (NOTE 2, NOTE 4)	Progress indicator No. 7
NOTE 1: Values 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 ("destination address is non-ISDN") shall be sent if Value 4 ("Call has returned to the ISDN") has been sent since value 1 or 2 was previously sent or if no value 1 or 2 was previously sent. NOTE 2: Value 4 ("Call has returned to the ISDN") shall be sent if value 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 ("destination address is non-ISDN") was sent previously and no value 4 has been signalled since. NOTE 3: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" parameters shall be copied. NOTE 4: The Progress Indicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the Progress Indicator "Location" parameter is "0100 (Public Network serving remote user)".

Table 7.2.3.2.6.1.2: Void

Table 7.2.3.2.6.1.3: Mapping of progress indicator in PSTN XML body into Event Indicator

CPG

180/183

Event indicator

PSTN XML body with Progress indicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with Progress Description" value No. X

"In-band information or appropriate pattern is now available"

No. 8

"In-band information or appropriate pattern is now available"

7.2.3.2.7 Coding of the CPG

7.2.3.2.7.0 General

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4].

7.2.3.2.7.1 Event information

bits G-A Event indicator

0 0 0 0 0 0 1 alerting if 180 Ringing response received

0 0 0 0 0 1 0 progress, if 181 Call is Being Forwarded response received

0 0 0 0 0 1 1 in-band information or an appropriate pattern is now available, if the received 183 Session
Progress response and most recently received P-Early-Media header authorizes backward early media

NOTE: In national networks other values of the Event indicator may be used.

If the O-MGCF supports the PSTN XML body as a network option and receives in the 180 or 183 a "ProgressIndicator" element in the PSTN XML body with a "Coding Standard" value "00 (ITU-T standardized coding)" and with Progress Description" value No. 8, instead of the mapping above, the O-MGCF shall map this "Progress Indicator" into the "Event Indicator" within the CPG as shown in table 7.2.3.2.6.1.3.

7.2.3.2.7.2 Access Transport Parameter

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 180 ringing or 183 session progress, the O-MGCF shall store the contained information as described in clause 7.2.3.2.5.3, and additionally shall map this "Progress Indicator" into the ATP within the CPG as shown in table 7.2.3.2.6.1.1.

NOTE: Multiple 18x responses can be received, both within a single dialog and in multiple dialogs. The PSTN XML bodies are stored on a per-dialog basis to be mapped to the ATP parameter on receipt of the 200 OK (see clause 7.2.3.2.9.2).

7.2.3.2.7.3 Void

Table 17h: Void

Table 17j: Void

7.2.3.2.7.4 Handling of Backward Call indicators

The Backward Call indicator shall be derived as shown in clause 7.2.3.2.5.1. The Backward Call Indicators parameter is optional in the CPG message and shall only be included if any indicators have changed from those previously sent.

7.2.3.2.7.5 Optional Backward call indicators

Bit A 1 "in-band information or an appropriate pattern is now available" shall be set if 181 Call is Being
Forwarded response is received and according to IETF RFC 5009 [89] the backward early media is
authorized.

Table 17k: Sending criteria of Optional backward call indicators parameter

CPG

 181 Call is Being Forwarded

Optional backward call indicators parameter

In-band information indicator

in-band information or an appropriate pattern is
now available

P-Early-Media header authorizing backward early media

7.2.3.2.7.6 Cause Value

If the O-MGCF sends the CPG upon reception of a SIP 183 provisional response containing a SIP reason header with a Q.850 Cause value, the O-MGCF may include the received Cause value within the ACM as a network option. The mapping of the Cause Indicators parameter to the Reason header as shown in table 8a shall be applied. IETF RFC 6432 [115] describes the use of the Reason header field in responses. The Reason header field itself is described in IETF RFC 3326 [116].

7.2.3.2.7a Receipt of 200 OK(INVITE)

Upon receipt of the first 200 OK (INVITE), the O-MGCF shall send an Answer Message (ANM) or Connect message (CON) as described in clauses 7.2.3.2.8 to 7.2.3.2.11.

The O-MGCF shall not progress any further early dialogues to established dialogues. Therefore, upon the reception of a subsequent final 200 (OK) response for any further dialogue for an INVITE request (e.g., due to forking), the O-MGCF shall:

1) acknowledge the response with an ACK request; and

2) send a BYE request to this dialog in order to terminate it.

If the received 200 OK (INVITE) response contains a Feature-Caps header field, defined in IETF RFC 6809 [142] with a "+g.3gpp.ics" header field parameter as specified in clause B.4 of 3GPP TS 24.292 [141] then according to operator policy the O-MGCF may mark a call as an "ICS call".

7.2.3.2.7b Internal through connection of the bearer path

The through connection procedure is described in clause 9.2.3.3.7.

7.2.3.2.8 Sending of the Answer Message (ANM)

Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has already been sent, the O-MGCF shall send the Answer Message (ANM) to the preceding exchange.

NOTE: Through connection and the stop of awaiting answer indication are described in clause 9.2.3.3

Figure 19: Sending of ANM

7.2.3.2.9 Coding of the ANM

7.2.3.2.9.1 Backwards Call Indicators

If Backwards Call Indicators are included in the ANM, then the coding of these parameters shall be as described in clause 7.2.3.2.5.1. The Backward Call Indicators parameter is optional in the ANM message and shall only be included if any indicators have changed from those previously sent.

7.2.3.2.9.2 Access Transport Parameter

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 200 OK(INVITE) or has been previously stored from a 18x message, the O-MGCF shall map the most recently received information for the established dialog (i.e. the dialog for which the first 200 OK has been received) into the ANM as shown in table 7.2.3.2.9.2.1 except Progress Indicator value No. 3 or No. 8.

Table 7.2.3.2.9.2.1: Mapping of PSTN XML elements into ISUP Parameters

 ANM		 200 OK / stored information from previous 18x
ISUP Parameter	Content	PSTN XML (NOTE 9)
Access Transport Parameter	Progress indicator (NOTE 5, NOTE 8)	ProgressIndicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" value No. 1 / 2
	Progress indicator with "Progress Description" value No. 4 (NOTE 4, NOTE 6, NOTE 9)	ProgressIndicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" value No. 7
	Progress indicator (NOTE 6, NOTE 8)	ProgressIndicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" value No. 4
	Progress indicator (NOTE 7, NOTE 8)	ProgressIndicator with "Coding Standard" value "00 (ITU-T standardized coding)" and with "Progress Description" value No. 5
	High layer compatibility (NOTE 1)	HighLayerCompatibility
	Bearer Capability	BearerCapability (NOTE 2)
	Bearer Capability ("UDI-TA")	BearerCapability ("UDI-TA") (NOTE 3)
NOTE 1: This information element shall only be mapped if the O-MGCF transfers media types listed in table 10b without transcoding. NOTE 2: Applicable if the O-MGCF has not propagated UDI fallback signalling according to clause 7.2.3.2.1.5. NOTE 3: Applicable if the O-MGCF has propagated UDI fallback signalling according to clause 7.2.3.2.1.5. Only the value "UDI-TA" within the PSTN XML BC shall be mapped. Other values within the PSTN XML BC are mapped to TMU as described in clause 7.2.3.2.9.3. NOTE 4: ProgressIndicator No. 7 is not mapped into the ISUP ATP. However, it may be mapped into PI=4. NOTE 5: Values 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 ("destination address is non-ISDN") shall be sent if Value 4 ("Call has returned to the ISDN") has been sent since value 1 or 2 was previously sent or if no value 1 or 2 was previously sent. NOTE 6: Value 4 ("Call has returned to the ISDN") shall be sent if value 1 ("call is not end-to-end ISDN: further call progress information may be available in-band") or 2 ("destination address is non-ISDN") was sent previously and no value 4 has been signalled since. NOTE 7: This value indicates a bearer service change and is present with an associated BearerCapability and indicates that fallback has occurred (i.e. TMR and TMR Prime present in IAM and the destination ISDN user has accepted the BearerCapability equating to TMR Prime). NOTE 8: The entire Progress Indicator, including the "Progress Description", "Coding Standard" and "Location" parameters shall be copied. NOTE 9: The Progress Indicator "Coding Standard" parameter shall be set to "00 (ITU-T standardized coding)". The default value for the Progress Indicator "Location" parameter is "0100 (Public Network serving remote user)".

7.2.3.2.9.3 Transmission Medium Used parameter (TMU)

The procedures in the present clause shall only apply if the O-MGCF supports the PSTN XML body, and has propagated UDI-TA fallback signalling according to clause 7.2.3.2.1.5.

If a Bearer Capability element within a PSTN XML body is received within the first 200 OK(INVITE) or has been previously stored from a 18x message relating to the now established dialog (i.e. the dialogue for which the first 200 OK has been received), the O-MGCF shall map the most recently received information (if any) into a TMU within the ANM as shown in table 7.2.3.2.9.3.1. If the most recently received PSTN XML BearerCapability is "UDI-TA", it shall be mapped into an ISUP Access Transport Parameter Bearer Capability (see clause 7.2.3.2.9.2).

NOTE: The TMU is only included if both the TMR and TMR Prime were received in the ISUP IAM and fallback has occurred.

Table 7.2.3.2.9.3.1 – Mapping to TMU parameter

 ANM	 200 OK / stored information from previous 18x
TMU	PSTN XML BearerCapability
TMU = "Speech"	PSTN XML BearerCapability = "Speech"
TMU= "3.1 kHz audio"	PSTN XML BearerCapability = "3.1 kHz audio"
No mapping (fallback has not occurred)	PSTN XML BearerCapability = "UDI-TA"
TMU = "3.1 kHz audio"	PSTN XML BearerCapability not present

7.2.3.2.10 Sending of the Connect message (CON)

Upon receipt of the first 200 OK (INVITE), if the Address Complete Message (ACM) has not yet been sent, the O-MGCF shall send the Connect message (CON) to the preceding exchange.

Figure 20: Sending of CON

7.2.3.2.11 Coding of the CON

7.2.3.2.11.0 General

The description of the following ISDN user part parameters can be found in ITU-T Recommendation Q.763 [4].

7.2.3.2.11.1 Backward call indicators

The Called Party’s status indicator (Bit DC) of BCI parameter shall be set to "no indication". The other BCI indicators shall be set as described in clause 7.2.3.2.5.1

7.2.3.2.11.2 Access Transport Parameter

The O-MGCF shall apply the same procedure as described for the ANM in clause 7.2.3.2.9.2.

7.2.3.2.11.3 Transmission medium used parameter

The O-MGCF shall apply the same procedure as described for the ANM in clause 7.2.3.2.9.3.

7.2.3.2.11A Receipt of a reINVITE request

When a reINVITE request is received from the network containing a Call-Info header field the MGCF may instruct the IM-MGW to send media available at the associated URL to the PSTN leg of the communication.

7.2.3.2.12 Receipt of Status Codes 4xx, 5xx or 6xx

Figure 21: Receipt of Status codes 4xx, 5xx or 6xx

If a Reason header as described in IETF RFC 6432 [115] is included in a 4xx, 5xx, 6xx response, then the Cause Value of the Reason header shall be mapped to the ISUP Cause Value field in the ISUP REL message. The Reason header field itself is described in IETF RFC 3326 [116]. The mapping of the Reason header to the Cause Indicators parameter is shown in table 8a (see clause 7.2.3.1.7). Otherwise coding of the Cause value field in the REL message is derived from the SIP Status code received according to table 18. The Cause Indicators Parameter Values are defined in ITU-T Recommendation Q.850 [38].

In all cases where SIP itself specifies additional SIP side behaviour related to the receipt of a particular INVITE response these procedures should be followed in preference to the immediate sending of a REL message to BICC/ISUP.

If there are no SIP side procedures associated with this response, the REL shall be sent immediately.

NOTE Depending upon the SIP side procedures applied at the O-MGCF it is possible that receipt of certain 4xx/5xx/6xx responses to an INVITE may in some cases not result in any REL message being sent to the BICC/ISUP network. For example, if a 401 Unauthorized response is received and the O-MGCF successfully initiates a new INVITE containing the correct credentials, the call will proceed.

When the O-MGCF receives a 415 Unsupported Media Type response, as a result from a multipart MIME body in an initial INVITE request not being accepted, and when the handling of all the MIME bodies in the initial INVITE request except for the SDP MIME body are optional (Content-Disposition header parameter "handling" is set to optional), the O-MGCF shall send an ACK request and send a new initial INVITE request with SDP as only MIME body in accordance with clause 8.1.3.5 of IETF RFC 3261 [19].

Table 18: 4xx/5xx/6xx Received on SIP side of O-MGCF

REL (cause value)	4xx/5xx/6xx SIP Message
Cause value No 111 (Protocol error, unspecified)	400 Bad Request
Cause value No 127 (Interworking, unspecified)	401 Unauthorized
Cause value No 127 (Interworking, unspecified)	402 Payment Required
Cause value No 79 (Service or option not implemented, unspecified)	403 Forbidden
Cause value No 1 (Unallocated (unassigned) number)	404 Not Found
Cause value No 127 (Interworking, unspecified)	405 Method Not Allowed
Cause value No 127 (Interworking, unspecified)	406 Not Acceptable
Cause value No 127 (Interworking, unspecified)	407 Proxy authentication required
Cause value No 102 (Recovery on timer expiry)	408 Request Timeout
Cause value No 22 (Number changed)	410 Gone
Cause value No 127 (Interworking, unspecified)	413 Request Entity too long
Cause value No 111 (Protocol error, unspecified)	414 Request-URI too long
Cause value No 127 (Interworking, unspecified)	415 Unsupported Media type
Cause value No 111 (Protocol error, unspecified)	416 Unsupported URI scheme
Cause value No 79 (Service or option not implemented, unspecified)	417 Unknown Resource-Priority
Cause value No 111 (Protocol error, unspecified)	420 Bad Extension
Cause value No 111 (Protocol error, unspecified)	421 Extension required
Cause value No 31 (Normal, unspecified)	422 Session Interval Too Small
Cause value No 127 (Interworking, unspecified)	423 Interval Too Brief
Cause value No 127 (Interworking, unspecified)	428 Use Identity Header (NOTE 5)
Cause value No 24 (Call rejected due to feature at the destination)	433 Anonymity Disallowed (NOTE 1)
Cause value No 127 (Interworking, unspecified)	436 Bad Identity Info (NOTE 5)
Cause value No 127 (Interworking, unspecified)	437 Unsupported Credential (NOTE 5)
Cause value No 127 (Interworking, unspecified)	438 Invalid Identity Header (NOTE 5)
Cause value No 127 (Interworking, unspecified)	440 Max-Breadth Exceeded
Cause value No 20 (Subscriber absent)	480 Temporarily Unavailable
Cause value No 127 (Interworking, unspecified)	481 Call/Transaction does not exist
Cause value No 127 (Interworking, unspecified)	482 Loop detected
Cause value No 25 (Exchange routing error)	483 Too many hops
Cause value No 28 (Invalid number format (address incomplete))	484 Address Incomplete
Cause value No 1 (Unallocated (unassigned) number)	485 Ambiguous
Cause value No 17 (User busy)	486 Busy Here
Cause value No 127 (Interworking, unspecified) or not interworked. (NOTE 2)	487 Request terminated
Cause value No 50 (Requested facility not subscribed)	488 Not acceptable here
Cause value No 127 (Interworking, unspecified)	493 Undecipherable
Cause value No 127 (Interworking, unspecified)	500 Server Internal error
Cause value No 79 (Service or option not implemented, unspecified)	501 Not implemented
Cause value No 27 (Destination out of order)	502 Bad Gateway
Cause value No 41 (Temporary failure)	503 Service Unavailable
Cause value No 102 (Recovery on timer expiry)	504 Server timeout
Cause value No 127 (Interworking, unspecified)	505 Version not supported
Cause value No 95 (Invalid message, unspecified)	513 Message too large
Cause value No 127 (Interworking, unspecified)	580 Precondition failure
Cause value No 17 (User busy)	600 Busy Everywhere
Cause value No 21 (Call rejected)	603 Decline
Cause value No 2 (No route to specified transit network)	604 Does not exist anywhere
Cause value No 88 (Incompatible destination)	606 Not Acceptable
Cause value No 21 (Call rejected)	607 Unwanted (NOTE 4)
NOTE 1: Anonymity Disallowed, IETF RFC 5079 [77] refers. NOTE 2: No interworking if the O-MGCF previously issued a CANCEL request for the INVITE. NOTE 3: The 4xx/5xx/6xx SIP responses that are not covered in this table are not interworked. NOTE 4: The "607 Unwanted" SIP response code is defined in IETF RFC 8197 [154]. NOTE 5: The 428, 436, 437 and 438 SIP response codes are defined in IETF RFC 8224 [153].

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the 4xx/5xx/6xx, the O-MGCF shall map the contained information into the Access Transport Parameter of the REL as shown in clause 7.2.3.2.9.2.

When a 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info header field, the O-MGCF, supporting the capabilities associated with the Error-Info header field, may instruct the IM-MGW to play out media available at the associated URL towards PSTN.

7.2.3.2.12.1 Special handling of 404 Not Found and 484 Address Incomplete responses after sending of INVITE without determining the end of address signalling

This clause is only applicable when the network option of Sending of INVITE without determining the end of address signalling is being used (see clause 7.2.3.2.1.a).

On receipt of a 404 Not Found or 484 Address Incomplete response while Ti/w2 is running, the O-MGCF shall start timer Ti/w3, if there are no other pending INVITE transactions for the corresponding call.

At the receipt of a SAM, a SIP 18x provisional response or a SIP 200 OK (INVITE), the O-MGCF shall stop Ti/w2 and Ti/w3.

The O-MGCF shall send a REL message with Cause Value 28 towards the BICC/ISUP network if Ti/w3 expires.

7.2.3 2.13 Receipt of a BYE

Figure 22: Receipt of BYE method

If a Reason header field with Q.850 Cause Value is included in the BYE request, then the Cause Value shall be mapped to the ISUP Cause Value field in the ISUP REL as shown in table 8a (see clause 7.2.3.1.7). Otherwise, the O-MGCF sends a REL message with Cause Code value 16 (Normal Call Clearing).

If the O-MGCF supports the PSTN XML body as a network option and if a PSTN XML body is received within the BYE, the O-MGCF shall map the contained information into the Access Transport Parameter of the REL as shown in clause 7.2.3.2.9.2.

If a Reason header field with SIP status code "607 (Unwanted)" (defined in IETF RFC 8197 [154]) is included in the BYE request, then the O-MGCF shall send a REL message with the Cause Code value "21 (Call rejected)".

7.2.3.2.14 Receipt of the Release Message

In the case that the REL message is received and a final response (i.e. 200 OK (INVITE)) has already been received the O-MGCF shall send a BYE request. If the final response (i.e. 200 OK (INVITE)) has not already been received the O-MGCF shall send a CANCEL method.

A Reason header field containing the received (Q.850) Cause Value of the REL message shall be added to the CANCEL or BYE request. The mapping of the Cause Indicators parameter to the Reason header is shown in table 9a (see clause 7.2.3.1.8).

If the O-MGCF supports the PSTN XML body as a network option, the O-MGCF shall map the contained information into a PSTN XML body within the BYE or CANCEL as shown in table 9aa.

7.2.3.2.15 Receipt of RSC, GRS or CGB (H/W oriented)

Upon receipt of a RSC, GRS or CGB (H/W oriented) message the following applies independently for each affected circuit:

If a final response (i.e. 200 OK (INVITE) has already been received, the O-MGCF shall send a BYE method. If a final response (i.e. 200 OK (INVITE)) has not already been received, the O-MGCF shall send a CANCEL method.

A Reason header field containing the (Q.850) Cause Value of the REL message generated by the ISUP procedures shall be added to the SIP message (BYE or CANCEL request) to be sent by the SIP side of the O‑MGCF.

7.2.3.2.16 Autonomous Release at O-MGCF

If the O-MGCF determines due to internal procedures that the call shall be released then the MGCF shall send

– A BYE method if the ACK has been sent.

– A CANCEL method before 200 OK (INVITE) has been received.

NOTE: The MGCF shall send the ACK method before it sends the BYE, if 200 OK (INVITE) is received.

A Reason header field containing the (Q.850) Cause Value of the REL message sent by the O‑IWU shall be added to the SIP Message (BYE or CANCEL request) to be sent by the SIP side of the O‑IWU.

Table 18a: Autonomous Release at O-MGCF

REL  Cause parameter	Trigger event	 SIP
As determined by BICC/ISUP procedure.	COT received with the Continuity Indicators parameter set to "continuity check failed" (ISUP only) or the BICC/ISUP timer T8 expires.	CANCEL or BYE according to the rules described in this subclause.
REL with cause value 47 (resource unavailable, unspecified).	Internal resource reservation unsuccessful	As determined by SIP procedure
As determined by BICC/ISUP procedure.	BICC/ISUP procedures result in generation of autonomous REL on BICC/ISUP side.	CANCEL or BYE according to the rules described in this subclause.
Depending on the SIP release reason.	SIP procedures result in a decision to release the call.	As determined by SIP procedure.

7.2.3.2.17 Special handling of 580 precondition failure received in response to either an INVITE or UPDATE

A 580 Precondition failure response may be received as a response either to an INVITE or to an UPDATE request.

7.2.3.2.17.1 580 Precondition failure response to an INVITE

Release with cause code as indicated in table 18 is sent immediately to the BICC/ISUP network.

7.2.3.2.17.2 580 Precondition failure response to an UPDATE within an early dialog

A BYE request is sent for the early dialog within which the UPDATE was sent.

If all the early dialogs that were generated from the INVITE request have answered the respective UPDATE request with 580 Precondition failure response then the O-MGCF shall send the Release message with Cause Code ‘127 Interworking’ to the ISUP network.

7.2.3.2.18 Sending of CANCEL

Figure 23: Receipt of COT (failure)

CANCEL shall be sent if the Continuity message is received with the Continuity Indicators parameter set to "continuity check failed" or the ISUP (or BICC) timer T8 expires.

A Reason header field containing the (Q.850) Cause Value 41 Temporary Failure shall be added to the CANCEL request to be sent by the SIP side of the O‑MGCF.

7.2.3.2.19 Receipt of SIP redirect (3xx) response

Figure 24: Receipt of SIP response code 3xx

When receiving a SIP response with a response code 3xx, the default behaviour of the O-MGCF is to release the call with a cause code value 127 (Interworking unspecified).

NOTE: The O-MGCF may also decide for example to redirect the call towards the URIs in the Contact header field of the response as an operator option, but such handling is outside of the scope of the present document.

7.2.3.2.20 Sending of INFO for overlap signalling using the in-dialog method

7.2.3.2.20.1 General

SIP INFO request ("legacy" mode of usage of the INFO method as defined in IETF RFC 6086 [133]) is used to carry additional digits when overlap signalling is sent using the in-dialog method as described in clause 7.2.3.2.1a.2, which is a network option. Clause 7.2.3.2.1a.2 also describes when the O-MGCF sends a SIP INFO request.

7.2.3.2.20.2 Encoding of the INFO

Table 18b provides a summary of how the header fields within the outgoing INFO messages are populated when in-dialog SIP INFO requests are used for overlap dialling.

Table 18b: Interworked contents of the INFO message

SAM	INFO
Digits	See TS 24.229 [9] clause 7.12.1.2

7.2.3.3 Timers

Table 19: Timers for interworking

Symbol	Time-out value	Cause for initiation	Normal termination	At expiry	Reference
Ti/w1	4 s to 6 s (default of 4 s)	When last address message is received and the minimum number of digits required for routing the call have been received.	At the receipt of fresh address information.	Send INVITE, send the address complete message	7.2.3.2.1 7.2.3.2.4 (NOTE 1)
Ti/w2	4 s to 20 s (default of 4 s)	When INVITE is sent unless the ACM has already been sent.	On reception of 180 Ringing , or 183 Session Progress and P-Early-Media header authorizing backward early media, or 181 Call is Being Forwarded, or 404 Not Found or 484 Address Incomplete for an INVITE transaction for which Ti/w3 is running, or 200 OK (INVITE).	Send ACM (no indication)	7.2.3.2.4 7.2.3.2.1 (NOTE 2)
Ti/w3	4‑6 seconds (default of 4 seconds)	On receipt of 404 Not Found or 484 Address Incomplete if there are no other pending INVITE transactions for the corresponding call.	At the receipt of SAM	Send REL with Cause Value 28 to the BICC/ISUP side.	7.2.3.2.1A, 7.2.3.2.12.1 (NOTE 3)
NOTE 1: This timer is used when overlap signalling is received from BICC/ISUP network and converted to en-block signalling at the MGCF. NOTE 2: This timer is used to send an early ACM if a delay is encountered in receiving a response from the subsequent SIP network. NOTE 3: This timer is known as the "SIP dialog protection timer". This timer is only used where the O‑MGCF is configured to send INVITE before end of address signalling is determined.