6 Jul
2005
6 Jul
'05
10:58 a.m.
Günther Starnberger wrote:
On Wed, 2005-07-06 at 12:16 +0300, Bogdan-Andrei Iancu
wrote:
Hello,
yes, this is a strong point
Indeed, accounting the transferred calls may be
trick.
A short idea that might help you:
- spy the REFER request and add to the "Refer-to" header's URI a
parameter containing the billing user (usually is FROM URI of the REFER)
- use avpops to do this -> avp_write() to get the from URI into an AVP
and subst() to added the AVP as a Refer-to URI parameter (for example
named "billing".
- look for INVITEs which have in RURI, URI with the "billing"
parameter; if so, move its value to the X-Account header; For this you
need the new avp_subst() function (only in OpenSER 0.10.x)-> the idea
will be like this: move RURI in an AVP (avp_write), extract from the avp
only the param (avp_subst) and push the avp as header (avp_pushto).
Thanks for the info - I already thought of something similar, but the
downside of this solution is that i would need some kind of
'ticket' (e.g. a random number) which i put into the refer-to header -
otherwise the remote peer would be able to call on someone elses credit
even without a transfer.
Something like the following steps:
* OpenSER gets a REFER and writes a random number together with a
timeout value in the database.
* OpenSER puts this number in the Refer-to header as a parameter
* On an incoming call the number is checked against the database - if it
matches the account of the person wo initiated the transfer is used -
otherwise the account of the person who sent the INVITE is used.
I hoped that there would be a simpler solution for this problem :(
a way to simplify it is to relay on acc data: log the REFER with the
FROM, REFER-to hdr (and whatever you find useful). Then, from ACC table,
you can put thing together : A <-> B, A refer to B with refer-to C,
B->C; so A must pai also fo B->C; checkings timestamps will avoid any
doubts.
Maybe using some additional random tokens to re-enforce the correlation
between the two calls will be good.
How is this case usually handled in the VOIP world? Are
calls just
assigned to the account of the person who sent the invite? Or are
workarounds (either your suggestion or a B2BUA which keeps track of the
calls) common?
I don't thing a B2BUA is really required.
regards,
bogdan