Re: ARI: add channel to bridge immediatelly after originate action

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Joshua,

I've tried it with latest version 14.2.1 and I'm quite satisfied how it
works except one thing. Here is the flow:

1. IN call comes to stasis app
2. app creates bridge and adds channel to it
3. app creates new OUT channel for dialing and adds it to the same bridge
4. app dials on out channel
5. when one of the channels disconnects, app tries to destroy bridge. After
that, following events are received from asterisk:
	- 'ChannelLeftBridge' for IN channel
	- 'ChannelLeftBridge' for OUT channel
6. app hangup other channel

The problem is that 'BridgeDestroyed' event never comes. In version 13, as I
recall, this event was sometimes fired, sometimes not, but bridge was in
most cases or always destroyed. But in v 14, bridge is not really destroyed,
it is still listed with ari/bridges request. E.g. response is following:

{
  "video_mode": "talker",
  "name": "CONF-1484303820.435",
  "id": "C-1-40",
  "bridge_class": "stasis",
  "technology": "simple_bridge",
  "bridge_type": "mixing",
  "creator": "Stasis",
  "channels": []
}

As you can see, creator is Stasis, and there are no channels inside. Looks
like that bridge is not properly destroyed on delete http command and it
will hang forever in asterisk. Good thing is that app can again later create
bridge with the same ID, so this problem is not fatal, but it's not nice to
see a lot of 'hanging' unused bridges.

Can you check this?

Thanks a lot, Marin


-----Original Message-----
From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx
[mailto:asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Joshua Colp
Sent: Tuesday, October 25, 2016 3:15 PM
To: Asterisk Application Development discussion
Subject: Re:  ARI: add channel to bridge immediatelly
after originate action

Marin Odrljin wrote:

<snip>

>
> Events that are odd to me are:
>
> 1.ChannelDialplan - DialplanApp is ' AppDial2' (my ARI app is called
> differently, I assume this is some native Asterisk app that does the
> originate work)

This is correct. That's the name that the underlying API puts in for 
that information when originating out.

>
> 2.StasisStart is not received yet. It will come after destination is
> answered, so after event: ChannelStateChange (Up). Probably this is the
> essence of the problem.
>
> As soon as event ChannelStateChange (Up) comes, app can successfully add
> outbound channel to bridge, event if it is started before StasisStart
> event comes. But I would like to add channel to bridge before it is
> answered, so channels are already bridged in the moment they are both
> connected.
>
> Can somebody please tell me if this behaviour is intended and fine? Or
> maybe I have to use different approach to solve the problem?

This is expected in 13. There is no support for dialing a channel and 
interacting with it to that level before it has been answered. The 
closest you could do is originate to a Local channel that does an 
Answer() and then does the Dial(). Support for what you want was added 
in 14[1] though.

[1] http://blogs.asterisk.org/2016/08/24/asterisk-14-ari-create-bridge-dial/

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev


_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev



[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux