[Home]

Summary:ASTERISK-14282: [patch] Billsec is zero when playing a file in the Dial function
Reporter:Private Name (falves11)Labels:
Date Opened:2009-09-22 14:49:22Date Closed:2009-11-04 15:45:05.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_dial
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) dial-caller-answer1.diff
( 1) dial-macro-billsec-fix1.diff
Description:The Open Source 1.4 version of Asterisk will bill nothing, zero, if the caller or callee hangs up before the file has finished playing, but will record the duration of the call correctly, just the billsec amount is wrong. It is very easy to duplicate. My dialplan is one line:
exten => _X.,1,Dial(Sip/${EXTEN}@XXX.XX.XX.XXX,25,CA(demo-instruct)L(1800000))

The file demo_instruct is part of asterisk's sounds and it is the longest one. Just place a sip call and hangup a few seconds into the call. The CDR will show zero  billsec, but duration will be 60+ seconds.


 

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

Note, it makes no difference if I use this dialplan
xten => _X.,1,Dial(Sip/${EXTEN}@XXX.XX.XX.XXX,25,A(demo-instruct)L(1800000))
Comments:By: Tilghman Lesher (tilghman) 2009-09-22 15:12:15

This is by design.  An announcement is generally played to the called user, and the caller remains unanswered until the two are bridged, so for the caller, the billed seconds are indeed 0 (since the CDR belongs to the caller).
By: Private Name (falves11) 2009-09-22 15:37:54

The design is wrong since in before Asterisk plays the file  I execute a macro, and in the first line of the macro I answer the call. But no billsec is recorded. I know this is a bug because the behavior of the business edition is reversed, but equally wrong. In the same scenario, the billsec will be the length of the entire file played, even if it is 10 min long, while the call may have lasted only a few seconds.
                                     
[inbound]        
exten => _X.,1,Dial(Sip/${EXTEN}@XX.XX.XX.XX,25,M(get-callid)A(demo-instruct)L(1800000))
                                                                                                     
[macro-get-callid]                                                                                                                                    
exten => s,1,Answer

The right design would be to start counting the billsec since we receive an 200 OK from the second  leg of the call and also we should deliver this 200 OK to the caller immediately, which we are not doing now, apparently. The way it is now we are missing a billable event, which is terrible, actually, a deal-killer for any telecom carrier.
By: Tilghman Lesher (tilghman) 2009-09-22 16:52:56

Nope.  Again, the CALLED channel is what executes the Macro, not the CALLING channel.  The calling channel is not answered, and therefore, the billing time does not start.

This is by design.
By: Matthew Nicholson (mnicholson) 2009-09-30 13:01:38

I consider this a bug.  If the called channel answers that call, that call is billable.  Asterisk should be recording this in the CDR.
By: Private Name (falves11) 2009-09-30 13:04:54

I support mnicholson


By: Matthew Nicholson (mnicholson) 2009-09-30 13:23:58

Try the patch I just uploaded to see if it fixes your issue.
By: Private Name (falves11) 2009-09-30 14:45:25

The patch goes only half way, I mean, it is not enough. It records the moment when the callee picks up the phone, and that is wonderful, but if the caller, the originator, drops the call, the call continues on for the callee, even if the caller is long gone several minutes ago. If the callee drops the call, then the call correctly stops and gets billed.
The correct way to solve this is to stop the call if either leg sends BYE, and stop the billing right there. If you need to see a live example please contact me via the information in Digium's ticket system for ticket
FDI-431113


By: Matthew Nicholson (mnicholson) 2009-09-30 14:52:39

I have observed that behavior too, but I don't have time to fix that issue at this moment.
By: Leif Madsen (lmadsen) 2009-10-01 08:55:37

The original issue has been fixed by mnicholson it seems based on the comments here. For the additional issue that was brought up, please open a separate ticket to track it.
By: Private Name (falves11) 2009-10-01 09:05:34

I did, the new issue is 16005. Please advise if this patch is already in svn so I may upgrade my boxes.
By: Matthew Nicholson (mnicholson) 2009-10-01 09:09:13

The patch is not in SVN yet.  The bug will be closed when this patch is added.
By: Private Name (falves11) 2009-10-02 21:55:08

Please feel free to add this to SVN.
By: Private Name (falves11) 2009-10-28 22:27:11

I think that the patch needs some work. I am having tons of billing disputes. I think the "200 OK" is NOT relied to the caller when the calee picks up the phone. The seconds recorded may be correct, but of the "200 OK" is not send immediately to the caller, the caller will not start counting the seconds from the same time, and my bill will never, ever, match. I think that is happening. The behavior of Asterisk must match the "regular" behavior when there is no file playing.
Also, I am now playing the file inside a Macro. Maybe that is the issue? The caller should get the 200 OK as soon as we receive it, in any scenario.
By: Matthew Nicholson (mnicholson) 2009-10-29 09:21:10

I understand why this is a problem for you, but I am not sure this is the right approach to fix this scenario.  If you answer the caller's channel when the called channel answers, then play an announcement to the called channel, the caller will hear silence for the duration of the announcement.  I think the behavior with the patches is the correct behavior.

Playing the file from a macro should not make a difference.
By: Private Name (falves11) 2009-10-29 09:25:38

That is the correct behavior, but the 200 OK must be relied back as soon as we get it. I mean, we answer the call and play silence back for the duration of the file. I need the counter to start moving on the caller at the same time as ours. The question is: Is the patch doing that right now?.
By: Matthew Nicholson (mnicholson) 2009-10-29 09:31:54

The patch is not sending the 200 OK until after the announcement finishes, which is unchanged from the unpatched behavior.  The patch makes the counter start when the called party answers, even if the calling party hangs up before they receive the 200 OK.  The past behavior was to set billsec to 0 if the calling party hung up early, but billsec would be set according to when the called channel answered if the calling party did not hangup.
By: Private Name (falves11) 2009-10-29 10:15:29

Can you find a way for me to do and Answer() inside the macro for the calling channel? The function works but it does not pick up the incoming channel.
That would solve the issue.
By: Matthew Nicholson (mnicholson) 2009-10-29 14:37:15

That would eliminate the billing discrepancies, but you would still have a period of silence on the calling channel while the macro was executing.  I don't think that is the best solution here.
By: Private Name (falves11) 2009-10-29 14:46:00

That is fine for me. I guess I can play a file towards the caller, is it possible?
There are powerful business reasons behind this. The carriers started to charge 2 cents per call shorter than 6 seconds, in excess of 6%. It means that we need to keep the customer entertained for at least 6 seconds, before he can talk to the caller, or hears the message. The entire dialer industry is at stake.
By: Matthew Nicholson (mnicholson) 2009-10-29 15:33:01

I will look into the best way to accomplish answering the calling channel when the called channel answers.  Right now, I am leaning towards an option to the Dial application.
By: Matthew Nicholson (mnicholson) 2009-10-30 10:29:26

Ok, try the patch I just uploaded.  It should cause an answer to be sent right away.
By: Private Name (falves11) 2009-11-01 20:07:45.000-0600

Actually, there is something not right. The D() option, is supposed to play some DTMF to the calling party (D:1234567890), before bridging the call, after there is a connect. This should be done right after a connect, and if the A() option of a Macro is being executed, the D() option should be working simultaneously with the A() option or the Macro. It does not. It works after the Macro finishes executing, but since now we know that there is a connect, it should go in parallel. If the D() option finishes earlier than the Macro or the A() option, it should hold and wait and the the connection should  proceed as always.
By: Matthew Nicholson (mnicholson) 2009-11-02 09:07:22.000-0600

That is a separate issue.  Please open a new bug for that.
By: Atis Lezdins (atis) 2009-11-02 11:54:58.000-0600

It might be good to provide summary log with SIP debugs for the issue, so that it's possible to calculate billable time from log and see exactly where is the problem.

For example:

10:00 chan_sip: INVITE
10:01 chan_sip: 200 Trying
20:02 app_dial: Dial(..)
20:05 app_macro: NoOp(starting answer macro)
..
res_cdr_mysql: INSERT INTO cdr ...
By: Matthew Nicholson (mnicholson) 2009-11-04 15:08:30.000-0600

This issue will only be fixed in the trunk version of asterisk because properly fixing this issue requires modifications to app_dial which may affect billing records.  Patches for asterisk 1.4 will remain available here.
By: Digium Subversion (svnbot) 2009-11-04 15:45:01.000-0600

Repository: asterisk
Revision: 227897

U   trunk/CHANGES
U   trunk/apps/app_dial.c

------------------------------------------------------------------------
r227897 | mnicholson | 2009-11-04 15:45:01 -0600 (Wed, 04 Nov 2009) | 11 lines

Added the 'a' option to app dial and modified app_dial to set the answertime when the called channel answers.

This change causes answertime to be correct even if the called channel hangs up during an announcement triggered by the A() option.

(closes issue ASTERISK-14282)
Reported by: falves11
Patches:
     dial-macro-billsec-fix1.diff uploaded by mnicholson (license 96)
     dial-caller-answer1.diff uploaded by mnicholson (license 96)
Tested by: falves11, mnicholson

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

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