Subject: Re: [clue] Design team meeting this week - Framework - meeting notes December 16th

From: "Roni Even" <[email-masked]>
Date: Tue, 16 Dec 2014 17:30:43 +0200

Participants : Mark, Rob, Paul K., Roni

Went through the major comments on the framework WGLC 

Roni's comments conclusions

In section 4 remove "" While the actual mapping of those RTP flows  to the
header fields of the RTP packets is not subject of this specification""

The text in section 5 on  discuss the model and from the following text
"First,  it MUST construct and send a CLUE Configure message to tell the
Provider what the Consumer wishes to receive. Second, it MAY, but is not
necessarily REQUIRED to, use the  information provided to tailor the SDP  it
is going to send  during the following SIP offer/answer exchange, and its
reaction to SDP it receives in that step."  There were a couple of points
raised. The Consumer needs a previous offer in order to send a configure
(discussed in section 10). An SDP answer cannot be used to add to the SDP.
The order of the offer/answer in relation to the configure is not needed
(remove the First and Second that may hint on order). 

Mark will look at the text and fix it to address those points.

In section 5 "   A CLUE-implementing device interoperates with a device that
does  not support CLUE, because the non-CLUE device does, by definition ,
not understand the offer of a CLUE channel in the initial  offer/answer
exchange and, therefore, will reject it. This  rejection MUST be used as the
indication to the CLUE-implementing  device that the other side of the
communication is not compliant  with CLUE, and to fall back to behavior that
does not require CLUE ." The question was if an endpoint sends an offer with
the sip.clue feature tag but do not offer a data channel currently, what
does it mean in terms of CLUE support or is it require to send both. 

The conclusion was that the question is for the signaling document and the
text her is general but the framework should be consistent?

Paul comment discussed:

In section 15: " In addition, the media is based on RTP and thus existing
RTP security  mechanisms, such as DTLS/SRTP, MUST be supported."

Suggested " In addition, the media is based on RTP and thus existing RTP
security  mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported." 

Conclusion: We agreed to take this suggestion but also mention that the
Media security is discussed in the signaling and RTP mapping documents.

Rob comments discussed

Section 7.2. page 22:

"A MCC MAY contain no references to other Captures to indicate that the MCC
contains content from multiple sources but no information regarding those
sources is given." - We don't specify if an MCC containing 1 or more defined
captures may also contain undefined captures. My personal choice would be no
- advertised MCCs either contain the defined captures and no others, or have
no defined captures and contain only undefined ones. If there are good
reasons that any MCC with defined captures also needs to contain potentially
undefined ones that's fine too but we should spell it out.

Conclusion: agreed to Rob's proposal " advertised MCCs either contain the
defined captures and no others, or have no defined captures and contain only
undefined ones."

Section 10. page 39:

"The Consumer may or may not choose to receive all the indicated captures.
Therefore it can choose to receive a sub-set ofCaptures indicated by the
MCC." - this allowance means that any device that provides an MCC and
defines the captures it contains is required to allow any subset of those
captures to be chosen bv the consumer. Often the reason the provider is
providing an MCC initially is because it cannot supply all the captures
directly; unless it has the resources to provide a unique subset of each
capture (eg, switched view or custom

composition) it will be forced to ot include the contained captures in the
MCC, removing the value of having an MCC in the first place. 

Depending on the clarification to the question on page 22 (whether an MCC
with defined captures can also contain undefined captures) the consumer may
still be receiving captures it hasn't specified. My preference would be to
remove this degree of freedom on the consumer side, or at least make it a
suggestion to the provider rather than a mandatory restriction.

Conclusion: recommend that the provider may ignore an MCC from a configure
that includes a subset of the MCs from the advertise if cannot support it.
This is the case when an MCU may not be able to support personal layouts for
example. Mark will verify on the list (the other option was to have an
attribute in the MCC that explicitly specify support for subset of the MCs
in the configure. Note that this is for the defined capture case based on
the previous comment) 

Roni Even

From: Roni Even [mailto:[email-masked]] 
Sent: 14 December, 2014 5:18 PM
To: [email-masked]
Cc: Paul Kyzivat ([email-masked]); [email-masked]
Subject: Design team meeting this week - Framework 

Hi,

We would like to resume the weekly design team meetings. 

The Framework WGLC will end on the 17th but since this will be before the
Holidays  it will be good to hold a conference call the Tuesday December
16th at the usual time see
http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

Since we did not meet for some time please let us know If there are any time
issues

Regards

Roni Even

CLUE WG Co-chair