Subject: [clue] Tomorrow's design team meeting

From: Mary Barnes <[email-masked]>
Date: Mon, 27 Aug 2012 17:35:03 -0500

The meeting is on for tomorrow.  We have lots that we could talk about.  We
can start going through these and see how far we get and continue
discussion on the mailing list and then start back where we left off the
following week (or revisit if we think we have some progress).

1) RTP requirements - per
http://datatracker.ietf.org/doc/draft-lennox-clue-rtp-usage/
  Does everyone agree these are sufficient and if not why and what's
missing?
2) RTP topologies - per
http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/
  Are these adequate and comprehensive?
3) Tele-medical use case -
http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/
  Is this good - any other concerns?
4) Call flows in the framework document?
  Do we need them?
5) New signaling tickets - per the email I just posted (which isn't yet in
the archives)

Thanks,
Mary.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 28 Aug 2012 12:58:34 +0200

On the first item  the requirements are also discussed in section 5 of
draft-even-clue-rtp-mapping-03

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: 28 August, 2012 12:35 AM
To: CLUE
Subject: [clue] Tomorrow's design team meeting

The meeting is on for tomorrow.  We have lots that we could talk about.  We
can start going through these and see how far we get and continue discussion
on the mailing list and then start back where we left off the following week
(or revisit if we think we have some progress). 

2) RTP topologies - per

  Do we need them?

Thanks,

Mary.

---

From: Robert Hansen <[email-masked]>
Date: Tue, 28 Aug 2012 18:16:38 +0100

Notes from the meeting:

Participants:

Mary Barnes
Paul Kyzivat
Christer Holmberg
Espen Berger
John Leslie
Jonathon Lennox
Roni Even
Tom Kristensen
Robert Hansen

Mary brought up the requirements section of the two RTP documents; Roni 
clarified that he felt that there should be an explicit requirement that 
we should use existing protocols where they exist and ensure there is no 
duplication. There was agreement that this wasn't an RTP-specific 
requirement, and Mary pointed out that this was already present in the 
charter. Jonathon clarified that his document only referred to the media 
plane and RTP - Roni felt that that this was unclear and should be made 
explicit.

There was some further discussion and clarification of the requirements. 
Roni asked whether requirement 6 (being able to match packets to 
captures) was strictly an RTP requirement; Jonathon agreed that this was 
not a purely RTP requirement, but that one of his main aims was to avoid 
specifying any SDP syntax. There was further discussion of the 
reliability requirement, with clarification that the actual requirement 
was that the information was either predefined before the packet was 
received or was received as part of the packet iself.

Finally, Roni asked how SVC would interact with the requirement to only 
send a single stream to a given decoder. Jonathon explained that the 
solution would work with this, but that the language needed improving 
(and that he was referring to a single capture/encoding instantiation 
rather than to a capture itself).

Media capture 8 was contentious, as not all receivers will be able to 
support moving decode state between decoders (for instance, they could 
be on seperate hardware, in the extreme case). Roni pointed out that the 
receiver would need to signal this capability before the provider could 
take advantage of it. There was debate about whether this requirement 
was worth including, and if it was whether it needed to add an explicit 
requirement for this to be signalled or negotiated in signalling.

It was clarified that when there was a requirement for a refresh in 
decoder state this wasn't suggesting a new method for doing so and that 
RTCP FIR was suitable; CLUE would need to mandate supporting this. Roni 
also had concerns about the use of the phrase 'as much as possible' when 
it comes to the use of existing protocols (requirement 10). Jonathon 
clarified that what he meant was that we should stay within existing 
protocols and use well-defined extension points CLUE would make new use 
of the protocols, but as far as possible should, as far as possible, 
match existing behaviour. There was concern that some middle boxes might 
have issues with things like generally multiplexing multiple media 
streams onto a single RTP session, but we have limited control over that.

Finally for requirement 12 Jonathon explained why synchronisation was 
important, and clarified how this could be solved using CNAME in RTCP.

At the end of the meeting Paul reiterated that we could really use a 
term for the capture/encoding instantiations.

Rob

On 27/08/2012 23:35, Mary Barnes wrote:
> The meeting is on for tomorrow.  We have lots that we could talk about.
>   We can start going through these and see how far we get and continue
> 5) New signaling tickets - per the email I just posted (which isn't yet
> in the archives)
>
> Thanks,
> Mary.
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 28 Aug 2012 15:47:34 -0500

Rob,

Thanks for the taking the notes.  This is one session where folks might
find it useful (in particular those that couldn't make) to listen to the
recording:

*Streaming recording link:*
https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=7982272&rKey=94b7647395baf2ca
*Download recording link:*

https://ietf.webex.com/ietf/lsr.php?AT=dw&SP=MC&rID=7982272&rKey=9bedcff4e6dee779

On Tue, Aug 28, 2012 at 12:16 PM, Robert Hansen <[email-masked]> wrote:

> clarified that he felt that there should be an explicit requirement that we
> should use existing protocols where they exist and ensure there is no
> Roni asked whether requirement 6 (being able to match packets to captures)
> was strictly an RTP requirement; Jonathon agreed that this was not a purely
> RTP requirement, but that one of his main aims was to avoid specifying any
> SDP syntax. There was further discussion of the reliability requirement,
> with clarification that the actual requirement was that the information was
> either predefined before the packet was received or was received as part of
> the packet iself.
>
> solution would work with this, but that the language needed improving (and
> that he was referring to a single capture/encoding instantiation rather
> than to a capture itself).
>
> support moving decode state between decoders (for instance, they could be
> on seperate hardware, in the extreme case). Roni pointed out that the
> take advantage of it. There was debate about whether this requirement was
> worth including, and if it was whether it needed to add an explicit
> also had concerns about the use of the phrase 'as much as possible' when it
> comes to the use of existing protocols (requirement 10). Jonathon clarified
> that what he meant was that we should stay within existing protocols and
> use well-defined extension points CLUE would make new use of the protocols,
> but as far as possible should, as far as possible, match existing
> behaviour. There was concern that some middle boxes might have issues with
> things like generally multiplexing multiple media streams onto a single RTP
> session, but we have limited control over that.
>
> At the end of the meeting Paul reiterated that we could really use a term
> for the capture/encoding instantiations.
>
> Rob
>
>
>> http://datatracker.ietf.org/**doc/draft-lennox-clue-rtp-**usage/<http://datatracker.ietf.org/doc/draft-lennox-clue-rtp-usage/>
>> http://datatracker.ietf.org/**doc/draft-even-clue-rtp-**mapping/<http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping/>
>> http://datatracker.ietf.org/**doc/draft-ietf-clue-**
>> telepresence-use-cases/<http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/>
>> ______________________________**_________________
>> 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>
>