A.1 Support for SIP forking

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

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

2004-09

25

NP-040421

Approved at CN Plenary and placed under change control

2.0.2

6.0.0

2004-12

26

NP-040586

001

1

Gmb. New AVP to indicate Multicast or Broadcast service

6.0.0

6.1.0

2004-12

26

NP-040586

002

1

Gmb. Table with reused AVPs

6.0.0

6.1.0

2004-12

26

NP-040586

003

1

Gmb. Correction to the Result-Code AVP

6.0.0

6.1.0

2004-12

26

NP-040586

009

1

Gmb. Correction to the Result-Code AVP

6.0.0

6.1.0

2004-12

26

NP-040586

008

3

Gmb. Update of AVPs codes and permanent failures codes.

6.0.0

6.1.0

2004-12

26

NP-040586

010

Gmb. Serving Network identity

6.0.0

6.1.0

2005-03

27

NP-050106

011

Correction to Specific-Action AVP terminology

6.1.0

6.2.0

2005-03

27

NP-050106

012

3

Clarification on charging identifier(s) exchange

6.1.0

6.2.0

2005-03

27

NP-050114

013

3

Specific Action AVP update

6.1.0

6.2.0

2005-06

28

CP-050244

014

3

Various Corrections

6.2.0

6.3.0

2005-06

28

CP-050244

015

Correction to missing AVP code values

6.2.0

6.3.0

2005-06

28

CP-050244

016

Correction of references

6.2.0

6.3.0

2005-06

28

CP-050225

017

3

Gq Auth-Application-Id AVP use

6.2.0

6.3.0

2005-09

29

CP-050384

018

1

Missing description of behaviour when AAA is not received

6.3.0

6.4.0

2005-09

29

CP-050378

019

NASREQ Reference update

6.3.0

6.4.0

2005-09

29

CP-050378

020

1

Procedural Corrections

6.3.0

6.4.0

2005-09

29

CP-050378

023

1

Auth-Application-ID required in STR

6.3.0

6.4.0

2006-06

32

CP-060222

025

2

Port Usage in Flow Description AVP

6.4.0

6.5.0

2006-09

33

CP-060427

027

3

Rx Port Usage in Flow Description AVP

6.5.0

6.6.0

2007-06

36

CP-070417

029

1

Handling of disabled flows for forking

6.6.0

6.7.0

2011-09

53

CP-110601

030

Updated of reference to RFC 4566

6.7.0

6.8.0