Subject: [clue] review of draft-romanow-clue-call-flow-01.txt

From: "Roni Even" <[email-masked]>
Date: Thu, 19 Jul 2012 11:39:29 +0200

Hi,
I reviewed the draft and think it is a good start.

 Some comments

Section 1:
1.	" The following assumptions related to UDP are being made: these are
also stated in". I think it is about SDP description and not UDP. I also do
not understand the last part "these are also stated in".
2.	First bullet "there will be at most one corresponding ..".  This
statement is not correct. We agreed that this is the preferred mode but we
also can have the case of having more than one m-line per media type.
3.	I think the second bullet is the same as the first one with the same
comment.
4.	I am not sure what you mean in the fourth bullet. I assume that by
streams you mean RTP streams. RTP by definition is uni-direction while RTCP
is bi-directional. As for other channels not carried in RTP it depends on
the definition, example is BFCP.
5.	The last sentence of the third paragraph "This is not the typical
communication model for SDP offer/answer, which is more often a
bidirectional agreement on parameter values." My understanding of SDP
parameters is that they may have direction semantics. For example the
bandwidth value in the offer is what the max value that the offerer would
like to receive while the bandwidth in the answer is what the max value the
answerer would like to receive. In general most parameters in SDP have a
direction (receive or send values) semantics. The only thing I can agree is
that CLUE may want to provide the semantics for the other direction so if in
the offer it is a receive value in CLUE advertisement we want to specify the
send value.
6.	The first sentence in the next paragraph "As specified in the CLUE
framework, parties in a Telepresence  conference do not negotiate a single
value between them." I am not clear what this sentence means or why you talk
about encoding, CLUE adds spatial information which is not the encoding but
about the semantics of the content which is not the media encoding.
7.	General comment about terminology. Using CLUE with the term media
capture encoding is confusing since encoding for media means the process of
creating the payload using an encoder.  Just use media capture without
encoding or instead of in the sentence in the above comment.
8.	I think that we should discuss in the assumption if all RTP streams
of the same type share the same codec (all H.264) and the same parameter
(for H.264 it will be profile and level). If not, I think that we should
state that we are not going to duplicate all these parameters in CLUE and
they will be specified in the Offer/answer SDP information.

Section 3
1.	On bullet three, even though I do not object to the assumption that
we will use a separate channel, I do not think that the sentence about not
using SDP based the sdp-usage draft is correct since that draft do not have
the content to prove it. Just delete the sentence in the parenthesis. 
2.	In bullet 3 I think it need to say SCTP with ordered delivery.
3.	In bullet 7 first sentence I do not like the use of "consumer" since
it is based on the offer or answer. I think that a non-controversial term
will be "user" or "endpoint"
4.	In figure 1 and all over the document (section 8) you call the non
CLUE as single-stream while CLUE is called multi-streams. I do not think
that this is the correct. A video conference call may have multi-streams
like 2 video streams, one or more audio streams and application streams
without using CLUE. The difference is that CLUE adds some CLUE semantic
description for relations between the streams. 

Other sections

1.	Section 5.2.1 talks about RTP mapping to CLUE media capture. I think
that the text is a partial approach and the correct one is as specified in
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-03 which addresses
the different RTP topologies.
2.	In section 5.2.1 "For example, Alice has a 3 camera system but in
SDP  she negotiates a single RTP session for main video". The negotiation
may be for a single RTP session but with multiple RTP streams.
3.	In section 5.4 I am not sure what the proposal is. According to RFC
3264 the bandwidth value in the offer is the maximum receive value for the
offerer while the value in the answer in the maximum receive value for the
answer. The bandwidth specified at the SDP session level is the total for
all streams and the value specified at the SDP media level is for the media.
If there are multiple media they can each state a value that will cause the
total of all the media bandwidth to be higher than the SDP session level
which will limit the actual allowed bandwidth. The issue of bandwidth is
discussed in
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-00 and I
think that for bandwidth management at the session and media level we should
use SDP.
4.	In section 5.4 I missed the reference to flow control using RTCP CCM
for temporary bandwidth change.
5.	In section 7.1 talks about RTP so the following statement is not
correct  "Demultiplexing these media streams is achieved via the
urn:ietf:params:clue:demux RTP header extension negotiated in the SIP
messages." The demultiplexing is based on SSRC , what you are talking is
about mapping to media capture which can be done base on
draft-even-clue-rp-mapping. There are two terms, media demultiplexing is
SSRC or RTP session based (separate UDP ports). The other term is RTP
mapping to CLUE media captures.
6.	The examples in the appendix has <simultaneous-transmission-set />.
Is this the correct value or you just thought it is not important to have
the list of capture IDs in the example.

Roni Even