Subject: [rtcweb] Contributions for the Interim meeting

From: Ted Hardie <[email-masked]>
Date: Tue, 3 May 2011 17:07:31 -0700

As you will have seen from Cullen's announcement, we are now officially a working group and starting to collect data on the possible timing of an interim meeting. 

For the interim meeting, we want to start work on the chartered deliverables.  If you are interested in being an editor for one of the working group docs, the chairs would like you to prepare something for the Interim as a draft-00 of your take.  If you can, raise your hand on the list to say you're doing so, so as to let others know to talk to you about collaborating.  If you are not able to attend any of the times put forward for the interim, you can still volunteer to edit a document--it just means you'll have to have the -00 done early enough for the chairs to find a stuckee for feedback coming in at the interim.

regards,

Ted, Cullen, and Magnus

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 03 May 2011 17:09:07 -0700

On 5/3/2011 5:07 PM, Ted Hardie wrote:
> For the interim meeting, we want to start work on the chartered deliverables.  If you are interested in being an editor for one of the working group docs, the chairs would like you to prepare something for the Interim as a draft-00 of your take.  If you can, raise your hand on the list to say you're doing so, so as to let others know to talk to you about collaborating.

I have started poking at charter item #3 "Define the solution - 
protocols and API requirements - for firewall and NAT traversal" to the 
point of starting a draft of my thoughts towards creating the 
browser-side requirements to support this.

Whether or not I have enough cycles to prepare a complete draft for the 
interim meeting is another story... if anyone else has put thought into 
this item lets get in touch.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 04 May 2011 14:29:41 +0200

I will offer an update to draft-alvestrand-dispatch-rtcweb-protocols as 
a candidate for the group's "overview/architecture" document. I'm not 
sure it makes sense to continue with 
draft-alvestrand-dispatch-rtcweb-datagram at this time.

                     Harald

On 05/04/11 02:07, Ted Hardie wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 5 May 2011 23:19:53 +0100

> For the interim meeting, we want to start work on the chartered deliverables.  If you are interested in being an editor for one of the working group docs, the chairs would like you to prepare somet…

We're planning an update to draft-perkins-rtcweb-rtp-usage-00 before the interim. This a candidate document for work item 4 from the charter:

  Define which media functions and extensions shall be supported in
  the client and their usage for real-time media, including media
  adaptation to ensure congestion safe usage.

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 05 May 2011 20:37:42 -0700

>    adaptation to ensure congestion safe usage.

I noticed within 
http://tools.ietf.org/id/draft-perkins-rtcweb-rtp-usage-00.txt that 
section 2 covers multiplexing. One item that may be of interest to bring 
into scope, from general multicasting (already denoted out of scope), is 
if the desired multicast-ability is within frame-complexes. I comprehend 
the concern to leave general multicasting out of discussion, so I have 
no argument there. My concern is more about shared memory and being able 
to stage frames across multiple clients (ideally on the same network or 
computer in the RESTful paradigm).

Even the simple review of RTP usage reveal others that desire shared 
memory across virtualization, which fallbacks to shared memory even if 
"frames" aren't mentioned in general. This is even more common now with 
virtualization of media surfaces. Frames then take on the role of to 
hold multiple regions where each region may be updated separately by 
multiple clients. In this in-frame scenario is where multicast is 
automatically back in scope in communication to each client that has 
some role in the single frame. This is not an argument to bring 
multicast fully back in scope, yet more for the similarity where shared 
memory is more obviously needed/requested for RTP Frames.

Perhaps, there is another terminology we can refer to this besides 
multicast since the "client/server" roles can flip/flop and not make 
much sense (especially to convey in documentation) to use either 
"client" or "server" when that flip/flop happens often enough. Other WGs 
have used forward flow and reverse flow after the client establishes 
initial connection (and both roles becomes moot-to-point), as they are 
seen as just end-points.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 06 May 2011 14:18:57 +0200

On 05/06/11 05:37, Dzonatas Sol wrote:
> section 2 covers multiplexing. One item that may be of interest to 
> bring into scope, from general multicasting (already denoted out of 
> scope), is if the desired multicast-ability is within frame-complexes. 
> I comprehend the concern to leave general multicasting out of 
> discussion, so I have no argument there. My concern is more about 
> shared memory and being able to stage frames across multiple clients 
> (ideally on the same network or computer in the RESTful paradigm).
>
> "frames" aren't mentioned in general. This is even more common now 
> with virtualization of media surfaces. Frames then take on the role of 
> to hold multiple regions where each region may be updated separately 
> by multiple clients. In this in-frame scenario is where multicast is 
> multicast fully back in scope, yet more for the similarity where 
> shared memory is more obviously needed/requested for RTP Frames.
If the charter can be read to make shared-memory models (the way the 
term "shared memory" is commonly used - with hardware accessible on the 
microsecond timescale) in scope, I think we have not formulated the 
charter well.

Synchronization of state is important for many kinds of applications, 
and I'm sure we'll get to primitives that are useful for that sooner or 
later, but I don't want to discuss "shared memory" paradigms.

                       Harald

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 06:48:43 -0700

On 05/06/2011 05:18 AM, Harald Alvestrand wrote:
>> scope), is if the desired multicast-ability is within 
>> frame-complexes. I comprehend the concern to leave general 
>> multicasting out of discussion, so I have no argument there. My 
>> concern is more about shared memory and being able to stage frames 
>> across multiple clients (ideally on the same network or computer in 
>> the RESTful paradigm).
>>
>> memory across virtualization, which fallbacks to shared memory even 
>> if "frames" aren't mentioned in general. This is even more common now 
>> with virtualization of media surfaces. Frames then take on the role 
>> of to hold multiple regions where each region may be updated 
>> separately by multiple clients. In this in-frame scenario is where 
>> multicast is automatically back in scope in communication to each 
>> client that has some role in the single frame. This is not an 
>> argument to bring multicast fully back in scope, yet more for the 
>> similarity where shared memory is more obviously needed/requested for 
>> RTP Frames.
> term "shared memory" is commonly used - with hardware accessible on 
> the microsecond timescale) in scope, I think we have not formulated 
> the charter well.
>
> and I'm sure we'll get to primitives that are useful for that sooner 
> or later, but I don't want to discuss "shared memory" paradigms.
>

Thanks. The word "region" appears more applicable than "shared memory" 
or "synchronization". Let the word "region" identifies the transition 
within staged frames. The concept of multiple regions within the RTP 
frame, and the frame succession of frame by frame over time, will do 
just enough for now with expectation to only "multicast" the regions 
within the given frame. The assumption can then be made regions are 
volatile in variable microseconds, yet default upon the update of the frame.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 06 May 2011 07:07:15 -0700

On 05/06/2011 06:48 AM, Dzonatas Sol wrote:
>>> if "frames" aren't mentioned in general. This is even more common 
>>> now with virtualization of media surfaces. Frames then take on the 
>>> role of to hold multiple regions where each region may be updated 
>>> similarity where shared memory is more obviously needed/requested 
>>> for RTP Frames.

This use-case may help convey this further: at the edge of the blackbox, 
assume end-point-A has an asset it doesn't want to share with the other 
end-points, yet given access to the frame then end-points-A can render 
to the media its asset while other end-points do the same with their 
assets they don't want to openly share. The end-points need to identify 
their region and when each region is volatile. Further multiplexing can 
either be done by proxy or where one end-points acts like the host to 
the other end-points as guest.

--

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 May 2011 16:51:01 +0200

Hi,

We are willing to continue the work on the use-case & requirements draft (draft-holmberg-rtcweb-ucreqs), if the group thinks thinks it's useful.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ted Hardie
> Sent: 4. toukokuuta 2011 3:08
> To: [email-masked]
> Subject: [rtcweb] Contributions for the Interim meeting
> 
> As you will have seen from Cullen's announcement, we are now 
> officially a working group and starting to collect data on 
> the possible timing of an interim meeting. 
> 
> For the interim meeting, we want to start work on the 
> chartered deliverables.  If you are interested in being an 
> editor for one of the working group docs, the chairs would 
> like you to prepare something for the Interim as a draft-00 
> of your take.  If you can, raise your hand on the list to say 
> you're doing so, so as to let others know to talk to you 
> about collaborating.  If you are not able to attend any of 
> the times put forward for the interim, you can still 
> volunteer to edit a document--it just means you'll have to 
> have the -00 done early enough for the chairs to find a 
> stuckee for feedback coming in at the interim.
> 
> regards,
> 
> Ted, Cullen, and Magnus

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 27 May 2011 09:26:54 +0200

Hi,

We are willing to contribute to the work on the use-case & requirements
document especially with inputs from the "draft-
marjou-dispatch-rtcweb-sip-rtp-interwk-reqs".

Cheers,
Xavier and Jean-François

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 30 May 2011 17:06:28 +0200

WG,

The Interim meeting is coming up. I would like to remind everyone that
has promised to contribute update documents, that these needs to be
available to everyone prior to the meeting. And prior enough that people
have a chance to read them. Thus before the end of these week they do
need to be submitted to IETF as drafts.

Cheers

Magnus

On 2011-05-04 02:07, Ted Hardie wrote:
> officially a working group and starting to collect data on the
> possible timing of an interim meeting.
> 
> For the interim meeting, we want to start work on the chartered
> deliverables.  If you are interested in being an editor for one of
> the working group docs, the chairs would like you to prepare
> something for the Interim as a draft-00 of your take.  If you can,
> raise your hand on the list to say you're doing so, so as to let
> others know to talk to you about collaborating.  If you are not able
> to attend any of the times put forward for the interim, you can still
> volunteer to edit a document--it just means you'll have to have the
> -00 done early enough for the chairs to find a stuckee for feedback
> coming in at the interim.
> 
> regards,
> 
> Ted, Cullen, and Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------