[Asterisk-Users] CDR for transfered calls

[John Todd]

[sorry - too lazy to re-arrange this top-posting stuff]

Not all Asterisk channel types lose control when they step out of the 
media stream.  SIP devices will notify the proxy server (Asterisk, in 
our case) that a call has terminated, so even though the media stream 
never went through the "proxy" (Asterisk).  This is an important 
distinction between IAX2 and SIP - media and control messages are not 
tightly linked with SIP as they are with IAX2.  Until IAX2 has some 
type of "backwards path notification", there is no method (to my 
knowledge) that IAX2 can notify the origin servers that the call has 
been terminated.  The only way for any server in the path to know the 
status of the call (with IAX2) is to not transfer the call away from 
itself, thus bearing the full load of the media stream and the 
control channel.

I would be happy to learn of other's experiences in managing this 
issue, as it is quite important (mandatory, really) in any type of 
managed service environment.

JT



At 10:53 AM -0700 on 6/15/04, Chris A. Icide wrote:
>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.
>
>-Chris
>
>On 12:32 AM 6/10/2004, Florian Overkamp wrote:
>>Hi,
>>
>>>  -----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.
>>
>  >Florian