Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP?

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Aug 2012 17:51:54 -0400

(As individual)

Issues 12 & 13 ask how we separate what data should be carried in SDP 
vs. what should be in clue-specific signaling. I've been thinking about 
that, and while I don't have any answers I do have some thoughts to 
share that might help decide this.

One difference between the SDP and the CLUE-specific signaling is that 
the SDP is governed by the O/A mechanism, while the clue signaling is 
governed by the Advertisement/Configuration mechanism. Of course we can 
change the mechanism for the clue signaling if we want, but for the time 
being I'll assume we leave that mechanism as-is.

There must be a coupling between the two. At the very least, before 
transmission can begin in response to a new configuration message, the 
negotiated SDP must be sufficient to support that. If the SDP in effect 
*before* sending that configuration is not sufficient, then a new O/A 
will need to be performed, and transmission according to the new 
configuration can't begin until that O/A is complete.

One approach to this would be to require an advertiser to constrain what 
it advertises to things that are covered by currently negotiated SDP. 
This then ensures that any configurations selected from that 
advertisement can be done without another O/A. But it may also require 
SDP demanding more resources (e.g. bandwidth) than will be required in 
practice.

Another approach would be to defer any needed adjustments to SDP until a 
configuration is received by the advertiser. It could then initiate any 
SDP changes needed to support that configuration. This allows the SDP 
configuration to be tuned to what is needed for the particular 
configuration. A downside is that if the O/A then fails, what should happen?

Those are extremes. Between them are possibilities to do adjustments 
from the receiving end before sending the configuration, and probably 
other ways.

Which approach is taken seems likely to profoundly impact the decision 
about what which information can be in the SDP rather than the clue 
messages.

This gets more complex when you consider that advertisements and 
configurations are flowing in both directions. If we aren't careful we 
may end up needing an O/A exchange for each advertisement or 
configuration. (But maybe this doesn't matter.)

At the very least, it's important that it be clear which side is 
responsible for initiating an O/A required by any clue message.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Aug 2012 19:53:19 +0200

Hi,

I don't think CLUE signalling will be used only for adv/conf. I guess we may also use it for certain types of indications - perhaps even some type of controlling messages.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, August 31, 2012 12:51 AM
To: CLUE
Subject: [clue] Thoughts on issues #12/#13 - what goes in SDP?

(As individual)

        Thanks,
        Paul
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Aug 2012 14:10:34 -0400

> I don't think CLUE signalling will be used only for adv/conf. I guess we may also use it for certain types of indications - perhaps even some type of controlling messages.

I suppose that's possible, though AFAIK nothing of that sort has yet 
been proposed. But it's irrelevant to the point I was making, which is 
about which info should go in Adv/Conf and which should go in SDP.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Aug 2012 21:14:21 +0200

Hi,

> about which info should go in Adv/Conf and which should go in SDP.

We also need to decide whether we put ANY requirements (when it comes to support of protocol extensions etc) on non-CLUE devices, in order to be able to interwork with CLUE systems. That will also impact what-do-we-transport-where decisions.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 Aug 2012 16:33:31 -0400

> We also need to decide whether we put ANY requirements (when it comes to support of protocol extensions etc) on non-CLUE devices, in order to be able to interwork with CLUE systems. That will also…

That is also something that is distinct from resolving these two issues.
So I've changed the subject.

IMO the only requirements a non-clue endpoint need meet are:
- support 3261
- support SDP, including ignoring unknown a-lines
   and rejecting m-line media types it doesn't support
- support at least one audio and/or video m-line
- have some codec in common with the other end

That should be enough to get an initial session established. Then the 
clue endpoint can cope.

	Thanks,
	Paul