Subject: [MEDIACTRL] Open Issues for IVR and Mixer packages

From: "McGlashan, Scott" <[email-masked]>
Date: Wed, 15 Oct 2008 12:21:10 +0000

Both IVR and Mixer packages have been recently updated and posted as requested by the chairs at IETF 72 in Dublin.

IVR: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-ivr-control-package-01.txt

Mixer: http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-mixer-control-package-01.txt

The changes arise from discussion at IETF 72 in Dublin, RAI comments on IVR package, mailing list comments and issues arising from implementation experience. The changes between version -00 and version -01 are logged in a "Change Summary" Section of both documents (Section 9 in the IVR package, Section 10 in the mixer package).

If you have any open issues with these control packages, please send them to the mailing list so we can discuss them at the Interim teleconference this Friday. The chairs are keen to get these packages done by IETF 73 and "STRONGLY encourage that WG participants offer comments on WG documents prior to the end of WGLC ("there is no penalty for getting WGLC comments in EARLY ...")", to quote from the IETF 72 minutes.

We can start with the following open issues already identified in the packages themselves ("IVR-NNN" and "MIXER-NNN" in the text as editors notes):

[1] IVR Package

- No known open issues (but MIXER-009/MIXER-010 shared with this package)
- Thorough review of the security section required
- Check with RAI reviewer on changes (editors)

Next Steps: We believe this version (or minor update) is ready for WGLC.

[2] Mixer Package

(Issues in document order)

MIXER-003 (<video-layout>, 5.2.1.4.2.1). ASCII art help required to draw the layout and name the regions for the remaining XCON layouts. [ Mary Barnes has already volunteered and the next version will include Mary's diagrams.]

MIXER-008 (<join>, 5.2.2.2). Should the draft allow multiple joins of the same user to the same conference? a (maybe silly) use case for this might be having a user's video appear in 2 different regions of the same conference. With the current specification an "already joined" 425 error would be generated, considering that the same connection/conference can only be attached once to each other. (Lorenzo)

MIXER-009 (<join>, 5.2.2.2). The package isn't clear on the behavior of connectionid with a label part (i.e. from~to~label) permitted in Section 17.1 of the Control Framework. Connection identity: how is from1~to1 and from1~to1~label1 related to one another? If from1~to1 is unjoined, then is from1~to1~label1 also unjoined? Some possible approaches: (a) remove connectionids with label part from the Control Framework? (like this package, other packages can use a <stream> element to control the behavior). (b) explicitly specify this package does not support the label part of connection (or make a 'special' feature in the Control Framework). Or (c) clarify usage in Control Framework and this package. (Lorenzo)

MIXER-010 (<stream>, 5.2.2.5). "inactive" value: clarify that this value means the stream is not established. Alternative: it is established but no send/receive media flow. This has an impact when a <modifyjoin> makes an established stream inactive (removed?), or a previously inactive stream is made active in sendrecv direction, for example.

MIXER-006 (<joinaudit>, 5.3.2.2.2). Do we need to specify stream information associated with the join?

Generally, we need more examples in the next version  - Section "7. Examples" is a too thin.

Next Steps: Version -02 (with above issues addressed) should be ready for RAI review, followed by WGLC.
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 17 Oct 2008 12:01:52 +0200

Hi all,

here's a couple of doubts I have that may be worth discussing during  
the Interim call later. They're just doubts coming from an  
implementation point of view. I don't think any of them would require  
a change, just maybe a bit of rephrasing to better clarify some points  
for implementors.

1) The first doubt is related to the IVR draft, specifically to the  
<prompt> directive. The issue I met is related to consecutive media to  
play. Let's say you have an audio file, and then a video with no  
audio: are they to be played simultaneously, or must the order  
requested in the directive be respected and have them played one after  
another? The approach we chose in our prototype at the moment is the  
simultaneous playout, but this raises an issue for a similar use case:  
what if the video file does have an audio track as well? a  
simultaneous playback would cause the audio track from the video to be  
"shifted" when playing. I think there are many use cases that could  
benefit from the simultaneous playback of different media types, but  
if these are the possible drawbacks how should we deal with it?

2) Moving to the Mixer draft, I have a doubt related to the region  
element, which is likely to be only related to an interpretation of  
the document itself. Let's say we have a layout configuration that  
states "if there's only one active source, than use single-view,  
otherwise use quad-view", and that we have one single active source  
(Bob) with a statc region assignment to region 2. This would have the  
MS choose the single-view layout, since only Bob is active, but Bob  
would be out of it anyway, considering he's assigned to region 2. Can  
this be considered ok? In my interpretation it is, since it is mostly  
related to how the AS configures the mix ad assignments, and so is  
part of possibly flawed business logic. Do you think more  
clarifications are needed in the text instead?

3) Another doubt partly related to the region element in <join>, which  
is actually also related to other sub-elements of <stream> as well in  
the use case. We agreed on how the direction element works: it is the  
direction related to the id1->id2 direction. Is it the same for  
priority/region/volume/etc as well? To make an example: is region  
involved anytime a conference and a connection are involved (whoever  
is id1/id2), or just when the connection is id1 and the conference is  
id2 (to state "connection id1 goes to region X of conference id2)? The  
doubt came to my mind when I thought about the possibility of joining  
two conferences, instead of a connection and a conference: in such a  
case, to which of the two conferences would region, priority and the  
like apply?

That's all, I think. Some more comments are inline in response to  
Scott's issues [LM].

<cut>

> We can start with the following open issues already identified in   
> the packages themselves ("IVR-NNN" and "MIXER-NNN" in the text as   
> editors notes):
>
> [1] IVR Package
>
> MIXER-003 (<video-layout>, 5.2.1.4.2.1). ASCII art help required to   
> draw the layout and name the regions for the remaining XCON layouts.  
>  [ Mary Barnes has already volunteered and the next version will   
> include Mary's diagrams.]
>
> MIXER-008 (<join>, 5.2.2.2). Should the draft allow multiple joins   
> of the same user to the same conference? a (maybe silly) use case   
> for this might be having a user's video appear in 2 different   
> regions of the same conference. With the current specification an   
> "already joined" 425 error would be generated, considering that the   
> same connection/conference can only be attached once to each other.   
> (Lorenzo)

Thinking it through, we probably don't need such feature. At least, I  
can't think of any use case scenario for it.

> MIXER-009 (<join>, 5.2.2.2). The package isn't clear on the behavior  
>  of connectionid with a label part (i.e. from~to~label) permitted in  
>  Section 17.1 of the Control Framework. Connection identity: how is   
> from1~to1 and from1~to1~label1 related to one another? If from1~to1   
> is unjoined, then is from1~to1~label1 also unjoined? Some possible   
> approaches: (a) remove connectionids with label part from the   
> Control Framework? (like this package, other packages can use a   
> <stream> element to control the behavior). (b) explicitly specify   
> this package does not support the label part of connection (or make   
> a 'special' feature in the Control Framework). Or (c) clarify usage   
> in Control Framework and this package. (Lorenzo)

I'd say (c). But considering that <stream> can be used to address  
specific media via their label and/or type, I'm not against (a) and  
(b) either. I'd prefer (a) in this case, but then some words would  
have to be added to the framework, just as guidance, clarifying that  
any package needing access to per-label connections would need a  
<stream>-like mechanism.

> MIXER-010 (<stream>, 5.2.2.5). "inactive" value: clarify that this   
> value means the stream is not established. Alternative: it is   
> established but no send/receive media flow. This has an impact when   
> a <modifyjoin> makes an established stream inactive (removed?), or a  
>  previously inactive stream is made active in sendrecv direction,  
> for  example.

I'm for "established but no send/receive media flow". If you don't  
want the stream to be established, you just remove it. This way,  
instead, passing from "sendrecv" to "inactive" and viceversa (e.g. in  
conferences) is just like an on/off trigger, and no actual  
establishment/removal is needed.

> information associated with the join?

I'm ok with that,

> ready for RAI review, followed by WGLC.

Talk to you later at the conference call.

Lorenzo

-- 
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]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl