[asterisk-bugs] [JIRA] (ASTERISK-24138) dial: Call forwarding information presented through AMI/ARI is wrong

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-24138:
-----------------------------------

    Status: Open  (was: Triage)

> dial: Call forwarding information presented through AMI/ARI is wrong
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-24138
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24138
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_dial, Core/ManagerInterface, Resources/res_ari
>    Affects Versions: 12.4.0
>            Reporter: Matt Jordan
>
> There are several issues currently with how call forwarding is handled in {{app_dial}}.
> # When a call forward occurs, the current dial attempt is not completed before a new dial attempt is started. From the perspective of listeners on the Stasis message bus, this appears as:
> ** Dial starts between A and B
> ** Dial starts between A and C
> ** Dial ends between A and B (due to being forwarded to C)
> {code}
>                         ast_channel_publish_dial(in, c, stuff, NULL);
>                         ast_channel_publish_dial_forward(in, original, c, NULL, "CANCEL",
>                                 ast_channel_call_forward(original));
> {code}
> Because the forwarding information is not presented until the Dial end message, we have a strange situation where dialing has started twice for a party A (which is allowed) but A is not technically in a parallel dial situation. The ordering of messages should be:
> ** Dial starts between A and B
> ** Dial ends between A and B (due to being forwarded to C)
> ** Dial starts between A and C
> # It is highly unlikely that off nominal code paths in {{do_forward}} of {{app_dial}} will not emit all messages that it should. Tests need to be written to cover those cases.
> # The publication of messages in {{stasis_channels}} currently attempts to publish the forward to the {{peer}} channel instead of the {{caller}}:
> {code}
>         if (forwarded) {
>                 struct stasis_subscription *subscription = stasis_subscribe(ast_channel_topic(peer), dummy_event_cb, NULL);
>                 stasis_publish(ast_channel_topic(peer), msg);
>                 stasis_unsubscribe_and_join(subscription);
>         } else {
>                 publish_message_for_channel_topics(msg, caller);
>         }
> {code}
> This actually works fine for AMI. For ARI, however, it poses a problem: it is highly unlikely that an ARI application in a dial situation will have subscribed to the peer. What's more, there is also a good likelihood that the peer may hang up (or forward the call) faster than a subscription can even be made (if a 302 is sent from a SIP phone, it is often because the user has told the phone to forward the calls while they are gone). As such, ARI is not receiving the Dial end notification during call forwards, which makes the situation extremely confusing.
> # Finally, AMI does not display the forward information when a call is forwarded, nor does it contain the forwarding channel. It probably should.



--
This message was sent by Atlassian JIRA
(v6.2#6252)