[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:
 >   http://lists.digium.com/mailman/listinfo/asterisk-users

More information about the asterisk-users mailing list