Re: [MMUSIC] [rtcweb] SDP work needed for WebRTC stuff

[Magnus Westerlund <[e-mail]>]

Hi,

My Personal view on this topics.

On 2012-12-11 06:01, Bernard Aboba wrote:
> I do not think that a single meeting, virtual or actual, will suffice to
> get things back on track.  We need a fundamental change of approach.
> 

Fully agreed. One of the issues, is that not a single individual of use
across 5-6 WG have a complete picture of the issues we are stepping into
with the fundamental issues that are in the center of this. This will
require multiple individuals having knowledge on different aspects to
fill in details and educate the others on the diverse issues.


>  
> 
> The basic problem is that WebRTC work items have been dispersed between
> a number of WGs other than RTCWEB.  Within these WGs, WebRTC is only a
> sideline.

I am not certain that is the fundamental issue here. I think the very
basic problem is that we are attempting for fork lift SDP into a clear
specification supporting multi-stream RTP sessions and dealing with the
diverse landscape of relationships that exists in multi-media
applications between a large number of terminologies that include
concepts such as:

- Multi-party
- Multiple media sources, i.e. camera microphones
- Media Mixes or Compositions
- Synchronization Contexts
- End-point concepts, virtual, distributed, etc.
- Diverse signalling models
- Simulcast
- Layered Encoding
- Transport robustification, i.e RTP Retransmission, Duplications, FEC.
- Different transports, aggregated over single unicast, multiple unicast
flows, multicast
- Different security mechanisms

This coupled with that the people putting in requirements on this are
working on different type of systems or applications, RTCWEB/WebRTC and
CLUE just being two. We also have existing users of RTP that made
different assumptions in extensions and signalling.

It was very evident in RTCWEB and AVTEXT that we are lacking common
terminology to even discuss the above and what it means in different
contexts.

Then we haven't even discussed what happens the minute you drag the word
"Legacy" into any of the above debates for actual solutions. But now I
am getting ahead of myself. I think the most important is to build a
good description of the different functionalities and their
relationships that we today believe are necessary to deal with currently
and in the near future.

> 
>                                                                                                                            
> 
> 
> As a result, work items such as BUNDLE (which require non-trivial
> analysis and discussion) have found themselves a needle in a haystack of
> other items, getting a fraction of the attention that they need to move
> forward.  

Yes, bundle is something that covers parts of the above and clearly
related. I, however think more close to the core of the issues is the
multiple stream issues and how we deal with relationships. However, I
think failing to take the related topics into account and think that
this will be quickly resolved will only result in generating even more
mess.

I also believe that in the end we are going to have to take some though
decisions when it comes how to deal with existing definitions. Either
replace them or basically deprecate some behaviors.

> 
> While allocating some substantial time at an in-person RTCWEB/MMUSIC
> interim can help, for that time to be well spent will require
> substantial preparation.  As an example, I could see a virtual AVTEXT
> interim being scheduled for mid-January at which Jonathan Lennox’s
> hierarchy draft could be given substantial time and an MMUSIC virtual
> interim in the same time frame which could be devoted to one or two
> important topics (e.g. BUNDLE, SCTP).
> 

Fully agreed. This takes preparations and hard work.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------