Subject: [clue] Definitions: Participant

From: Stephan Wenger <[email-masked]>
Date: Tue, 31 May 2011 16:03:51 -0700

Hi all,
I thought I would quickly rev the definitions doc, and found out that I
cannot find agreements on a number of terms.  This is the first of a set of
eamils that will hopefully lead us to close the definitions on a few terms.
So this email is about "Participant".

We have the odd definition that RFC 4353 lists participant essentially as a
piece of software and not as a human.  To Song Haibin, Steve Botzko (and to
me), Participants sounds like human, though.

Several ways forward:
1. Use Participant in the 4353 sense only
2. Use Participant in the sense of a human participating in a telepresence
session only.  That would mean that there can be many participants at any
endpoint, and endpoint can have no participant (empty room or webcam), and
so forth.
3. Use Participant in the sense of 2) above, and add remark that if 4353
Participant is meant, this will be explicitely mentioned.
My preference is 1.  2 and 3 have too much potential for confusion.  Shame
on 4353 for that.

Opinions?

Stephan

---

From: "Gorzynski, Mark E (The Right One)" <[email-masked]>
Date: Tue, 31 May 2011 23:39:05 +0000

Greetings,

My preference is to use 'participant' in the 4353 sense as well since that is already established.  Perhaps there are other terms like 'attendee' or 'user'  that could be used for humans if needed?

If I could go back in time, I would try to change 4353 :).

Best Regards,
Mark G.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Tuesday, May 31, 2011 4:04 PM
To: [email-masked]
Subject: [clue] Definitions: Participant

Hi all,
I thought I would quickly rev the definitions doc, and found out that I cannot find agreements on a number of terms.  This is the first of a set of eamils that will hopefully lead us to close the definitions on a few terms.
So this email is about "Participant".

We have the odd definition that RFC 4353 lists participant essentially as a  piece of software and not as a human.  To Song Haibin, Steve Botzko (and to me), Participants sounds like human, though.

Several ways forward:

 1.  Use Participant in the 4353 sense only
 2.  Use Participant in the sense of a human participating in a telepresence session only.  That would mean that there can be many participants at any endpoint, and endpoint can have no participant (empty room or webcam), and so forth.
 3.  Use Participant in the sense of 2) above, and add remark that if 4353 Participant is meant, this will be explicitely mentioned.
My preference is 1.  2 and 3 have too much potential for confusion.  Shame on 4353 for that.

Opinions?

Stephan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 May 2011 19:49:57 -0400

I support using Participant in the 4353 sense.
(Its really the only definition that most of the software can use in a 
useful way. E.g. the conference roster is about these automata. This 
becomes especially obvious when you have the same "person" showing up 
multiple times in the roster.)

If there is need to talk about the human(s) associated with a 
participant, then it would make sense to define another term for that.

	Thanks,
	Paul (as individual)

On 5/31/2011 7:03 PM, Stephan Wenger wrote:
> cannot find agreements on a number of terms. This is the first of a set
> of eamils that will hopefully lead us to close the definitions on a few
> terms.
> We have the odd definition that RFC 4353 lists participant essentially
> as a piece of software and not as a human. To Song Haibin, Steve Botzko
> (and to me), Participants sounds like human, though.
>
> Several ways forward:
>
>    2. Use Participant in the sense of a human participating in a
>       telepresence session only. That would mean that there can be many
>       participants at any endpoint, and endpoint can have no participant
>       (empty room or webcam), and so forth.
>    3. Use Participant in the sense of 2) above, and add remark that if
>       4353 Participant is meant, this will be explicitely mentioned.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: aravind sethuraman <[email-masked]>
Date: Tue, 31 May 2011 22:28:56 -0400

Folks,
I apologize if i am repeating anything already discussed or have missed any point.
My 2 cents,

1.I agree with defining participant as per 4353. However, If we define participant in 4353 sense (to represent an entity), we must also further define the # of participants(humans in the call) to support possible offer and answer negotiation between 2 end points. Consider, for example, an end point (A) with 4 screens and 4 cameras in a telepresence call and have 4 human participants(for now) with another endpoint B with 4 camera 4 screen room that has 8 humans. if we do not consider the number of participants, we will expect a symmetrical 4 pairs of media sessions between the rooms. However, an optimal approach could be that, only the 2 middle camera capture from Room A and get rendered on the middle 2 screens of Room B whilst the capture from 4 cameras in Room B will be rendered on Room A. And these could perhaps be as part of re-negotiation or initial invite itself. 

2. In case of multi-point calls (i have not seen anywhere which says we do not support this  ) say a 3 way, would we would have to consider 2 separate SIP Invites as dialogs within a Telepresence Call transaction: or a Single SIP Call transaction? 

3. LEft Right and Center - does this mean there will be only ONE camera /screen to handle the Left segment, Center and Right (?). Does this not limit the end points to be 1,2 or 3 screen only? What about endpoints that want to send only or receive only?Also how will it be effective in end-points where # of cameras IS NOT EQUAL TO # of screens.
I would propose a publishing of end point capability in terms of # of screens and # of cameras and also define SEGMENTS (and # of capture cards and human participants per segment)

4 Again, in case of multi-point calls, how will simple L and Right be effective?

5. Asymmetrical end point interoperability - as in my previous example....what if Room B is a 3 screen room with 8 participants. Does the middle camera capture 4 and the cameras on the side capture 2 humans? 

Either we chose to be simple in interoperability and have CLUE worry ONLY about how to signal and negotiate multiple media lines and leave the rendering to the end point OR we enter Telepresence (not video conferencing) and further define such granular elements.

Comments/Criticisms are most welcome
Regards
Aravind Sethuraman

On May 31, 2011, at 7:49 PM, Paul Kyzivat wrote:

> (Its really the only definition that most of the software can use in a useful way. E.g. the conference roster is about these automata. This becomes especially obvious when you have the same "person" showing up multiple times in the roster.)
> 
> If there is need to talk about the human(s) associated with a participant, then it would make sense to define another term for that.
> 
> 	Thanks,
> 	Paul (as individual)
> 

Aravind Sethuraman
Software Architect
Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman