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

From: "Robert Hansen (rohanse2)" <[email-masked]>
Date: Sat, 15 Feb 2014 08:30:56 +0000

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: [email-masked] [mailto:[email-masked]] 
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Feb 2014 12:18:33 -0500

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:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Tue, 18 Feb 2014 02:44:14 +0000

Hello Rob,

    Thanks for the update. 

    Section 3.2:

    I am a little confused about the first sentence. What do you mean about non-CLUE-controlled channels?
    If you mean the data channels such as webrtc data channel, the webrtc data channel is for non-media transport and not for media.
    The draft-ietf-rtcweb-data-channel-06 draft does say in abstract:
         This document specifies the non-media data transport aspects of the RTCWeb framework.
         
Best Regards,
Scarlett

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Robert Hansen (rohanse2)
Sent: Saturday, February 15, 2014 4:31 PM
To: [email-masked]
Subject: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

Abstract:

The IETF Secretariat

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Tue, 18 Feb 2014 03:17:27 +0000

Hi Paul,

    Please see as below. Thanks.

Best Regards
Scarlett

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, February 18, 2014 1:19 AM
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification for draft-kyzivat-clue-signaling-07.txt

Rob,

Section 3.2:

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.
[Scarlett] Maybe the purpose for these streams before the negotiation for CLUE are divided into two sets: meaningless or useful.
Of course, which purpose will depend on the endpoints' behavior and policy. If they are meaningless, they should be dropped (port=0) or set to a=inactive.
If they are useful, they should continue and will not be controlled by CLUE.

Section 4.1:

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:

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:
> To: Lennard Xiao; Paul Kyzivat; Lennard Xiao; Robert Hansen 
> (rohanse2); Robert Hansen (rohanse2); Christian Groves; Christian 
> Groves; Paul Kyzivat

---

From: Robert Hansen <[email-masked]>
Date: Tue, 18 Feb 2014 12:40:10 +0000

Hi Scarlett,

There's a 'CLUE-controlled media' term in the terminology section, 
defining it as being a media line under the control of CLUE as defined 
in section 4 of the document (contains an mid value that is part of a 
CLUE group). The terminonology also mentions that:

'There is a corresponding "non-CLUE-controlled" media term'

Which I confess I didn't really define, but intended to be the opposite: 
any media stream that isn't defined by the grouping framework as being 
under CLUE control.

The intent of the sentence was that if two CLUE-enabled devices are in a 
call and have successfully negotiated the CLUE data channel, they may 
wish to send no media while the CLUE signalling negotiation is ongoing 
and only start sending audio and video once they have negotiated how 
many streams are wanted and what they should contain (as opposed to 
sending one audio and one video stream as cut-through media, and then 
upgrading the call to multiple audio/video streams).

Rob

---

From: Robert Hansen <[email-masked]>
Date: Tue, 18 Feb 2014 12:55:22 +0000

Hi Paul, Scarlett,

Comments inline.

> If they are useful, they should continue and will not be controlled by CLUE.

[Rob] Paul, I think you're right that we need explicit language 
recommending what to do with the nonCLUE audio/video streams once CLUE 
is brought up (currently all there is is that section on what happens 
with those streams *before* CLUE comes up). However, I don't think it 
should be mandatory; as Scarlett intimates there may be specific use 
cases where the system might still want to receive both CLUE and 
non-CLUE media. However, I do think that the majority of systems will 
want to disable their non-CLUE streams once CLUE comes up, and there 
should be text to that effect in the document.

> - use capneg, as Christian discusses in draft-groves-clue-latent-config

[Rob] I agree with you on the costs if you have to have a unique port 
for each encoding, though it would be necessary if one side did not want 
to multiplex their media. Ultimately though we do want a way of 
multiplexing the media, but I think we'll probably still have an m-line 
per encoding (just not with a unique port each).

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

[Rob] I put this as a SHOULD rather than a MUST as I felt there might be 
systems that wanted to define their encoding capabilities in a static 
fashion, even in cases where they didn't have capture devices connected 
that could use some of those encodings. As such, it was either a case of 
not having a label for some encodings, or having a label but not 
referring to it in the CLUE ADVERTISEMENT. The latter, making label 
mandatory for CLUE-controlled "m" lines, is probably a better way of 
illustrating this, though.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Feb 2014 17:32:09 -0500

> should be text to that effect in the document.

I agree that we should not be normative about what is done with the 
non-clue media, but we should give some guidelines. (E.g., either set 
the port to zero or add a=inactive.)

IMO it should be *permissible* to repurpose them as clue-m-lines, after 
clue has been negotiated. We don't really have to say anything about 
that. They will just be additional m-lines added to the clue group in a 
subsequent O/A.

> per encoding (just not with a unique port each).

Yes. My point here is that I think it would be good to allow encodings 
that can be referenced from advertisements but aren't ready to be used. 
This can be by having them in the SDP with a zero port, or by use of 
latent-configs.

> illustrating this, though.

So you are talking about m-lines that are in the clue group, but don't 
have labels. I guess that would work. Or they could also be in the clue 
group, *with* labels, but without any references to those labels in the 
advertisement.

But I still take issue with your wording. Even if the m-line is in the 
clue group, it doesn't represent an encoding unless it has a label that 
is referenced from an Advertisement. If it has a label that isn't 
referenced from an advertisement then it *could* represent an encoding 
in the future. If it has no label, then it cannot represent an encoding 
until it is updated to contain a label.

So I still think that "SHOULD" should be a "MUST.

Then you *could* add:

     Every CLUE-controlled "m" line SHOULD contain a "label"
     attribute as defined in [RFC4574].

But I don't really think that adds anything.

	Thanks,
	Paul

>>> 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
>>>
>>> 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:
>>> 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
>>>