B.3 Support for SIP forking

29.5143GPP5G SystemPolicy Authorization ServiceRelease 18Stage 3TS

B.3.0 General

The P-CSCF shall be able to handle forking when PCC is applied and the "IMS_SBI" feature is supported. Forking can occur as specified in 3GPP TS 23.228 [33]. The related UE procedures are described in 3GPP TS 24.229 [32].

B.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 Npcf_PolicyAuthorization_Update service operation containing the "sipForkInd" attribute 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 Npcf_PolicyAuthorization_Update service operation containing the "sipForkInd" attribute with value "SEVERAL_DIALOGUES" and the derived service information.

When receiving an Npcf_PolicyAuthorization_Update service operation containing the "sipForkInd" attribute with value "SEVERAL_DIALOGUES", the PCF shall identify the existing "Individual Application Session Context" resource with existing authorization information.

The PCF shall send additional PCC Rules or individual service data flow filters to already provided PCC rules as required by the "fDescs" attribute within the AF session context information to the SMF. The PCF shall authorize any additional media components and any increased QoS requirements for the previously authorized media components, as requested within the service information.

The PCF 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 PCF 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 PCF receives service information that disable this flow ID within an Npcf_PolicyAuthorization_Update service operation containing the "sipForkInd" attribute with value "SEVERAL_DIALOGUES".

If the P-CSCF provides one or more media components within the "medComponents" attribute with the "fStatus" attribute set to "REMOVED" for previously authorized media component(s) the media component shall remain as authorized and the PCF 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 B.6 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 PCF about the removal of the corresponding media component. However this media component is already supported by other UEs and the PCF 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.

B.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 Npcf_PolicyAuthorization_Update service operation setting to null the "sipForkInd" attribute and shall 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 "fDescs" attribute and "fStatus" attribute.

When receiving an Npcf_PolicyAuthorization_Update service operation with a "sipForkInd" attribute with value "SINGLE_DIALOGUE", the PCF shall update installed PCC Rules information and Authorized-QoS information to match only the requirements of the service information within this Npcf_PolicyAuthorization_Update service operation. The PCF 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 PCF shall also open or close the gates for service flows according to the flow status in the received service information.