Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
5.8 Procedures at the MRFC  5.8.1 General  5.8.2 Call initiation  5.8.3 Call release  5.8.4 Call-related requests  5.8.5 Further initial requests  5.8A Procedures at the MRB  5.10 Procedures at the IBCF  5.10.1 General  5.10.2 IBCF as an exit point  5.10.3 IBCF as an entry point  5.10.4 THIG functionality in the IBCF  5.10.5 IMS-ALG functionality in the IBCF  5.10.6 Screening of SIP signalling  5.10.7 Media transcoding control  5.10.8 Privacy protection at the trust domain boundary  5.10.9 Roaming architecture for voice over IMS with local breakout  5.10.10 HTTP procedures over the Ms reference point 
...

 

5.8  Procedures at the MRFC  p. 340

5.8.1  General  p. 340

Although the MRFC is acting as a UA, it is outside the scope of this specification how the MRFC associated addresses are made known to other entities.
For all SIP transactions identified:
  • if priority is supported, as containing an 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 MRFC shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the MGCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
When the MRFC sends any request or response (excluding CANCEL requests and responses) related to a dialog or standalone transaction, the MRFC may insert previously saved values into P-Charging-Vector header field before sending the message.
When the MRFC sends any request or response (excluding ACK requests and CANCEL requests and responses) related to a dialog or standalone transaction, the MRFC may insert previously saved values into P-Charging-Function-Addresses header fields before sending the message.
The MRFC shall use a GRUU referring to itself (as specified in RFC 5627) when inserting a contact address in a dialog establishing or target refreshing SIP message. This specification does not define how GRUUs are created by the MRFC; they can be provisioned by the operator or obtained by any other mechanism. A GRUU used by the MRFC when establishing a dialog shall remain valid for the lifetime of the dialog.
The MRFC shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which the GRUU was provided.
EXAMPLE:
Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and containing a Replaces header field referencing that dialog, the MRFC will be able to establish the new call replacing the old one.
The MRFC 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 sending a failure response to any received request, depending on operator policy, the MRFC 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 "mrfc" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.
Up

5.8.2  Call initiation  p. 341

5.8.2.1  Initial INVITE  p. 341

5.8.2.1.1  MRFC-terminating case  p. 341
5.8.2.1.1.1  Introduction  p. 341
The MRFC shall provide a P-Asserted-Identity header field in a response to the initial request for a dialog, or any response for a standalone transaction. It is a matter of network policy whether the MRFC expresses privacy according to RFC 3323 with such responses.
When the MRFC receives an initial INVITE request, the MRFC shall store the values received in the P-Charging-Vector header field, e.g. "icid-value" header field parameter. The MRFC shall store the values received in the P-Charging-Function-Addresses header field.Based on local policy, the MRFC shall add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier to an initial request.
If the MRFC receives an initial request with a P-Charging-Vector header field, the MRFC shall, based on local policy, store the "fe-identifier" header field parameter of the P-Charging-Vector header field.
When the MRFC receives a final response, the MRFC shall, based on local policy, include the stored "fe-identifier" header field parameter in 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.
Up
5.8.2.1.1.2  Tones and announcements   p. 341
The MRFC can receive INVITE requests to set up a session to play tones and announcements. The MRFC acts as terminating UA in this case.
When the MRFC receives an INVITE request for a tone or announcement, the MRFC shall:
  • send 100 (Trying) response.
5.8.2.1.1.3  Ad-hoc conferences   p. 341
The MRFC can receive INVITE requests to set up an ad-hoc conferencing session (for example a multiparty call) or to add parties to the conference. The MRFC acts as terminating UA in this case.
When the MRFC receives an INVITE request for ad hoc conferencing, the MRFC shall:
  • send 100 (Trying) response.
When the MRFC receives an INVITE request to add a party to an existing ad hoc conference (i.e. MRFC conference identifier), the MRFC shall:
  • send 100 (Trying) response.
5.8.2.1.1.4  Transcoding   p. 342
The MRFC may receive INVITE requests to set up transcoding between endpoints with incompatible codecs. The MRFC acts as terminating UA in this case.
When the MRFC receives an INVITE request for transcoding and a codec is supplied in SDP, the MRFC shall:
  • send 100 (Trying) response.
When the MRFC receives an INVITE request with an indicator for transcoding but no SDP, the MRFC shall:
  • send 183 (Session Progress) response with list of codecs supported by the MRFC/MRFP.
5.8.2.1.2  MRFC-originating case  p. 342
The MRFC shall provide a P-Asserted-Identity header field in an initial request for a dialog, or any request for a standalone transaction. It is a matter of network policy whether the MRFC expresses privacy according to RFC 3323 with such requests.
When an MRFC generates an initial request for a dialog or a request for a standalone transaction, the MRFC shall insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260.
Up

5.8.2.2  Subsequent requests  p. 342

5.8.2.2.1  Tones and announcements  p. 342
When the MRFC receives an ACK request for a session, this may be considered as an event to direct the MRFP to start the playing of a tone or announcement.
5.8.2.2.2  Transcoding  p. 342
When the MRFC receives a PRACK request (in response to the 183 (Session Progress) response with an indicator for transcoding and codec supplied in SDP, the MRFC shall:
  • after the MRFP indicates that the transcoding request is granted, send 200 (OK) response.

5.8.3  Call release  p. 342

5.8.3.1  S-CSCF-initiated call release  p. 342

5.8.3.1.1  Tones and announcements  p. 342
When the MRFC receives a BYE request for a session, the MRFC directs the MRFP to stop the playing of a tone or announcement.

5.8.3.2  MRFC-initiated call release  p. 342

5.8.3.2.1  Tones and announcements  p. 342
When the MRFC has a timed session to play tones and announcements and the time expires, the MRFC shall:
  • send a BYE request towards the UE.
When the MRFC is informed by the MRFP that tone or announcement resource has been released, the MRFC shall:
  • send a BYE request towards the UE.

5.8.4  Call-related requests  p. 342

5.8.4.1  ReINVITE  p. 342

5.8.4.1.1  MRFC-terminating case  p. 342
5.8.4.1.1.1  Ad-hoc conferences   p. 342
The MRFC can receive reINVITE requests to modify an ad-hoc conferencing session (for example a multiparty call) for purposes of floor control and for parties to leave and rejoin the conference.
When the MRFC receives a reINVITE request, the MRFC shall:
  • send 100 (Trying) response; and
  • after the MRFP indicates that the conferencing request is granted, send 200 (OK) response. The MRFC may choose to send a 183 (Session Progress) response prior to the 200 (OK) response.
5.8.4.1.2  MRFC-originating case  p. 343
Void.

5.8.4.2  REFER  p. 343

5.8.4.2.1  MRFC-terminating case  p. 343
Void.
5.8.4.2.2  MRFC-originating case  p. 343
Void.
5.8.4.2.3  REFER initiating a new session  p. 343
Void.
5.8.4.2.4  REFER replacing an existing session  p. 343
Void.

5.8.4.3  INFO  p. 343

Void.

5.8.5  Further initial requests  p. 343

When the MRFC responds to an OPTIONS request with a 200 (OK) response, the MRFC may include a message body with an indication of the supported tones/announcement packages, DTMF capabilities, supported codecs and conferencing options of the MRFC/MRFP.
Up

5.8A  Procedures at the MRB |R11|  p. 343

For all SIP transactions identified:
  • if priority is supported, as containing an 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 MRB shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the MRB shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
The MRB shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field based on local policy.
Up

5.9  Void

5.9.1  Void

5.10  Procedures at the IBCF |R7|  p. 344

5.10.1  General  p. 344

As specified in TS 23.228 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:
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.
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.
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.
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, 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.
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.
Up

5.10.2  IBCF as an exit point  p. 345

5.10.2.1  Registration  p. 345

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
  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.
    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.
Up

5.10.2.1A  General |R8|  p. 345

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.
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.
Up

5.10.2.2  Initial requests  p. 346

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;
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;
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, if present, prior to forwarding the request;
and forward the request according to RFC 3261.
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 Section 8 of RFC 4028.
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.
Up

5.10.2.3  Subsequent requests  p. 347

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.
Up

5.10.2.4  IBCF-initiated call release  p. 348

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.
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.
Up

5.10.3  IBCF as an entry point  p. 348

5.10.3.1  Registration  p. 348

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;
  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
  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.
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.
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.
Up

5.10.3.1A  General |R8|  p. 348

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;
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.
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.
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.
Up

5.10.3.2  Initial requests  p. 349

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;
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;
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;
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 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;
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;
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;
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;
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;
7)
if the initiator of the request is understood to always send and receive private network traffic:
  1. add the identity of the initiator in a P-Served-User header field as defined in RFC 5502 as a SIP URI identifying the initiator; and
  2. 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:
  1. an Attestation-Info header field specified in subclause 7.2.18 set to a value "C", specified in RFC 8588; and
  2. an Origination-Id header field specified in subclause 7.2.19 containing an "origid" claim as specified in RFC 8588 set to a value identifying the source of the request;
and forward the request according to RFC 3261.
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 Section 8 of RFC 4028.
If the serving network supports HSS based P-CSCF restoration as specified in TS 23.380, 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:
  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".
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.
Up

5.10.3.3  Subsequent requests  p. 352

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;
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, 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.
Up

5.10.3.4  IBCF-initiated call release  p. 352

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.
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.
Up

5.10.3.5  Abnormal cases |R11|  p. 353

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:
  • 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:
      1. 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:
        1. a <type> child element, set to "restoration" (see table 7.6.2) to indicate that restoration procedures are supported;
        2. a <reason> child element, set to an operator configurable reason; and
        3. an <action> child element, set to "initial-registration" (see table 7.6.3).
Up

5.10.4  THIG functionality in the IBCF  p. 353

5.10.4.1  General  p. 353

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.
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:
    1. IBCF supports indicating traffic leg associated with a URI as specified in RFC 7549; and
    2. 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.
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; 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.
Up

5.10.4.2  Encryption for network topology hiding  p. 354

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;
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);
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.
Up

5.10.4.3  Decryption for network topology hiding  p. 355

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
Up

5.10.5  IMS-ALG functionality in the IBCF  p. 356

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.
The internal function of the IBCF as an IMS-ALG is defined in TS 29.162.
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.
Up

5.10.6  Screening of SIP signalling  p. 357

5.10.6.1  General  p. 357

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.
Up

5.10.6.2  IBCF procedures for SIP header fields  p. 357

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.
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.
The IBCF may add, or omit any P-Asserted-Identity header fields prior to forwarding SIP messages according to local policy.
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.
Up

5.10.6.3  IBCF procedures for SIP message bodies  p. 358

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 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.
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.
Up

5.10.7  Media transcoding control |R8|  p. 358

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.
Up

5.10.8  Privacy protection at the trust domain boundary |R10|  p. 358

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 and RFC 7044 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.
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:
    • remove all received Via header fields and then add a single Via header field with a URI of its own as described in Section 5.1 of RFC 3323;
    • 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 Section 5.1 of RFC 3323; and
    • remove any Record-Route header fields as described in Section 5.1 of RFC 3323;
  2. if "user" level privacy is requested as specified in RFC 3323:
    • anonymize the From header field. The convention for configuring an anonymous From header field described in RFC 3323 and RFC 3325 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 Section 5.3 of RFC 3323.
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, RFC 3323 and RFC 7044 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.
Up

5.10.9  Roaming architecture for voice over IMS with local breakout |R11|  p. 359

The IBCF shall apply OMR as specified in TS 29.079 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
  2. if indicating traffic leg as specified in RFC 7549 is supported and used:
    1. the "iotl" SIP URI parameter with the value "visitedA-homeA" in the bottommost Route header field; or
    2. the "iotl" SIP URI parameter with the value "homeA-visitedA" in the bottommost Route header field.
Up

5.10.10  HTTP procedures over the Ms reference point |R15|  p. 359

5.10.10.1  General  p. 359

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  p. 359

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 RFC 9410 and RFC 9366, 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.
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.
Up

5.10.10.3  Procedures for an IBCF acting as an exit point  p. 360

When receiving an initial INVITE or MESSAGE request containing:
  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.
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.
Up

Up   Top   ToC