[Home]

Summary:ASTERISK-11739: Originate call is already answered even if destination channel is still ringing
Reporter:KR Torio (krtorio)Labels:
Date Opened:2008-03-28 03:26:33Date Closed:2008-09-10 16:48:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/ManagerInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:

All calls made through the manager command Originate call are already answered (which in turn starts the billsec timer) even if the destination channel is still ringing and hasn't answered the source channel.

This of course will give out an incorrect billsec value (ex. nonzero value even if dest. channel rejects source channel) and will affect the accuracy of our talktime reports.

Seems that the issue exists since version 1.4.9, I reported a similar case like this (http://bugs.digium.com/view.php?id=10444).



Problem is easily reproducible:
extensions.conf:
exten => _6XX,1,Dial(SIP/${EXTEN},60,tr)

in manager interface:
Action: Originate
Channel: SIP/660
Exten: 676
Context: outgoing
Priority: 1
Comments:By: David Woolley (davidw) 2008-03-28 06:31:40

I suspect you may need more than one option.  I assume that the original intended use of Originate was for achieving something like predictive dialling, or for completely automated messages.  In that case, the first party is likely to be a toll number in most parts of the world, and one may want the billing information to reconcile toll costs.

Are you trying to bill for the agent's time, or are you making the local party the first party?
By: KR Torio (krtorio) 2008-03-31 20:25:16

We just want to get the actual talk time between the two parties.

To get the correct talk time, what I did is put ResetCDR before Dial to wipe out the answered status and the billsec value.
By: Steve Murphy (murf) 2008-06-23 10:53:36

Interesting. I read 10444 (it's been a while!), and noted that I mentioned
better behavior in CDRfix5... so, since you are reporting this against 1.6.0,
I suggest you check out:

http://svn.digium.com/svn/asterisk/team/murf/CDRfix6

and see if your problem is solved without the resetCDR call.

Since I fully intend to merge the CDRfix6 and CDRfix4 branches soon, it would be good to have feedback against these branches!

By: Steve Murphy (murf) 2008-09-09 12:36:33

OK, this bug has been in feedback since June. I'm in a CDR frame of mind, and a lot of water has gone under the bridge since then, so to speak, so I labbed this one up, and tested to see what the problems were.

In my case, I send a call file:

Action: Originate
Channel: Sip/snom360
Exten: 842
Priority: 1
Context: extension

which initiates a call from my snom360 to exten 842, which in AEL:

Dial(SIP/polycom430|25|Tt);

I let the first phone ring a long time. The second phone I quickly pick up and set back down to complete the call.

I get the following cdr_custom:

"","","842","extension","SIP/snom360-0822bbc0","SIP/polycom430-08231050","Dial","SIP/polycom430|25|Tt","2008-09-09 11:22:00","2008-09-09 11:22:14","2008-09-09 11:22:15","15","1","NO ANSWER","DOCUMENTATION","","1220980920.0","",""


The answer to end time is correct; however, the disposition is set to "NO ANSWER", which is incorrect. The CID info is missing. I will assume that the missing CID info is due to the fact that the manager initiating the call interrupted the normal setting of these fields. I will investigate these problems and see if a fix can be made.
By: Digium Subversion (svnbot) 2008-09-10 16:48:46

Repository: asterisk
Revision: 142474

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r142474 | murf | 2008-09-10 16:48:45 -0500 (Wed, 10 Sep 2008) | 30 lines

(closes issue ASTERISK-11739)
Reported by: krtorio

I made a small change to the code that handles local channel situations.
In that code, I copy the answer time from the peer cdr, to the bridge_cdr,
but I wasn't also copying the disposition from the peer cdr.

So, Now I copy the disposition, and I've tested against
these cases:

1. phone 1 never answers the phone; no cdr is generated at all.
  this should show up as a manager command failure or something.

2. phone 2 never answers. CDR is generated, says NO ANSWER

3. phone 2 is busy. CDR is generated, says BUSY

4. phone 2 answers: CDR is generated, times are correct; disposition
  is ANSWERED, which is correct. The start time is the time that
  the manager dialed the first phone. The answer time is the time
  the second phone picks up.

I purposely left the cid and src fields blank; since this call really
originates from the manager, there is no 'easy' data to put in these
fields. If you feel strongly that these fields should be filled in,
re-open this bug and I'll dig further.




------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=142474