Diameter Unable To Comply (5012) During Billing
(Doc ID 2732698.1)
Last updated on DECEMBER 03, 2020
Applies to:Oracle Communications BRM - Elastic Charging Engine - Version 220.127.116.11.0 and later
Information in this document applies to any platform.
During BRM Billing, online (diameter) users are affected by series of UNABLE_TO_COMPLY(5012) errors, i.e cannot use their internet. It is caused by a transaction lock set by BRM in ECE. There are 2 scenarios, the transaction lock happens. Once the process is completed, it clears the lock.
1. When there is a sync from BRM to ECE, the sync process and post commit happens. This will create customer in transaction lock.
2. For sharing group scenario, when more than one member’s usage request sent at the same time. This creates sharing group lock. One request will finish and clears the lock and then next request will start.
In both the scenarios, there is a common number of retries. There is a parameter by name saying sharingRetryCount, it is applicable for both the cases.
During billing the ECE sync is started from BRM to ECE and it creates customer in transaction lock. Then post commit will be called to clear the lock. During this period (after customer in transaction and before post commit) if there is a usage request to ECE, then it finds that there is a lock then it retries 200 times instead of error out immediately. Though the number of retries are 200, it is actually very fast because it just do the lookup and retry again and again. If the retry count reached 200 and if it still finds the lock then it will send UNABLE_TO_COMPLY error. In our environment this has been kept retry as 200 then I see the response is coming out in around 110 milli seconds. If I increase the number of retries then the final response also taking time.
We can also think of increasing the number of retry from 200 to little higher value, but I think we should make sure that it is not crossing the timeout set at the EPG/CMG. Otherwise, the retransmission will be triggered.
Expected improvements: implement a sleep/wait in the retry loop, in order the retries configured by sharingRetryCount should last longer, i.e. more than a period between setting the lock and releasing the lock. For example, a new paramter sharingRetryWait set in Milliseconds would make waiting as sharingRetryCount * sharingRetryWait (ms) hence give a chance to finish the bill for locked account.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document