Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions

I think this is an important topic and should receive some agenda time in Quebec.

John 

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] 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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
> 