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

From: "Robert Hansen (rohanse2)" <[email-masked]>
Date: Fri, 11 Apr 2014 02:59:35 +0000

Apologies - didn't end up getting it done until a day and a half after I said I would.

I've included proposals for a number of open issues, with the exception of tackling unidirectional streams or re-use of initial audio/video m lines as CLUE-controlled lines (parly because they're more optimisations than anything we need to make CLUE work, and partly because I don’t have strong opinions about them).

I've also reformatted the SDP related section of the document to make it more centred around the grouping framework and its use - thanks to Christer for suggestions on how to do that.

Oh, and rather than 'sip.clue' for the media tag and 'CLUE' for the grouping semantic I went with 'sip.telepresence' and 'TELEPRESENCE', as I think the latter will make it more obvious to people what the functionality that is being invoked is for. I know people may have strong opinions to the contrary, but I figured I'd raise the issue now before we got too comfortable with the existing syntax.

Rob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 11 April 2014 03:51
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-08.txt

A new version of I-D, draft-kyzivat-clue-signaling-08.txt
has been successfully submitted by Robert Hansen and posted to the IETF repository.

Name:		draft-kyzivat-clue-signaling
Revision:	08
Title:		CLUE Signaling
Document date:	2014-04-11
Group:		Individual Submission
Pages:		41
URL:            http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-08.txt
Status:         https://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/
Htmlized:       http://tools.ietf.org/html/draft-kyzivat-clue-signaling-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-08

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.ietf-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, 14 Apr 2014 10:51:27 -0400

Rob,

Thanks for this update. It is much improved.
Following are some comments on this new version.

	Thanks,
	Paul

Section 4.2:

There is some ambiguity in the use of the term "data channel" in this 
section. In some places it refers (properly) to an individual channel 
over the SCTP association. In other places it refers to the m-line of 
the SCTP association that carries the clue data channel. (E.g., "mid"s 
for more than one data channel.)

Perhaps the last paragraph of this section could say a bit more. The 
feature tag indicates that CLUE is *supported* but does not indicate a 
desire to use it. The telepresence group indicates a desire to *use* 
clue - is CLUE-enabled. So "SHOULD" isn't quite right - it is impossible 
to be CLUE-enabled without including the group. And if the group is 
included, then I think the SCTP m-line MUST be included.

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
    TELEPRESENCE group.  If no data channel is included in the group 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.

This allows a telepresence group that doesn't have an SCTP association. 
Do we want to allow that?

Section 4.4:

General observation: this section is now structured into subsections 
according to the usual pattern for describing SDP O/A. When following 
this pattern we need to keep in mind what the subsections mean. The 
"Initial Offer" refers to the first offer of the SDP session, which 
should also be the first offer of the SIP session.

"Modifying the Session" applies to any subsequent offer within the SIP 
and SDP session.

I *think* we have been assuming that the first O/A will contain "legacy" 
media, while sorting out whether CLUE is supported by both ends. Then 
once that is known, a subsequent offer will include the clue-controlled 
media.

We have been working on the assumption that the CLUE channel and/or the 
SCTP association and clue group would be in the initial offer as an 
indicator of clue support. Now that we are proposing to use a feature 
tag to indicate clue support, the initial offer doesn't need to include 
either a tp group or the SCTP m-line.

So, I think that *all* of the SDP that is specific to clue (the 
telepresence group, the SCTP association in the telepresence group, and 
the encodings) should all fall under the "Modifying the Session" section 
of the document. Within that section there will then probably need to be 
section on "Enabling CLUE" and then "Modifying the CLUE session".

Section 4.4.1.3:

If you agree with my point on 4.4, then this section doesn't need a 
special case for the SCTP association.

Section 4.4.2.2:

Regarding RTCP - IIUC this gets complicated once we introduce bundling, 
because there isn't separate RTCP per m-line in the bundle. I don't know 
if that affects what is said here or not. (Let's hear from the RTP experts.)

Section 4.4.1.2 talked about preemptively including recvonly m-lines in 
an offer. But I find nothing talking about generating the answer in that 
case. I think some discussion of that belongs in this section.

Section 4.4.4.1:

This seems to say that the call is clue enabled if *one* side adds the 
SDP association to the telepresence group. IIUC, one side doing this is 
a request to enable clue, and it takes both sides to *enable* clue.

Also note that it would be possible to negotiate an SCTP association 
m-line that is not in the telepresence group, and then at some later 
point simply add it to the telepresence group. That too would enable 
clue. (I don't think the wording needs to change to cover this. But I 
want to make sure people have considered it.)

Section 6.2.1:

If my earlier comments are followed, it may be that the SCTP association 
is first offered concurrently with the first encodings. That might mean 
that no bundle is negotiated until then.

We might want to discuss how to avoid an extra O/A, or extra ports, in 
this case.

One possibility is to create a bundle group around the legacy media. But 
that might not be desired.

Another would be to include the SCTP association as a bundle group with 
only one m-line in the initial offer even though it isn't otherwise 
needed, so that when the encodings are added they can be added to the 
bundle without separate ports.

Another would be to make an offer with the SCTP association in a bundle 
group, and all of the encodings as bundle-only. (That runs the risk that 
the other side doesn't support bundle. If it doesn't, then another offer 
could be made to offer them on separate ports.)