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

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Dec 2012 18:27:12 +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.
>
> 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.

Basically, yes. However, I wasn't talking so much about the signalling, or what one entity knows about the remote entity. I was more talking about the structure of scene/SDP 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.
>
> While I think what you suggest seems to be a reasonably wise choice, I
> don't see any reason to specify it.

I disagree. I think it would be very useful to specify it :)

It will make life easier when operators of non-CLUE networks introduce CLUE services. They will know what to assume/require from existing entities (network and endpoints) in order to be able to communicate with the CLUE entities, it will allow them to specify test and conformance specifications.

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

Well, we could basically say that a CLUE entity should reply with a similar response as the offer above:

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

...assuming, of course, that the offer contains the associated streams.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Mon, 03 Dec 2012 15:12:09 +1100

Hello Christer,

Given the recent discussion on restructuring the documentation for CLUE 
where do you see such guidelines being documented?

Perhaps the call flows can document the case of an initial invite to a 
CLUEfull and a CLUEless endpoint? In some cases the provider may know 
that the peer supports CLUE in some cases not.

Regards, Christian

On 3/12/2012 5:27 AM, Christer Holmberg wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Dec 2012 07:33:48 +0000

Hi,

>Given the recent discussion on restructuring the documentation for CLUE where do you see such guidelines being documented?
>
>Perhaps the call flows can document the case of an initial invite to a CLUEfull and a CLUEless endpoint? In some cases the provider may know that the peer supports CLUE in some cases not.

Call flow is good, but I would also like to have it normatively documented.

We are anyway going to need to have some normative procedures regarding SDP and offer/answer (which SDP extensions are used etc), so...

Regards,

Christer

On 3/12/2012 5:27 AM, Christer Holmberg wrote:
>>> 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.
>>>
>> - The CLUE entity doing an initial dialog establishing INVITE, where 
>> the CLUE support of the callee is unknown.
>>
>> 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.
>>
>>> That also ensures that every CLUE entity is able to generate scenes 
>>> based on those requirements.
>>>
>>> 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.
>> 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?