Subject: [MEDIACTRL] draft-ietf-mediactrl-ivr-control-package-03 and <control>

From: Christian Groves <[email-masked]>
Date: Fri, 12 Dec 2008 11:49:03 +1100

Hello,

I'm having a look at the <control> element in section 4.3.1.2. of the 
IVR draft. Towards the end of the section it describes the interactions 
between the different keys. Several sets of interactions do not seem to 
be explicitely described, what happens when playback is paused and keys 
other than "resume" are pressed?

There is a text:

 2.  Runtime controls are active only during prompt playback (if no
       <prompt> element is specified, then runtime controls are
       ignored).

Does this mean that key presses other than resume are ignored?

Or is the correct behaviour that the key press action is applied?
ie. During pause if fast forward is pressed playout will commence at the 
skip interval past the pause point
During pause if volume up is pressed will the volume increase X percent 
when the resume key is pressed? or does playback start automatically 
with a volume increase of X percent?

On a side point I assume that there should also be text regarding what 
happens when the speed operations go beyond what is supported.

Regards, Christian
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 19 Dec 2008 11:56:35 +0000

Hi Christian,

Thanks for your perceptive comments and apologies for the delay in replying.

A. Pressing control keys when playback is paused. The spec could be clarified along one of two lines:

1. speed/volume/skip operations are applied but pause-resume state is unchanged.

2. speed/volume/skip operations are applied AND playback is automatically resumed if required.

Most use cases I'm aware of would work well with option 2. Let me know if there are any objections to clarifying the spec with option 2.

B. Speed/volume settings beyond what is supported. This would result in an execution error (status=4) reported in a <dialogexit> notification event. I'll clarify this in the next version if there are no objections.

thanks

Scott

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christian Groves [[email-masked]]
Sent: Friday, December 12, 2008 01:49
To: [email-masked]
Subject: [MEDIACTRL] draft-ietf-mediactrl-ivr-control-package-03 and    <control>

Hello,

There is a text:

Regards, Christian

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 19 Dec 2008 13:55:13 +0100

Hi,

just a small thought about B. I'm not sure an execution error would be  
a good idea for that situation: having a whole dialog fail and  
terminate because of a UAC raising too much the volume is a bit too  
strict IMHO. How about having threshold values, and just ignoring  
requests that try to overcome it instead? To give proper feedback to  
the AS and not silently fail, we might just add to the dtmfnotify  
event information about the impossibility to enforce what the tone  
requested to: what do you think about it?

Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> Most use cases I'm aware of would work well with option 2. Let me   
> know if there are any objections to clarifying the spec with option 2.
>
>
> B. Speed/volume settings beyond what is supported. This would result  
>  in an execution error (status=4) reported in a <dialogexit>   
> notification event. I'll clarify this in the next version if there   
> are no objections.
>
> thanks
>
> Scott
>
>
>
>
>
> From: [email-masked] [[email-masked]] On   
> Behalf Of Christian Groves [[email-masked]]

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Dec 2008 16:03:55 +1100

Hello Scott,

I'm happy to continue along the lines of 2.

With regards to item B my point was that the text already says that 
volume operations that go beyond the max and min will be ignored. 
However there was no such text for speed. ie. in 4.3.1.2 /"If a volume 
operations attempts to go beyond the minimum or maximum volume supported 
by the platform, then the operation is ignored."/

If you clarify according to your proposal below then the behaviour will 
change from the existing specified behaviour. I'm not sure even 
reporting the fact through signalling is worthwhile because a user will 
receive immediate feedback when he presses a key and the volume doesn't 
continue to increase or decrease.

Regards, Christian

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 22 Dec 2008 11:27:52 +0000

Agreed, raising an error is probably not the best solution. Any objections to treating all controls like volume so that changes beyond the platform min/max are ignored?

Scott
________________________________________
From: Lorenzo Miniero [[email-masked]]
Sent: Friday, December 19, 2008 13:55
To: McGlashan, Scott
Cc: Christian Groves; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-ivr-control-package-03 and        <control>

Hi,

Lorenzo

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 22 Dec 2008 11:30:27 +0000

Any objections to treating all controls like volume so that changes beyond the platform min/max are ignored?

Scott

________________________________________
From: Christian Groves [[email-masked]]
Sent: Monday, December 22, 2008 06:03
To: McGlashan, Scott
Cc: [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-ivr-control-package-03 and        <control>

Hello Scott,

Regards, Christian

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Dec 2008 18:42:56 -0500

[As participant]
  You should guess my answer: no one checks error codes, anyway :-)

On Dec 22, 2008, at 6:30 AM, McGlashan, Scott wrote:

>> B. Speed/volume settings beyond what is supported. This would  
>> result in an execution error (status=4) reported in a <dialogexit>

---

From: Christian Groves <[email-masked]>
Date: Tue, 23 Dec 2008 11:16:39 +1100

Hello Scott,

No problems from my side.

Regards, Christian

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 23 Dec 2008 10:57:35 +0100

That works for me.

Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> Agreed, raising an error is probably not the best solution. Any   
> objections to treating all controls like volume so that changes   
> beyond the platform min/max are ignored?
>
> Scott