29.2093GPPPolicy control over Gq interfaceRelease 6TS

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

A.1.1 Authorization of resources 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. The P-CSCF shall apply the same authorization token to all the forked responses and the corresponding early dialogues.

The UE and the P-CSCF become aware of the forking only when the second provisional response arrives. For this, and any subsequent provisional response, 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 PDF shall identify the existing authorization information for that Diameter session. The PDF shall authorize any additional media components and any increased QoS requirements for the previously authorized media components, as requested within the service information. The PDF 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 PDF shall also send additional packet classifiers as required by the Flow Description AVPs within the session information to the GGSN. The PDF shall enable or disable the packet classifiers (i.e. open or close the gates) for the packet classifiers depending on the flow status that is being provisioned. However, if a flow ID has been enabled in uplink or downlink direction or bothway within previous service information, it shall remain enabled even if the PDF receives service information that disable this flow ID within an AA request containing the SIP-Forking-Indication AVP with value SEVERAL_DIALOGUES.

A.1.2 Updating the authorization information 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 authorization 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 PDF shall update authorization information and packet classifiers to match only the requirements of the service information within this AA request. The PDF shall also enable or disable the packet classifiers according to the flow status in the received service information.

Annex B (informative):
Change history