6 Gq protocol

29.2093GPPPolicy control over Gq interfaceRelease 6TS

6.1 Protocol support

The Diameter Base Protocol as specified in RFC 3588 [6] shall apply except as modified by the defined Gq application specific procedures and AVPs. Unless otherwise specified, the procedures (including error handling and unrecognized information handling) are unmodified.

In addition to the AVPs defined within the clause 6.5, the Diameter AVPs from the Diameter base application (RFC 3588 [6]) are reused within the Diameter messages of the Gq application. The support of AVPs from the Diameter Network Access Server Application (NASREQ) (IETF RFC 4005 [7]) is not required from Diameter implementations that conform to the present document.

Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used in the Gq interface.

The Gq application is defined as an IETF vendor specific Diameter application with application ID 16777222, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.

Due to the definition of the commands used in Gq protocol, there is no possibility to skip the Auth-Application-Id AVP and use the Vendor-Specific-Application-Id AVP instead. Therefore the Gq application identifier shall be included in the Auth-Application-Id AVP.

With regard to the Diameter protocol defined over the Gq interface, the PDF acts as a Diameter server, in the sense that it is the network element that handles authorization requests for a particular realm. The AF acts as the Diameter Client, in the sense that is the network element requesting authorization to use bearer path network resources.

The support of Diameter agents between the PDF and the AF, is optional for the IMS, where the Gq is intra operator i.e. GGSN, PDF and P-CSCF are all in the same network.

6.1.1 Advertising application support

The AF and the PDF shall advertise the support of the Gq specific Application by including the value 16777222 of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities‑Exchange-Request and Capabilities-Exchange-Answer commands as specified in RFC 3588 [4], i.e. as part of the Vendor-Specific-Application-Id AVP. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands are specified in the Diameter Base Protocol.

6.2 Securing Diameter messages

For secure transport of Diameter messages, see 3GPP TS 33.210 [10].

6.3 Gq messages

Existing Diameter command codes from the Diameter base protocol RFC 3588 [6] and the NASREQ Diameter application (IETF RFC 4005 [7]) are used with the Gq specific AVPs. A Gq specific Auth‑Application id is used together with the command code to identify the Gq messages.

NOTE: The notion of NAS (Network Access Server) is not used here, NASREQ is just used for protocol purposes, not for its functional meaning.

6.3.1 AA-Request (AAR) command

The AAR command, indicated by the Command-Code field set to 265 and the ‘R’ bit set in the Command Flags field, is sent by an AF to the PDF in order to request the authorization for the bearer usage for the AF session.

Message Format:

<AA-Request> ::= < Diameter Header: 265, REQ, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

*[ Media-Component-Description ]

*[ Flow-Grouping ]

[ AF-Charging-Identifier ]

[ SIP-Forking-Indication ]

*[ Specific-Action ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

6.3.2 AA-Answer (AAA) command

The AAA command, indicated by the Command-Code field set to 265 and the ‘R’ bit cleared in the Command Flags field, is sent by the PDF to the AF in response to the AAR command.

Message Format:

<AA-Answer> ::= < Diameter Header: 265, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ Authorization-Token ]

*[ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ AVP ]

6.3.3 Re-Auth-Request (RAR) command

The RAR command, indicated by the Command-Code field set to 258 and the ‘R’ bit set in the Command Flags field, is sent by the PDF to the AF in order to indicate a specific action.

As an option, the AF may send an AAR command to the PDF to update the service information when receiving an RAA command. However, application-specific authentication and/or authorization messages are not mandated for the Gq application in response to an RAR command.

The values INDICATION_OF_LOSS_OF_BEARER, INDICATION_OF_RECOVERY_OF_BEARER and INDICATION_OF_RELEASE_OF_BEARER of the Specific-Action AVP shall not be combined with each other in an Re-Auth-Request.

Message Format:

<RA-Request> ::= < Diameter Header: 258, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

*{ Specific-Action }

*[ Access-Network-Charging-Identifier ]

[ Access-Network-Charging-Address ]

*[ Flows ]

[ Abort-Cause ]

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

6.3.4 Re-Auth-Answer (RAA) command

The RAA command, indicated by the Command-Code field set to 258 and the ‘R’ bit cleared in the Command Flags field, is sent by the AF to the PDF in response to the RAR command.

Message Format:

<RA-Answer> ::= < Diameter Header: 258, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

*[ Media-Component-Description ]

*[ Flow-Grouping ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Failed-AVP ]

*[ Proxy-Info ]

*[ AVP ]

6.3.5 Session-Termination-Request (STR) command

The STR command, indicated by the Command-Code field set to 275 and the ‘R’ bit set in the Command Flags field, is sent by the AF to inform the PDF that an authorized session shall be terminated.

Message Format:

<ST-Request> ::= < Diameter Header: 275, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Termination-Cause }

{ Auth-Application-Id }

[ Destination-Host ]

*[ Class ]

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

*[ AVP ]

6.3.6 Session-Termination-Answer (STA) command

The STA command, indicated by the Command-Code field set to 275 and the ‘R’ bit cleared in the Command Flags field, is sent by the PDF to the AF in response to the STR command.

Message Format:

<ST-Answer> ::= < Diameter Header: 275, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Failed-AVP ]

[ Origin-State-Id ]

*[ Redirect-Host ]

[ Redirect-Host-Usage ]

[ Redirect-Max-Cache-Time ]

*[ Proxy-Info ]

[ AVP ]

6.3.7 Abort-Session-Request (ASR) command

The ASR command, indicated by the Command-Code field set to 274 and the ‘R’ bit set in the Command Flags field, is sent by the PDF to inform the AF that all bearer resources for the authorized session have become unavailable.

Message Format:

<AS-Request> ::= < Diameter Header: 274, REQ, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Destination-Host }

{ Auth-Application-Id }

{ Abort-Cause }

[ Origin-State-Id ]

*[ Proxy-Info ]

*[ Route-Record ]

[ AVP ]

6.3.8 Abort-Session-Answer (ASA) command

The ASA command, indicated by the Command-Code field set to 274 and the ‘R’ bit cleared in the Command Flags field, is sent by the AF to the PDF in response to the ASR command.

Message Format:

<AS-Answer> ::= < Diameter Header: 274, PXY >

< Session-Id >

{ Origin-Host }

{ Origin-Realm }

[ Result-Code ]

[ Experimental-Result ]

[ Origin-State-Id ]

[ Error-Message ]

[ Error-Reporting-Host ]

*[ Failed-AVP ]

*[ Redirected-Host ]

[ Redirected-Host-Usage ]

[ Redirected-Max-Cache-Time ]

*[ Proxy-Info ]

*[ AVP ]

6.4 Experimental-Result-Code AVP values

This subclause defines the specific values of the Experimental-Result-Code AVP:

INVALID_SERVICE_INFORMATION (5061)

The service information provided by the AF is invalid or insufficient for the server to perform the requested action.

FILTER_RESTRICTIONS (5062)

The Flow_Description AVP(s) cannot be handled by the server because restrictions defined in clause 6.5.8 are not observed.

6.5 Gq specific AVPs

Table 6.5.1 describes the Diameter AVPs defined for the Gq interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415).

Table 6.5.1: Gq specific Diameter AVPs

AVP Flag rules (note 1)

Attribute Name

AVP Code

Clause defined

Value Type (note 2)

Must

May

Should not

Must not

May Encr.

Abort-Cause

500

6.5.1

Enumerated

M,V

P

Y

Access-Network-Charging-Address

501

6.5.2

Address

M,V

P

Y

Access-Network-Charging-Identifier

502

6.5.3

Grouped

M,V

P

Y

Access-Network-Charging-Identifier-Value

503

6.5.4

OctetString

M,V

P

Y

AF-Application-Identifier

504

6.5.5

OctetString

M,V

P

Y

AF-Charging-Identifier

505

6.5.6

OctetString

M,V

P

Y

Authorization-Token

506

6.5.7

OctetString

M,V

P

Y

Flow-Description

507

6.5.8

IPFilterRule

M,V

P

Y

Flow-Grouping

508

6.5.9

Grouped

M,V

P

Y

Flow-Number

509

6.5.10

Unsigned32

M,V

P

Y

Flows

510

6.5.11

Grouped

M,V

P

Y

Flow-Status

511

6.5.12

Enumerated

M,V

P

Y

Flow-Usage

512

6.5.13

Enumerated

M,V

P

Y

Specific-Action

513

6.5.14

Enumerated

M,V

P

Y

Max-Requested-Bandwidth-DL

515

6.5.16

Unsigned32

M,V

P

Y

Max-Requested-Bandwidth-UL

516

6.5.17

Unsigned32

M,V

P

Y

Media-Component-Description

517

6.5.18

Grouped

M,V

P

Y

Media-Component-Number

518

6.5.19

Unsigned32

M,V

P

Y

Media-Sub-Component AVP

519

6.5.20

Grouped

M,V

P

Y

Media-Type

520

6.5.21

Enumerated

M,V

P

Y

RR-Bandwidth

521

6.5.22

Unsigned32

M,V

P

Y

RS-Bandwidth

522

6.5.23

Unsigned32

M,V

P

Y

SIP-Forking-Indication

523

6.5.24

Enumerated

M,V

P

Y

NOTE 1: The AVP header bit denoted as ‘M’, indicates whether support of the AVP is required. The AVP header bit denoted as ‘V’, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see RFC 3588 [6].

NOTE 2: The value types are defined in RFC 3588 [6].

6.5.1 Abort-Cause AVP

The Session-Abort-Cause AVP (AVP code 500) is of type Enumerated, and determines the cause of a session abort request or of an RAR indicating a PDP context release. The following values are defined:

BEARER_RELEASED (0)

This value is used when the bearer has been deactivated as a result from normal signalling handling. For GPRS the bearer refers to the PDP Context.

INSUFFICIENT_SERVER_RESOURCES (1)

This value is used to indicate that the server is overloaded and needs to abort the session.

INSUFFICIENT_BEARER_RESOURCES (2)

This value is used when the bearer has been deactivated due to insufficient bearer resources at a transport gateway (e.g. GGSN for GPRS).

6.5.2 Access-Network-Charging-Address AVP

The Access-Network-Charging-Address AVP (AVP code 501) is of type Address, and it indicates the IP Address of the network entity within the access network performing charging (e.g. the GGSN IP address). The Access‑Network‑Charging-Address AVP should not be forwarded over an inter-operator interface.

6.5.3 Access-Network-Charging-Identifier AVP

The Access-Network-Charging-Identifier AVP (AVP code 502) is of type Grouped, and contains a charging identifier (e.g. GCID) within the Access-Network-Charging-Identifier-Value AVP along with information about the flows transported within the corresponding bearer within the Flows AVP. If no Flows AVP is provided, the Access‑Network‑Charging-Identifier-Value applies for all flows within the AF session.

The Access-Network-Charging-Identifier AVP can be sent from the PDF to the AF. The AF may use this information for charging correlation with session layer.

AVP Format:

Access-Network-Charging-Identifier ::= < AVP Header: 502 >

{ Access-Network-Charging-Identifier-Value}

*[ Flows ]

6.5.4 Access-Network-Charging-Identifier-Value AVP

The Access-Network-Charging-Identifier-Value AVP (AVP code 503) is of type OctetString, and contains a charging identifier (e.g. GCID).

6.5.5 AF-Application-Identifier AVP

The AF-Application-identifier AVP (AVP code 504) is of type OctetString, and it contains information that identifies the particular service that the AF service session belongs to. This information may be used by the PDF to differentiate QoS for different application services. For example the AF-Application-Identifier may be used as additional information together with the Media-Type AVP when the QoS class for the bearer authorization at the Go interface is selected. The AF-Application-Identifier may be used also to complete the QoS authorization with application specific default settings in the PDF if the AF does not provide full Session-Component-Description information.

6.5.6 AF-Charging-Identifier AVP

The AF-Charging-Identifier AVP (AVP code 505) is of type OctetString, contains the AF Charging Identifier that is sent by the AF. This information may be used for charging correlation with bearer layer.

6.5.7 Authorization-Token AVP

The Authorization-Token AVP (AVP code 506) is of type OctetString, and contains the Authorization Token defined in the RFC 3520 [9].

6.5.8 Flow-Description AVP

The Flow-Description AVP (AVP code 507) is of type IPFilterRule, and defines a packet filter for an IP flow with the following information:

– Direction (in or out).

– Source and destination IP address (possibly masked).

– Protocol.

– Source and destination port (The source port may be omitted to indicate that any source port is allowed).

The IPFilterRule type shall be used with the following restrictions:

– Only the Action "permit" shall be used.

– No "options" shall be used.

– The invert modifier "!" for addresses shall not be used.

– The keyword "assigned" shall not be used.

– The destination port(s) shall be supplied for the Rx and Gq interfaces. Similarly, for the Rx and Gq interfaces source ports shall be supplied if available. For the Gq interface, lists or ranges shall not be used for source and destination ports. For the Rx interface, lists or ranges may be used as specified in IETF RFC 3588 [6]. However, it is recommended that omission, lists or ranges of ports are either not used or only used to describe a small number of ports.

NOTE: For the Rx interface, using list or ranges of ports can be done in specific scenarios, e.g. when the UE contacts a server using several ports where a server may be listening to.

NOTE: For Gq and Rx interfaces, not specifying explicitly the ports (source or destination) in any of the fields or the Flow Description AVP may lead to the following problems:
+ If omission, lists or ranges of ports are used in service information, a CRF/PDF may obtain service information with overlapping filters relating to different AFs or different service data flows within one AF and may therefore not be able to supply charging rules/policy information that unambiguosly identify service data flows of those applications.
+ As the Flow Description AVP is intended to be used to define a flow identifier for a single IP flow, other Gq/Rx functionality that makes use of this flow identifier may be negatively impacted if the Flow-Description contains omission, lists or ranges of ports and thus may match multiple IP flows, e.g. the indication of bearer events and the flow grouping description within the service information.

If any of these restrictions is not observed by the AF, the server shall send an error response to the AF containing the Experimental-Result-Code AVP with value FILTER_RESTRICTIONS.

For the Gq interface, the Flow description AVP shall be used to describe a single IP flow.

The direction "in" refers to uplink IP flows, and the direction "out" refers to downlink IP flows.

6.5.9 Flow-Grouping AVP

The Flow-Grouping AVP (AVP code 508) is of type Grouped, and it indicates that no other IP Flows shall be transported together with the listed IP Flows in the same PDP context(s).

If Flow-Grouping AVP(s) have been provided in earlier service information, but are not provided in subsequent service information, the old flow grouping remains valid.

If Flow-Grouping AVP(s) have been provided in earlier service information, and new Flow-Grouping AVP(s) are provided, the new flow grouping information replaces the previous information. Previous flow grouping information is invalidated even if the new Flow-Grouping AVP(s) affect other IP flows.

A Flow-Grouping AVP containing no Flows AVP may be used to invalidate flow grouping information provided in earlier service information. A Flow-Grouping AVP containing no Flows AVP shall not be supplied together with other Flow-Grouping AVP(s).

If earlier service information has already been provided, flow grouping information in subsequent service information shall not restrict the flow grouping further for IP flows already described in the previous service information. However, new IP flows described for the first time in the subsequent service information may be added to existing flow groups or in new flow groups.

AVP Format:

Flow-Grouping ::= < AVP Header: 508 >

*[Flows]

6.5.10 Flow-Number AVP

The Flow-Number AVP (AVP code 509) is of type Unsigned32, and it contains the ordinal number of the IP flow(s), assigned according to the rules in annex C of 3GPP TS 29.207 [4].

6.5.11 Flows AVP

The Flows AVP (AVP code 510) is of type Grouped, and it indicates IP flows via their flow identifiers.

If no Flow-Number AVP(s) are supplied, the Flows AVP refers to all Flows matching the media component number.

AVP Format:

Flows::= < AVP Header: x >

{ Media-Component-Number}

*[ Flow-Number]

6.5.12 Flow-Status AVP

The Flow-Status AVP (AVP code 511) is of type Enumerated, and describes whether the IP flow(s) are enabled or disabled. The following values are defined:

ENABLED-UPLINK (0)

This value shall be used to enable associated uplink IP flow(s) and to disable associated downlink IP flow(s). If any downlink RTCP IP flow(s) are identified by the Flow_Usage AVP(s), those flow(s) shall be enabled.

ENABLED-DOWNLINK (1)

This value shall be used to enable associated downlink IP flow(s) and to disable associated uplink IP flow(s). If any uplink RTCP IP flow(s) are identified by the Flow_Usage AVP(s), those flow(s) shall be enabled.

ENABLED (2)

This value shall be used to enable all associated IP flow(s) in both directions.

DISABLED (3)

This value shall be used to disable all associated IP flow(s) in both directions. If any RTCP IP flow(s) are identified by the Flow_Usage AVP(s), those flow(s) shall be enabled.

REMOVED (4)

This value shall be used to remove all associated IP flow(s). The IP Filters for the associated IP flow(s) shall be removed. The associated IP flows shall not be taken into account when deriving the authorized QoS.

6.5.13 Flow-Usage AVP

The Flow-Usage AVP (AVP code 512) is of type Enumerated, and provides information about the usage of IP Flows. The following values are defined:

NO_INFORMATION (0)

This value is used to indicate that no information about the usage of the IP flow is being provided

RTCP (1)

This value is used to indicate that an IP flow is used to transport RTCP.

NO_INFORMATION is the default value.

NOTE: An AF may choose not to identify RTCP flows, e.g. in order to avoid that RTCP flows are always enabled by theserver.

6.5.14 Specific-Action AVP

The Specific-Action AVP (AVP code 513) is of type Enumerated.

Within a PDF initiated Re-Authorization Request, the Specific-Action AVP determines the type of the action.

Within an initial AA request the AF may use the Specific-Action AVP to request specific actions from the server at the bearer events and to limit the contact to such bearer events where specific action is required. If the Specific-Action AVP is omitted within the initial AA request, no notification of any of the events defined below is requested.

The following values are defined:

SERVICE_INFORMATION_REQUEST (0)

Within a RAR, this value shall be used when the server requests the service information from the AF for the bearer event. In the AAR, this value indicates that the AF requests the server to demand service information at each bearer authorization.

CHARGING_CORRELATION_EXCHANGE (1)

Within a RAR, this value shall be used when the server reports the access network charging identifier to the AF. The Access-Network-Charging-Identifier AVP shall be included within the request. In the AAR, this value indicates that the AF requests the server to provide an access network charging identifier to the AF at each bearerestablishment/modification, when a new access network charging identifier becomes available.

INDICATION_OF_LOSS_OF_BEARER (2)

Within a RAR, this value shall be used when the server reports a loss of a bearer (e.g. in the case of GPRS PDP context bandwidth modification to 0 kbit) to the AF. In the AAR, this value indicates that the AF requests the server to provide a notification at the loss of a bearer.

INDICATION_OF_RECOVERY_OF_BEARER (3)

Within a RAR, this value shall be used when the server reports a recovery of a bearer (e.g. in the case of GPRS, PDP context bandwidth modification from 0 kbit to another value) to the AF. In the AAR, this value indicates that the AF requests the server to provide a notification at the recovery of a bearer.

INDICATION_OF_RELEASE_OF_BEARER (4)

Within a RAR, this value shall be used when the server reports the release of a bearer (e.g. PDP context removal for GPRS) to the AF. In the AAR, this value indicates that the AF requests the server to provide a notification at the removal of a bearer.

INDICATION_OF_ESTABLISHMENT_OF_BEARER (5)

Within a RAR, this value shall be used when the server reports the establishment of a bearer (e.g., PDP context activation for GPRS) to the AF. In the AAR, this value indicates that the AF requests the server to provide a notification at the establishment of a bearer. This value is not used by the Gq Protocol.

6.5.15 Void

6.5.16 Max-Requested-Bandwidth-DL AVP

The Max-Requested-Bandwidth-DL AVP (AVP code 515) is of type Unsigned32, and it indicates the maximum requested bandwidth in bits per second for a downlink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

6.5.17 Max-Requested-Bandwidth-UL AVP

The Max -Bandwidth-UL AVP (AVP code 516) is of type Unsigned32, and it indicates the maximum requested bandwidth in bits per second for an uplink IP flow. The bandwidth contains all the overhead coming from the IP-layer and the layers above, e.g. IP, UDP, RTP and RTP payload.

6.5.18 Media-Component-Description AVP

The Media-Component-Description AVP (AVP code 517) is of type Grouped, and it contains service information for a single media component within an AF session. It may be based on the SDI exchanged between the AF and the AF client in the UE. The information may be used by the server to determine authorized QoS and IP flow classifiers for bearer authorization and charging rule selection.

Within one Diameter message, a single IP flow shall not be described by more than one Media-Component-Description AVP.

Bandwidth information and Flow-Status information provided within the Media-Component-Description AVP applies to all those IP flows within the media component, for which no corresponding information is being provided within Media-Sub-Component AVP(s).

If a Media-Component-Description AVP is not supplied, or if optional AVP(s) within a Media-Component-Description AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid.

All IP flows within a Media-Component-Description AVP are permanently disabled by supplying a Flow Status AVP with value "REMOVED". The server may delete corresponding filters and state information.

AVP format:

Media-Component-Description ::= < AVP Header: 517 >

{ Media-Component-Number } ; Ordinal number of the media comp.

*[ Media-Sub-Component ] ; Set of flows for one flow identifier

[ AF-Application-Identifier ]

[ Media-Type ]

[ Max-Requested-Bandwidth-UL ]

[ Max-Requested-Bandwidth-DL ]

[ Flow-Status ]

[ RS-Bandwidth ]

[ RR-Bandwidth ]

6.5.19 Media-Component-Number AVP

The Media-Component-Number AVP (AVP code 518) is of type Unsigned32, and it contains the ordinal number of the media component, assigned according to the rules in annex C of 3GPP TS 29.207 [4].

6.5.20 Media-Sub-Component AVP

The Media-Sub-Component AVP (AVP code 519) is of type Grouped, and it contains the requested QoS and filters for the set of IP flows identified by their common Flow-Identifier. The Flow-Identifier is defined in 3GPP TS 29.207 [4].

Possible Bandwidth information and Flow-Status information provided within the Media-Sub-Component AVP takes precedence over information within the encapsulating Media Component Description AVP. If a Media-Sub-Component- AVP is not supplied, or if optional AVP(s) within a Media-Sub-Component AVP are omitted, but corresponding information has been provided in previous Diameter messages, the previous information for the corresponding IP flow(s) remains valid, unless new information is provided within the encapsulating Media-Component-Description AVP. If Flow-Description AVP(s) are supplied, they replace all previous Flow-Description AVP(s), even if a new Flow-Description AVP has the opposite direction as the previous Flow-Description AVP.

All IP flows within a Media-Sub-Component- AVP are permanently disabled by supplying a Flow Status AVP with value "REMOVED". The server may delete corresponding filters and state information.

AVP format:

Media-Sub-Component ::= < AVP Header: 519 >

{ Flow-Number } ; Ordinal number of the IP flow

0*2[ Flow-Description ] ; UL and/or DL

[ Flow-Status ]

[ Flow-Usage ]

[ Max-Requested-Bandwidth-UL ]

[ Max-Requested-Bandwidth-DL ]

6.5.21 Media-Type AVP

The Media-Type AVP (AVP code 520) is of type Enumerated, and it determines the media type of a session component. The media types indicate the type of media in the same way as the SDP media types with the same names defined in IETF RFC 4566 [12]. The following values are defined:

AUDIO (0)

VIDEO (1)

DATA (2)

APPLICATION (3)

CONTROL (4)

TEXT (5)

MESSAGE (6)

OTHER (0xFFFFFFFF)

6.5.22 RR-Bandwidth AVP

The RR-Bandwidth AVP (AVP code 521) is of type Unsigned32, and it indicates the maximum required bandwidth in bits per second for RTCP receiver reports within the session component, as specified in RFC 3556 [11]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

6.5.23 RS-Bandwidth AVP

The RS-Bandwidth AVP (AVP code 522) is of type Unsigned32, and it indicates the maximum required bandwidth in bits per second for RTCP sender reports within the session component, as specified in RFC 3556 [11]. The bandwidth contains all the overhead coming from the IP-layer and the layers above, i.e. IP, UDP and RTCP.

6.5.24 SIP-Forking-Indication AVP

The SIP_Forking AVP (AVP code 523) is of type Enumerated, and describes if several SIP dialogues are related to one Diameter session.:

SINGLE_DIALOGUE (0)

This value is used to indicate that the Diameter session relates to a single SIP dialogue.
This is the default value applicable if the AVP is omitted.

SEVERAL_DIALOGUES (1)

This value is used to indicate that the Diameter session relates to several SIP dialogues.

Annex A (normative):
Support for SIP forking