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 |
|