The AVPs used by Sentinel IPSMGW in the credit control request are described.

Sentinel IPSMGW Service population of Credit Control Request

The Credit Control Request message is defined according to IETF RFC 4006, and some AVPs are removed and not used according to 3GPP TS 32.299. Sentinel products use the definition in 3GPP TS 32.299 v12.11.0 for CCR.

This table indicates the top-level AVPs inside a CCR request and how the Sentinel SIP service populates them.

AVP Name Specification reference Included in CDR Included in CCR Comments

Service-Context-Id

IETF RFC 4006 and refined by 3GPP TS 32.299 v12.11.0 section 7.1.12

Yes

Yes

For IP-SM-GW the value is set to 12.32274@3gpp.org.

Session-Id

IETF RFC 4006

Yes

Yes

The Session-Id optional part is set to the Call-ID of the initial request for the Session

Origin-Host

IETF RFC 4006

No

Yes

Resource Adaptor entity configuration defines the value to be used for this AVP

Origin-Realm

IETF RFC 4006

No

Yes

Resource Adaptor entity configuration defines the value to be used for this AVP

Destination-Realm

IETF RFC 4006

No

Yes

This is set in Sentinel configuration, when selecting an OCS to use for the Session

Auth-Application-Id

IETF RFC 4006

No

Yes

Set to the value 4L ## in volte documentation

Service-Context-Id

IETF RFC 4006

Yes

Yes

CC-Request-Type

IETF RFC 4006

No

Yes

CC-Request-Number

IETF RFC 4006

No

Yes

Destination-Host

IETF RFC 4006

No

No

Origin-State-Id

IETF RFC 4006

No

No

Event-Timestamp

IETF RFC 4006

No

Yes

Subscription-Id

IETF RFC 4006

Yes

Yes

Set to the Served User, either as a SIP URI or Tel URI. This is populated via the SIP Subscriber Determination Feature.

Termination-Cause

IETF RFC 3588

No

No

Requested-Action

IETF RFC 4006

No

Yes

AoC-Request-Type

IETF RFC 4006

No

No

Multiple-Services-Indicator

IETF RFC 4006

No

Yes

Set to 1 multiple services supported

Multiple-Services-Credit-Control

IETF RFC 4006

Yes

Yes

In the case of AVP CDRs, if Ro charging is used then MSCC AVPs from the most recent CCA are written to the CDR. In the case of Ro charging the CCR’s MSCC AVP includes Populated AVPs in the Multiple-Services-Credit-Control AVP

CC-Correlation-Id

IETF RFC 4006

No

No

User-Equipment-Info

IETF RFC 4006

Yes

Yes

The IMEI is used rather than the IMEISV, and the User-Equipment-Type AVP is set to IMEISV.

Proxy-Info

IETF RFC 4006

No

No

Route-Record

IETF RFC 4006

No

No

Service-Information

3GPP TS 32.299

No

Yes

Refer to Populated AVPs in the Service-Information AVP ## in volte documentation

User-Name

IETF RFC 6733

Yes

Yes

This contains the Private Id from registration data

The BNF for the CCR message according to 32.299 v12.11.0 is

<CCR> ::= < Diameter Header: 272, REQ, PXY >

    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Auth-Application-Id }
    { Service-Context-Id }
    { CC-Request-Type }
    { CC-Request-Number }
    [ Destination-Host ]
    [ User-Name ]
    [ CC-Sub-Session-Id ]      // not used in 3GPP
    [ Acct-Multi-Session-Id ]  // not used in 3GPP
    [ Origin-State-Id ]
    [ Event-Timestamp ]
   *[ Subscription-Id ]
    [ Service-Identifier ]     // not used in 3GPP
    [ Termination-Cause ]
    [ Requested-Service-Unit ] // not used in 3GPP
    [ Requested-Action ]
   *[ Used-Service-Unit ]      // not used in 3GPP
    [ AoC-Request-Type ]
    [ Multiple-Services-Indicator ]
   *[ Multiple-Services-Credit-Control ]
   *[ Service-Parameter-Info ] // not used in 3GPP
    [ CC-Correlation-Id ]
    [ User-Equipment-Info ]
   *[ Proxy-Info ]
   *[ Route-Record ]
    [ Service-Information ]
   *[ AVP ]
Previous page Next page
Sentinel IP-SM-GW Version 3.0.0