[Users] Accounting Information and Call Transfers

Günther Starnberger gst at sysfrog.org
Wed Jul 6 11:33:52 CEST 2005


On Wed, 2005-07-06 at 12:16 +0300, Bogdan-Andrei Iancu wrote:

Hello,

> 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 :(

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?

cu
/gst

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.kamailio.org/pipermail/users/attachments/20050706/bdc60456/attachment.pgp 


More information about the Users mailing list