Re: [maitai] Roles of Sender and Receiver

[Peter Musgrave <[e-mail]>]

Hi Paul, 

I too gravitate towards concrete examples...so I am happy to go down the rabbit hole.

<rabbit_hole>
One of Charles points was that an endpoint might not be able to select a specific video feed, but rather say something like "I only receive one stream, please use voice activity to decide which stream to send me".  So the answering EP might not know which of three streams this should be....

It's also starting to seem like either end potentially could be the one who makes the decision. 

In the SIP context you present, it is therefore not clear to me that the answering endpoint is always the one making the decision about which media stream to get (as would be "normal" in SIP) and the offeror can't make any decisions until it knows about the receivers configuration. 

In fact in the first exchange we also need to provide some information about media asymmetry (e.g. I may have three screens, but 4 cameras or three screens and two cameras). so my video m lines do not necessarily imply anything my ability to send that many videos....

I am not sure how best to do capability exchange. I suspect the description we end up with will be of non-trivial size. Perhaps it is a new Content body type - and these capabilities are exchanged instead of SDP in the first exchange? It would work - but it creeps me out - since I expect it breaks when going through most middle boxes. The other tools in the toolbox which could apply are SUBSCRIBE, NOTIFY, PUBLISH etc. Perhaps there is a role for them. If OPTIONS went end-to-end it could be a candidate...

Ok - out of the rabbit hole!
</rabbit_hole>

Let me ask more questions: 

Does the capability exchange need to be part of dialog establishment? 
Could it be done as a precursor exchange?
Could an endpoint reasonably cache capabilities of EPs it has prior contact with? [This may be important if our data representation requires a certain amount of "interpretation"] ?

Peter

On 2010-12-03, at 8:20 PM, Paul Kyzivat wrote:

> 
> 
> On 12/2/2010 7:53 AM, Peter Musgrave wrote:
>> Hi,
>> 
>> I have been pondering possible ways of representing a room configuration - but I think I need to back up and ask a question about basic interop architecture.
>> 
>> In the selection of content on a stream, who is the active decision making entity, sender - or receiver - or both?
>> 
>> Consider a three display, 3 camera (3d3c) room A sending to a 1d1c room B.
>> 
>> Does A offer all three streams to B and let B pick? (This leads in the direction of dynamic changes based on B, which is powerful but leads us into continuous control...)
>> Does A determine B has only one display and select which video B should get and send only one stream?
>> 
>> IHMO an approach which lets B have control over what it gets is more powerful. e.g. If I have heard the pitch from the speaker 100 times, I want to watch the customer and see if they are engaged, rather than watch the active speaker blather on....
> 
> Interesting question.
> 
> Maybe good to start considering this in purely sip terms without regard to telepresence specifics.
> 
> In that context I guess A might be sending an offer with three video m-lines, and would not initially know whether the recipient could deal with them all or not. (I'll ignore the audio to keep things simpler.) In a pure sip context it also may not be apparent what the roles are for the three media streams.
> 
> Then B would have to answer. If it can't handle three video m-lines, then it will have to choose one, though it may not have any basis to pick one over another. Perhaps it would just take the first.
> 
> So then we end up with a session having one video stream, with B having chosen *which* of the streams it was, and with A choosing *what* is transmitted on that stream.
> 
> And of course the challenge of maitai is to improve on that situation.
> 
> A minimalist improvement is for A to label the offered streams with the roles they play, so that B has a basis for choosing.
> 
> For maitai it will be necessary to do more than the above, so there is need for more description. But ideally it will be "backward compatible" to the extent that a dumb device will be able to make *some* sense of what it is offered and end up doing something as reasonable as it makes sense for a dumb device to do in that context.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> maitai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/maitai