Subject: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th

From: Mary Barnes <[email-masked]>
Date: Mon, 17 Dec 2012 09:52:24 -0600

Hi all,

The plan had been to discuss further details on the signaling
solution.  However, there is no new material related to this at this
time.

We'll start back with meetings on January 7th (pending of course
content for the meetings).

Regards,
Mary
CLUE WG co-chair.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Dec 2012 19:21:57 +0000

Hi,

It is true that there is currently no new material.

I'd like to discuss one thing, related to signalling, though.

Some time ago, I indicated that I think it would be good to define a "single-stream SDP offer", ie how an SDP offer sent from a CLUE entity to a single-stream device would look like. The reason why I think it is useful is because it makes it much easier for operators (and other SDOs) to introduce CLUE into their networks, and to verify that non-CLUE entities can interoperate with CLUE entities.

I am currently working on a short draft, which:

- Describes with m- lines (audio, main video, presentation video and "clue channel") the SDP offer would contain. A non-CLUE entity would of course reject the "clue channel" m- line, which would also be an indicator that it is a CLUE entity.
- Describes the SDP attributes which the SDP offer would contain, in order to provide a good experience. Of course, we cannot guarantee that the non-CLUE entity will support all SDP attributes, and the CLUE entity should be prepared to handle that. But, it will make it easier for operators to put requirements on their non-CLUE entity vendors.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Mary Barnes [[email-masked]]
Sent: Monday, 17 December 2012 5:52 PM
To: CLUE
Subject: [clue] Cancelled: CLUE Design Team meeting - Dec. 17th

Hi all,

Regards,
Mary
CLUE WG co-chair.
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Dec 2012 14:50:04 -0500

> - Describes the SDP attributes which the SDP offer would contain, in order to provide a good experience. Of course, we cannot guarantee that the non-CLUE entity will support all SDP attributes, and…

While this might eventually be interesting, IMO it puts the cart before 
the horse.

We REALLY REALLY REALLY need to nail down our signaling, and we have 
hardly any specifics yet. The main cases of interest for that are the 
multistream cases. When the general mechanism is worked out for 
multistream, there will be a degenerate case of *that* where only one 
capture is configured. Ideally that will be just fine for a clue 
supporting endpoint that is only capable of managing one capture. The 
SDP for that may also turn out to be fine for non-clue-supporting 
endpoints. If not, we can then discuss if we want to do something 
different for non-clue endpoints.

But right now I think this is a distraction from getting a good start on 
the signaling. And you signed up for the team working on signaling.

	Thanks,
	Paul (as co-chair)

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Dec 2012 20:03:08 +0000

Hi Paul,

I think this IS part of the signalling work.

We have been discussing that the first SDP offer should establish some "basic" session. What I'm talking about is how that SDP offer would look lite.

(Then, if both endpoints are CLUE, it will also establish the CLUE channel, and after that the multistream negotiations, CLUE advertisements/configurations etc will start).

I do agree that the single-stream use-case as such is not our main priority. But, if we don't even know how the first offer will look like, how can we define the additional signalling procedures? We need to know whether we need to add m- lines etc, or whether we can re-use the "basic" session m- lines and only add additional SSRC etc.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Monday, 17 December 2012 9:50 PM
To: [email-masked]
Subject: [clue] Signaling - single-stream special case

        Thanks,
        Paul (as co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 17 Dec 2012 16:40:40 -0500

> I think this IS part of the signalling work.

I agree it is *part* of the signaling work.
I just think it is a low priority part of the work.

> We have been discussing that the first SDP offer should establish some "basic" session. What I'm talking about is how that SDP offer would look lite.

Based on prior discussion, it is my understanding that there are a 
variety of opinions on how the first O/A should be structured, and 
agreement that this could in large part be up to individual 
implementations to decide. (Though it might be good to discuss 
implications of various choices and recommend something.)

I have the impression that some might want to optimize for contacting 
another telepresence endpoint, perhaps even for another instance of the 
same implementation, while allowing others to be supported, perhaps with 
need for more time to negotiate. Others might want to optimize to cause 
"least distress" for calling even marginal sip implementations, and 
postpone all the fancy stuff until after its known that there is a 
clueful peer.

Perhaps even these observations of mine are controversial. I just don't 
want that to distract from the more fundamental stuff.

I'll be happy if, and part of the signaling proposal, you make 
sufficient assumptions about the initial o/a to bootstrap the rest of 
the signaling. And then circle back to revisit it once the overall 
mechanism is specified.

> (Then, if both endpoints are CLUE, it will also establish the CLUE channel, and after that the multistream negotiations, CLUE advertisements/configurations etc will start).

Yes, this is the key part.

> I do agree that the single-stream use-case as such is not our main priority. But, if we don't even know how the first offer will look like, how can we define the additional signalling procedures? W…

I just don't want to get hung up on this one, and on compatibility with 
clueless endpoints, and delay getting to the key stuff.

In "steady state" advertisements and configurations have been previously 
exchanged, consistent O/As have been exchanged, and media is flowing 
consistent with the configurations. THEN:

A provider sends an advertisement that is most likely inconsistent with 
the previously received configuration. The consumer sends a 
configuration consistent with the newly received advertisement. If the 
new configuration would be inconsistent with the currently negotiated 
SDP, then one side or the other sends an offer and the other side 
answers it. (The O/A may occur in various positions relative to the 
advertisement/config exchange.) then media starts to flow based on the 
new configuration rather than the old one. The signaling spec needs to 
work out all the details of this.

The beginning of the session will be more or less the same as the above, 
but is a special case in that the same thing is most likely going on in 
both directions concurrently, and there are some optimizations that may 
be possible. And in this case there was no *prior* advertisement and 
config to build on. It may or may not be worthwhile to "optimize" this 
rather than simply establishing some defaults and then employing the 
"normal" logic do its thing. (And perhaps optimization can be left to 
individual implementations without standardizing it.)

I've been expecting to see a document addressing all this for a long 
time. I suspect many of us have a general idea of this but have not 
written it down in detail. (We probably don't have the *same* idea. But 
we won't know until it is written down.)

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 18 Dec 2012 14:15:21 -0600

Thanks for your email.  This work certainly has merit in that it is
something we need to make sure and cover for the complete solution.
It might well also help to inform the decision as to how much we can
put in SDP.

If you can let us know about when you'll have the draft submitted, so
we can ensure we have discussion time allocated for it in one of the
design team meetings, that would be great.

Thanks,
Mary.