[Home]

Summary:ASTERISK-28687: Originate with early media option treats the call as answered which does not reflect the actual state of the call
Reporter:Vilius Adamkavicius (vilius365@gmail.com)Labels:
Date Opened:2020-01-13 05:22:18.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:PBX/General
Versions:17.0.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Linux inv-br-lab-va-2 2.6.32-754.24.3.el6.x86_64 #1 SMP Thu Nov 14 15:35:16 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux CentOS release 6.10 (Final)Attachments:
Description:In Asterisk 15 and 17 early media handling treats the call as answered and AMI state messages also report an "up" (answered) state. This does not reflect the actual state of the call.
We have recently gone from  using Asterisk 11 to Asterisk 15 and 17. Our usage of Asterisk involves programmatically placing a call on behalf of a user in a conference. We do this using the AMI originate command. We want the user to hear the provider's call progress audio, so we originate the call with the early media flag set true.
Our applications also monitors the connection state of the call via AMI events. We note that when a progress indication (signifying early media) is received on the trunk (usually SIP 183 response) that the call is regarded ANSWERED in asterisk. This does not reflect the true state of the call. We feel that the discrepancy between the actual state of the call and presented state of the call is radical enough to be considered as a bug. This may be considered serious, as a call over a SIP trunk might incur charges if answered. The current functionality inhibits the ability to determine if the call is incurring a charge by the provider. Any reports generated from data relating to such calls may be grossly misrepresentative.

I note substantial changes between Asterisk 11 and 15 with respect to "dial" functionality
In appears that the current handling of calls receiving early media as being answered is explicitly deliberate in the code.    

We hope the Asterisk developers recognise this issue and make this behaviour configurable.

We have found that normal behaviour is restored if the "dial->state = AST_DIAL_RESULT_ANSWERED" is delayed. locating this line as shown below will connect the voice path and complete any originate
without indicating the call state is up/answered. Should the call be answered at the remote end, the state "up" is then reported appropriately at that point.

{noformat}
dial.c
static enum ast_dial_result monitor_dial(struct ast_dial *dial, struct ast_channel *chan)
...
                               /* Attempt to read in a frame */

                               if (!(fr = ast_read(who))) {

                                               /* If this is the caller then we switch state to hangup and stop */

                                               if (chan && IS_CALLER(chan, who)) {

                                                               set_state(dial, AST_DIAL_RESULT_HANGUP);

                                                               break;

                                               }

                                               ast_channel_publish_dial(chan, who, channel->device, ast_hangup_cause_to_dial_status(ast_channel_hangupcause(who)));

                                               ast_hangup(who);

                                               channel->owner = NULL;

                                               continue;

                               }



                               /* Process the frame */

                               handle_frame(dial, channel, fr, chan);



                               /* Free the received frame and start all over */

                               ast_frfree(fr);

               }



               // ***************** add 2 lines ****************

               if (dial->state == AST_DIAL_RESULT_PROGRESS && dial->state_callback )

                               dial->state = AST_DIAL_RESULT_ANSWERED;

             

               /* Do post-processing from loop */

               if (dial->state == AST_DIAL_RESULT_ANSWERED) {

                               /* Hangup everything except that which answered */

                               AST_LIST_LOCK(&dial->channels);

                               AST_LIST_TRAVERSE(&dial->channels, channel, list) {

                                               if (!channel->owner || channel->owner == who)
{noformat}
Comments:By: Asterisk Team (asteriskteam) 2020-01-13 05:22:18.907-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.