[Asterisk-Users] CDR for transfered calls
Chris A. Icide
chris at netgeeks.net
Tue Jun 15 10:53:29 MST 2004
The issue we have here is not just related to IAX. If you have Asterisk
step out of the media stream for any call, you lose the capability to
determine the status of the call, and therefore lose the ability to track
the call in your CDR.
Perhaps (at least for the case of IAX transfers or maybe sip registry
transfers (reinvite from/to a different asterisk server), we need an option
for "centralized CDR" record keeping. At the begining of any transaction,
create a truly global unique ID for the transaction and log it with the
central CDR system. Now pass that Unique ID along to any parties in the
transaction, and each party updates the central CDR system with any changes
to the transaction. In a scenerio like this you would be able to maintain
accurate CDR records for any calls in which the media stream passes through
devices supporting the CDR system. For it to work fully, you'd need to get
UAs to support it as well (probably would need an RFC and alot of
prodding), since in some cases calls will be UA to UA after all the initial
signalling is completed.
On 12:32 AM 6/10/2004, Florian Overkamp wrote:
>> -----Original Message-----
>> > Yes. The issue here is that billing information is never correct in
>> > such a scenario, since the call duration on the registered asterisk
>> > machine (the one that is kicked from the path) is no longer correct.
>> > To fix this a notransfer=yes is mandatory, but that defies the
>> > practicality of having a voip conversation take the shortest path.
>> Sure... So, this issue is "sort of a bug" and it really needs to be
>> implemented then!
>I'm afraid its not that simple. Unless I'm misunderstanding the concepts of
>IAX(2) design, it does not support such behaviour _by design_. Who knows
>what would break if someone hacked our desires in there. A solution then
>would be: choose another protocol. Technically you could spin off an
>IAX2-cdr channel that supports it, but that would require duplicate efforts
>to maintain both channels. My current position is 'deal with it' and accept
>the extra traffic. If someone with more knowledge about IAX(2) can comment
>on the feasability of this behaviour we may proceed in that direction,
>otherwise we're just stuck.
>Asterisk-Users mailing list
>Asterisk-Users at lists.digium.com
>To UNSUBSCRIBE or update options visit:
More information about the asterisk-users