If I make a regular call via softphone from one local extension to another, while the party B phone is ringing, we have the following channel states: Channel_A: Ring, Channel_B: Ringing.
If I initiate a call via Originate (AMI, console, dialplan app, doesn’t matter), after the first softphone answers and starts to hear the progress tone and while the second phone is ringing, we have the following channel states: Channel_A: Up, Channel_B: Ringing.
I never use the Answer() app in the dialplan, but despite this in the second case the Channel_A state is already Up before two channels are bridged.
As a consequence, I have a CDR problem where the answer time and the billsec field values are set incorrectly (these fields are not null for the unanswered call and the billsec counts from the party A answer, not party B which in case of originate doesn’t make sense).
Is this behaviour intended or maybe this is a bug?
Is it possible to somehow change this originate app behaviour (some walkaround) not to put the first channel in the Up state before the second party answers?
While reading about the possible causes, I also tried to reproduce the example with originate and local channels described here Asterisk 12 CDR Specification, particularly the section captioned “Local channel between bridges”. This might be my case, I thought, but the actually generated CDR records differ from the described (my Asterisk generates the same answer time for both CDR records with no 10 sec difference as is in the example).
Firstly both legs are outgoing, so the transient state is Ringing.
Secondly, the dialplan, or application, to call the B side isn’t started until the A side has answered. When A has answered, the call is up on that side.
Is it possible then to initiate a call from the asterisk side (like originate does) where it would be CDRed like a regular Dial call? With just the actually bridged time billed.
Unfortunately ForkCDR and ResetCDR (or even CDR_PROP(“disable”) toggle) don’t do the thing. I already tried to put them just before the Dial that calls the B-party (or from the b-/B-handlers of the Dial or Originate calls), because the call is considered answered already, so the event of B-party answer doesn’t affect the resulting CDR in any way (so I cannot deduce its timing from the resulting CDR).
int ast_cdr_reset(const char *channel_name, int keep_variables) {
...
/* Reset to initial state */
...
cdr_object_check_party_a_answer(it_cdr);
}
static void cdr_object_check_party_a_answer(struct cdr_object *cdr)
{
if (cdr->party_a.snapshot->state == AST_STATE_UP && ast_tvzero(cdr->answer)) {
cdr->answer = cdr->lastevent;
...
}
}
As far as I can understand, if the party A channel state is Up when ResetCDR is called, the new CDR record’s “answer” field value is set instantly (before the actual party B’s answer). And that’s exactly what I get doing live tests.
Well, if the maintainers are ignoring the originate app CDR problem since the Asterisk 13 release (and I’ve found quite enough threads about it even here), it seems to write a patch by myself is the only solution I end up with.