#dial to multiple recipients

[Srushti Ambekallu]

I'm facing a particular issue and I need to know if the behaviour is as expected. On an incoming call I'm attempting to make a #dial to multiple recipients, and I'm trying join the incoming call with the first one to confirm (using a confirmation controller).

    dial [number1, number2, number3], confirm: MyConfirmationController

The problem is, the other outgoing calls get dropped as soon as one of them answers, and before the confirmation controller runs through. I would have assumed it would wait for the confirmation controller to finish executing.

If this is a bug I can report it as one on GitHub. If it's working as expected but can be made to work the way I want (perhaps based on an option) I'll open a feature request. Or it's possible it's just a technical limitation.

I'm using Adhearsion with FreeSWITCH if that makes any difference.

Thanks,
Srushti

[Ben Langfeld]

This is indeed the intended behaviour. Can you confirm that you would like "first to confirm" semantics? How would you like to deal with legs that are answered and half way through confirmation when another leg wins the race?

Please do open a feature request ticket.

Regards,

Ben Langfeld

--
You received this message because you are subscribed to the Google Groups "Adhearsion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adhearsion+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ben Klang]

On May 10, 2013, at 9:10 AM, Ben Langfeld <b...@langfeld.co.uk> wrote:

This is indeed the intended behaviour. Can you confirm that you would like "first to confirm" semantics? How would you like to deal with legs that are answered and half way through confirmation when another leg wins the race?

While I can see it adds complexity, I can see "first to confirm" being the less surprising (and therefor correct) behavior.  For example, I often use confirmation controllers to allow me to call other systems which may have voicemail, like cell phones.  When cell phones are off or out of range calls often go straight to VM.  In those cases I still want my other destinations to ring.  My cell voicemail will pick up almost immediately, but it will never confirm the call, so I want the chance to confirm on other legs.

There is a small possible UX problem in simply hanging up if another leg wins the confirmation race, but perhaps we could have a callback right before hanging up so an application developer could play a message saying "Another party has already accepted this call."

/BAK/

-- 

Ben Klang

Principal/Technology Strategist, Mojo Lingo

bkl...@mojolingo.com

+1.404.475.4841

Mojo Lingo -- Voice applications that work like magic

http://mojolingo.com

Twitter: @MojoLingo

[Srushti Ambekallu]

I've created a feature request for this (https://github.com/adhearsion/adhearsion/issues/305).

I agree with Ben Klang, the current behaviour was certainly the more surprising one for me, so much so that I had to double-check to make sure I wasn't using Adhearsion wrong.

I also liked the idea of the callback to allow us to clean up the call before hanging up on anyone else in the process of confirming.

The last question to answer is do we try to keep both behaviours and switch between them with an option or just move to the new one? And if we do keep both, what becomes the default?

Thanks,

Srushti

[Ben Klang]

On May 11, 2013, at 5:13 AM, Srushti Ambekallu <srs...@gmail.com> wrote:

I've created a feature request for this (https://github.com/adhearsion/adhearsion/issues/305).

I agree with Ben Klang, the current behaviour was certainly the more surprising one for me, so much so that I had to double-check to make sure I wasn't using Adhearsion wrong.

I also liked the idea of the callback to allow us to clean up the call before hanging up on anyone else in the process of confirming.

The last question to answer is do we try to keep both behaviours and switch between them with an option or just move to the new one? And if we do keep both, what becomes the default?

I'm inclined to treat the current behavior as a bug, because a confirmation controller that hangs up before confirmation isn't terribly useful.  For that reason, unless someone comes up with a compelling use case, I'm inclined to fix the bug.  That means changing the behavior to not disconnect any calls until one of them passes confirmation, then disconnect all the rest.

/BAK/

[Luca Pradovera]

I agree, this could be useful in applications.

What happens if two dialed calls are in the confirmation controller at the same time and one finishes first?

--

Luca Pradovera

luca.pr...@gmail.com

[Ben Klang]

On May 11, 2013, at 8:56 AM, Luca Pradovera <luca.pr...@gmail.com> wrote:

I agree, this could be useful in applications.

What happens if two dialed calls are in the confirmation controller at the same time and one finishes first?

I addressed this case in my first email: in the simplest case, the losing call would simply be hung up.  In my example case, that call leg would only have something like voicemail on the other end anyway, so we didn't actually hang up on anyone.  However I can see cases where it might be useful to play a message before terminating, which is why I suggested a callback to allow prompting the losing channel: "This call has already been taken by another party."

/BAK/

[Srushti Ambekallu]

I agree that the current behaviour should be considered a bug, but I was wondering if anyone has gotten used to it and actually expects it, but that's unlikely, I guess.

I had a separate thought about the confirm_metadata. Will that hash be shared across all active confirmation controller instances?

Thanks,

Srushti

[Ben Langfeld]

So I do think we should support the case of "first-to-confirm". I also agree that it should be the default and the existing behaviour can be considered a bug. Really, I regret adding confirmation controllers to #dial, and should have implemented #dial_and_confirm instead. Handling confirmation controllers causes a significant branching in how #dial works. One option would be to implement these changes in #dial_and_confirm, and deprecate the usage of #dial for confirmation controllers. That gets around both problems at once.

As for the case of handling mid-confirmation disconnection - does anyone have any suggestions about a nice API for this? I can come up with something, but if you let me know what would be simplest in your app, that's a good starting point.

Srushti: confirm_metadata is shared, yes. This should probably be documented better. If you want to avoid concurrent mutation issues, you should pass something immutable :) I'd love a pull request clarifying this in the documentation.

Regards,
Ben Langfeld

[Srushti Ambekallu]

Srushti: confirm_metadata is shared, yes. This should probably be documented better. If you want to avoid concurrent mutation issues, you should pass something immutable :)

The reason that occurred to me was I'm sort of cheating by setting some values on an object that represents the phone call from our perspective in the metadata to return back to the original controller. We want to know who ended up confirming the call and at what precise moment the call started (the moment when the two calls were connected), which we then subtract from the moment when the call ends (the line after the #dial call).

I know these are multi-threaded but I was counting on only one being active at a given moment. In my own situation the update to the object I'm making will still only happen on one thread, but I'm more aware of what I'm probably doing wrong with multiple threads sharing my object now.

With that in mind, is there a more accepted way to pass arbitrary metadata back, and more specifically get the call duration (between joining till one of them hangs up) and which number actually got connected to from the CallResult object. The documentation doesn't seem very clear on this or at least I'm not reading it clearly.

Thanks,

Srushti

[Ben Langfeld]

On 13 May 2013 02:56, Srushti Ambekallu <srs...@gmail.com> wrote:

Srushti: confirm_metadata is shared, yes. This should probably be documented better. If you want to avoid concurrent mutation issues, you should pass something immutable :)

The reason that occurred to me was I'm sort of cheating by setting some values on an object that represents the phone call from our perspective in the metadata to return back to the original controller. We want to know who ended up confirming the call and at what precise moment the call started (the moment when the two calls were connected), which we then subtract from the moment when the call ends (the line after the #dial call).

I know these are multi-threaded but I was counting on only one being active at a given moment. In my own situation the update to the object I'm making will still only happen on one thread, but I'm more aware of what I'm probably doing wrong with multiple threads sharing my object now.

You should really consider anything you pass in there to be inherently unsafe. Anything could happen to it. I'll add better documentation about that.

 

With that in mind, is there a more accepted way to pass arbitrary metadata back, and more specifically get the call duration (between joining till one of them hangs up) and which number actually got connected to from the CallResult object. The documentation doesn't seem very clear on this or at least I'm not reading it clearly.

These kind of details are not currently accessible. We should add a bunch of these kinds of metrics to the DialStatus we return. Can we make a list of things we think would be useful?

[Srushti Ambekallu]

Can we make a list of things we think would be useful?

Let me tell you the stuff we'll need (& are having to hack potentially non-threadsafe operations to get currently):

1) Successfully joined number (assuming there was one)

2) Joined call duration (the time from when the incoming & outgoing were joined to when either of them hung up)

3) Results of all attempted outgoing calls [successfully joined/cancelled/rejected(didn't finish confirmation)/hung up on(because someone else finished confirmation)]

Thanks,

Srushti

[Srushti Ambekallu]

As for the case of handling mid-confirmation disconnection - does anyone have any suggestions about a nice API for this?

There are two approaches I can think of. Explicit or implicit (convention over configuration).

Either we #dial, or rather #dial_with_confirm, with another option. Something like,

dial_with_confirm numbers, ConfirmationController, confirm_metadata: {}, confirmation_termination_callback: :cleanup_after_alternate_confirmation

The problem with this it breaks encapsulation a bit. Our original controller needs to know what method in the ConfirmationController needs to be called.

The second option, is to define another standard method like #run which you can define on your confirmation controllers. So, if a particular confirmation controller implements a #on_confirmation_termination method, that gets called on any calls in mid-confirmation when someone else has successfully confirmed.

I would prefer the second, although it feels like the old-style activerecord callbacks. I'm not sure we want to go the macro-style for this, but that could work too.

Thanks,

Srushti

On 11-May-2013, at 10:42 PM, Ben Langfeld wrote:

[Srushti Ambekallu]

To separate the discussion about the data we need returned in the CallResult from the multiple recipients discussion, I've created an issue on GitHub. If there's anything else others need please add them there (although judging from the fact there hasn't been anything more on this thread about it I guess there isn't).

https://github.com/adhearsion/adhearsion/issues/318

Thanks,

Srushti