A.1 Provision of Service Information at P-CSCF

29.2143GPPPolicy and charging control over Rx reference pointRelease 17TS

The P-CSCF shall send service information to the PCRF upon every SIP message that includes an SDP answer payload for the purpose of authorizing the IP flows and the QoS resources required for a negotiated IMS session, unless the SDP payload only relates to a circuit-switched bearer (i.e. "c=" line set to "PSTN" and an "m=" line set to "PSTN", refer to 3GPP TS 24.292 [26]). The service information shall be derived both from the SDP offer and the SDP answer. This ensures that the PCRF receives proper information to perform media authorization for all possible IMS session set-up scenarios, and that the PCRF is also capable of handling session modifications. The P-CSCF may include the Service-Info-Status AVP with the value set to FINAL_SERVICE_INFORMATION.

Additionally, the P-CSCF may send service information to the PCRF when receiving a SIP message that includes an SDP offer payload for the purpose of performing an early bandwidth authorization check, or for enabling pre-authorization for a UE terminated IMS session establishment or modification with UE initiated resource reservation, or for the retrieval of network provided access network information (see clause A.10.2). The P-CSCF shall send service information to the PCRF when receiving a SIP message that includes an SDP offer payload when the IMS session is an MPS session that requires priority treatment. For a UE terminated session the P-CSCF may send the service information derived from the SDP offer when the SDP offer either does not include any preconditions information or includes preconditions information indicating that the local preconditions (i.e. the preconditions related to the remote peer) are already met. In this case, the P-CSCF shall derive the service information only from the SDP offer and shall include the Service-Info-Status AVP with the value set to PRELIMINARY SERVICE INFORMATION.

NOTE 1: For a UE terminated session setup, when the SDP offer either does not include any preconditions information or includes preconditions information indicating that the local preconditions (i.e. the preconditions related to the remote peer) are already met, the terminating UE can request a resource modification prior to sending the SDP answer. Even if the IP address and port information in the session information derived from the SDP offer can be insufficient for PCC rule authorization, the policy to handle such UE initiated requests at the PCRF can take into account the fact that an IMS session establishment is ongoing, for instance in deciding whether to authorize the request and in selecting an appropriate charging key and a gating policy.

The P-CSCF shall derive Flow-Description AVP within the service information from the SDP as follows:

– An uplink Flow-Description AVP shall be formed as follows: The destination address shall be taken from the SDP information received by the P-CSCF in downlink direction, while the source IP address may be formed from the address present in the SDP received by the P-CSCF in uplink direction (taking into account only the 64 bit prefix of the Ipv6 address) Source and destination ports shall be derived according to rules provided in 3GPP TS 29.213 [9] clause 6.2.

EXAMPLE 1: Assuming UE A sends an SDP to UE B, the PCRF of UE B uses the address present in this SDP for the destination address of UE B’s uplink Flow-Description AVP, while the PCRF of the UE A uses the 64 bit prefix of the same address for the source address of UE A’s uplink Flow‑Description AVP. If the source address is not formed from the 64 bit prefix, the source address shall be wildcarded.

– A downlink Flow-Description AVP shall be formed as follows: The destination address shall be taken from the SDP information received by the P-CSCF in uplink direction, while the source IP address may be formed (in order to reduce the possibilities of bearer misuse) from the destination address in the SDP received by the P-CSCF in downlink direction (taking into account only the 64 bit prefix of the Ipv6 address) Source and destination ports shall be derived according to rules provided in 3GPP TS 29.213 [9] clause 6.2.

EXAMPLE 2: Assuming UE A sends an SDP to UE B, the PCRF of UE A uses the address present in this SDP for the destination address of UE A’s downlink Flow-Description AVP, while the PCRF of UE B uses the 64 bit prefix of the same address for the source address of UE B’s downlink Flow‑Description AVP. If the source address is not formed from the 64 bit prefix, the source address shall be wildcarded.

The P-CSCF shall derive the bandwidth information within the service information, from the "b=AS" SDP parameter and "a=bw-info" SDP parameter, if available and if the E2EMTSIQOS feature is supported. If "a=bw-info" is used for bandwidth derivation, the P-CSCF shall use the SDP attribute line that contains the bandwidth properties for the IP version used by the UE, as detailed in 3GPP TS 29.213 [9] clause 6.2. If the received "a=bw-info" SDP attribute line(s) contain only bandwidth properties for an IP version that is not used by the UE, the P-CSCF shall re-compute the bandwidth properties for the used IP version and use that value for the bandwidth derivation as defined in 3GPP TS 26.114 [41].

NOTE 2: If no IP version is included for any of the "a=bw-info" SDP attribute lines related to a certain payload type and direction then IPv6 is assumed for all bandwidth properties related to the same direction and payload type, on all of the related "a=bw-info" SDP attribute lines, see clause 19 of 3GPP TS 26.114 [41].

If "a=bw-info" is used for bandwidth derivation and it includes both known and unknown bandwidth properties, the P-CSCF shall only consider the known bandwidth properties to derive the bandwidth information and ignore the unknown ones. If the" a=bw-info" line is received with an unknown directionality, then the entire "a=bw-info" line shall be ignored.

For the possibly associated RTCP IP flows, the P-CSCF shall use the SDP "b=RR" and "b=RS" parameters, if present, as specified in 3GPP TS 29.213 [9] clause 6.2. The "b=AS", "b=RR" and "b=RS" parameters in the SDP contain all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTCP payload, or IP, UDP and RTCP.

For multiplexed RTP/RTCP flows (as negotiated using the"a=rtcp-mux" SDP attribute defined in IETF RFC 5761 [42], a P-CSCF supporting RTP/RTCP transport multiplexing shall derive the bandwidth information within the service information as specified in 3GPP TS 29.213 [9] clause 6.2.

However, if service information is received containing the "b=TIAS" SDP parameter that corresponds to an SDP answer payload, and if the P-CSCF supports this parameter, the P-CSCF may derive the bandwidth from this parameter rather than from the "b=AS" SDP parameter, as detailed in 3GPP TS 29.213 [9] clause 6.2.

When available, the P-CSCF shall also indicate to PCRF, as a complement to the Service Information, the IMS Communication Service Identifier within the AF-Application-Identifier AVP. The originating P-CSCF shall take the IMS Communication Service Identifier value from the SIP response. The terminating P-CSCF shall take the IMS Communication Service Identifier value from the SIP request. Otherwise, the P-CSCF may not be able to provide an IMS Communication Service Identifier value to the PCRF. The format and specific headers where IMS communication service identifiers are transported within SIP are defined in 3GPP TS 24.229 [17].

NOTE 3: In order to indicate the IMS Communication Service Identifier to the PCRF, the originating P-CSCF sets the AF-Application-Identifier AVP to the ICSI contained in the topmost occurance of the "+g.3gpp.icsi-ref" header field parameter of the Feature-Caps header field(s) of 18x or 2xx SIP response (Feature-Caps: *;+g.3gpp.icsi-ref=”urn%Aurn-7%A3gpp-service.ims.icsi.mmtel”) and the terminating P-CSCF sets the AF-Application-Identifier AVP to the ICSI of the P-Asserted-Service header information received in the SIP request (e.g. P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel). Since the headers and the format of the ICSI can vary depending on the case, the PCRF has to be prepared to accept the complete ICSI information received in different formats, as described in clause 7.2A.8.2 in 3GPP TS 24.229 [17].

Additionally, the P-CSCF may include the Sharing-Key-DL AVP and/or Sharing-Key-UL AVP within the Media-Component-Description AVP in order to indicate the PCRF that resource sharing should apply for the media components in the related direction with the same value for the Sharing-Key-DL AVP and/or Sharing-Key-UL AVP.

Additionally, if PrioritySharing feature is supported, the P-CSCF may provide the Priority-Sharing-Indicator AVP within the Media-Component-Description AVP as described in clause 4.4.47.

NOTE 4: The P-CSCF obtains this information from the Application Server as described in 3GPP TS 23.228 [16], clause 5.4.7.9.

NOTE 5: RTCP flows are not subject to resource sharing. This requirement cannot be met for multiplexed RTP/RTCP flows as in this case there is no mechanism in the current release to distinguish between RTP and RTCP flows.

If the Service-URN AVP does not include an emergency service URN, i.e. a top-level service type of "sos" as specified in IETF RFC 5031 [21] and possibly additional sub-service information on the type of the emergency service and the PCRF binds the IMS service session to an IP-CAN session established to an Emergency APN, the PCRF shall return an AAA command with Experimental-Result-Code AVP set to the value UNAUTHORIZED_NON_EMERGENCY_SESSION to the P-CSCF. Upon receiving an AAA with Experimental-Result-Code AVP set to the value UNAUTHORIZED_NON_EMERGENCY_SESSION the P-CSCF shall apply the procedures defined in 3GPP TS 24.229 [17].

NOTE 6: The PCRF determines whether an IP-CAN session is established to an Emergency APN based on the information received over Gx and operator configuration.

If the AF-Requested-Data AVP is provided in the AA-Request command indicating "EPC-level Identities required", the PCRF shall provide the available user information for the IP-CAN session within the Subscription-Id AVP (s) and/or User-Equipment-Info AVP or User-Equipment-Info-Extension AVP if the User-Equipment-Info-Extension feature is supported.

The PCRF may decide not to authorize requested service information. The PCRF will indicate it to the P-CSCF by sending an AA-Answer with Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED. Upon receiving an AA-Answer with Experimental-Result-Code AVP set to the value REQUESTED_SERVICE_NOT_AUTHORIZED the P-CSCF shall apply the procedures defined in 3GPP TS 24.229 [17].