A.3 Support for SIP forking

29.2143GPPPolicy and charging control over Rx reference pointRelease 17TS

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

A.3.0 General

The P-CSCF shall be able to handle forking when PCC is applied. Forking can occur as specified in 3GPP TS 23.228 [16]. The related UE procedures are described in 3GPP TS 24.229 [17].

A.3.1 PCC rule provisioning for early media for forked responses

When a SIP session has been originated by a connected UE, the P-CSCF may receive multiple provisional responses due to forking before the first final answer is received. Multiple early media session may be established during this process.

The UE and the P-CSCF become aware of the forking only when a subsequent provisional response arrives for a new early dialogue. After the first early media session is established, for each subsequent provisional response establishing an additional early media session,, the P-CSCF shall use an AA request within the existing Diameter session containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES and include the service information derived from the latest provisional response.

The P-CSCF shall also provision the service information derived from any subsequent SDP offer-answer exchange within an early dialogue (e.g. in PRACK and OK(PRACK), or UPDATE and OK(UPDATE) ) using an AA request within the existing Diameter session containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES and the derived service information.

When receiving an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES, the PCRF shall identify the existing authorization information for that AF session. The PCRF shall send additional PCC Rules or individual service data flow filters to already provide PCC rules as required by the Flow Description AVPs within the session information to the PCEF. The PCRF shall authorize any additional media components and any increased QoS requirements for the previously authorized media components, as requested within the service information. The PCRF shall authorize the maximum bandwidth required by any of the dialogues, but not the sum of the bandwidths required by all dialogues. Thus, the QoS authorized for a media component is equal to the highest QoS requested for that media component by any of the forked responses. The PCRF shall open or close the gates for service flows depending on the flow status that is being provisioned. However, if a flow ID has been enabled in uplink or downlink direction or both way within previous service information, it shall remain enabled even if the PCRF receives service information that disable this flow ID within an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES.

If the P-CSCF provides one or more Media-Component-Description AVP with the Flow-Status AVP set to "REMOVED" for previously authorized media component(s) the media component shall remain as authorized and the PCRF shall not take any action on that media component(s).

NOTE: There can be cases where a forked response could not support some of the media components included in the SDP Offer (e.g. when early session disposition SDP as described in Annex A.7 applies, the forked response related to the early session could include the port set to zero for those media components not related to the early session or when a subsequent SDP Offer-Answer to indicate that some media is disabled). For those cases the P-CSCF will indicate the PCRF about the removal of the corresponding media component. However this media component is already supported by other UEs and the PCRF needs to maintain the corresponding PCC rules until the final SDP answer is received in the P-CSCF in order to avoid the release of resources in the network.

A.3.2 Updating the provisioned PCC rules at the final answer

The P-CSCF shall store the SDP information for each early dialogue separately till the first final SIP answer is received. Then the related early dialogue is progressed to an established dialogue to establish the final SIP session. All the other early dialogues are terminated. The service information for the SIP session is updated to match the requirements of the remaining early dialogue only.

When receiving the first final SIP response, the P-CSCF shall send an AA request without the SIP-Forking-Indication AVP and include the service information derived from the SDP corresponding to the dialogue of the final response. The P-CSCF shall provision the full service information including the applicable Flow-Description AVP(s) and Flow-Status AVP(s).

When receiving an AA request with no SIP-Forking-Indication AVP or with a SIP-Forking-Indication AVP with value SINGLE_DIALOGUE, the PCRF shall update installed PCC Rules information and Authorized-QoS information to match only the requirements of the service information within this AA request. The PCRF should immediately remove PCC Rule(s) or individual service data flow filters not matching IP flow(s) in the updated Service Information, to reduce the risk for initial clipping of the media stream, and to minimize possible misuse of resources. The PCRF shall also open or close the gates for service flows according to the flow status in the received service information.