5.10 Procedures at the IBCF

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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

5.10.1 General

As specified in 3GPP TS 23.228 [7] border control functions may be applied between two IM CN subsystems or between an IM CN subsystem and other SIP-based multimedia networks based on operator preference. The IBCF may act both as an entry point and as an exit point for a network. If it processes a SIP request received from other network it functions as an entry point (see subclause 5.10.3) and it acts as an exit point whenever it processes a SIP request sent to other network (see subclause 5.10.2).

The functionalities of the IBCF are entry and exit point procedures as defined in subclause 5.10.2 and subclause 5.10.3 and additionally can include:

– network configuration hiding (as defined in subclause 5.10.4);

– application level gateway (as defined in subclause 5.10.5);

– transport plane control, i.e. QoS control (as defined in subclause 5.10.5);

– screening of SIP signalling (as defined in subclause 5.10.6);

– inclusion of an IWF if appropriate;

– media transcoding control (as defined in suclause 5.10.7);

– privacy protection (as defined in subclause 5.10.8);

– additional routeing functionality (as defined in Annex I); and

– invocation of an AS over the Ms reference point (as defined in subclause 5.10.10).

NOTE 1: The functionalities performed by the IBCF are configured by the operator, and it is network specific.

The IBCF shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field if required by local policy.

When an IBCF acting as an exit or an entry point receives a SIP request, the IBCF may reject the SIP request based on local policy by sending an appropriate SIP 4xx response.

NOTE 2: The local policy can take bilateral agreements between operators into consideration.

NOTE 3: Some SIP requests can be rejected by an AS instead of the IBCF according to local policy.

The IBCF, acting as B2BUA, which is located between visited network and home network shall preserve the dialog identifier, i.e. shall not change the Call-Id header field value, the "tag" header field parameter value of the From header field in any SIP INVITE request and any SIP response to the SIP INVITE request, and shall preserve the "tag" header field parameter value of the To header field, in any SIP response to the SIP INVITE request.

NOTE 4: The IBCF can identify whether it is located between visited network and home network based on local configuration or, if IBCF supports indicating traffic leg associated with a URI as specified in RFC 7549 [225], based on the value of the "iotl" SIP URI parameter.

If the IBCF has verified that an initial INVITE request is for a PSAP callback, then depending on local policy it may include a Priority header field with a "psap-callback" header field value in the INVITE request. If the IBCF included the Priority header field with a "psap-callback" header field value, if the IBCF supports priority verification using assertion of priority information as specified in subclause 3.1 and if required by operator policy, the IBCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197] if not already present.

NOTE 5: The means for the IBCF to verify that a request is for a PSAP callback is outside the scope of this specification.

When receiving a dialog creating SIP request or a SIP stand-alone request and if an IBCF acting as an entry or exit point supports indicating the traffic leg as specified in RFC 7549 [225], the IBCF can identify the II-NNI traversal scenario as described in subclause 4.13 and make policy decisions based on the II-NNI traversal scenario type. If a received request contains more than one "iotl" SIP URI parameter the IBCF shall select one of the "iotl" SIP parameters in the received request in accordance with the RFC 7549 [225].

When sending a failure response to any received request, depending on operator policy, the IBCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "ibcf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.

5.10.2 IBCF as an exit point

5.10.2.1 Registration

When IBCF receives a REGISTER request, the IBCF shall:

1) void;

2) if network topology hiding is required or IBCF is configured to perform application level gateway and/or transport plane control functionalities, then the IBCF shall add its own routeable SIP URI to the top of the Path header field; and

NOTE 1: The IBCF can include in the inserted SIP URI an indicator that identifies the direction of subsequent requests received by the IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating case. The IBCF can encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a character string in the username part of the URI, or a dedicated port number in the URI.

NOTE 2: Any subsequent request that includes the direction indicator (in the Route header field) or arrives at the dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF.

3) select an entry point of the home network and forward the request to that entry point.

If the selected entry point:

– does not respond to the REGISTER request and its retransmissions by the IBCF; or

– sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request;

the IBCF shall select a new entry point and forward the REGISTER request to that entry point.

NOTE 3: The list of the entry points can be either obtained as specified in RFC 3263 [27A] or provisioned in the IBCF. The entry point can be an IBCF or an I-CSCF.

If the IBCF fails to forward the REGISTER request to any entry point, the IBCF shall send back a 504 (Server Time-Out) response to the P-CSCF, in accordance with the procedures in RFC 3261 [26].

5.10.2.1A General

For all SIP transactions identified:

– if priority is supported, as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;

the IBCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the IBCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.

NOTE 1: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

Based on local policy, the IBCF acting as an exit point shall add in responses in the P-Charging-Vector header field a "transit-ioi" header field parameter with an entry which identifies the operator network which the response is transitting or with a void entry.

Based on local policy the IBCF shall delete or void in responses in the P-Charging-Vector header field any received "transit-ioi" header field parameter value.

If an IBCF in the originating visited network, supporting barring of premium numbers when roaming, receives a request to be sent towards the originating home network and the request is originated from a roaming UE and the Request-URI contains an E.164 number encoded as described in subclause 5.1.2A.1.2 which the IBCF is able to identify as a premium rate number in the country of the served network, the IBCF shall, based on local policy, add the "premium-rate" tel URI parameter specified in subclause 7.2A.17 set to a value "information" or "entertainment" as appropriate.

NOTE 2: The feature barring of premium numbers when roaming can be implemented in the P-CSCF or an IBCF of the visited network. Local policy ensures that the feature is only activiated in one of the two.

NOTE 3: If the visited network supports indicating traffic leg as specified in RFC 7549 [225] the above request includes the "iotl" SIP URI parameter with the value "visitedA-homeA" in the bottommost Route header field.

5.10.2.2 Initial requests

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction, except the REGISTER method; or

– a request for an unknown method that does not relate to an existing dialog;

the IBCF shall:

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response;

1A) remove its own SIP URI from the topmost Route header field;

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, save the Contact, CSeq and Record-Route header field values received in the request such that the IBCF is able to release the session if needed;

2A) If the request is a SUBSCRIBE and the IBCF does not need to act as B2BUA, based on operator policy, the IBCF shall determine whether or not to retain, for the related subscription, the SIP dialog state information and the duration information;

NOTE 1: The event package name can be taken into account to decide whether or not the SIP dialog state and the subscription duration information needs to be retained.

NOTE 2: The IBCF needs to insert its own URI in Record-Route of the initial SUBSCRIBE request and all subsequent NOTIFY requests if it decides to retain the SIP dialog state information.

2B) if the request is an initial request for a dialog and local policy requires the application of IBCF capabilities in subsequent requests, perform record route procedures as specified in RFC 3261 [26];

3) void;

4) void;

5) void;

5A) if the recipient of the request is understood from configured information to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;

6) store the values from the P-Charging-Function-Addresses header field, if present;

7) if the request is an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain;

– store the "fe-identifier" header field parameter in the P-Charging-Vector header field; and

– remove the "fe-identifier" header field parameter from the P-Charging-Vector header field;

8) remove some of the parameters from the P-Charging-Vector header field or the header field itself, depending on operator policy, if present;

9) remove the P-Charging-Function-Addresses header fields, if present; and

10) remove the Via "received-realm" header field parameter, as defined in RFC 8055 [208], if present, prior to forwarding the request;

and forward the request according to RFC 3261 [26].

NOTE 3: If IBCF processes a request without a pre-defined route (e.g. the subscription to reg event package originated by the P-CSCF), the next-hop address can be either obtained as specified in RFC 3263 [27A] or be provisioned in the IBCF.

When the IBCF receives an INVITE request, the IBCF may require the periodic refreshment of the session to avoid hung states in the IBCF. If the IBCF requires the session to be refreshed, the IBCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE 4: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

When receiving a response to the initial request with a P-Charging-Vector header field, the IBCF acting as an exit point shall, if "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain:

– remove any received "fe-identifier" header field parameter from the P-Charging-Vector header field; and

– add the "fe-identifier" header field parameter stored from the initial request to the P-Charging-Vector header field and add its own address or identifier as an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field.

With the exception of 305 (Use Proxy) responses, the IBCF shall not recurse on 3xx responses.

5.10.2.3 Subsequent requests

Upon receipt of a subsequent request, the IBCF shall:

1) if the request is an INVITE request, respond with a 100 (Trying) provisional response;

1A) if the request is a NOTIFY request with the Subscription-State header field set to "terminated" and the IBCF has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the IBCF can remove all the stored information related to the associated subscription;

2) if the request is a target refresh request and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the IBCF is able to release the session if needed; and

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the IBCF is able to release the session if needed;

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26].

5.10.2.4 IBCF-initiated call release

If the IBCF provides transport plane control functionality and receives an indication of a transport plane related error the IBCF may:

1) generate a BYE request for the terminating side based on information saved for the related dialog; and

2) generate a BYE request for the originating side based on the information saved for the related dialog.

NOTE: Transport plane related errors can be indicated from e.g. TrGW, or PCRF. The protocol for indicating transport plane related errors to the IBCF is out of scope of this specification.

Upon receipt of the 2xx responses for both BYE requests, the IBCF shall release all information related to the dialog and the related multimedia session.

5.10.3 IBCF as an entry point

5.10.3.1 Registration

When IBCF receives a REGISTER request, the IBCF shall:

1) verify if it arrived from a trusted domain or not. If the request arrived from an untrusted domain, respond with 403 (Forbidden) response;

NOTE 1: The IBCF can find out whether the request arrived from a trusted domain or not, from the procedures described in 3GPP TS 33.210 [19A].

2) if network topology hiding, or screening of SIP signalling, is required or IBCF is configured to perform application level gateway and/or transport plane control functionalities, add its own routeable SIP URI to the top of the Path header field; and

NOTE 2: The IBCF can include in the inserted SIP URI an indicator that identifies the direction of subsequent requests received by the IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating case. The IBCF can encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a character string in the username part of the URI, or a dedicated port number in the URI.

NOTE 3: Any subsequent request that includes the direction indicator (in the Route header field) or arrives at the dedicated port number, indicates that the request was sent by the S-CSCF towards the P-CSCF.

3) If IBCF is colocated with an I-CSCF, or it has a preconfigured I-CSCF to be contacted, forward the request to that I-CSCF. Otherwise select an I-CSCF and forward the request to that I-CSCF.

NOTE 5: The selection of an I-CSCF can lead to additional delays.

If the selected I-CSCF:

– does not respond to the REGISTER request and its retransmissions by the IBCF; or

– sends back a 3xx response or 480 (Temporarily Unavailable) response to a REGISTER request;

the IBCF shall select a new I-CSCF and forward the REGISTER request to that I-CSCF.

NOTE 4: The list of the I-CSCFs can be either obtained as specified in RFC 3263 [27A] or provisioned in the IBCF.

If the IBCF fails to forward the REGISTER request to any I-CSCF, the IBCF shall send back a 504 (Server Time-Out) response towards the P-CSCF, in accordance with the procedures in RFC 3261 [26].

5.10.3.1A General

For all SIP transactions identified:

– if priority is supported (NOTE 1), as containing an authorised Resource-Priority header field or a temporarily authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;

NOTE 1: For an INVITE request, various mechanisms can be applied to recognize the need for priority treatment (e.g., based on the dialled digits). The exact mechanisms are left to national regulation and network configuration.

Based on the alternative mechanism to recognize the need for priority treatment, the IBCF shall insert the temporarily authorised Resource-Priority header field with appropriate namespace and priority value in the INVITE request.

NOTE 2: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

Based on local policy, the IBCF acting as an entry point shall add in requests in the P-Charging-Vector header field a "transit-ioi" header field parameter with an entry which identifies the operator network which the request is transitting or with a void entry.

Based on local policy the IBCF shall delete or void in requests in the P-Charging-Vector header field any received "transit-ioi" header field parameter value.

NOTE 3: Only one "transit-ioi" header field parameter entry is added per transit network.

5.10.3.2 Initial requests

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction except the REGISTER request; or

– a request for an unknown method that does not relate to an existing dialog;

the IBCF shall verify whether the request is arrived from a trusted domain or not. If the request arrived from an untrusted domain, then the IBCF shall:

– if the topmost Route header field of the request contains the "orig" parameter, respond with 403 (Forbidden) response.

Otherwise,

– remove all P-Charging-Vector header fields and all P-Charging-Function-Addresses header fields the request may contain; and

– remove all Feature-Caps header fields, if present.

Upon receipt of:

– an initial request for a dialog;

– a request for a standalone transaction except the REGISTER request; or

– a request for an unknown method that does not relate to an existing dialog;

the IBCF shall:

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response;

1A) if a P-Private-Network-Indication header field is included in the request, check whether the configured information allows the receipt of private network traffic from this source. If private network traffic is allowed, the IBCF shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that configured information. If private network traffic is not allowed, or the received domain name does not match, then the IBCF shall remove the P-Private-Network-Indication header field;

1B) if the initiator of the request is understood from configured information to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that configured information;

1C) remove its own SIP URI from the topmost Route header field;

2) if the request is an INVITE request and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, then the IBCF shall save the Contact, CSeq and Record-Route header field values received in the request such that the IBCF is able to release the session if needed;

NOTE 1: The event package name can be taken into account to decide whether or not the SIP dialog state and the subscription duration information needs to be retained.

NOTE 2: The IBCF needs to insert its own URI in Record-Route of the initial SUBSCRIBE request and all subsequent NOTIFY requests if it decides to retain the SIP dialog state information.

2C) if

– the request is an initial request for a dialog, or a standalone request, and

– the Request-URI contains an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69] and

– a P-Private-Network-Indication valid within the trust domain is not included, and

– based on local policy, no Route header field is remaining after step 1C) was executed,

then include a topmost Route header field set to the URI associated with an E-CSCF;

2D) if the network uses the Resource-Priority header field to control the priority of emergency calls, the IBCF shall add a Resource-Priority header field containing a namespace of "esnet" as defined in RFC 7135 [197];

3) void;

4) if IBCF receives an initial request for a dialog or standalone transaction, that contains a single Route header field pointing to itself, and it is co-located with an I-CSCF, or it has a preconfigured I-CSCF to be contacted, then forward the request to that I-CSCF. Otherwise select an I-CSCF and forward the request to that I-CSCF. If the single Route header field of the request contains the "orig" parameter, the IBCF shall insert the "orig" parameter to the URI of the I-CSCF;

NOTE 3: The selection of an I-CSCF can lead to additional delays.

5) if the request does not contain a Route header field or if it contains one or more Route header fields where the topmost Route header field does not contain the "orig" parameter, optionally – based on operator policy – append the "orig" parameter to the URI in the topmost Route header field of the next request sent from the IBCF to an entity of the IM CN subsystem for which it is an entry point;

NOTE 4: The appending of an "orig" parameter to the URI in the topmost Route header field enables an IM CN subsystem to perform originating services to the network that originated the initial request. The appending can be dependent on the network that originated the initial request as determined by e.g. origin IP address of the received request, etc.

6) if services that require knowledge of the adjacent network are provided within the network for which the IBCF is acting as an entry point, based on operator policy, insert a Via "received-realm" header field parameter, as defined in RFC 8055 [208];

6A) if the IBCF, acting as an entry point to a terminating visited network, PCRF based P-CSCF restoration procedures,

– the request contains a topmost Route header field pointing to a P-CSCF, and

– the IBCF considers the P-CSCF is in a non-working state,

remove all entries in the Route header field and add a Route header field set to the URI associated with an alternative P-CSCF;

NOTE 5: How the SIP URI of the alternative P-CSCF is obtained by the IBCF is implementation dependent. The IBCF can make sure that selected P-CSCF support the PCRF based P-CSCF restoration procedures based on local configuration.

NOTE 6: It is implementation dependent as to how the IBCF determines the P-CSCF is in non-working state.

7) if the initiator of the request is understood to always send and receive private network traffic:

NOTE 7: The IBCF can identify that a request is received from a source that always sends or receives private traffic by evaluating the TLS session or by other means.

a) add the identity of the initiator in a P-Served-User header field as defined in RFC 5502 [133] as a SIP URI identifying the initiator; and

NOTE 8: The IBCF can retrieve the identity of the initiator from the subjectCommonName (CN) if it is not present in the subjectAltName in the certificates during the TLS session setup in accordance with the procedures of RFC 5280 [213] or by other means.

b) if not already appended in 4) or 5) above, append the "orig" parameter to the URI in the topmost Route header field of the request sent from the IBCF to the entity of the IM CN subsystem for which it is an entry point;

8) if the request is an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain:

– remove any received "fe-identifier" header field parameter from the P-Charging-Vector header field; and

– add an "fe-addr" element in an "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier; and

9) if the IBCF supports calling number verification using signature verification and attestation information as described in subclause 3.1 and no Identity header field is received in an initial INVITE or MESSAGE request, based on local policy insert:

a) an Attestation-Info header field specified in subclause 7.2.18 set to a value "C", specified in RFC 8588 [261]; and

b) an Origination-Id header field specified in subclause 7.2.19 containing an "origid" claim as specified in RFC 8588 [261] set to a value identifying the source of the request;

and forward the request according to RFC 3261 [26].

NOTE 9: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

If the serving network supports HSS based P-CSCF restoration as specified in 3GPP TS 23.380 [7D], the IBCF is acting as an entry point to a terminating visited network and the IBCF does not receive any response within a configured time:

NOTE 10: The configurable time needs to be less than timer B and timer F.

1) to an initial INVITE request, then if the Route header field contains only one entry the IBCF shall in the 408 (Request Timeout) response include a Restoration-Info header field specified in subclause 7.2.11 containing the value "noresponse"; and

2) to an initial non-INVITE request for a dialog, a standalone transaction or an unknown method that does not relate to an existing dialog, then if the Route header field contains only one entry the IBCF shall send a 504 (Server Time-out) response include a Restoration-Info header field specified in subclause 7.2.11 containing the value "noresponse".

NOTE 11: The IBCF determines if it is acting as an entry point to a terminating visited network based on configuration or other data in the incoming request, or the "iotl" SIP URI parameter specified in RFC 7549 [225].

NOTE 12: If there is only one entry in the Route header field it represents either an MSC server or a P-CSCF. The S-CSCF will use the g.3gpp.ics media feature tag to determine if it is the MSC server or the P-CSCF.

When the IBCF receives a response to an initial request (e.g. 183 or 2xx), the IBCF shall:

1) store the values from the P-Charging-Function-Addresses header field, if present;

2) remove the "fe-identifier" header field parameter from the P-Charging-Vector header field, if present; and

3) remove the P-Charging-Function-Addresses header field prior to forwarding the message;

With the exception of 305 (Use Proxy) responses, the IBCF shall not recurse on 3xx responses.

5.10.3.3 Subsequent requests

Upon receipt of a subsequent request, the IBCF shall:

1) if the request is an INVITE request, then respond with a 100 (Trying) provisional response;

2) if the request is a target refresh request and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, then the IBCF shall save the Contact and CSeq header field values received in the request such that the IBCF is able to release the session if needed;

3) if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the IBCF is configured to perform application level gateway and/or transport plane control functionalities, then the IBCF shall save the Contact and CSeq header field values received in the request such that the IBCF is able to release the session if needed;

4) void;

5) if the request is received from an untrusted domain, remove all Feature-Caps header fields, if present; and

6) if the subsequent request is received from an entity outside the trust domain, then the IBCF shall remove a P-Charging-Vector header field, if present;

and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261 [26].

5.10.3.4 IBCF-initiated call release

If the IBCF provides transport plane control functionality and receives an indication of a transport plane related error the IBCF may:

1) generate a BYE request for the terminating side based on information saved for the related dialog; and

2) generate a BYE request for the originating side based on the information saved for the related dialog.

NOTE: Transport plane related errors can be indicated from e.g. TrGW or PCRF. The protocol for indicating transport plane related errors to the IBCF is out of scope of this specification.

Upon receipt of the 2xx responses for both BYE requests, the IBCF shall release all information related to the dialog and the related multimedia session.

5.10.3.5 Abnormal cases

When the IBCF acting as an entry point in the originating home network is unable to forward a SIP request, as determined by one of the following:

NOTE 1: If IBCF supports indicating traffic leg associated with a URI as specified in RFC 7549 [225], the IBCF can determine that IBCF is acting as an entry point in the originating home network by inspecting the value of the "iotl" SIP URI parameter, if an "iotl" SIP URI is included in the SIP request.

– there is no response to the SIP request and its retransmissions by the IBCF; or

– by unspecified means available to the IBCF;

and:

– the IBCF supports S-CSCF restoration procedures;

then the IBCF:

1) shall reject the request by returning a 504 (Server Time-out) response; and

2) shall include in the 504 (Server Time-out) response:

– a Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body as described in subclause 7.6.1;

– a P-Asserted-Identity header field set to the value of the SIP URI of the IBCF included in the Path header field during the registration (see subclause 5.10.3.1); and

– a 3GPP IM CN subsystem XML body containing:

a) an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service:

i) a <type> child element, set to "restoration" (see table 7.6.2) to indicate that restoration procedures are supported;

ii) a <reason> child element, set to an operator configurable reason; and

iii) an <action> child element, set to "initial-registration" (see table 7.6.3).

NOTE 2: These procedures do not prevent the usage of unspecified reliability or recovery techniques above and beyond those specified in this subclause.

5.10.4 THIG functionality in the IBCF

5.10.4.1 General

NOTE 1: THIG functionality is performed in I-CSCF in Release-5 and Release-6 and is compatible with the procedures specified in this subclause.

The following procedures shall only be applied if network topology hiding is required by the network. The network requiring network topology hiding is called the hiding network.

NOTE 2: Requests and responses are handled independently therefore no state information is needed for that purpose within an IBCF.

The IBCF shall apply network topology hiding to all header fields which reveal topology information, such as Via, Route, Record-Route, Service-Route, and Path.

Upon receiving an incoming REGISTER request for which network topology hiding has to be applied and which includes a Path header field, the IBCF shall add the routeable SIP URI of the IBCF to the top of the Path header field. The IBCF may:

1) include in the inserted SIP URI an indicator that identifies the direction of subsequent requests received by the IBCF i.e., from the S-CSCF towards the P-CSCF, to identify the UE-terminating case. The IBCF may encode this indicator in different ways, such as, e.g., a unique parameter in the URI, a character string in the username part of the URI, or a dedicated port number in the URI; and

2) if:

a) IBCF supports indicating traffic leg associated with a URI as specified in RFC 7549 [225]; and

b) if the SIP URI in the bottommost hidden Path header field contains an "iotl" SIP URI parameter;

then append an "iotl" SIP URI parameter with the same value to its own SIP URI in the Path header field.

Upon receiving a 200 (OK) response to the REGISTER request and:

1. if the IBCF is located in the visited network; and

2. if the IBCF applied topology hiding on the Path header field contained in the REGISTER request;

the IBCF shall:

1. perform a decryption procedure, as described in subclause 5.10.4.3, on the received Path header field; and

2. insert a "+g.3gpp.thig-path" Feature-Caps header field parameter, as defined in subclause 7.9A.9, set to the same IBCF’s SIP URI value as included in the Path header field of the REGISTER request sent to the home network.

NOTE 4: If a decryption of the Path header field contained in a 200 (OK) response on REGISTER request is not done then the UE will not perform restoration procedures if the P-CSCF rejects an initial request for a dialog or a request for a standalone transaction with a 504 (Server Time-out) response since there will be a mismatch between a SIP URI in the P-Asserted-Identity header field received in a valid 504 (Server Time-out) response and the SIP URIs the UE received in the Path header field.

Upon receiving an incoming initial request for which network topology hiding has to be applied and which includes a Record-Route header field, the IBCF shall add its own routeable SIP URI to the top of the Record-Route header field.

Upon receiving a 200 (OK) response to a REGISTER request for which network topology hiding has to be applied and which includes an URI identifying the IBCF in the topmost Service-Route header field and:

1) if IBCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225]; and

2) if an "iotl" parameter is included in the bottommost SIP URI;

then append an "iotl" SIP URI parameter with the same value to its own SIP URI in the Service-Route header field.

When the home network IBCF receives a 504 (Server Time-out) response containing a P-Asserted-Identity header field set to the value of the S-CSCF’s SIP URI for a roaming UE and if the home network is a hiding network then the IBCF shall replace the received P-Asserted-Identity header field with the P-Asserted-Identity header field set to the value of the own SIP URI.

NOTE 5: By provision or by obtaining from the corresponding request’s Route header field, the IBCF deduces whether the received value of the P-Asserted-Identity header field in the 504 (Server Time-out) response is the value of S-CSCF’s SIP URI.

5.10.4.2 Encryption for network topology hiding

Upon receiving an outgoing request/response from the hiding network the IBCF shall perform the encryption for network topology hiding purposes, i.e. the IBCF shall:

0) if applying encryption procedure on the Service-Route header field, exclude from the Service-Route header field the entry corresponding to its own SIP URI and use the remaining header field values which were added by one or more specific entity of the hiding network as input to encryption and skip item 1) below;

NOTE 1: In accordance with the procedures described in RFC 3608 [38], the IBCF does not insert its own routable SIP URI to the Service-Route header field i.e. the SIP URI identifying the IBCF in the topmost entry of the Service-Route header field is inserted by the S-CSCF. However this entry is excluded from encryption and will stay in the topmost entry of the Service-Route header field i.e. before the topmost encrypted entry.

1) use the whole header field values which were added by one or more specific entity of the hiding network as input to encryption, besides the UE entry;

2) not change the order of the header fields subject to encryption when performing encryption;

3) use for one encrypted string all received consecutive header field entries subject to encryption, regardless if they appear in separate consecutive header fields or if they are consecutive entries in a comma separated list in one header field;

4) construct a hostname that is the encrypted string in a way that allows to identify the encrypting network’s name (i.e. the IBCF network);

NOTE 2: This is to allow the IBCF to identify that itself has encrypted the string when subsequently receiving the encrypted string. The details of encoding the encrypting networks’s name are not specified as the IBCF is the creator and consumer of this value. This is needed because header field parameters (like "tokenized-by") are not required to be preserved when creating a route set.

5) append a "tokenized-by" header field parameter and set it to the value of the encrypting network’s name, after the constructed hostname;

6) form one valid entry for the specific header field out of the resulting NAI, e.g. prepend "SIP/2.0/UDP" for Via header fields or "sip:" for Path, Service-Route, Route and Record-Route header fields;

7) if the IBCF encrypted an entry in the Route header field, then it also inserts its own URI before the topmost encrypted entry; and

8) if the IBCF encrypted an entry in the Via header field, then it also inserts its own URI before the topmost encrypted entry.

NOTE 3: Even if consecutive entries of the same network in a specific header field are encrypted, they will result in only one encrypted header field entry. For example:

Via: SIP/2.0/UDP ibcf1.home1.net;lr,

SIP/2.0/UDP Token( SIP/2.0/UDP scscf1.home1.net;lr,

SIP/2.0/UDP pcscf1.home1.net;lr)@home1.net;

tokenized-by=home1.net,

SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]

NOTE 4: If multiple entries of the same network are within the same type of header fields, but they are not consecutive, then these entries will be tokenized to different strings. For example:

Record-Route: sip:ibcf1.home1.net;lr,

sip:Token(sip:scscf1.home1.net;lr)@home1.net;tokenized-by=home1.net,

sip:as1.foreign.net;lr,

sip:Token(sip:scscf1.home1.net;lr,

sip:pcscf1.home1.net;lr)@home1.net;tokenized-by=home1.net

NOTE 5: If request will return to the hiding network (e.g. after visiting an AS), then the URI of IBCF is inserted. For example:

Route: sip:as1.foreign.net;lr,

sip:ibcf1.home1.net;lr,

sip:Token(sip:scscf1.home1.net;lr);tokenized-by=home1.net

5.10.4.3 Decryption for network topology hiding

Upon receiving and incoming requests/response to the hiding network the IBCF shall perform the decryption for network topology hiding purposes, i.e. the IBCF shall:

1) identify hostnames encrypted by the network this IBCF belongs to within all header fields of the incoming message;

2) use those hostnames that carry the identification of the hiding network as input to decryption;

3) use as encrypted string the hostname which follows the sent-protocol (for Via header fields, e.g. "SIP/2.0/UDP") or the URI scheme (for Path, Route and Record-Route header fields, e.g. "sip:");

4) replace all content of the received header field which carries encrypted information with the entries resulting from decryption.

EXAMPLE: An encrypted entry to a Via header field that looks like:

Via: SIP/2.0/UDP Token(SIP/2.0/UDP scscf1.home1.net;lr,

SIP/2.0/UDP pcscf1.home1.net;lr);tokenized-by=home1.net

will be replaced with the following entries:

Via: SIP/2.0/UDP scscf1.home1.net;lr, SIP/2.0/UDP pcscf1.home1.net;lr

NOTE: Motivations for these decryption procedures are e.g. to allow the correct routeing of a response through the hiding network, to enable loop avoidance within the hiding network, or to allow the entities of the hiding network to change their entries within e.g. the Record-Route header field.

5.10.5 IMS-ALG functionality in the IBCF

The IBCF shall only apply the following procedures if application level gateway functionality is required by the network.

The IBCF acts as a B2BUA when it performs IMS-ALG functionality. As an IMS-ALG, the IBCF will internally map the message header fields between the two dialogs that it manages. It is responsible for correlating the dialog identifiers and will decide when to simply translate a message from one dialog to the other, or when to perform other functions. The IBCF, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem.

An IBCF may replace a contact address with a URI of its own when the contact address in the incoming message is not a GRUU. In all other cases the IBCF shall use a GRUU (e.g when the contact address is an IP address).

The IBCF shall transparently forward a received Contact header field when the Contact header field contains a GRUU or a media feature tag is included indicating a capability for which the Contact URI can be used by the remote party. When transparently forwarding a received Contact header field of a dialog-forming request, the IBCF shall include its own URI in a Record-Route header field in order to ensure that it is included on the route of subsequent requests.

NOTE: One example of such a media feature tag is the isfocus media feature tag used by conference services to transport the temporary conference identity that can be used when rejoining an ongoing conference.

The internal function of the IBCF as an IMS-ALG is defined in 3GPP TS 29.162 [11A].

If the IBCF receives a message with a body part for a UE from an S-CSCF, and:

– if the body part is the 3GPP IM CN subsystem XML body (as indicated by the Content-Type header field, see subclause 7.6) and the body part is not optional (as indicated by the (absence of the) Content-Disposition header field); or

– if a header field that describes the body is present and the header field’s value is not understood (e.g. Content-Language header field or Content-Encoding header field);

then the IBCF shall transparently forward the message with the body part and the header field(s) that describe the body part.

5.10.6 Screening of SIP signalling

5.10.6.1 General

The IBCF may act as a B2BUA when it performs screening of SIP signalling functionality. In this case the B2BUA behaviour of the IBCF shall comply with the description given in subclause 5.10.5 for the IMS-ALG functionality.

NOTE: Many header fields are intended for end-to-end operation; removal of such header fields will impact the intended end-to-end operation between the end users. Additionally the IM CN subsystem does not preclude security mechanisms covering SIP header fields; any such removal can prevent validation of all header fields covered by the security mechanism.

5.10.6.2 IBCF procedures for SIP header fields

If specified by local policy rules, the IBCF may omit or modify any received SIP header fields prior to forwarding SIP messages, with the following exceptions.

As a result of any screening policy adopted, the IBCF should not modify at least the following header fields which would cause misoperation of the IM CN subsystem:

– Authorization; and

– WWW-Authenticate.

Where the IBCF appears in the path between the UE and the S-CSCF, some header fields are involved in the registration and authentication of the user. As a result of any screening policy adopted as part of normal operation, e.g. where the request or response is forwarded on, the IBCF should not modify as part of the registration procedure at least the following header fields:

– Path; and

– Service-Route.

NOTE 1: If the IBCF modifies SIP information elements (SIP header fields, SIP message bodies) other than as specified by SIP procedures (e.g., RFC 3261 [26]) caution needs to be taken that SIP functionality (e.g., routeing using Route, Record-Route and Via) is not impacted in a way that could create interoperability problems with networks that assume that this information is not modified.

NOTE 2: Where operator requirements can be achieved by configuration hiding, then these procedures can be used in preference to screening.

The IBCF may add, remove, or modify, the P-Early-Media header field within forwarded SIP requests and responses according to procedures in RFC 5009 [109].

NOTE 3: The IBCF can use the P-Early-Media header field for the gate control procedures,by through-connect control as described in 3GPP TS 29.162 [11A]. In the presence of early media for multiple dialogs due to forking, if the IBCF is able to identify the media associated with a dialog, (i.e., if symmetric RTP is used by the UE and the IBCF can use the remote SDP information to determine the source of the media) the IBCF can selectively open the gate corresponding to an authorized early media flow for the selected media.

The IBCF may add, or omit any P-Asserted-Identity header fields prior to forwarding SIP messages according to local policy.

NOTE 4: The IBCF can use the P-Asserted-Identy header field to trigger identity specific procedures in subsequent entities, e.g. for malicious call identification. As an example, a P-Asserted-Identity header field will be deleted and a new P-Asserted-Identity header field with operator specific content will be added to the outgoing request, if the request was received from a network which cannot support the deletion of INFO request which is needed for the support of the malicious call identification service.

When the IBCF, located in the home network, receives a SIP request from another entity within the same trust domain, the IBCF may police the ICSI value contained in the P-Asserted-Service header field.

5.10.6.3 IBCF procedures for SIP message bodies

If the IBCF acts as a B2BUA, and the IBCF receives a message with a body part for a UE from an S-CSCF, and:

– if a header field that describes the body is present and the header field’s value is not understood (e.g. Content-Language header field or Content-Encoding header field),

then the IBCF shall transparently forward the message with the body part and the header field(s) that describe the body part.

If IP address translation (NA(P)T or IP version interworking) occurs on the user plane, the IBCF shall modify SDP according to subclause 6.7.1;

Additionally, the IBCF may take the followings action upon SIP message bodies:

1) examine the length of a SIP message body and if required by local policy, take an appropriate action (e.g. forward the message body transparently, reject the request, remove the body);

2) examine the characteristics of the SIP message body MIMEs (i.e. check the values of any Content-Type, Content-Disposition, and Content-Language header fields), take an appropriate action defined by local policy (e.g. forward the body unchanged, remove the SIP message body MIME, reject the call); and

3) examine the content of SIP message body MIMEs, and take appropriate action defined by local policy (e.g. forward the body unchanged, remove the SIP message body MIME, reject the call).

When the intended action of an IBCF, based on local policy, is to remove a message body MIME from a SIP message body, and a Content-Disposition header field with a "handling" parameter set to "required" is associated with the MIME, the IBCF shall reject the SIP request with the 415 (Unsupported Media Type) response code as specified in RFC 5621 [150].

5.10.7 Media transcoding control

The IBCF may perform the media transcoding control in order to allow establishing communication between IM CN subsystems using different media codecs based on the interworking agreement and session information. When performing media transcoding control the IBCF acts as a special case of an IMS-ALG compliant with the description given in subclause 5.10.5.

Upon receipt of any request containing an SDP offer, based on local policy and signalling inspection (e.g ICSI values, SDP), the IBCF may perform media transcoding control, as defined in subclause 6.7.1.3. Based on the local configuration determines the media which requires transcoding in the SDP offer.

5.10.8 Privacy protection at the trust domain boundary

In order to ensure privacy IBCF shall additionally to what is specified in subclause 4.4 and before sending the SIP requests or SIP responses outside the trust domain boundary perform the privacy protection as specified in RFC 3323 [33] and RFC 7044 [66] applicable to header fields with the clarifications in this subclause. If there are any conflicts between topology hiding specified in subclause 5.10.4 and the procedures in this subclause, the topology hiding takes precedence over privacy protection.

NOTE: The privacy protection for the History-Info header field is performed in accordance with RFC 7044 [66] subclause 10.1.2.

If a Privacy header field with a value different from "none" is received the IBCF shall:

1) if "header" privacy is requested as specified in RFC 3323 [33]:

– remove all received Via header fields and then add a single Via header field with a URI of its own as described in RFC 3323 [33] subclause 5.1;

– if the Contact header field does not contain a GRUU or does not contain an isfocus media feature tag, replace the value of the URI of the Contact header field with a URI that does not dereference to the originator of the message as described in RFC 3323 [33] subclause 5.1; and

– remove any Record-Route header fields as described in RFC 3323 [33] subclause 5.1;

2) if "user" level privacy is requested as specified in RFC 3323 [33]:

– anonymize the From header field. The convention for configuring an anonymous From header field described in RFC 3323 [33] and RFC 3325 [34] should be followed; i.e. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag= xxxxxxx; and

3) if any modification of any dialog-matching headers for privacy protection reasons is done act as a transparent B2BUA as described in RFC 3323 [33] subclause 5.3.

If a Privacy header field is not received IBCF may based on local policy act as if "id", "user", "header" and "history" was received and perform privacy protection as specified in RFC 3325 [34], RFC 3323 [33] and RFC 7044 [66] with the clarifications above.

If a Privacy header field with the value "none" is received the IBCF should not protect the privacy of the identity information.

NOTE: A local policy can regard a Privacy header field with the value "none" the same as if no Privacy header field was received.

5.10.9 Roaming architecture for voice over IMS with local breakout

The IBCF shall apply OMR as specified in 3GPP TS 29.079 [11D] and in accordance with the roaming architecture for voice over IMS with local breakout when a session is identified as a roaming architecture for voice over IMS with local breakout session.

A session can be identified as a potential roaming architecture for voice over IMS with local breakout session when:

1) a received initial INVITE request contains a Feature-Caps header field with a "+g.3gpp.trf" header field parameter, a "+g.3gpp.loopback" header field parameter or any other implementation dependent indication; or

NOTE: An implementation dependent indication can e.g. be in a URI parameter, a character string in the user part of the URI or be a port number in the URI.

2) if indicating traffic leg as specified in RFC 7549 [225] is supported and used:

a) the "iotl" SIP URI parameter with the value "visitedA-homeA" in the bottommost Route header field; or

b) the "iotl" SIP URI parameter with the value "homeA-visitedA" in the bottommost Route header field.

5.10.10 HTTP procedures over the Ms reference point

5.10.10.1 General

General procedures over the Ms reference point are specified in clause V.2.

5.10.10.2 Procedures for an IBCF acting as an entry point

When receiving an initial INVITE, re-INVITE or MESSAGE request containing one or more SIP Identity header fields, the IBCF shall determine the information (originating identity, diverting identities, contents of the Resource-Priority and Priority header fields) to be verified by decoding the Identity header fields containing a PASSporT SHAKEN JSON Web Token and/or a PASSporT rph JSON Web Token with an optional PASSporT sph JSON Web Token. The IBCF uses the Identity header fields to:

1) build and send a verificationRequest, specified in annex V, to an AS for verification over the Ms reference point; and

2) shall upon receiving an HTTP 200 (OK) response to the above request, use:

– the verstat claim from this response to populate the "verstat" tel URI parameter associated with the originating identity and add this parameter to the verified identity in the SIP From header field or the SIP P-Asserted-Identity header field in the forwarded SIP request. Additionally, if the HTTP 200 (OK) response included verification results for the diverting identities, the IBCF shall based on local policy add the "verstat" tel URI parameter to the verified diverting identities in the History-Info header field if this field is available;

– the verstatPriority claim from this response to populate the Priority-Verstat header field associated with the Resource-Priority header field and with the header field value "psap-callback" of the Priority header field (if present) and include the Priority-Verstat header field in the forwarded SIP request; and

– the verifyResults from this response, if present, to store any of the PASSporT verification failure parameters shown in Table V.2.6.2-4.

Based on local policy, the IBCF may populate for each reported Identity header field verification error a Reason header field in the next provisional or final response of the INVITE or MESSAGE request, where the Reason header field protocol value is set to "STIR", as specified in draft-ietf-stir-identity-header-errors-handling [294] and draft-ietf-sipcore-multiple-reasons [296], and the "cause" header field parameter contains the stored "reasonCode" value. Additionally, the IBCF may include the "ppi" header field parameter containing the failing PASSporT.

NOTE 1: Multiple Reason header fields with the protocol value set to "STIR" are not supported in the present document.

Based on local policy, the IBCF may verify that the validated claims returned in the validClaims parameter of the verification response authorize the associated SIP header field values.

NOTE 2: For sessions originating in another domain, only one of the following entities needs to be configured to verify the Identity header field for the resource priority: the IBCF or the AS. Which functional entity inserts the Identity header field verification is subject to network configuration and local policy.

5.10.10.3 Procedures for an IBCF acting as an exit point

When receiving an initial INVITE or MESSAGE request containing:

NOTE 1: As part of the border control procedures the IBCF can apply privacy procedures and in these cases this procedure is not needed.

1) a "verstat" tel URI parameter in at least one of the SIP From header field or the SIP P-Asserted-Identity header field;

2) a SIP Attestation-Info header field as defined in subclause 7.2.18; and

3) a SIP Origination-Id header field as defined in subclause 7.2.19;

and if no Identity header field exists, the IBCF sends a signingRequest, specified in annex V, over the Ms reference point. When the HTTP 200 (OK) response to this request is received, the IBCF shall include value of the "identity" claim in an Identity header field in the forwarded SIP request.

When receiving an initial INVITE or MESSAGE request containing at least one Identity header field and a "verstat" tel URI parameter in a tel URI or a SIP URI with a user=phone parameter in one or more History-Info header field(s) or using other not specified means to determine that a diversion has occurred, then the IBCF sends a signingRequest, specified in annex V, over the Ms reference point for each of the identities to be signed. When the HTTP 200 (OK) response for any of these requests is received, the IBCF shall include the value of the "identity" claim in an Identity header field in the forwarded SIP request.

NOTE 2: As part of the border control procedures the IBCF can apply privacy procedures and in these cases this procedure is not needed.

When receiving an initial INVITE request containing the Resource-Priority header field and optionally the Priority header field with a "psap-callback" header field value or if the IBCF included the Priority header field with a "psap-callback" header field value and the Resource-Priority header field (as specified in subclause 5.10.1), the IBCF sends a signingRequest, over the Ms reference point, as specified in annex V, for the resource priority and optionally, the Priority header fields. When the HTTP 200 (OK) response to this request is received, the IBCF shall include the value of the "identity" claim in an Identity header field in the forwarded initial INVITE request.

When receiving a re-INVITE request containing the Resource-Priority header field, the IBCF sends a signingRequest, over the Ms reference point, as specified in annex V, for the resource priority. When the HTTP 200 (OK) response to this request is received, the IBCF shall include the value of the "identity" claim in an Identity header field in the forwarded re-INVITE request.

NOTE 3: For sessions terminating in another domain, only one of the following entities needs to be configured to provide an Identity header field for the resource priority: the IBCF or the AS. Which functional entity inserts the Identity header field is subject to network configuration and local policy.