Using the Answer() application

[valmison]

I don’t know if it is a failure or normal behavior, but on Asterisk 16 I came across a configuration / programming conflict due to the Answer() application.

When using it, the CDR bills and duration information are recorded with the same value, which does not meet my needs, as I need billsec to consider only the time after the successful Dial().

However, if I stop using Answer(), sending the caller’s DTMF after dialing a valid dial plan extension does not work and, consequently, the Queue’s context option is unusable.

Is there any way to avoid this problem?

[fabricioojaime]

I have this same problem.
If anyone has a solution, it will be of great help.

[david551]

@valmison

Could you provide more detail. I’m pretty sure you have a misunderstanding of how Asterisk works, but I’m unable to work our exactly what you are doing/trying to do. Start with the dialplan and the channel technology types for both caller and callee. Also who is sending the DTMF, and what is consuming it.

Generally the point at which the call is answered is the point at which the provider will start charging the caller for an incoming call, which generally means you want to start accumulating billing time when Answer is issued.

If the caller is sending the DTMF, does the caller side network support early media?

@fabricioojaime I don’t think the original question is clear enough for you to be able to say it is the same problem.

[valmison]

@david551, thanks for listening.

But it does seem to be a problem with Asterisk, according to other unanswered topics:

CDR is broken, billsec is broken

I use Asterisk from 15 years and I’ve just spent 9 hours trying to get the correct CDR(billsec) duration of the second leg of a call. The call originates from a .call file, when answered it goes to a context, which runs an agi, which calls an agent. I’ve read the documentation here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification and I sure loved that there isn’t a single example. I’ve tried all the combinations of ResetCDR, ForkCDR, CDR_PROP(disable)=false, CDR(part…

How to get billsec of the second leg when originate call

hello guys after upgrading from asterisk-11 to asterisk-13.15.0, i’m facing problem of getting correct billsec of the second leg when originating call via AMI. It always return with billsec of 1st-leg. below is my scenario: My dialplan: i originated a call like this: picked my cellphone with 3s talktime. But from verbose, all variables returned with billsec of 1st-leg call (since i answered my extension): this was not happen in asterisk-11, but i can not rollback to 11 because of some …

What I tried to explain were two scenarios in which I had a problem, one using Answer() and the other without using it.

Using Answer() in a simple dial plan, like the one below, makes the “duration” and “billsec” fields of the CDR file stay the same time. I need the “billsec” time to be counted after answering the call, after the Dial() is able to connect the caller with the called number.

extensions.conf

[test]
exten => _ZXXX, 1, Answer
same => n, Dial (PJSIP / $ {EXTEN})
same => n, Hangup

The second scenario is when I stop using Answer () for a dial plan that uses “Queue”, where the caller has the possibility to dial a single digit to get out of the queue and go to another context. What does not work, because by not using Answer () the caller is unable to issue DTMF, in the example below, by dialing 1 before being answered by a member of the queue, the caller would withdraw from the queue and the call would be handled by the “queue-out” context.

extensions.conf

[test]
exten => 8000, Queue (support)
same => n, Hangup

[queue-out]
exten => 1, 1, NoOp (You left the queue to do something else)
...

queues.conf

[support]
musicclass = default
context = queue-out
strategy = rrmemory
joinempty = yes
leavewhenempty = no
ringinuse = no

[david551]

If this is SIP (including PJSIP) and the DTMF is from the caller, note that there is no certainty that the caller knows where to send media, including telephone events, before the the call is answered, unless the, optional, PRACK feature is implemented, or the SDP is contained in the 100 Trying. Other provisional responses are not sent reliably, so may get lost, without the client realizing. I’m not sure of the level of PRACK support in Asterisk, but the client would also need to support it. I can’t remember if Asterisk sends SDP on the 100 Trying, and whether that is the same for both SIP and PJSIP.

If this is SIP or PJSIP and the caller is supplying the DTMF, you might want to try replacing Answer by Progress.

[valmison]

I’m using only PJSIP and both scenarios are working if I reverse the use of Answer(), I just tried to be brief with the examples.

However, thanks for the suggestion to use Progress(), I’ll try it out.

[jcolp]

I don’t really have a solution for you using CDRs, as I haven’t experimented with or tried to do such a thing but I think this is really a good example of why CDRs are hard. They’re ultimately business logic and trying to make an out of the box solution that works for how everyone wants them to work is hard/impossible. The current implementation added multiple CDRs for a channel/call, and even that still doesn’t completely reflect how some people want them to work. This is why CEL was added long ago. I’m not saying to use CEL, but it was made to give the events to be able to construct billing records based on external business logic.

[valmison]

Thank you, but my problem with CDR was solved by changing the Answer() to Progress() in the dial plan.

[valmison]

The CDR problem was resolved by changing Answer() to Progress() in the dial plan.

However, it didn’t work for the second scenario, since sending DTMV only works if my dial plan contains Answer().

[jsmith]

@valmison

However, it didn’t work for the second scenario, since sending DTMV only works if my dial plan contains Answer().

It’s entirely possible that your upstream provider isn’t passing DTMF until you answer the call. From their perspective, this is entirely reasonable – you shouldn’t be able to get inbound DTMF if you haven’t yet answered the call, as you’re likely not paying for the call until you answer it.

I’ve worked with literally dozens of carriers over my 18+ years of using Asterisk that behave this way, on both T1/PRI and SIP providers.