Subject: [MEDIACTRL] My notes from the interim telechat for MEDIACTRL

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Oct 2008 09:59:18 -0500

Attending...

- Framework draft

have one open issue after last face-to-face

now have secdir review in hand, didn't require lots of changes, have changes 
in current version (along with nits)

Keith requested rephrase making it more clear what entity is required to do 
what

Secdir review has been sent to the mailing list (by Chris, on 10/16)

Thought that the secdir review was reasonable

Section 4/Section 6 interaction? Keith doesn't understand what material 
belongs in each section, doesn't think requirements are clear - switching 
terminology between client, UAC, etc... Can you put all the UAC requirements 
together, etc?

Can we agree on terminology? control client and control server? anyone 
opposed? We like that. Packages are calling them control framework server, 
etc - just drop "framework". Chris will make a consistency pass through the 
document

Steve - Breaking client and server requirements into two groups?

Not sure what requirements go in Section 4 vs Section 6? 4 is intended to be 
control channel setup, 6 is intended to be framework interactions. Keith 
will look that over given this background. Chris will add a statement in 4.1 
explaining the structure.

Chris will publish update next week for WGLC - 05 version

Keith - Section 8 has template for control packages, does template work for 
people who have drafted packages? Worked for IVR and MIXER? Scott thinks it 
works.

Eric - did you go over the changes?

Changed output from MIXER-09 version, have made changes based on Secdir 
review, we'll change based on Keith's email and make 4.1 changes that we've 
just discussed.

Keith has small number of nits - will send to the list.

Are people really using TLS? Not in existing implementations - secdir review 
asked for strong statement of what the security story really is, should be 
in 05 draft.

- IVR

Open issues - couple of things that may come up with MIXER, but security is 
the big change in this version of the draft.

Dan will review and post comments to the list - this section will be 
cut-and-pasted into MIXER as well.

Lorenzo comments -

prompt executed in sequence? Yes, no provision to play in parallel. What 
about different kinds of media? People are assuming children can be played 
in parallel - will make this clearer.

Is it common practice to have two separate source files? URI points to one 
resource, container format contains both resources. Multiple resources are 
possible and have been added to VXML, SMIL, etc. but this opens up lots of 
issues - currently out of scope, could be extended (either in IETF or 
proprietary). Is it OK if we have this limitation? It is common to have two 
resources, one for audio and one for video.

Add "parallel" element? adding complexity quickly here... Parallel playback 
for different kinds of media, so there's no expectation of mixing? Would be 
a one-week addition (Spencer is now less unhappy). Would not include 
parallel recording? Is that a proprietary MIME type? Can we have different 
destinations for recording? This is harder... does anyone need parallel 
playback without parallel recording? Only in theory, not in practice. 
Playback is easy to extend, record is multiple child elements with different 
destinations - a harder thing to do.

Assumptions about forward compatibility aren't in the draft... This would be 
a different version number for the package. Could have another package with 
own namespace doing extensions.

Does anyone need parallel record-only? Real-world is video mail, with record 
against two resources. Is it worth slowing down the draft to do parallel 
record? Steve thinks so and will review any changes in this area. Scott will 
include this in next week's version of the draft.

Keith - think the document structure does not match the structure of the 
template. Templates mandate sections (example is missing), mandates 
compatibility statements, MIME type for control bodies, etc...

Scott will make these additions to match the template, making sure IVR is 
aligned.

Do structures actually have to match the template exactly? Must be a 
subsection... Event package templates are usually followed exactly, so there 
is RAI history here. We want it to be obvious that we've ticked all the 
boxes.

- MIXER

There are a number of issues in 01 version, flagged in the document

Will update with ascii art (thank you Mary).

008 - multiple JOINs - would not be allowed? No change here, already have 
language that describes this.

Does anyone NEED to do this? No one spoke up.

009 - may have framework impact. JOIN can reference connection id, from and 
to parts of SIP signaling plus media label. Framework isn't clear on whether 
from/to and from/to/label refer to the same connection id. Do  people use 
this now? Lorenzo is now, but would be OK with removing the label to address 
a specific media stream. Weren't thinking about stream elements when we were 
writing the control framework.

Anyone opposed to removing the label? Would we just punt this in the 
framework? Could describe "stream-like element" in the framework... Chris 
thinks it's OK to remove, was just future-proofing in case someone wanted to 
reference a media line in SDP. Chris will make this change in the control 
framework.

010 - stream has "inactive" attribute - is stream established with no media, 
or not established? established and can be manipulated.

006 - JOIN audit - all we do is indicate IDs, no information about stream 
connections. Do we need more (what streams are established, what is 
directionality, etc)? Would anyone use H.248 recovery? No one speaking in 
favor - no action required here.

Is there an attribute for conference ID, or is it generic? It's generic. 
Want to audit a specific conference? Don't think this is required.

Lorenzo has a couple of items from the mailing list - clarifications.

Region element - person added to region but not appearing in the conference? 
Will clarify here.

Role of region priority and elements of the stream? What happens when you 
attach two conferences to each other? Will clarify here as well.

Keith - same comments about template as previous document. Overview says out 
of scope... attempting to say "extensible using other namespaces", just 
saying be aware you can get back 426.

Floor control out of scope, but the document is talking about floor control. 
There is a floating floor control package, just want a hook for later use 
now.

Noted there are lots of elements and not many examples. Volunteers to 
provide examples? Lorenzo can provide text.

Keith - additional description of status codes? Usually have more 
description than this... certainly is that way in SIP. Documented at the 
point of failure, not collected. Implementers may need guidance in choosing 
between status codes. 450 isn't in any procedure, for example. This has been 
an huge issue for BLISS. Appropriate recovery actions to take (informative, 
not normative)? Scott can take a stab at this.

Scott is good for everything except examples - who can help besides Lorenzo?

We are planning on Framework revision next week, one-week WGLC, and IVR and 
MIXER in the last week of October, two-week WGLC - goal is PUB-requested 
before Minneapolis...

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

---

From: Eric Burger <[email-masked]>
Date: Fri, 17 Oct 2008 11:51:48 -0400

Jabber logs at http://jabber.ietf.org/logs/mediactrl/2008-10-17.txt

On Oct 17, 2008, at 10:59 AM, Spencer Dawkins wrote:

> now have secdir review in hand, didn't require lots of changes, have  
> changes in current version (along with nits)
>
> Keith requested rephrase making it more clear what entity is  
> required to do what
>
> Section 4/Section 6 interaction? Keith doesn't understand what  
> material belongs in each section, doesn't think requirements are  
> clear - switching terminology between client, UAC, etc... Can you  
> put all the UAC requirements together, etc?
>
> Can we agree on terminology? control client and control server?  
> anyone opposed? We like that. Packages are calling them control  
> framework server, etc - just drop "framework". Chris will make a  
> consistency pass through the document
>
> Not sure what requirements go in Section 4 vs Section 6? 4 is  
> intended to be control channel setup, 6 is intended to be framework  
> interactions. Keith will look that over given this background. Chris  
> will add a statement in 4.1 explaining the structure.
>
> Keith - Section 8 has template for control packages, does template  
> work for people who have drafted packages? Worked for IVR and MIXER?  
> Scott thinks it works.
>
> Changed output from MIXER-09 version, have made changes based on  
> Secdir review, we'll change based on Keith's email and make 4.1  
> changes that we've just discussed.
>
> Are people really using TLS? Not in existing implementations -  
> secdir review asked for strong statement of what the security story  
> really is, should be in 05 draft.
>
> - IVR
>
> Open issues - couple of things that may come up with MIXER, but  
> security is the big change in this version of the draft.
>
> prompt executed in sequence? Yes, no provision to play in parallel.  
> What about different kinds of media? People are assuming children  
> can be played in parallel - will make this clearer.
>
> Is it common practice to have two separate source files? URI points  
> to one resource, container format contains both resources. Multiple  
> resources are possible and have been added to VXML, SMIL, etc. but  
> this opens up lots of issues - currently out of scope, could be  
> extended (either in IETF or proprietary). Is it OK if we have this  
> limitation? It is common to have two resources, one for audio and  
> one for video.
>
> Add "parallel" element? adding complexity quickly here... Parallel  
> playback for different kinds of media, so there's no expectation of  
> mixing? Would be a one-week addition (Spencer is now less unhappy).  
> Would not include parallel recording? Is that a proprietary MIME  
> type? Can we have different destinations for recording? This is  
> harder... does anyone need parallel playback without parallel  
> recording? Only in theory, not in practice. Playback is easy to  
> extend, record is multiple child elements with different  
> Assumptions about forward compatibility aren't in the draft... This  
> would be a different version number for the package. Could have  
> another package with own namespace doing extensions.
>
> Does anyone need parallel record-only? Real-world is video mail,  
> with record against two resources. Is it worth slowing down the  
> draft to do parallel record? Steve thinks so and will review any  
> changes in this area. Scott will include this in next week's version  
> of the draft.
>
> Keith - think the document structure does not match the structure of  
> the template. Templates mandate sections (example is missing),  
> mandates compatibility statements, MIME type for control bodies,  
> etc...
>
> Scott will make these additions to match the template, making sure  
> IVR is aligned.
>
> subsection... Event package templates are usually followed exactly,  
> so there is RAI history here. We want it to be obvious that we've  
> ticked all the boxes.
>
> - MIXER
>
> 008 - multiple JOINs - would not be allowed? No change here, already  
> have language that describes this.
>
> 009 - may have framework impact. JOIN can reference connection id,  
> from and to parts of SIP signaling plus media label. Framework isn't  
> clear on whether from/to and from/to/label refer to the same  
> connection id. Do  people use this now? Lorenzo is now, but would be  
> OK with removing the label to address a specific media stream.  
> Weren't thinking about stream elements when we were writing the  
> control framework.
>
> framework? Could describe "stream-like element" in the framework...  
> Chris thinks it's OK to remove, was just future-proofing in case  
> someone wanted to reference a media line in SDP. Chris will make  
> this change in the control framework.
>
> 010 - stream has "inactive" attribute - is stream established with  
> no media, or not established? established and can be manipulated.
>
> 006 - JOIN audit - all we do is indicate IDs, no information about  
> stream connections. Do we need more (what streams are established,  
> what is directionality, etc)? Would anyone use H.248 recovery? No  
> one speaking in favor - no action required here.
>
> Is there an attribute for conference ID, or is it generic? It's  
> generic. Want to audit a specific conference? Don't think this is  
> required.
>
> Region element - person added to region but not appearing in the  
> conference? Will clarify here.
>
> Role of region priority and elements of the stream? What happens  
> when you attach two conferences to each other? Will clarify here as  
> well.
>
> Keith - same comments about template as previous document. Overview  
> says out of scope... attempting to say "extensible using other  
> namespaces", just saying be aware you can get back 426.
>
> Floor control out of scope, but the document is talking about floor  
> control. There is a floating floor control package, just want a hook  
> for later use now.
>
> Noted there are lots of elements and not many examples. Volunteers  
> to provide examples? Lorenzo can provide text.
>
> description than this... certainly is that way in SIP. Documented at  
> the point of failure, not collected. Implementers may need guidance  
> in choosing between status codes. 450 isn't in any procedure, for  
> example. This has been an huge issue for BLISS. Appropriate recovery  
> actions to take (informative, not normative)? Scott can take a stab  
> at this.
>
> We are planning on Framework revision next week, one-week WGLC, and  
> IVR and MIXER in the last week of October, two-week WGLC - goal is  
> PUB-requested before Minneapolis...
>
>
>