[asterisk-dev] Proposed changes to Originate Action [Issue: 0017221]

Timothy Rodriguez timothy.rodriguez at gmail.com
Tue Apr 27 09:46:06 CDT 2010


These all look like really positive changes. How will the events
appear when using local channels?

I've been using the asterisk-java API and it can't successfully
provide a returning channel object because the event stream is
different with local channels as opposed to normal channels, due in
part to the masquerading it seems.

-Tim

On Apr 27, 2010, at 10:35 AM, Ryan Bullock <rrb3942 at gmail.com> wrote:

> I have suggested some changes to how the Originate action behaves and
> I also submitted a patch that changes the behavior.
>
> Here is an overview of what it changes and fixes compared to the
> current Originate action.
>
> Currently the Originate action for the manager interface behaves very
> inconsistently when compared to other manager actions.
>
> The major problems I see are:
>
> 1. The output and information returned is different between 'Async: 0'
> and 'Async: 1'
> 2. With 'Async: 1' it returns two packets that are a 'Response'
> packet, the second is actually a 'Response' and an 'Event' packet.
> 3. If you do not have call events enabled and have 'Async: 1' you will
> never get the event generated by action. This is not the case with
> other actions, which will send events regardless of the eventmask for
> the connection.
>
> This patch makes the following changes:
>
> 1. It will always create the outgoing call asynchronously. The Async
> option has been removed.
> 2. It will always respond on the manager connection, regardless of the
> eventmask.
> 3. It checks the validity of the tech for the channel, existence of
> the exten/context/priority, existence of the application. If these
> fail it immediately returns with an error.
> 4. It includes the Application and Data, or Exten/Context/Priority in
> the response event depending on which is used. (Old behavior always
> included Exten/Context/priority regardless of what was used)
> 5. The 'Response' line in the event is removed in favor of 'Result'
> which contains the text equivalent of 'Reason'.
> 6. It will always respond to an action as follows: Response Packet,
> EventResponse, EventComplete. If there is an error before the outgoing
> call is made it will only respond with a Response Packet.
>
> I also believe that the old action would send the action response out
> on all manager connections when 'Async: 1'. The event contained the
> ActionID which could cause some odd problems when multiple users are
> involved. The new one only sends the response to the appropriate
> manager session.
>
> Their is some sample output from the patch in the ticket
> (https://issues.asterisk.org/view.php?id=17221).
>
> What do others think of the proposed changes? At the very least I feel
> that the Originate action should be changed to be more in-line with
> other actions.
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list