Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14]

From: Mary Barnes <[email-masked]>
Date: Mon, 26 Aug 2013 13:42:19 -0500

Christian,

It wasn't clear to me whether you are agreeing or disagreeing with what I
proposed.  I was suggesting a very basic definition so that we can complete
the requirements section. Are you suggesting an alternative to be included
in the requirements document?    I don't think we should have to wait for
completion of the framework to complete the requirements.

One thing I noticed is that the terms (and the text you have) are actually
introduced in the use cases document as follows, so I don't think we need
to re-iterate in other documents.  We could easily add a reference to this
specific section (3.3) of the use cases.  And, actually, I think the right
thing to do is to just add the reference to the "Multi-point meeting" use
case as a reference to REQMT-13 and REQMT-14.

   One common policy is called site switching.  Let's say the speaker is
   at site A and everyone else is at a "remote" site.  When the room at
   site A shown, all the camera images from site A are forwarded to the
   remote sites.  Therefore at each receiving remote site, all the
   screens display camera images from site A.  This can be used to
   preserve full size image display, and also provide full visual
   context of the displayed far end, site A.  In site switching, there
   is a fixed relation between the cameras in each room and the screens
   in remote rooms.  The room or participants being shown is switched
   from time to time based on who is speaking or by manual control,
   e.g., from site A to site B.

   Segment switching is another policy choice.  Still using site A as
   where the speaker is, and "remote" to refer to all the other sites,
   in segment switching, rather than sending all the images from site A,
   only the speaker at site A is shown.  The camera images of the
   current speaker and previous speakers (if any) are forwarded to the
   other sites in the conference.  Therefore the screens in each site
   are usually displaying images from different remote sites - the
   current speaker at site A and the previous ones.  This strategy can
   be used to preserve full size image display, and also capture the
   non-verbal communication between the speakers.  In segment switching,
   the display depends on the activity in the remote rooms - generally,
   but not necessarily based on audio / speech detection).

Mary

On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves <
[email-masked]> wrote:

> Hello Mary,
>
> Here's some text I've been working on with regards to the framework to
> better describe site and segment switch.
>
> The "site-switch" policy means all captures are switched at the same time
> to keep captures from the same endpoint site together. Let's say the
> speaker is at site A and everyone else is at a "remote" site.
> When the room at site A shown, all the camera images from site A are
> forwarded to the remote sites. Therefore at each receiving remote site, all
> the screens display camera images from site A. This can be used to preserve
> full size image display, and also provide full visual context of the
> displayed far end, site A. In site switching, there is a fixed relation
> between the cameras in each room and the displays in remote rooms. The room
> or participants being shown is switched from time to time based on who is
> speaking or by manual control.
>
> The "segment-switch" policy means different captures can switch at
> different times, and can be coming from different endpoints. Still using
> site A as where the speaker is, and "remote" to refer to all the other
> sites, in segment switching, rather than sending all the images from site
> A, only the image containing the speaker at site A is shown. The camera
> images of the current speaker and previous speakers (if any) are forwarded
> to the other sites in the conference.
> Therefore the screens in each site are usually displaying images from
> different remote sites - the current speaker at site A and the previous
> ones. This strategy can be used to preserve full size image display, and
> also capture the non-verbal communication between the speakers. In segment
> switching, the display depends on the activity in the remote rooms -
> generally, but not necessarily based on audio / speech detection.
>
> Regards, Christian
>
>
> On 24/07/2013 3:17 AM, Mary Barnes wrote:
>
>> My suggestion is to define the terms "site switching" and "segment
>> switching" in this document using terminology consistent with this
>> document. NOte, that these terms don't explicitly appear in the terminology
>> section of the framework, however, they are clearly described in 6.2.2. So
>> I think we can borrow some of that text and add a definition to the
>> requirements document and close this issue. My suggestion is something like:
>>
>> Site-switching:there is a fixed relation between the cameras in each room
>> and the displays in remote rooms. The room or participants being shown is
>> switched from time to time based on who is speaking or by manual control.
>>
>> Segment-switching: there is a variable relation between the cameras in
>> each room and the displays in different rooms. Rather than sending all the
>> images from a room, only the image with the active speaker is sent from a
>> specific room. Therefore the screens in each site are usually displaying
>> images from different remote sites - the current speaker at site A and the
>> previous ones.
>>
>> Please make suggestions if you have alternative wording. I'd like to get
>> this issue closed no later than August 12, 2013.
>>
>> Thanks,
>> Mary.
>>
>>
>> On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker <
>> [email-masked] <mailto:[email-masked].**ietf.org<[email-masked]>>>
>> wrote:
>>
>>     #39: OPEN-3 Conference modes [REQMT-14]
>>
>>     This wording of this requirement
>>     is problematic in part because the conference modes (site
>>     switching and segment switching) are not defined. It at
>>     least needs rewording. This is deferred until broader
>>     discussion on layout is concluded.
>>
>>     --
>>     ------------------------------**-------+----------------------**
>> ---------------
>>     Reporter: | Owner: draft-ietf-clue-
>>     [email-masked] <mailto:mary.ietf.barnes@**gmail.com<[email-masked]>>
>> |
>>     telepresence-
>>     Type: defect | [email-masked]
>>     <mailto:requirements@tools.**ietf.org <[email-masked]>>
>>
>>     Priority: major | Status: new
>>     Component: telepresence- | Milestone: milestone1
>>     requirements | Version:
>>     Severity: Active WG Document | Keywords:
>>     ------------------------------**-------+----------------------**
>> ---------------
>>
>>     Ticket URL: <http://trac.tools.ietf.org/**wg/clue/trac/ticket/39<http://trac.tools.ietf.org/wg/clue/trac/ticket/39>
>> >
>>     clue <http://tools.ietf.org/wg/**clue/<http://tools.ietf.org/wg/clue/>
>> >
>>
>>
>>
>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 27 Aug 2013 11:07:54 +1000

Hello Mary,

I was making a comment to stimulate discussion. If we want to finish the 
requirements document without referring to the other documents e.g. the 
use cases or framework we should avoid using these terms. It would mean 
that we just need to update REQ-14:

    REQMT-14:  The solution MUST support mechanisms to make possible for
               either or both site switching or segment switching.  [Edt:
               This needs rewording.  Deferred until layout discussion is
               resolved.]

I propose rewording to:

REQMT-14: The solution MUST support mechanisms to allow media from one 
source endpoint or/and multiple source endpoints to be sent to a remote 
endpoint at a particular point in time. Which media is sent at a point 
in time may be based on local policy.

I think we just need to focus on the "source" and "time" aspect rather 
than the relation between camera and displays. The display aspect is up 
to the local policy of the receiving endpoint.

Regards, Christian

On 27/08/2013 4:42 AM, Mary Barnes wrote:
> Christian,
>
> It wasn't clear to me whether you are agreeing or disagreeing with 
> what I proposed.  I was suggesting a very basic definition so that we 
> can complete the requirements section. Are you suggesting an 
> alternative to be included in the requirements document?    I don't 
> think we should have to wait for completion of the framework to 
> complete the requirements.
>
> One thing I noticed is that the terms (and the text you have) are 
> actually introduced in the use cases document as follows, so I don't 
> think we need to re-iterate in other documents.  We could easily add a 
> reference to this specific section (3.3) of the use cases.  And, 
> actually, I think the right thing to do is to just add the reference 
> to the "Multi-point meeting" use case as a reference to REQMT-13 and 
> REQMT-14.
> On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     Hello Mary,
>
>     Here's some text I've been working on with regards to the
>     framework to better describe site and segment switch.
>
>     The "site-switch" policy means all captures are switched at the
>     same time to keep captures from the same endpoint site together.
>     Let's say the speaker is at site A and everyone else is at a
>     "remote" site.
>     When the room at site A shown, all the camera images from site A
>     are forwarded to the remote sites. Therefore at each receiving
>     remote site, all the screens display camera images from site A.
>     This can be used to preserve full size image display, and also
>     provide full visual context of the displayed far end, site A. In
>     site switching, there is a fixed relation between the cameras in
>     each room and the displays in remote rooms. The room or
>     participants being shown is switched from time to time based on
>     who is speaking or by manual control.
>
>     different times, and can be coming from different endpoints. Still
>     using site A as where the speaker is, and "remote" to refer to all
>     the other sites, in segment switching, rather than sending all the
>     images from site A, only the image containing the speaker at site
>     A is shown. The camera images of the current speaker and previous
>     speakers (if any) are forwarded to the other sites in the conference.
>     Therefore the screens in each site are usually displaying images
>     from different remote sites - the current speaker at site A and
>     the previous ones. This strategy can be used to preserve full size
>     image display, and also capture the non-verbal communication
>     between the speakers. In segment switching, the display depends on
>     the activity in the remote rooms - generally, but not necessarily
>     based on audio / speech detection.
>
>     Regards, Christian
>
>
>         My suggestion is to define the terms "site switching" and
>         "segment switching" in this document using terminology
>         consistent with this document. NOte, that these terms don't
>         explicitly appear in the terminology section of the framework,
>         however, they are clearly described in 6.2.2. So I think we
>         can borrow some of that text and add a definition to the
>         Site-switching:there is a fixed relation between the cameras
>         in each room and the displays in remote rooms. The room or
>         participants being shown is switched from time to time based
>         on who is speaking or by manual control.
>
>         Segment-switching: there is a variable relation between the
>         cameras in each room and the displays in different rooms.
>         Rather than sending all the images from a room, only the image
>         with the active speaker is sent from a specific room.
>         Therefore the screens in each site are usually displaying
>         images from different remote sites - the current speaker at
>         site A and the previous ones.
>
>         Please make suggestions if you have alternative wording. I'd
>         like to get this issue closed no later than August 12, 2013.
>
>         Thanks,
>         Mary.
>
>
>         On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>         -------------------------------------+-------------------------------------
>         [email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>> |
>             telepresence-
>         <mailto:[email-masked]>
>             <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         -------------------------------------+-------------------------------------
>
>             Ticket URL:
>         <http://trac.tools.ietf.org/wg/clue/trac/ticket/39>
>             clue <http://tools.ietf.org/wg/clue/>
>
>
>
>
>         _______________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/clue
>
>
>     _______________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Aug 2013 08:35:18 -0500

Hi Christian,

Thanks for the proposal.  My comments are below.

For the WG, we really need feedback from other folks on how to handle this
requirement.  This is the only remaining open issue for the requirements
document.

Mary.

On Mon, Aug 26, 2013 at 8:07 PM, Christian Groves <
[email-masked]> wrote:

> requirements document without referring to the other documents e.g. the use
> cases or framework we should avoid using these terms.

[MB] Actually, the requirements absolutely should refer to the use cases.
 There are references to many of the use cases referenced in the
requirements. [/MB]

> It would mean that we just need to update REQ-14:
>
> endpoint at a particular point in time. Which media is sent at a point in
> time may be based on local policy.
>
[MB] I'd like to hear from others, but personally, I think that the
requirement stated as is is okay if we add the reference to section 3.3 to
the requirement.   However, I have no issues with your proposal either.
[/MB]

> than the relation between camera and displays. The display aspect is up to
> the local policy of the receiving endpoint.
>
> Regards, Christian
>
>
>> actually introduced in the use cases document as follows, so I don't think
>> we need to re-iterate in other documents.  We could easily add a reference
>> to this specific section (3.3) of the use cases.  And, actually, I think
>> the right thing to do is to just add the reference to the "Multi-point
>> meeting" use case as a reference to REQMT-13 and REQMT-14.
>> [email-masked] <mailto:Christian.Groves@**nteczone.com<[email-masked]>>>
>> wrote:
>>
>>     Hello Mary,
>>
>>         <mailto:trac%2Bclue@trac.**tools.ietf.org<[email-masked]>
>> >
>>         <mailto:[email-masked].**ietf.org<[email-masked]>
>>
>>         <mailto:trac%2Bclue@trac.**tools.ietf.org<[email-masked]>>>>
>> wrote:
>>
>>                    ------------------------------**
>> -------+----------------------**---------------
>>         [email-masked] <mailto:mary.ietf.barnes@**gmail.com<[email-masked]>
>> >
>>         <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>
>>
>>         <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>>>
>> |
>>             telepresence-
>>         <mailto:requirements@tools.**ietf.org<[email-masked]>
>> >
>>             <mailto:requirements@tools.**ietf.org<[email-masked]>
>>
>>         <mailto:requirements@tools.**ietf.org<[email-masked]>
>> >>
>>
>>                    ------------------------------**
>> -------+----------------------**---------------
>>
>>             Ticket URL:
>>         <http://trac.tools.ietf.org/**wg/clue/trac/ticket/39<http://trac.tools.ietf.org/wg/clue/trac/ticket/39>
>> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Aug 2013 09:53:46 -0400

IMO Christian's rewording gets the job done and avoids getting the 
requirements entangled with terms that are hard to define.

	Thanks,
	Paul (as individual)

On 8/27/13 9:35 AM, Mary Barnes wrote:
> For the WG, we really need feedback from other folks on how to handle
> this requirement.  This is the only remaining open issue for the
> requirements document.
>
> Mary.
>
>
> On Mon, Aug 26, 2013 at 8:07 PM, Christian Groves
>     I was making a comment to stimulate discussion. If we want to finish
>     the requirements document without referring to the other documents
>     e.g. the use cases or framework we should avoid using these terms.
>
> [MB] Actually, the requirements absolutely should refer to the use
> cases.  There are references to many of the use cases referenced in the
> requirements. [/MB]
>
>     REQMT-14: The solution MUST support mechanisms to allow media from
>     one source endpoint or/and multiple source endpoints to be sent to a
>     remote endpoint at a particular point in time. Which media is sent
>     at a point in time may be based on local policy.
>
> requirement stated as is is okay if we add the reference to section 3.3
> to the requirement.   However, I have no issues with your proposal
> either. [/MB]
>
>
>     I think we just need to focus on the "source" and "time" aspect
>     rather than the relation between camera and displays. The display
>     aspect is up to the local policy of the receiving endpoint.
>
>     Regards, Christian
>
>
>         It wasn't clear to me whether you are agreeing or disagreeing
>         with what I proposed.  I was suggesting a very basic definition
>         so that we can complete the requirements section. Are you
>         suggesting an alternative to be included in the requirements
>         document?    I don't think we should have to wait for completion
>         of the framework to complete the requirements.
>
>         One thing I noticed is that the terms (and the text you have)
>         are actually introduced in the use cases document as follows, so
>         I don't think we need to re-iterate in other documents.  We
>         could easily add a reference to this specific section (3.3) of
>         the use cases.  And, actually, I think the right thing to do is
>         to just add the reference to the "Multi-point meeting" use case
>         as a reference to REQMT-13 and REQMT-14.
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>              Hello Mary,
>
>         images
>                  requirements document and close this issue. My
>         suggestion is
>                  something like:
>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked]
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>>> wrote:
>
>           ------------------------------__-------+----------------------__---------------
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>
>
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>> |
>                      telepresence-
>                  <mailto:[email-masked]
>                      <mailto:[email-masked]
>                  <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>           ------------------------------__-------+----------------------__---------------
>
>                      Ticket URL:
>                  <http://trac.tools.ietf.org/__wg/clue/trac/ticket/39
>         <http://trac.tools.ietf.org/wg/clue/trac/ticket/39>>
>                      clue <http://tools.ietf.org/wg/__clue/
>         <http://tools.ietf.org/wg/clue/>>
>
>
>
>
>                  _________________________________________________
>                  clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>              _________________________________________________
>              clue mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>
>
>