top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter Result code 4999, can anyone tell me the implementation made/seen for this result code.

+1 vote
3,493 views
Diameter Result code 4999, can anyone tell me the implementation made/seen for this result code.
posted Jul 3, 2016 by Hiteshwar Thakur

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
4xxx is transient failure case but as far as I remember 4999 is not defined. So in reality if anywhere its being used then it must be propitiatory implementation.

1 Answer

0 votes

Hi
Please follow this link ftp://ftp.itsinternet.net/pub/rfc/iana/aaa-parameters/aaa-parameters.xml , it's clearly states that result code 4014-4999 are unassigned. Refer Result-Code AVP Values (code 268) - Transient Failures in that link.

answer Jul 4, 2016 by Chinmoy Padhi
Thanks for the useful link.
I know it is one of the unassigned result codes that's why I have asked for the real time implementation.
As Salil said in comment that It could be proprietary.

I have got my answer.
For others: It can be mapped for timeout.
Similar Questions
+6 votes

Can someone please explain difference between these two. Could both Result-Code and Experimental-Result AVPs be used in same diameter or only one of them is allowed ?

+4 votes

I am not able to understand the significance of "limited success" in a answer message and also want to know what a diameter node does when it receives this limited success within a answer message ?

+3 votes

I'm doing some integration toward Gy client (PCEF), and encountered an unclear area. I'm not sure if it is unclear in RFC 4006 or the 3GPP TS32.299 or both.

Scenario: A user logs on. The user has no credit left for a rating-group 42.

CCR-initial and CCA-initial:
Nothing interesting. In Gy it is typically just "empty" requests for the purpose of registering the user session.

The user then attempts to use rating-group 32:

CCR-update:

 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Requested-Service-Unit {
 }
 }

to which the OCS (Gy server) would normally respond:

CCA-update:

 Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Final-Unit-Indication {
 ...
 }
 }

However, the Gy specification says that a zero-grant is needed, which to me sounds a bit odd, but nevertheless:

Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Granted-Service-Unit {
 CC-Total-Octets = 0
 }
 Final-Unit-Indication {
 ...
 }
 }

Now, the Gy client vendor says that the result-code inside the MSCC must be 2001 (success). It sort of makes sense because there is a grant.

But that made me wonder: In which case would result-code=4012 make sense? Is it just 3GPP who has "mangled" diameter-credit-control in the Gy application?

+2 votes

Based on the 3GPP 29.272, the IDR (Insert-Subscriber-data Request message) is generated by the HSS to the MME to update the subscriber profile in the MME and/or requesting subscriber info such as location-information, subscriber state...
However the SUBSCRIPTION-DATA AVP containing the of profile to be added or updated is defined as Mandatory.
What should contain this AVP if the IDR is sent only for requesting subscriber-info without updating the subscriber profile.
Should ot be present without any nested AVP under it?

...