timers-started event

[chewi]

I am using Sippy Cup to test Adhearsion but I didn't want to rely on sleep to keep things in sync. I therefore used SIP messages as a signalling mechanism instead but still required an event to trigger these messages from. This event needed to fire when the input timers start, hence I created a timers-started event. You can see a working preliminary implementation of this at chewi/FreeSWITCH@f7c56ec4fd.

There was some discussion about exactly what conditions this should fire under and I want to get this cleared up before I start making changes to the spec.

It was suggested that it should only apply to prompt components when barge-in = false but this does not fit my use case. My prompts have barge-in = true but I still find the event useful because even though humans can barge in if they wish, I would rather have Sippy Cup wait until the prompt has completed as that is what humans are more likely to do for this particular service.

I don't believe the event should fire if the timers are to start immediately. This would always be the case for a bare input component as @crienzo says that such components either start their timers straight away or they never do.

The current code is supposed to effectively only fire the event from prompt components, irrespective of barge-in. This is how I think it should work. However, I just tested with barge-in = false, expecting it to work, and it didn't. Seemingly there is no internal start-timers command in this scenario, @crienzo?

[benlangfeld]

So, MRCPv2 does not include an event in this case, since the client is responsible for issuing the start-timers command. In Rayo, a prompt component takes this coordination responsibility, so I agree that this event should be emitted only from a prompt component. I think for consistency, it makes sense to ignore the barge-in attribute.

I'd love a PR on the spec :)

[chewi]

Wasn't too sure about the Formal Definition and XML Schema parts. You told me to use a namespace of urn:xmpp:rayo:input:1 but this still doesn't feel right.

[benlangfeld]

Namespace issue:

benlangfeld
So I do wonder about the namespace
on the one hand, this is defined on prompt only
on the other, the timers are related to the input part
13:03
Chewi
internally it gets emitted from input and then forwarded but that's an implementation detail
13:03
benlangfeld
I wonder if <input-timers-started xmlns="urn:xmpp:rayo:prompt:1"/> would be a good balance?
13:03
Chewi
works for me
13:04
benlangfeld
I guess it hinges on wether or not we would ever permit the event from an input component
13:04
Chewi
I was wondering how this might play with the CPA stuff
13:04
benlangfeld
Which we might if we added a start-paused/preload type mode to input.
13:04
Chewi
but I haven't looked at that yet
even if you do start it paused, the client would be the one to resume it so it still seems a bit redundant?
13:05
benlangfeld
There's a balance to be had, because Rayo makes a lot of assumptions for simplicity and every time we remove one we get closer to it being a better idea to just use SIP and MRCP directly.
good point
lets do the above then
13:06
Chewi
ok
13:06
benlangfeld
<input-timers-started xmlns="urn:xmpp:rayo:prompt:1"/>

[benlangfeld]

:+1: