Hi Mark, I think you can guess my possition on this, but I'm all for an event and handling this myself. IN fact, I think that's far more powerful and will give the developer control, which I am always in favour of. With relation to backwards compatability, I do see your point. However, I think because your introducing something new, IMHO this is prefectly acceptable. It's possible this could be handled with an option in Originate of course to provide default backwards compatability... AutoForward for example (default false). This would follow with SemVer of ARI too, but it depends of course on the complexity of offering both options. That I leave in your far more capable hands. For me, ARI is the bridge between Asterisk and app_*. The fact we give more control to the developer is always preferable, because then ARI feels less of a second class citizen to anything before it. Thanks once again for your hard work. :) Skrusty/Ben > -----Original Message----- > From: asterisk-app-dev-bounces@xxxxxxxxxxxxxxxx [mailto:asterisk-app-dev- > bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mark Michelson > Sent: 11 April 2016 19:33 > To: Asterisk Application Development discussion <asterisk-app- > dev@xxxxxxxxxxxxxxxx> > Subject: ARI Early Bridge Development: Call Forwarding > > Hi folks, > > You may recall that I sent an e-mail [1] out about a month ago saying that I > was working on implementing some new ARI methods for Asterisk 14 that > would allow for bridging calls early, the idea being that this would allow for > situations like allowing early media to be bridged to callers. What I have > created so far are two new ARI methods: one that creates a new channel, > and a second that dials that channel. You are free to place the newly created > channel into a bridge and then dial it, or you can create the channel, dial it, > and then add it to the bridge based on some channel state change (like if it > starts ringing). I've got basic operations working really well right now, and > now I'm investigating the more interesting corners of the feature. > > This has led me to an issue regarding call forwarding. In the interest of > brevity, I'll just say that call forwarding does not play well with ARI's threading > when it comes to bridged channels. I fear that attempting to handle call > forwards automatically within Asterisk will require jumping through some > hoops resulting in the potential for errors to occur. > > I would like to propose a solution to this. Instead of having Asterisk > automatically handle call forwards when performing an ARI dial, raise an > event stating "Outbound channel X wants to forward the call to Y". This way, > the ARI application writer can act on this event as desired. You can ignore the > call forward attempt altogether. You can look up who Y is and forward the call > manually. You can check some presence database and forward to Y's > voicemail instead of Y. You can say "screw you X" and forward the call to Z > instead. > > The upsides to this are that > 1) It places the ARI author in complete control of the destination of the call. > Automatic behavior from Asterisk is limited, and there will be no surprises. > 2) By always dialing outbound calls from the ARI application, we can assure > that channels are being tracked as expected and there are no hoops that we > have to jump through internally to ensure that everything is set up properly. > > The big downside I can think of is that the current ARI originate command > does automatically perform call forwards. This would introduce an > inconsistency in the behaviors of the two methods of making outbound calls. > > What is the list's opinion on the proposal for handling call forwards in the new > ARI dial command? > > Thank you very much, > Mark Michelson > > [1] > http://lists.digium.com/pipermail/asterisk-app-dev/2016-March/000769.html > > _______________________________________________ > asterisk-app-dev mailing list > asterisk-app-dev@xxxxxxxxxxxxxxxx > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2016.0.7497 / Virus Database: 4545/12010 - Release Date: 04/11/16 _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
