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