Re: [rtcweb] How to multiplex between peers

[Stephan Wenger <[e-mail]>]

Hi Magnus,


On 7.25.2011 03:30 , "Magnus Westerlund" <[e-mail]>
wrote:

>[...]
>
>>
>> That said, if I'm not completely mistaken, you can implement the
>> multiparty use cases using the "RTCP terminating MCU" topology of RFC
>> 5117.  This is common implementation practice in video conferencing.  If
>> you do so, the multiparty support of RTPv2 is neither exercised nor
>>needed
>> in a multiparty video conference.
>
>First of all if you do that you loose functionality as discussed in RFC
>5117. For example the indication of who actually sent a packet
>originally or contribute to the mix can't be provided unless you let the
>SSRC or CSRC plus CNAMES be forwarded across the Mixer/MCU.

Correct.  So what?  There is such a thing as a signaling plane.  In all
practical commercial systems I'm aware of, the signaling plane information
is the ONLY information that is used for the identification of
participants (including mixed participants).  Unfortunately, this
information is most often conveyed using nonstandard means.  No one in
video conferencing that I'm aware of relies on the SSRC/CSRC + CNAME
mechanism.  Let me know if I'm wrong.

I'm not saying that this design choice is necessarily the best possible
for rtcweb.  But I'm claiming that the practical implementation experience
speaks in favor of it.  So the burden of proof of requiring its use (which
may break other aspects that have been identified by many here as
critical, such as minimizing the number of ports), should be on you, not
on me.  

>In addition it forces the central unit into one particular
>implementation, instead of allowing to use what it most appropriate.
>
>An RTP mixer when you want something that has functionality and
>application enhancing behavior and the cost is more complexity.
>
>Or you use an relay which simply copies a packet from one entity to all
>the others. That is the simplest central node you can build and it will
>have no media processing at all.

Sorry, I wasn't able to follow this train of thought.  If this was related
to implementation complexity of media plane signaling of mixed media
streams vs. signaling plane signaling of similar information, I would
argue that the majority of the implementers, so far, appear to have sided
with signaling plane rather than media planeŠ  I'm sure that they had a
reason.  

>
>Also, in any gateway case to existing legacy you don't want to have to
>implement additional gatewaying functions just because one want to use
>non standard RTP.

That's also my understanding.  Is it strong enough an argument, given the
(many, I believe) other issues a gateway may need to worry about?

>
>For me it is clear that ensuring that RTCWEBs RTP usage is vanilla will
>help us avoid a lot of problems down the road.

I'm arguing the same thing as you, but we define "vanilla" differently.
You seem to define it as "use of RTP as specified in both language and
intent of the standard, and following the 1990 generation of understanding
of the standard".  I define it "use RTP in the way it has been implemented
in the industry relevant here (video conferencing industry) over the last
decade or so."

>
>If we are going to multiplex this mechanism needs to have a behavior
>that doesn't change the core behaviors of RTP. If we can do that the
>multiplexing becomes much less a hot topic.
>

Again, we agree, perhaps except for the interpretation of "core behavior".
 In my view, "core behavior" does not include mechanisms such as CC, CSRC,
as they are AFAIK  not practiced in most real-world systems.  It may
include, though, include mechanisms such as SSRC multiplexing, as this
mechanism IS deployed in millions of systems, with no known adverse
effects on the operation of the Internet as a whole, or the RTPish things
that are part of the Internet.

Cheers,
Stephan
 

>
>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]
>----------------------------------------------------------------------
>