 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi,
Would appreciate some advice for a newbie in this area regarding chapter 7.1.5 (draft-ietf-dime-rfc3588bis-03.tx)
http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-03#page-94
.....'In error conditions where it is not possible or efficient to compose application specific answer grammar
then answer messages with E-bit set and complying to the grammar described in 7.2 MAY also be used
for permanent errors.
To provide backward compatibility with existing implementations that follow [RFC3588],
some of the error values that have previously been used in this category by [RFC3588] will not be re-used.
Therefore the error values enumerated here maybe non-sequential.'
Does this mean that using the E-bit is applicable only for future error-codes to come or also for existing ones?
Reason for asking is we would like to avoid the dummy values in the following scenario and instead use E-bit described in chapter 7.2 (draft-ietf-dime-rfc3588bis-03.tx)
If a CCR is received in the DCC server where one or several of the mandatory AVPs Auth-Application-Id, CC-Request-Type and CC-Request-Number are missing;
In the CCA, Auth-Application-Id, CC-Request-Type and CC-Request-Number are filled with 'dummyvalues' and the the Failed-AVP AVP is included and filled with Auth-Application-Id, CC-Request-Type and CC-Request-Number where these AVPs are set to 'zero'
Example:
Credit-Control-Answer
Session-Id = 123
Result-Code = 5005
Origin-Host = hostname
Origin-Realm = realm
Auth-Application-Id = 4 // Dummyvalue, we're only serving DCC
CC-Request-Type = 4 // Dummyvalue, TERMINATION_REQUEST
CC-Request-Number = 0 // Dummyvalue,
Failed-AVP {
Auth-Application-Id = 0 // Zero
CC-Request-Type = 0 // Zero, violates AVP definition of CC-Request-Type
CC-Request-Number = 0 // Zero
Regards,
///Mats J
_______________________________________________ DiME mailing list DiME at ietf.org https://www1.ietf.org/mailman/listinfo/dime