Re: [rtcweb] How to multiplex between peers

[Colin Perkins <[e-mail]>]

On 21 Jul 2011, at 08:43, Stephan Wenger wrote:
> On 7.20.2011 23:51 , "Colin Perkins" <[e-mail]> wrote:
>> On 21 Jul 2011, at 00:24, Jonathan Lennox wrote:
>> ...
> Rtcweb is working towards what I would call a "system" specification--something, the IETF (or at least RAI) is not usually involved in.  Outside the IETF, it's not uncommon that "system" specifications effectively modify an underlying base specification--RTP in this case.  Such modifications can as easily remove functionality deemed unnecessary as add new one.
> 
> Speaking about session multiplexing as an example, I would guess that a lot of people here are implicitly arguing removal of functionality of RTP not needed for the application--namely multicast support.  SSRC (re-)allocation) may be broken, but since there should not be any need for it (no multicast), who cares?  RTCP reporting intervals and timing rules are broken: again, who cares if the RTP/RTCP communication relationship is either endpoint-endpoint or endpoint-MCU (and RTCP is not being forwarded to all endpoints)?  RTCP-Terminating MCU and not Mixer in RFC 5117 namespace?  We will not see network flooding or something with RTCP RRs in point-to-point RTP communication relationships... I have not thought about RTCP's issues with multiple clock rates, but those difficulties are probably not insurmountable, either, because, while there may be multiple clock rates, those ought to be a finite, and small, set.

I don't think anyone is arguing that there difficulties cannot be solved. Of course they can. What's being argued is that the result is different to RTP, is not backwards compatible, and is difficult to gateway into a standard RTP environment. 

Some of us believe that there's benefit to being able to reuse the RTP infrastructure, and to easily interoperate with existing systems. I do not believe the benefit of saving a small number of UDP ports, in a browser environment that regularly uses dozens of TCP ports, outweighs the loss of compatibility with other systems.

> Now to my key point: you argue these things need to be "carefully evaluated" in AVTCORE. IMO, while it may be desirable for AVTCORE experts to chip in (as they do on this very thread already:-), it is by no means necessary.  Neither formally, not practically.  And certainly AVTCORE should not assume a "blocking" position.  This puts IETF system level specification at a disadvantage to system level specification work elsewhere (where it happens on a daily basis, see ITU, see 3GPP), and where no one asks for AVTCORE's permission to re-use RTP data structures without re-using all of RTP.  Tinkering with the multicast functionally of RTP is not new, there is a lot of implementation experience in the field, and for once we can indeed rely on "running code" answers.
> 
> I advocate pragmatism. (And, heretic as I am, in the long term we should think about RTPv3, dumping multicast.  Have I said this before? :-)

You have, of course. Many people have. What's not clear to be is how you would remove multicast support from RTP without also removing multiparty support? I see lots of RTP features that are there to support group communication, very few that are specific to multicast.

And, besides, I can certainly envisage scenarios where one might want a browser-based RTP implementation to watch the multicast IPTV flows that ISPs are now offering. 

Colin