ASTERISK-06404: The CDR report the "src" and "dst" equal in any application

[Home]

Summary: ASTERISK-06404: The CDR report the "src" and "dst" equal in any application

Reporter: Fernando Romo (el_pop) Labels:

Date Opened: 2006-02-23 12:38:20.000-0600 Date Closed: 2006-09-20 10:24:22

Priority: Minor Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) extensions.conf
( 1) non_local_number_in_src_and_dst.pcap
( 2) same_numer_in_src_and_dst.pcap

Description: The CDR report the "src" (source of call) and "dst" (destination) with the same value in outgoing calls. we check a DB with 1,482,508 records and 6,081 are bad randomly, no mather the application used.

The data looks bad in the SQL data base and in the Master.csv file.

in the sample bellow, whe see the the "src" must be the extension number show in the "channel" field (without the channels type)...

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

acctid | calldate | clid | src | dst | dcontext | channel | dstchannel | lastapp | lastdata | duration | billsec | disposition | amaflags | accountcode | uniqueid | userfield
---------+------------------------+----------------+----------+----------+----------+---------------+---------------+---------+---------------------------------+----------+---------+-------------+----------+-------------+------------------+-----------
1482415 | 2006-02-16 17:19:39-06 | 53438723 | 53438723 | 53438723 | default | SIP/2022-31c9 | Zap/35-1 | Monitor | wav49|Local-1140131979.17026|mX | 43 | 35 | ANSWERED | 3 | | 1140131979.17026 |
1482308 | 2006-02-16 17:09:02-06 | 55510772 | 55510772 | 55510772 | default | SIP/2009-2e9b | Zap/60-1 | Monitor | wav49|Local-1140131342.16783|mX | 106 | 99 | ANSWERED | 3 | | 1140131342.16783 |
1479870 | 2006-02-16 13:11:53-06 | 019646984109 | 019646984109 | 019646984109 | default | SIP/2032-8626 | Zap/60-1 | Congestion |
| 101 | 89 | ANSWERED | 3 | | 1140117113.11651 |

Comments: By: Tilghman Lesher (tilghman) 2006-02-23 14:34:02.000-0600

Please post your ENTIRE extensions.conf, uploaded as a file, NOT pasted into a bugnote.
By: Fernando Romo (el_pop) 2006-02-23 17:09:54.000-0600

I attach my extensions.conf, let me know your comments.
By: Tilghman Lesher (tilghman) 2006-02-23 21:36:51.000-0600

I note that you're not actually setting your callerid at anyplace in your dialplan. You might want to start doing that.
By: Fernando Romo (el_pop) 2006-02-23 21:41:07.000-0600

ok, but.... why randomly?

I think the default value of the caller id must be the originate leg of the call.

This not have any sense for my, why works fine in more of one million calls and fail only in 6,000. If i take your aprouch, all the calls mus have a wrong value. You can explain me why????
By: Tilghman Lesher (tilghman) 2006-03-25 10:46:42.000-0600

Can you be certain that your callers are NOT setting their ANI and CallerID to the same number as they are calling?
By: Russell Bryant (russell) 2006-05-05 18:56:12

suspending due to a lack of response
By: jerjer (jerjer) 2006-06-07 02:49:30

kmilitzer requested re-opening this issue
By: Kai Militzer (kmilitzer) 2006-06-07 02:57:38

I have similar problems as described. I use only SIP, so all calls are SIP-to-SIP. I have CDRs that

1) contain the same (not-local-)number in src and dst
2) have non-local numbers in src and dst

In the first case in addition the duration is zero and the billsecs are > 0

An example looks like that:

+----------------+-------------+--------------+--------------+----------+--------------+------------------------------+-----------------+----------+----------+---------------------+---------------------+---------------------+----------+---------+-------------+----------+-----------------+---------------------+-------+---------------+------+----------------------+----------------+---------------+ | uniqueid | accountcode | src | dst | dcontext | clid | channel | dstchannel | lastapp | lastdata | start | answer | stop | duration | billsec | disposition | amaflags | userfield | calldate | preis | einkaufspreis | k_nr | berechnungszeitpunkt | k_nr_eingehend | resellerpreis | +----------------+-------------+--------------+--------------+----------+--------------+------------------------------+-----------------+----------+----------+---------------------+---------------------+---------------------+----------+---------+-------------+----------+-----------------+---------------------+-------+---------------+------+----------------------+----------------+---------------+ | 1149443650.770 | billing | 01520xxxxxxx | 01520xxxxxxx | outgoing | 01520xxxxxxx | SIP/sip.westend.com-081e6520 | SIP/bt-out-5ec2 | ResetCDR | w | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 0 | 61 | ANSWERED | 3 | 00491520xxxxxxx | 2006-06-04 19:55:40 | NULL | NULL | NULL | NULL | NULL | NULL | +----------------+-------------+--------------+--------------+----------+--------------+------------------------------+-----------------+----------+----------+---------------------+---------------------+---------------------+----------+---------+-------------+----------+-----------------+---------------------+-------+---------------+------+----------------------+----------------+---------------+

I have ethereal of that calls, that reveal that for calls with strange records like these a REFER was sent. I will try to anonymonize these traces to attach them to this ticket. Let me know if you need anything else.

By: Serge Vecher (serge-v) 2006-06-12 19:22:47

kmilitzer: is this an issue on 1.2.9.1 or trunk?
By: Kai Militzer (kmilitzer) 2006-06-13 01:42:59

vechers: It's an issue in 1.2.9.1, as the original bug report was not made by me this was not clear, sorry.
By: Olle Johansson (oej) 2006-06-13 02:53:33

kmilitzer: If you have time, please try with svn trunk - we have changed a lot of the SIP transfer support, so I need feedback if this issue is still there or not. Thanks.
By: Fernando Romo (el_pop) 2006-06-13 22:51:25

I report with branch version 1.2 revision 10736, not with 1.2.9.1 (???) but verchers change the info, The problem exists in all 1.2 branch, and i don't test trunk in production system, only in lab.
By: Kai Militzer (kmilitzer) 2006-06-14 05:43:35

I cannot test trunk on my production system either. I would test it on a lab system, but I don't know how to generate the REFERs, as they came from Sipura ATAs of some customers. :(
By: Serge Vecher (serge-v) 2006-06-14 08:41:01

el pop: I've changed the version number to 1.2.9.1, because that is the latest stable version kmilitzer has reported to have a problem with.

all: testing trunk was a suggestion...
By: Artur (bulo) 2006-06-25 11:59:56

I confirm...
When I make ResetCDR, values: clid,src,dst in cdr record are the same:

1230 Query INSERT INTO cdr (calldate,clid,src,dst,dcontext,channel,dstchannel,lastapp,lastdata,duration,billsec,disposition,amaflags,accountcode,uniqueid) VALUES ('2006-06-25 17:32:37','457390999','457390999','457390999','tel','SS7/tel/31','SS7/tel/1','Dial','ss7/tel/765868545|30',15,15,'ANSWERED',3,'','1151249557.42')

I use chan_ss7 by Sifira.
My extensions.conf is very simple:
exten => _X.,1,DeadAGI(tel-1.0.0.agi)

This is fragment of agi script
$AGI->answer();
$AGI->exec( 'read', 'result' );
$result=$AGI->get_variable( 'result');
$AGI->exec( 'ResetCDR', '' );
$AGI->exec( 'Dial', "ss7/tel/$result|30" );
$AGI->hangup();
$AGI->hangup();

when I make:
######### $AGI->exec( 'ResetCDR', '' );
(remove ResetCDR)
then cdr record is correct.

???error in configuration????

With best regards
Bulo

asterisk v. 1.2.9.1

PS
This error exist when i dial with C options.
PS
oej - manager
......we have changed a lot of the SIP transfer support.........
I don't use SIP.

By: Serge Vecher (serge-v) 2006-08-25 14:32:16

alright, is this an issue in 1.2.11?
By: Kai Militzer (kmilitzer) 2006-08-28 01:55:04

I am sorry, but I am not able to test if the bug still exists, because I still don't know how my customers generated the REFERs that triggered the problem. :(
By: Serge Vecher (serge-v) 2006-09-20 10:24:20

closing this again, unless somebody can reproduce this reliable in either trunk or latest stable (currently 1.2.12.1). If you do, please ask the bug-marshall to reopen the issue.