[Home]

Summary:ASTERISK-06251: dst field overwritten
Reporter:Juan Pablo Abuyeres (jpabuyer)Labels:
Date Opened:2006-02-03 09:18:09.000-0600Date Closed:2011-06-07 14:10:13
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Ill better explain this with steps to reproduce:

1.- SIP/1012 calls SIP/1006
2.- SIP/1006 answers
3.- SIP/1006 BlindTransfers the call to SIP/1005 and ForkCDR() before dial.
4.- SIP/1005 answers and hangs up.

dst field of the first call should be '1006', but it's '1005'.

| uniqueid        | calldate            | clid                | src       | dst       | dcontext                 | channel                          | dstchannel
| 1138982975.7729 | 2006-02-03 13:09:41 | "JCMOYANO" <1012>   | 1012      | 1005      | from-tecnoera            | SIP/1012-1af8                    | SIP/1005-52e3
| 1138982975.7729 | 2006-02-03 13:09:35 | "JCMOYANO" <1012>   | 1012      | 1005      | from-tecnoera            | SIP/1012-1af8                    | SIP/1006-2e5a


****** ADDITIONAL INFORMATION ******

That's not major as per bug guidelines.
Comments:By: Juan Pablo Abuyeres (jpabuyer) 2006-02-04 07:54:34.000-0600

I submited this issue as 'major' because if the dst field in the CDR is wrong, we can't charge our customers the correct tariff (according to the real destination), and that renders our billing system unusable.
By: Tilghman Lesher (tilghman) 2006-02-05 10:39:36.000-0600

Why not use the CDR(userfield) ?
By: Juan Pablo Abuyeres (jpabuyer) 2006-02-05 19:48:58.000-0600

you mean.. to workaround this bug? I really don't understand what are you suggesting.
By: Tilghman Lesher (tilghman) 2006-02-05 22:24:17.000-0600

It's not really a bug.  The problem that you have is that you'd like the dst field to describe the intended destination, rather than the actual destination.  The actual destination is what is recorded.

I'm suggesting an alternative course of action to get the accounting behavior you'd like to see, without altering the actual data stored by the standard fields.  You aren't likely to get the change you are suggesting, as the CDR records what actually transpires during a call (hence Call Detail Record), rather than what you would have liked to have happened during a call.
By: Juan Pablo Abuyeres (jpabuyer) 2006-02-06 07:06:25.000-0600

If I didn't ForkCDR() before the Dial() performed when blind-transfering, I would agree with you. Imagine a customer of mine calls me locally using the same asterisk box. We speak 5 minutes, then I realize he really needs to talk to a person who is a long distance call away. I (ForkCDR and) blindtransfer my customer to a longdistance call and they talk for an hour.
From using ForkCDR() I would expect 2 entries on the CDR:
1.- one from my customer calling _me_ for 3900 seconds (instead CDR currently logs my customer as performing the longdistance call himself, when in fact he might not have idea of the cost of the call).
2.- and a second from my customer (well, in terms of human normality it should be from me, but I can use ${BLINDTRANSFER} to know it's me the one that should be charged for the call) to the longdistance destination for 3600 secs.

Sometimes things that may not be a bug from a technical point of view don't make any sense in real life. I need to know the dst of the original call. If the real dst is a local number and it's overwrited with a longdistance number, i'll have to tweak the dialplan or do whatever it takes to get the real one. But I really think it should be a more out-of-the-box thing. I don't want to make this note larger than it already is. Please think about it. Thank you.