Content for  TS 24.229  Word version:  19.0.0

The UE shall establish a RLOS session as described in this sub-clause only after it has initiated a RLOS registration and has received a 403 (Forbidden) response sent from an S-CSCF. When establishing a RLOS session in case of an unregistered user, the UE is allowed to receive responses to RLOS requests and requests inside an established RLOS session on the unprotected ports. The UE shall reject or silently discard all other messages. Additionally, the UE shall transmit signalling packets pertaining to the RLOS session from the same IP address and unprotected port on which it expects to receive signalling packets containing the responses to RLOS requests and the requests inside the established RLOS session. When establishing a RLOS session for an unregistered user, the UE shall use the local IP address and P-CSCF address as used when sending the RLOS registration. The UE shall send only the initial INVITE requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE shall send the initial INVITE request to the SIP default port values as specified in RFC 3261. The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the following additions:

1. the UE shall set the From header field of the INVITE request to the public user identity as used in the RLOS registration;
2. the UE shall:
   1. if a dial string for a specific RLOS service is available in the UE, use the dial string to build the Request-URI as specified in subclause 5.1.2A.1.3; and
   2. if no dial string for a specific RLOS service is available in the UE use the dummy MSISDN value as defined in TS 23.003 to build the Request-URI as specified in subclause 5.1.2A.1.3;
3. the UE shall insert in the INVITE request, a To header field with the same value as in the Request-URI;
4. The UE shall insert a P-Preferred-Service header field according to RFC 6050 set to "urn:urn-7:3gpp-service.ims.icsi.rlos";
5. The UE shall insert an Accept-Contact header field field containing the "+g.3gpp.icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos";
6. the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any request. Insertion of the P-Access-Network-Info header field into the ACK request is optional. The UE shall populate the P-Access-Network-Info header field with the current point of attachment to the IP-CAN as specified for the access network technology (see subclause 7.2A.4).;
7. The UE shall populate the P-Preferred-Identity header field in the INVITE request with an IMEI based identity in the form of a SIP URI as specified in subclause 13.13 of TS 23.003;
8. a Contact header field set to include SIP URI that contains in the hostport parameter the IP address of the UE and an unprotected port where the UE will receive incoming requests belonging to this dialog. The UE shall also include a "sip.instance" media feature tag containing Instance ID as described in RFC 5626. The UE shall also include the "+g.3gpp. icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos" . The UE shall not include either the public or temporary GRUU in the Contact header field;
9. a Via header field set to include the IP address of the UE in the sent-by field and for the UDP the unprotected server port value where the UE will receive responses, while for the TCP, the response is received on the TCP connection on which the RLOS request was sent. For the UDP, the UE shall also include "rport" header field parameter with no value in the top Via header field.;
10. if the UE has its location information available, or a URI that points to the location information, the UE shall include a Geolocation header field in the INVITE request in the following way:
    • if the UE is aware of the URI that points to where the UE's location is stored, include the URI as the Geolocation header field value, as described in RFC 6442; or
    • if the UE is aware of its location information, include the location information in a PIDF location object, in accordance with RFC 4119, include the location object in a message body with the content type application/pidf+xml, and include a Content ID URL, referring to the message body, as the Geolocation header field value, as described RFC 6442, and include a Content-Disposition header field with a disposition type "render" value and a "handling" header field parameter with an "optional" value, as described in RFC 3261;
11. if the UE includes a Geolocation header field, the UE shall also include a Geolocation-Routing header field with a "yes" header field value, which indicates that the location of the UE can be used by other entities to make routing decisions, as described in RFC 6442; and
12. if the UE has neither geographical location information available, nor a URI that points to the location information, the UE shall not insert a Geolocation header field in the INVITE request.

The UE shall build a proper preloaded Route header field value for all new dialogs. The UE shall build a Route header field value containing only the P-CSCF URI which was used in the RLOS registration. When a SIP transaction times out, i.e. timer B, timer F or timer H expires at the UE, the UE may behave as if timer F expired, as described in subclause 5.1.1.4. If the response for the initial INVITE request indicates that the UE is behind NAT, and the INVITE request was sent over TCP connection, the UE shall keep the TCP connection during the entire duration of the emergency session. In this case the UE will receive all responses to the emergency requests and the requests inside the established emergency session over this TCP connection. If the Via header field of any provisional response, or of the final 200 (OK) response, for the initial INVITE request contains a "keep" header field parameter with a value, unless the UE detects that it is not behind a NAT, the UE shall start to send keep-alives associated with the session towards the P-CSCF, as described in RFC 6223.

The UE shall apply the procedures as specified in subclauses 5.1.2A and 5.1.3 with the following additions:

1. the UE shall include in the Request-URI of the initial INVITE request the dummy MSISDN value as defined in TS 23.003;
2. the UE shall insert in the INVITE request, a To header field with the same value as in the Request-URI;
3. The UE shall insert a P-Preferred-Service header field according to RFC 6050 set to "urn:urn-7:3gpp-service.ims.icsi.rlos"; and
4. The UE shall insert an Accept-Contact header field field containing the "+g.3gpp.icsi-ref" header field parameter containing an ICSI value set to "urn:urn-7:3gpp-service.ims.icsi.rlos";

If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request destined to the served user containg the Resource-Share header field parameter with the value "media-sharing" and the "origin" header field parameter set to the value "session-receiver" and if local policy requires resource reservation using the initial SDP offer the P-CSCF shall:

1. store resource sharing rules and corresponding sharing key values as described in subclause 7.2.13.5 and use each stored sharing key to identify resource sharing rules for media streams in this session; and
2. apply resource sharing as specified in TS 29.214 using the stored resource sharing rules.

Upon receiving a response to the above INVITE request containing an initial SDP answer, if the initial INVITE request containging the initial SDP offer contained the Resource-Share header field set to the value "media-sharing" and the "origin" header field parameter set to "session-receiver" and if local policy requires resource reservation on the initial SDP answer, the P-CSCF shall:

1. store resource sharing rules and corresponding sharing key values as described in subclause 7.2.13.5 and use the stored sharing keys to identify resource sharing rules for media streams in this session; and
2. apply resource sharing as specified in TS 29.214 using the stored resource sharing rules.

If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request containg the Resource-Share header field with the value "no-media-sharing" and the "origin" header field parameter set to the value "session-receiver", the P-CSCF shall not share media in this session. If P-CSCF supports resource sharing and when P-CSCF receives an initial INVITE request not containing a Resource-Share header field, the P-CSCF may apply resource sharing using local configuration. If the P-CSCF supporting resource sharing receives a request or response from the home network destined to the served user containing a Resource-Share header field with the "origin" header field parameter set to the value "session-initiator" or without the "origin" header field parameter, the P-CSCF shall not use the content of the header field and remove the header field from the outgoing response or request.

When the P-CSCF supporting resource sharing receives an 18x response or a 2xx response from a served UE and the response contains an initial SDP offer and local policy requires resource reservation using the initial SDP offer, the P-CSCF shall :

1. for each m-line in the SDP offer, internally generate a set of temporary resource sharing rules where:
   • each resource sharing rule contains a sharing key with a value that is unique and not used by any another media stream in any ongoing session involving the UE; and
   • directionality is included according to local policy; and
2. apply resource-sharing as specified in TS 29.214 using the temporary resource sharing rules.

Upon receiving a PRACK request or an ACK request containing the initial SDP answer and a Resource-Share header field with the value "media-sharing" and the "origin" header field parameter set to "session-receiver", the P-CSCF shall:

1. store resource sharing rules and the value of the corresponding sharing key as described in subclause 7.2.13.5 and use stored sharing key to identify resource sharing rules for the media streams in this session; and
2. apply resource sharing rules as specified in TS 29.214 using the stored sharing rules.

Upon receiving a PRACK request or an ACK request containing the initial SDP answer and a Resource-Share header field with the value "no-media-sharing", the P-CSCF shall not share resources in this session. Upon receiving a PRACK request or an ACK request containing the initial SDP answer and the response does not contain a Resource-Share header field, the P-CSCF may apply resource sharing using local configuration.

If the P-CSCF supports RLOS, the P-CSCF shall accept unprotected requests on the IP address and the unprotected port advertised to the UE during the P-CSCF discovery or the SIP default port. When the P-CSCF sends unprotected responses to the UE, it shall use the same IP address and port where the corresponding request was received.

If the P-CSCF receives an initial request for a dialog or standalone transaction, or an unknown method from an unregistered user on the IP address and the unprotected port advertised to the UE during the P-CSCF discovery or the SIP default port, The P-CSCF shall inspect the Request-URI independent of values of possible entries in the received Route header fields for the presence of the dummy MSISDN or a RLOS service specific dial string. The P-CSCF shall consider the Request URI of the initial request as indicating RLOS, if the Request-URI contains the dummy URI or a RLOS service specific dial string and if the request contains a P-Preferred-Service header field according to RFC 6050 [121] set to "urn:urn-7:3gpp-service.ims.icsi.rlos". If the P-CSCF detects that the initial request for a dialog or a standalone transaction, or an unknown method indicates RLOS, and the P-CSCF has previously stored a temporary unauthenticated subscriber record for the public user identity contained in the From header field of the request:

1. shall include a topmost Route header field set to the URI of the S-CSCF as stored in the unauthenticated subscriber record;
2. shall execute the procedure described in subclause 5.2.6.3.3, subclause 5.2.6.3.7, subclause 5.2.6.3.11 and subclause 5.2.7.2, as appropriate except for:
   • verifying the preloaded route against the received Service-Route header field;
   • routing to IBCF; and
   • inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field;
3. shall insert a P-Asserted-Identity header field set to the public user identity as stored in the unauthenticated subscriber record; and
4. if the P-CSCF detects that the UE is behind a NAT, and the UE's Via header field contains a "keep" header field parameter, shall add a value to the parameter, to indicate that it is willing to receive keep-alives associated with the dialog from the UE, as defined in RFC 6223.

When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute the appropriate procedure for the type of request described in subclause 5.2.6.3.4, subclause 5.2.6.3.8, and subclause 5.2.6.3.12, except that the P-CSCF may rewrite the port number of its own Record-Route entry to an unprotected port where the P-CSCF wants to receive the subsequent incoming requests from the UE belonging to this dialog. When the P-CSCF receives a target refresh request from the UE for a dialog, the P-CSCF shall execute the procedure described in subclause 5.2.6.3.5, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field. When the P-CSCF receives from the UE subsequent requests other than a target refresh request (including requests relating to an existing dialog where the method is unknown), the P-CSCF shall execute the procedure described in subclause 5.2.6.3.9, except for inserting a type 1 "orig-ioi" header field parameter in the P-Charging-Vector header field. When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute the appropriate procedure for the type of request described in subclause 5.2.6.3.5 or subclause 5.2.6.3.9.

The P-CSCF shall follow procedures specified subclause 5.2.6.

A S-CSCF supporting RLOS shall perform the procedures as specified in subclause 5.4.3.2 and in addition shall perform the procedures specified in this subclause. When the S-CSCF receives from the served user from an initial request for a dialog or a request for a standalone transaction and performing the procedures in subclause 5.4.3.2 and:

1. if there is no original dialog identifier that the S-CSCF previously placed in a Route header field is present in the topmost Route header field of the incoming request; and
2. if the Request-URI contains the dummy MSISDN value as defined in TS 23.003 or a RLOS service specific dial string and a P-Preferred-Service header set to "urn:urn-7:3gpp-service.ims.icsi.rlos" is included in the request;
   the S-CSCF shall build an ordered list of initial filter criteria based on the temporary unauthenticated subscriber record for the public user identiy of the served user instead of building the ordered list of initial filter criteria as described in bullet 3).