Open twmobius opened 4 years ago
I went a step further and added another parameter named parameter
on the Routing
h323-ivr-in
response in the authentication that a user could supply a set of radius attribute-value pairs that b2bua later adds in the accounting messages.
So for example if the authorization response if of this sort:
h323-ivr-in = 'Routing:123@192.168.5.104:5060;credit-time=7200;expires=15;np_expires=5;bill-to=123@realm;parameters=h323-ivr-out=Test-Data:d=2,vr=1,ar=8'
both originate
and answer
, start
, stop
accounting will containing the header:
h323-ivr-out = 'Test-Data:d=2,vr=1,ar=8'
The idea is that when the billing engine performs authorisation for a call, it could provide information to the accounting events so that the engine could easily charge the call without having to recalculate everything from scratch.
Please let me know if you are interested in such feature additions on b2bua. :)
Looks promising. I don't mind having this as a feature, would you please convert this to a PR?
Thanks!
-Max
On Thu., Oct. 29, 2020, 7:38 a.m. Paris, notifications@github.com wrote:
I went a step further and added another parameter named parameter on the Routing h323-ivr-in response in the authentication that a user could supply a set of radius attribute-value pairs that b2bua later adds in the accounting messages.
So for example if the authorization response if of this sort:
h323-ivr-in = 'Routing:123@192.168.5.104:5060 ;credit-time=7200;expires=15;np_expires=5;bill-to=123@realm ;parameters=h323-ivr-out=Test-Data:d=2,vr=1,ar=8'
both originate and answer, start, stop accounting will containing the header:
h323-ivr-out = 'Test-Data:d=2,vr=1,ar=8'
The idea is that when the billing engine performs authorisation for a call, it could provide information to the accounting events so that the engine could easily charge the call without having to recalculate everything from scratch.
Please let me know if you are interested in such feature additions on b2bua. :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sippy/b2bua/issues/37#issuecomment-718796698, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABVMJTZKUTBGWG2UPC3PCLSNF47ZANCNFSM4TA2F7HQ .
@sobomax there you go, I've split them up into two PRs one for each new feature.
Hi @sobomax,
I wanted to add the sip realm in the authentication radius request (without perform digest authentication), and I've been looking through RadiusAuthorization; there is an
extra_attributes
parameter in thedo_auth
method which is not used anywhere and got me thinking.Similarly to
pass_headers
parameters it would be nice to have an option to define a sip header from which b2bua will get specific radius attributes and add them to the Authentication request (via theextra_attributes
property)So I've modified the b2bua a bit to support exactly that. The patch adds an
-x
option, from which the user can add a sip header for b2bua to read radius attributes.So for example, opensips might do something like:
sippy would have to run with
-x x-test-header
parameter and in the authentication request the header contents is added to the radius request. Obviously it's up to the administrator/ matching dictionary to supply valid radius key/ value pairs for this to work.I am providing the patch in this comment, I don't know if you would be willing to add it to the b2bua source code. If you are, I'd be happy to supply you with a PR