Re: [rtcweb] To multiplex or not!

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: 19 July 2011 15:28
> To: [e-mail]
> Subject: [rtcweb] To multiplex or not!
> 
> Hi,
> 
> This email is as an individual contributor.
> 
> I want to get started on the discussion of the Multiplexing of the
> various protocols over single lower layer transport flow, 
> such as a UDP
> flow. I will attempt to split up the questions into different emails.
> 
> The first question I think is reasonably easy to get answered, but I
> think it is time we determine if my belief in the answer is 
> correct or not.
> 
> The traffic between two RTCWEB peers from the various components, such
> as RTP sessions, datagram service:
> 
> a) MUST be sent as Individual flows for each component.
> 
> b) MUST be multiplexed into a single transport flow.
> 
> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
> peer MUST be able to send them as individual flows.
[JRE] As soon as we start talking about what an RTCWEB peer MUST support, the question arises whether this applies to the browser, the script or both. For example, a browser might implement each PeerConnection object over separate transports, but if the script chooses to use a single PeerConnection object for both audio and video it might not be interoperable with a peer that doesn't support multiplexing.

So whilst I agree that picking something along the lines of c) might be possible, we would need to define more precisely what we mean before coming to such an agreement.

John

John Elwell
Tel: [phone] (office and mobile)
Email: [e-mail]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.



> 
> I would love if people can indicate their choice or preferences.
> 
> I personally prefer A as it it is simplest in all aspect 
> except the NAT
> traversal.
> - It allows for flow based QoS.
> - It is the what the implementation that exist mostly do
> - Signaling protocols that exist support it, no extra functionality
> - People are used to the concept
> - It minimizes the difference to legacy.
> 
> Thus it is the quickest road to define something with the least formal
> push back and concern over maturity of any solution.
> 
> The downside with B and C is that we do have to solve the multiplexing
> and get an agreement that gets through all the hurdles.
> 
> Of these two opens I do prefer C.  Although it results in the extra
> complexities of having both alternatives, it will give us both a
> fallback, flow based QoS and better legacy support.
> 
> Now it is your time to make your opinion heard!
> 
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>