Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-signaling-04.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jul 2013 13:05:51 -0400

This was actually submitted by Rob. (Thanks Rob!)

I do have some comments on the new changes. Please don't think I'm being 
critical. I am thrilled that we have something with enough substance to 
debug.

Section 4.1 says:

    The presence of an active m-line for the CLUE channel in an SDP offer
    is an indication that the offer that the sender is CLUE-capable and
    hence can understand CLUE-specific syntax.

We have to sort out if this is sufficient. It depends on whether the SDP 
for offering the CLUE channel is itself sufficient to distinguish it 
from an SCTP session for something else. Hopefully it will be. But as 
long as we are using the grouping framework with CLUE semantic, we can 
use *that* as a reliable indicator of clue capability. Then presence of 
the clue channel m-line in the CLUE group clearly indicates what it is, 
and acceptance of it indicates intent to use CLUE.

Section 4.2 says:

    A receiver who wishes to receive a CLUE stream via this encoding
    requires a matching "a=recvonly" "m" line.  As well as the normal
    restrictions defined in [RFC3264] media MUST NOT be sent on this
    stream until the sender has received a valid CLUE Configure message
    specifying the capture to be used for this stream.

This may need some qualification. If ICE is to be used, then it needs to 
be sent prior to the config. (But that isn't technically *media*.) And 
even in the absence of ICE, NAT traversal may require that *something* 
be sent at all times to keep the nat binding open.

Section 3.7 and 4.2 say:

An a=label will be used to link encodings to the advertisements and 
configures. But section 4.4 says that the grouping framework will be 
used to mark the m-lines that are clue-controlled. This seems like a 
redundancy/conflict to me.

IMO the grouping framework (with a=mid) is the right thing to use if 
there is a need to specify a certain form of grouping. And if doing 
that, then the a=mid is probably ok to use for application level 
reference as well. OTOH, if there is no need for grouping, then IMO 
a=label would be preferred.

In this case, the question is whether we need the grouping. Is there a 
need to identify those m-lines controlled by clue, without reference to 
an advertisement? Or is it sufficient to use the advertisement to 
identify those m-lines that are controlled by CLUE. I'm not sure.

One advantage of using the grouping is that it is a much more specific 
indication that CLUE is in use than the presence of the clue channel. 
And I suppose it can prevent premature decisions about what to do with 
m-lines, before an advertisement referencing them is received.

So maybe, on balance, there is advantage to using grouping. And if so, 
then I think we can just use the mid values to reference the specific 
m-lines from clue messages.

Section 5.2:

    Generally, implementations that receive messages for which they have
    incomplete information SHOULD wait until they have the corresponding
    information they lack before sending messages to make changes related
    to that information.  For instance, an implementation that receives a
    new SDP offer with three new "a=sendonly" CLUE "m" lines that has not
    received the corresponding CLUE Advertisement providing the capture
    information for those streams SHOULD NOT include corresponding
    "a=recvonly" lines in its answer, but instead should make a new SDP
    offer when and if a new Advertisement arrives with captures relevant
    to those encodings.

The above is a bit incomplete/confusing. When the offer is received, 
*some* answer must be sent. What should it be? The options are:
- accept the m-line, a=recvonly
- accept the m-line, a=inactive
- reject the m-line (port=0)
Do we really care which one is used? IMO we don't care. If we are to say 
anything, it might be that *if* the answerer chooses not to accept the 
m-line with a=recvonly, *then* it will need to send an offer to change 
this if it later decides to configure that encoding.

Section 6:

What prevents Bob from sending an INVITE to Alice right after sending 
ADV 2? (And thus glaring with the one from Alice?)

200 OK 2 says: "(+2 recvonly)". I find this confusing. The answer can't 
change the number of m-lines from what was in the offer.  Presumably 
this is intended to mean that it is accepting two of the added three 
m-lines. But its easy to misconstrue. I think it might be better to just 
leave this off and leave it to text to explain.

"MEDIA 3" says: "2 video A->B, 1 video B->A". This seems to be counting 
the sendrecv video in one direction but not the other. It looks to me 
like it should be "3 video A->B, 1 video B->A". (And so MEDIA 3 should 
mention *3* videos in each direction. At some point, either that first 
sendrecv m-line should be included as a clue-controlled m-line, as an 
encoding (for both sides?) or else it ought to be rejected or put into 
inactive state.

The answer to INVITE 2 doesn't have an a=mid for the rejected m-line. I 
think 5888 requires that it have one. (This shows up elsewhere too.)

The delay in sending a Configure, until an offer is received that 
defines the encodings in the Adv, may be in conflict with the proposal 
that every Adv should receive a Conf quite soon. *Maybe* the offer will 
be received soon "enough" to send a prompt configure. But its really 
hard to ensure that. This could lead to complex interactions between 
state machines for SIP O/A and CLUE and their respective timers.

So I think we should assume that each Adv will receive an immediate 
Conf, even if it doesn't request anything.

	Thanks,
	Paul (as individual)

On 7/15/13 11:08 AM, [email-masked] wrote:
>
> A new version of I-D, draft-kyzivat-clue-signaling-04.txt
> has been successfully submitted by Paul Kyzivat and posted to the
> IETF repository.
>
> Filename:	 draft-kyzivat-clue-signaling
> Revision:	 04
> Title:		 CLUE Signaling
> Creation date:	 2013-07-15
> Group:		 Individual Submission
> Number of pages: 33
> URL:             http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-04.txt
> Status:          http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling
> Htmlized:        http://tools.ietf.org/html/draft-kyzivat-clue-signaling-04
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-04
>
> Abstract:
>     This document specifies how signaling is conducted in the course of
>     CLUE sessions.  This includes how SIP/SDP signaling is applied to
>     CLUE sessions as well as defining a CLUE-specific signaling protocol
>     that complements SIP/SDP and supports negotiation of CLUE application
>     level data.
>
>
>
>
> The IETF Secretariat
>
>