Subject: [clue] Scene for non-CLUE/single stream devices

From: Christer Holmberg <[email-masked]>
Date: Fri, 30 Nov 2012 13:29:18 +0000

Hi,

As we know, we have use-case and requirement to interwork with non-CLUE/"single stream" entities.

When such entity sends an SDP offer to a CLUE entity, we can of course not specify how it will look like.

But, we can provide guidance on how an SDP offer from a CLUE entity shall look like, when communicating with a non-CLUE entity. That also ensures that every CLUE entity is able to generate scenes based on those requirements.

So, the SDP offer could e.g. look like this:

-          1 audio stream (single ssrc)

-          1 video stream (single ssrc)

-          1 presentation (video?) stream (single ssrc)

This does not require spatial information, the receiver does not need to understand multiple streams per m- line, and the need for understanding the stream content is minimal.

The provider of course have to be prepared that the non-CLUE entity may reject one or more of the offered streams. For example, an audio-only device would reject the video streams.

And, the SDP offer may of course not always contain all above, if there e.g. is a session without a presentation.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Nov 2012 13:02:27 -0500

On 11/30/12 8:29 AM, Christer Holmberg wrote:
> Hi,
>
> As we know, we have use-case and requirement to interwork with
> non-CLUE/”single stream” entities.
>
> But, we can provide guidance on how an SDP offer from a CLUE entity
> shall look like, when communicating with a non-CLUE entity.

There are a couple of cases here:

- The CLUE entity doing an initial dialog establishing INVITE, where the 
CLUE support of the callee is unknown.

- Offers to a peer that is known to not support CLUE. This will 
typically be subsequent offers within a dialog after an initial dialog 
establishing INVITE with o/a that discovers the peer doesn't support 
clue. It could also cover the initial invite/offer in cases where the 
caller knows (via config or whatever) that the peer doesn't support CLUE.

We have discussed the first of the above quite a bit, and IIUC we have 
agreed not to specify much about this. Some may choose to make a full 
CLUE offer and count on non-clue endpoints ignoring what they don't 
understand.

So I think you are talking about the other case. Is that right?
I'll assume that for now.

> That also
> ensures that every CLUE entity is able to generate scenes based on those
> requirements.
>
> -1 audio stream (single ssrc)
>
> -1 video stream (single ssrc)
>
> -1 presentation (video?) stream (single ssrc)
>
> This does not require spatial information, the receiver does not need to
> understand multiple streams per m- line, and the need for understanding
> the stream content is minimal.
>
> The provider of course have to be prepared that the non-CLUE entity may
> reject one or more of the offered streams. For example, an audio-only
> device would reject the video streams.
>
> And, the SDP offer may of course not always contain all above, if there
> e.g. is a session without a presentation.

While I think what you suggest seems to be a reasonably wise choice, I 
don't see any reason to specify it.

What I think might be more interesting is to talk about how a clue 
endpoint should interpret an incoming offer from a non-clue endpoint. In 
particular, how do various sorts of non-clue usages of SDP correspond to 
an implied advertisement from that endpoint?

	Thanks
	Paul