Subject: [rtcweb] New use case: Large multiparty session

From: Arno Bakker <[email-masked]>
Date: Wed, 3 Aug 2011 10:36:20 +0200

Hi

as proposed in the July 26th meeting I'd like to put forward a new use
case: assume a client is involved in a large multiparty session but is
unable (or unwilling) to upload his signals to all participants.

This suggests forwarding support from the network is required, e.g.
some relay server, multicast, or the future IETF peer-to-peer streaming
protocol (PPSP).

Thanks,
     Arno Bakker

---

From: Randell Jesup <[email-masked]>
Date: Wed, 03 Aug 2011 08:51:00 -0400

> some relay server, multicast, or the future IETF peer-to-peer streaming

So the use case is:

User is part of a multiparty (3 or greater) session, but for one of 
several reasons (such as
available upstream bandwidth)  cannot send media to all other 
participants ("mesh" conferencing).
This requires that another node, either a central network node (such as 
a conferencing server)
or another member in the session, relay or mix the user's media to 
distribute to the rest of the
members of the session.

-- 
Randell Jesup
[email-masked]

---

From: Arno Bakker <[email-masked]>
Date: Wed, 3 Aug 2011 15:34:46 +0200

On 03/08/2011 14:51, Randell Jesup wrote:
>> assume a client is involved in a large multiparty session but is

Yes. Although your wording suggests a single relay node (central or 
member) is used. Please leave the option of true peer-to-peer 
distribution (or IP multicast) of the signal open.

CU,
      Arno

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 03 Aug 2011 13:29:34 -0400

I strongly support the use case, but I was under the impression that 
there has been a use case thar required a similar architecture: a 
"central" server (of course, it can be replicated) for accumulating 
input and distributing output.

For one thing, the music collaboration use case, I believe, calls for 
this architecture.

Perhaps one thing to watch for in the use case write-ups is separation 
between a use case and architecture. These are two different things 
because one architecture can fit many (and maybe all) use cases.

Igor

On 8/3/2011 8:51 AM, Randell Jesup wrote:
> This requires that another node, either a central network node (such 
> as a conferencing server)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 4 Aug 2011 05:29:53 +0530

Hi all,

<snip>
> 
> Perhaps one thing to watch for in the use case write-ups is 
> separation between a use case and architecture. These are two 
> different things because one architecture can fit many (and 
> maybe all) use cases.
> 
</snip>

As mentioned by Igor, I'm also looking for the architecture document
which provide the insight into RTCWeb deployment possibilities.

draft-rosenberg-rtcweb-framework-00 is one of the RTCWeb document which
is in the similar line.  I'm interested in hearing others opinion on
this. 

Thanks
Partha 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Igor Faynberg
> Sent: Wednesday, August 03, 2011 11:00 PM
> To: [email-masked]
> Subject: Re: [rtcweb] New use case: Large multiparty session
> 
> I strongly support the use case, but I was under the 
> impression that there has been a use case thar required a 
> similar architecture: a "central" server (of course, it can 
> be replicated) for accumulating input and distributing output.
> 
> For one thing, the music collaboration use case, I believe, 
> calls for this architecture.
> 
> Perhaps one thing to watch for in the use case write-ups is 
> separation between a use case and architecture. These are two 
> different things because one architecture can fit many (and 
> maybe all) use cases.
> 
> Igor
> 
> >> case: assume a client is involved in a large multiparty 
> session but 
> >> is unable (or unwilling) to upload his signals to all participants.
> >>
> >> some relay server, multicast, or the future IETF peer-to-peer 
> >> streaming protocol (PPSP).
> >
> > So the use case is:
> >
> > several reasons (such as available upstream bandwidth)  cannot send 
> > media to all other participants ("mesh" conferencing).
> > as a conferencing server) or another member in the session, 
> relay or 
> > mix the user's media to distribute to the rest of the 
> members of the 
> > session.
> >
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 08 Aug 2011 14:52:01 +0200

> distribution (or IP multicast) of the signal open.
In draft-ietf-rtcweb-use-cases-and-requirements-01.txt, the "central 
server" model is listed in section 4.3.3, "Video conferencing system 
with central server".

I am strongly opposed to adding use cases (which in turn generate 
requirements) to this first iteration of RTCWEB that we do not know how 
to fulfil with any currently deployed standard technology, so I would 
definitely want to leave the "peer to peer distribution or IP multicast" 
out of the picture for now. It can be added to a working appendix of 
"Use cases that have been discussed, but will not be considered as 
requirements in this iteration of RTCWEB".