Re: [rtcweb] Common ways of handling video conferences? (Re: Why requiring pre-announcement)

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Emil Ivov
> Sent: 21 May, 2013 12:20 PM
> To: Paul Kyzivat
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Common ways of handling video conferences? (Re:
> Why requiring pre-announcement)
> 
> Hey Paul,
> 
> On 20.05.13, 20:00, Paul Kyzivat wrote:
> > On 5/17/13 4:30 AM, Emil Ivov wrote:
> >> On 16.05.13, 23:28, Harald Alvestrand wrote:
> >>> On 05/16/2013 09:22 PM, Emil Ivov wrote:
> >>>>> Then it is another
> >>>>>> question if it happens via SDP or via RTP header extensions or
> >>>>>> some other means.
> >>>>>>
> >>>>>> There was a discussion at the Stockholm rtcweb interim on what
> >>>>>> topologies that would be supported, but I fail to remember if
> >>>>>> this case was included or excluded.
> >>>> I couldn't find the discussion (in what WG did it happen?) but
> >>>> topologies based on RTP translators of one sort or another seem to
> >>>> be the default way of handling video conferencing these days so I
> >>>> don't see how we could possibly rule them out.
> >>>>
> >>>
> >>> This is an interesting statement. I've also heard the claim that
> >>> "RTP translators hardly exist outside the lab" - I think that quip
> >>> was referring to RFC 5117 section 3.3 Topo-Trn-Translators, the
> >>> story may be different for Topo-Media-Translators - but I thought
> >>> the most common form was the section 3.4 Topo-Mixer?
> >>
> >> Until recently, yes certainly, mixers were prevalent (which is
> >> arguably part of the reason why very few people had access to video
> conferencing).
> >>
> >> I think we'd all agree that this doesn't seem to be the case any
> >> longer and that for various reasons (including cost, quality and
> >> flexibility), most of the conferencing solutions today prefer
> >> shifting packets rather than mixing content.
> >
> > I would like to understand: when "most" is used in this discussion,
> > what are we measuring?
> > - number of distinct implementations (code bases) using this approach?
> > - number of conference sessions set up using this approach?
> > - number of conference user-minutes using this approach?
> > - something else
> 
> I was referring to easily observable trends. I certainly don't have exact
> numbers. I don't think I implied that and I don't think it's the most
important
> thing here. Skype, Hangouts, iChat, Asterisk, FreeSWITCH, Jitsi
Videobridge,
> all (seem to) have taken that approach rather than going for content
mixing.
> 
> While in RTCWEB we can't agree on the exact approach yet we all seem to
> have accepted that conferencing would imply separate RTP streams. The
> work you are doing in CLUE is another example since it is also about
> manipulating individual RTP streams.
> 
> Similar observations could be made about the not so distant past where
> content mixing seemed to be the default way of handling video
> conferencing.
> 
> So, the point I was making here was that:
> 
> With this shift in mind, topologies resembling RTP translators would
likely
> continue being increasingly popular. Constraints such as "Thou shalt
always
> pre-know your SSRCs" are hence likely to affect and weigh on a big number
> of scenarios.
> 
> Does this make more sense?
[Roni Even] This make sense but I assume that this approach works better
with scalable video (SVC) or simulcast  for endpoint mixing and I did not
see that RTCweb wants to mandate such support in the MTI video codec
discussion.

> 
> Emil
> 
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb