Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt

[Paul Kyzivat <[e-mail]>]

Rob,

Thanks for the update. A few comments:

Section 3.2:

    In the event that the CLUE data channel is successfully negotiated, a
    CLUE-enabled device MAY choose not to send media on the non-CLUE-
    controlled channels during the period in which control of the CLUE-
    controlled media lines is negotiated.  However, a CLUE-enabled device
    MUST still be prepared to receive media on non-CLUE-controlled media
    lines as defined in [RFC3264].

I think we need more words about this somewhere. If the non-clue m-lines 
remain enabled but nothing is sent, we will probably start to get 
errors, and those sessions will fail. And if media continues to be sent, 
even though the recipient doesn't want it, then that adds cost.

ISTM that either these should be dropped (port=0) or set to a=inactive 
if they are not to be used. Both sides have some responsibility in this 
- to make their intent known.

And if we don't specify what purpose these streams have once clue use 
begins, then it is hard to use these in an interoperable way.

Section 4.1:

    The CLUE Framework [I-D.ietf-clue-framework] defines the concept of
    "encodings", which represent the sender's encode ability.  Each
    encoding the media provider wishes to signal is signalled via an "m"
    line of the appropriate media type, which MUST be marked as sendonly
    with the "a=sendonly" attribute or as inactive with the "a=inactive"
    attribute.

I'm uncomfortable with requiring an m-line with port for every encoding. 
This requires assigning a pair of ports, maybe running ice on those 
ports, and sending RTCP. Some possible ways to improve on this:
- allow encodings to be offered with a zero port
- use BUNDLE
- use capneg, as Christian discusses in draft-groves-clue-latent-config

Also in that section:

    Every "m" line representing a CLUE encoding SHOULD contain a "label"
    attribute as defined in [RFC4574].  This label is used to identify
    the encoding by the sender in CLUE ADVERTISEMENT messages and by the
    receiver in CLUE CONFIGURE messages.

I think SHOULD must be MUST. Without the label the m-line doesn't 
represent an encoding.

	Thanks,
	Paul


On 2/15/14 3:30 AM, Robert Hansen (rohanse2) wrote:
> This update doesn't propose masses of new content, instead it is mostly removing discussion of issues like encoding limits in favour of more normative language, expanding the section on changing clue status mid-call and interop with non-CLUE devices, and rearranging the draft to focus more on the decisions made.
>
> Rob
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 14 February 2014 23:00
> To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian Groves; Paul Kyzivat
> Subject: New Version Notification for draft-kyzivat-clue-signaling-07.txt
>
>
> A new version of I-D, draft-kyzivat-clue-signaling-07.txt
> has been successfully submitted by Robert Hansen and posted to the IETF repository.
>
> Name:		draft-kyzivat-clue-signaling
> Revision:	07
> Title:		CLUE Signaling
> Document date:	2014-02-14
> Group:		Individual Submission
> Pages:		37
> URL:            http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/
> Htmlized:       http://tools.ietf.org/html/draft-kyzivat-clue-signaling-07
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-07
>
> Abstract:
>     This document specifies how CLUE-specific signaling such as the CLUE
>     protocol [I-D.presta-clue-protocol] and the CLUE data channel
>     [I-D.holmberg-clue-datachannel] are used with each other and with
>     existing signaling mechanisms such as SIP and SDP to produce a
>     telepresence call.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>