Here are some proposed modifications to handle the P-Charging-Vector header as defined in rfc3455 section 4.6 to - parse charging vector from SIP message - generate new unique charging vector - remove a charging vector header
a new pseudo variable
pseudo variables are exported and enable Read onlly access to charging vector fields
$pcv = whole field $pcv.value = icid-value field (see RFC3455 section 5.6) $pcv.genaddr = icid-generated-at field (see RFC3455 section 5.6)
a new function acc_charging_vector()
- g = generate a new charging vector or forward the orginal one - f = generate a new charging vector regardless of the orginal charging vector - r = remote the P-Charging vector header from the packet You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/215
-- Commit Summary --
* P-Charging-Vector implementation * Merge remote branch 'upstream/master' * P-Charging-Vector
-- File Changes --
M modules/acc/acc_mod.c (18) A modules/acc/chargingvector.c (435) A modules/acc/chargingvector.h (18)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/215.patch https://github.com/kamailio/kamailio/pull/215.diff
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215
Is this patch storing something new in accounting record (eg., storing something new in acc database table)?
If not and it is only about SIP header management, then might be better to relocate the code to siputils module. Acc is intended to be the connector to write records to a backend.
Some remarks:
* change to be a single class of variables: $pcv(name) - having like: $pcv(full), $pcv(value), $pcv(genaddr) -- it is more compact and adding new fields in the future will fit better * use commit message format as suggested at: http://www.kamailio.org/wiki/devel/git-commit-guidelines#commit_message
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#issuecomment-113422700
Regarding the variable naming, I will change it
It is currently not writting directly anything in the database however, the idea is that that this the value of P-Charging-Vector should be used in radius accounting to fill the field
Acct-Multi-Session-Id
As defined in RFC2866 (Radius accouning). We currently use "radius_extra" to bind this variable but I can resubmit a new version of this patch to automatically bind this $pcv(value) to the correct radius AVP.
One more question: to resubmit this what is the best way ? to create a new pull request I guess ?
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#issuecomment-114441339
Provided that the $pcv(value) is automatically bound to Acct-Multi-Session-Id. Do you advise to move this code into acc_radius module ?
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#issuecomment-114441476
That was my concern of binding the variable to a specific module which has the role of writing to an accounting backend. Either acc or acc_radius module, you practically force using the selected module to be used when wants to use the variable.
Think that someone might want to store the value in database or in syslog and from there to import in their billing engine that might use radius or not.
Therefore my idea to place it in a (rather) independent module of backend storage, so one can use it with acc as well as acc_radius (or acc_diameter), without a need to use a module depending on a backend not really needed in that config.
You can come with successive patches, but a new pull request can be cleaner.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#issuecomment-114443091
Closed #215.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#event-538199946
Pushed the code to utils module, along with changing the var to use $pcv(name) format.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215#issuecomment-179466762