[asterisk-bugs] [Asterisk 0012318]: Originate call is already answered even if destination channel is still ringing

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12318 
====================================================================== 
Reported By:                krtorio
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   12318
Category:                   Core/ManagerInterface
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0-beta5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             2008-03-28 03:26 CDT
Last Modified:              2008-09-10 16:48 CDT
====================================================================== 
Summary:                    Originate call is already answered even if
destination channel is still ringing
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

====================================================================== 

---------------------------------------------------------------------- 
 (0092323) svnbot (reporter) - 2008-09-10 16:48
 http://bugs.digium.com/view.php?id=12318#c92323 
---------------------------------------------------------------------- 
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 http://bugs.digium.com/view.php?id=12318)
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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-10 16:48 svnbot         Checkin                                      
2008-09-10 16:48 svnbot         Note Added: 0092323                          
======================================================================