CDRs of transferred outbound calls are no longer easy to id

Asterisk Asterisk General
1

system is trixbox based, * 1.2, freepbx 2.3.0, sip extensions (grandstram phones), the goal is to bill for internal back-charging…

CDRs of transferred (SIP based) outbound calls are no longer easy to identify as outbound calls

details:

  1. call from extension 5000 to an external number 555555
  2. transfer this connection to extension 5001

results in CDRs:

calldate: time0, clid: <User A 5000>, src: 5000, dst: 555555, channel: SIP/5000, dstchannel: Zap/1-1, disposition: answered, duration: t, uniqueid: a calldate: time0+t, clid: 5000, src: 5000, dst: 5001, channel: Zap/1-1, dstchannel: , disposition: answered, duration: 0, uniqueid: b calldate: time0+t, clid: 5000, src: 5000, dst: 5001, channel: Zap/1-1, dstchannel: SIP/5001, disposition: answered, duration: t1, uniqueid: b

the first record is easy to identify as external call to destination 555555 with duration t and can be billed based on this information. but: the much longer connection will be the one of the third record (duration t1), only that this looks at first hand like an incoming call (source channel is an external trunk line, eg Zap/1-1). Based on the clid:5000 and src:5000 i could identify that this is most probably a tranferred outbound call, but i have no information regardig the destination number to define the cost.

anybody any ideas?
is this basic * behaviour or is it related to the freepbx supplied extensions.conf?
can this behaviour be changed?

thx
regards
michael

2

Unfortunately this is default behavior for asterisk. If you want to fix this disable attended call transfers.

3

@walter: thanks a lot, insteresting idea. i understand it like this: in case of transfered calls write the destinationnumber to accountcode (or probably: in general write the destinationnumber to accountcode). will try this and post here in case of success.

4

Store the records in the mysql backend and activate the uniqueid field (a unique id per call, so if the call gets transferred the unique id stay the same).

Regards.

Marco Bruni

5

@marco: that would be terrific, but unfortunately (at least in my environment) the transferred call has a different uniqueid than the original call. do you have any ideas if this has to do with some specific type of configuration?

6

I’m sorry but I gave you a wrong information, the customer that has this feature to transfer the call doesn’t use the *'s standard features but instead uses a custom dialplan where I used the ResetCDR(w) function to write one cdr per call part but all the cdrs about a call and the subsequent transfers have the same unique id.

Cheers.

Marco Bruni

7

@marco: that sounds very interesting. would you mind sharing some technical details regarding how you achieved that this calls get the same uniqueid?

8

No problem at all about sharing :smile:
This seems not simple but all you have to do is ResetCDR before dialing to transfer the call, we use this when an operator of a queue want to transfer a call pressing the # key.

Cheers.

Marco Bruni

9

thanks a lot marco. that sounds easy enough. will try it asap and post about any success.

10

ma0xyz, did you have any successful results? Can you help me?

11

@rad.puga: not yet. i’m still looking for a solution. i currently believe that mbruni’s solution does not work for me because we are using sip ip-phones which signal a call transfer directly via sip to * and i cannot invoke ResetCDR anywhere in this process (or i did not find out how up to now). if i find any solution i will post here.

12

You mean # when you said * ?

Can you add me in MSN? rafael.adp at gmail.com

13

i meant asterisk when i said * :smile: