Asterisk skips local channel bridges - how to prevent?

Okay, so multiple things here.

You have to call “dial” on the created “;1” channel for the “;2” to actually go anywhere. This is the way things work because it’s a two stage operation. Create lets you set things up and add it to the bridge. You’re not actually going anywhere or dialing until you dial. Did you do that?

Secondly on originate the “;1” won’t go anywhere until the the “;2” leg is answered. Did you do that?

Oh, thirdly, the “;2” will always go to dialplan because that is its purpose. It dials an extension and context in the dialplan. The “app” specified to originate is for the “;1” leg only.

As for subscribing originator, I don’t know with any certainty but probably to get events as they are related. Even if a channel isn’t in ARI you can still subscribe to receive events about it to know what is going on.

I think the OP just wants a piping adaptor with two channel type ends, rather than the two bridge type ends that a bridge creates or the one that the dialplan provides. He hasn’t considered that these bits of piping have answered/unanswered states, and whilst it looks to him that local channels have the two ends of the right type, but he doesn’t like that fact that they always come plugged into a dialplan.

(The piping analogy I’m thinking of is the one used for garden hoses, where taps and tools come with male connectors and hoses come with female ones, but you can buy double ended male connectors to join two hoses together. I’m treating the hoses as being bridges, and the double ended male adaptor as being a local channel. I can probably push the analogy a bit two far, but one of the things he doesn’t like is that, in the Asterisk case, the adaptor has an on/off valve, and you can’t buy it on its own.)

As I’ve shown previously, ARI channels/create doesn’t trigger the dialplan - it just runs the technology requester then subscribes the one channel it returns into stasis and returns it. No dialplan to either channel.

But the technology requester for the local channel does trigger the dialplan, and that is fundamental to local channels.

If you’re referring to the “;2” leg then request does not trigger the dialplan. call does. Request merely creates the state, it doesn’t execute the dialplan.

You first request a channel, then you update it as needed/do other things, once ready to actually call then you call it. Originate lumps this all into one operation, in ARI the create/dial breaks it apart into two operations. Until dial is called on the channel in ARI then nothing will happen.

So this is the flow that I’m trying to use - I already use it successfully with a SIP channel - a bridge is created (where other stuff may be put in before or after) and then I create a SIP channel, put it in the bridge and dial it (according to the BKM article I linked before).

But I can’t get it to work for “Local” channels - I have two bridges (where the reason for their existence and why I can’t have a single bridge is out of scope from this discussion) and I want to use a “local channel set” to stream media between the two. I thought it should be trivial to do channels/create and then control “both ends” of the “local channel” and put them into the appropriate bridges.

Unfortunately, only the “;1” “end” of the local channel is put into stasis so I can control it with ARI - the “;2” remains outside stasis and outside the dial plan and AFAIK there is no way to control it.

Correction - I couldn’t get it to work. I wrote this patch for res/ari/resource_channels.c which uses the same API that ari_channels_handle_originate_with_id() uses, in ast_ari_channels_create() to connect the “;2” side of the local channel into stasis and now I can control both ends and my workflow works.

You can’t just do “channels/create”. You have to also call “channels/dial”[1]. Until this is done, then nothing happens and the “;2” channel would go nowhere. Did you ever do this? You haven’t stated one way or the other if you ever did, and you never showed what actually happened when you did. As well you’d need to answer the “;2” channel.

I can’t look at your patch as it’s unlicensed, so if it works for you then that’s fine but I truly believe that this can be achieved without code changes.

[1] Asterisk 19 Channels REST API - Asterisk Project - Asterisk Project Wiki

Actually, I know it can because I just looked at a customer script for demonstrating an unrelated issue and it does exactly this. The order of operations in the script:

  1. Create bridge ‘a’
  2. Create bridge ‘b’
  3. Create Local channel with channelId of ‘test1’ and otherChannelId of ‘test2’
  4. Calls dial on ‘test1’
  5. Calls answer on ‘test2’
  6. Adds ‘test1’ to bridge ‘a’
  7. Adds ‘test2’ to bridge ‘b’

I did try to dial, but got “channel not in stasis”. I did not try to answer - I’m assuming it will have the same issue (“Channel not in stasis” is documented as a possible error).

How would I go about submitting the patch in a way that it can be considered for including in Asterisk?

Which channel were you dialing? You would have to dial the “;1” leg. If you dialed the “;2” leg then you would get that exact message.

As for the patch, the wiki has documentation on the contribution process[1] but just from what you’ve said I do not believe it would be acceptable for inclusion.

[1] Patch Contribution Process - Asterisk Project - Asterisk Project Wiki

What happens with you “dial” the local channel? I don’t want it to leave stasis.

The “;1” leg remains in Stasis, and provided the Local channel is dialing into Stasis then the “;2” leg will also appear in Stasis afterwards.

Thank you, I will try that.

@jclop - thank you: that was the use case description I was looking for initially (well not initially - initially I thought the problem was something else entirely - but about half way through this thread :sweat_smile:).

I tried the setup that you specified and indeed after running channels/<channelId>/dial, “;2” started running the dial plan and with the correct context it entered stasis, after which I can call channels/<otherChannelId>/answer and the workflow continued as expected.

I wish your article at Asterisk 14 ARI: Create, Bridge, Dial. ⋆ Asterisk would include a mention of how this process would work for Local channels. I understand that it may be trivial to people used to using local channel dialing in a dial plan (as I was told today by an Asterisk veteran), but I’m not one of them and it was not obvious for me.

Thank you for suffering through my misunderstandings!