Subject: [clue] Comments on draft-ietf-clue-signaling-01

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 May 2014 11:20:16 -0400

I reviewed the new version of the signaling draft.
IMO this is shaping up nicely. The following are a few comments:

Section 4.3:

    CLUE-controlled media is controlled by the CLUE protocol as
    negotiated on the CLUE data channel with an "mid" included in the
    CLUE group.  If negotiation of the data channel in SDP failed due to
    lack of CLUE support by the remote device or for any other reason the
    other "m" lines in the group are still considered CLUE-controlled and
    under all the restrictions of CLUE-controlled media specified in this
    document.

What does it mean for an m-line to be clue-controlled by one end when 
the other end doesn't support clue? The other end will be expecting the 
m-line to operate according to "normal" rules.

Section 4.5.2.1:

    A CLUE-capable recipient that receives an "m" line for a data channel
    but no corresponding CLUE group containing the "mid" of that "m" line
    SHOULD include a corresponding data channel "m" line if there are any
    other non-CLUE protocols it can convey over that channel, otherwise
    it SHOULD NOT negotiate the data channel.

This seems too strong - it is specifying normative behavior in a case 
where we have no business doing so. I would say something weaker:

    If a CLUE-capable recipient receives an "m" line for a data
    channel but no corresponding CLUE group containing the "mid" of that
    "m" line, then the recipient's answer to this m-line is outside
    the scope of CLUE.

Section 4.5.2.2:

This says that if the offer contains recvonly m-lines then they should 
be accepted as sendonly m-lines. It fails to say anything about the need 
for these m-lines to be *compatibile* with encodings that the answerer 
wishes to advertise.

There are two distinct cases here:

The easy case:
- X sends an offer to Y including some sendonly m-lines.
- Y sends an answer that rejects those m-lines because it doesn't
   want them at that time.
- Later, Y sends an offer to X. It includes recvonly m-lines
   matching the earlier received sendonly ones it had previously
   rejected.
- unsurprisingly, X finds that these match encodings it has
   and so accepts them as sendonly in the answer.

The hard case:
- X, in its first offer after discovering that CLUE is to be used,
   includes some recvonly m-lines for encodings it would like to
   receive and hopes Y might be willing to send it.
- Y, when it receives the offer from X, looks for matches from
   among the recvonly m-lines and encodings it is planning to
   advertise. It accepts those that match.

ISTM that the "easy" case is important. It can significantly reduce the 
number of O/As, and it doesn't depend on one endpoint having any 
implicit knowledge of other endpoints. We might want to recommend that 
this be done.

The "hard" case might make sense if endpoints typically are connecting 
to known configurations, or if the endpoint only supports a small number 
of encoding options.

Section 4.5.3.1:

If the answerer is going to enable CLUE, it might choose to refuse 
(port=0) the non-clue-controlled m-lines. Then it wouldn't need to be 
prepared to receive on them. I didn't see any mention of this.

Perhaps we should not only mention this as a possibility, but indicate 
that clue capable endpoints should not drop a call just because the 
non-clue-controlled m-lines have been refused.

Something similar to this is mentioned in 4.5.4.1, but relates to 
subsequent O/A exchanges.

Section 4.5.4.2:

There is *some* cost to including a data channel in subsequent offers. 
Should we condition the SHOULD here on the presence of a sip.clue 
feature tag in the signaling?

Section 5.1:

The 2nd paragraph ends in an incomplete sentence. Something must have 
been lost or forgotten.

	Thanks,
	Paul