Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions

[Colin Perkins <[e-mail]>]

I agree that there is a clear perception of a requirement here, and that we should discuss the issue in Quebec to determine if it's a real issue, and if so, how we should address the requirement.

Colin


On 20 Jul 2011, at 10:30, Elwell, John wrote:
> I think this is an important topic and should receive some agenda time in Quebec.
> 
> John 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On 
>> Behalf Of Magnus Westerlund
>> Sent: 19 July 2011 16:35
>> To: IETF AVTCore WG
>> Subject: [AVTCORE] RTP Internal Multiplexing of RTP sessions
>> 
>> WG,
>> 
>> As Individual contributor.
>> 
>> I don't know if people in the WG are aware of the discussion 
>> ongoing in
>> RTCWEB around multiplexing of protocols over the same underlying
>> transport flow, like UDP flow. That include RTP sessions.
>> 
>> There is a proposal:
>> "Multiplexing of Real-Time Transport Protocol (RTP) Traffic 
>> for Browser
>>                  based Real-Time Communications (RTC)"
>> https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux
>> /?include_text=1
>> 
>> This proposal is criticized by the following draft.
>> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usag
>> e/?include_text=1
>> 
>> There is an ongoing discussion on several aspects of these 
>> proposals on
>> the RTCWEB WG. You are welcome to go join the discussion of the other
>> questions raised on that mailing list.
>> 
>> Here I primarily want to raise the issue I see with 
>> multiplexing several
>> RTP sessions onto the same lower layer transport without something
>> explicitly identifying these separate sessions. And in particular the
>> RTP SSRC semantics changes that is proposed by the Rosenberg draft.
>> 
>> Personally I think it is time we tackle the issue of how to 
>> efficiently
>> run multiple RTP sessions over one lower layer transport. 
>> This as there
>> are several wanting to have that functionality. However, I think this
>> must be done in a very careful way. As we don't want to create an
>> alternative version of RTP which is what the Rosenberg 
>> proposal in fact
>> does. I do want us to gather the requirements on this and think of how
>> we can accomplish this.
>> 
>> I think there is a clear risk that we will not be able to 
>> accomplish it
>> without either adding some type of shim header which has it sets of
>> drawback or in fact fork or change the RTP protocol in such a way that
>> it will not be fully compatible with what exist today. But if 
>> that is to
>> be done, we should have a very clear consensus on that and ensure that
>> we then develop future extensions to RTP within a single 
>> version of the
>> protocol, not two.
>> 
>> As WG chair:
>> 
>> We are considering re-arranging the agenda to facilitate a debate of
>> this topic in Quebec.
>> 
>> So please indicate both your view of the topic in general and if you
>> think we should re-prioritize the agenda.
>> 
>> 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]
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
>> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt


-- 
Colin Perkins
http://csperkins.org/