RE: Manage RTP and RTCP transports

Re the ICE candidates, will the list provided to the RTP transport be applicable to its RTCP counterpart?  I agree we need to define an attribute to track its state if we go down this path.

-Shijun

From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Monday, June 2, 2014 3:38 PM
To: Shijun Sun
Cc: public-ortc@w3.org
Subject: Re: Manage RTP and RTCP transports

I don't think we can return void from  RTCIceTransport.createAssociatedTransport()  because then the JS can't provide it candidates, track its state, etc.

Whether the rtcp Transport is explicitly tracking RtpSender and RtpReceiver depends on which option we choose.  In the last email about this topic I sent to Bernard, I showed 3 or 4 options.  That is one of them.  But some of the options do not require that.

On Sat, May 31, 2014 at 7:23 AM, Shijun Sun <shijuns@microsoft.com<mailto:shijuns@microsoft.com>> wrote:
Looking through recent discussions on handling RTP and RTCP when they are on separate transports, I like the approach in the RTCIceTransportController, where the UA is expected to keep track of the pairing of RTP and RTCP transports internally, and adding an RCTP transport explicitly to the controller will throw exception.

A couple thoughts based on that.

Do we need the rtcpTransport on the RTCRtpSender and the RTCRtpReceiver explicitly?  If we can track the pairing of RTP and RTCP internally, the interface can be a bit cleaner.

To go one step further, is it possible to keep the RTCP transports as internal to UA?  For example, I wonder if it makes sense to have RTCIceTransport.createAssociatedTransport() just return void and keep the new RTCP RTCIceTransport internal and indicate that with a simple readonly attribute (e.g. boolean associatedTransportCreated, or something like that).  We can add a new attribute for the RTCP transport state or redefine the existing "state" attribute as a combined state.  A similar approach can be applied to the RTCDtlsTransport if this is along the right direction.

Thanks, Shijun

Received on Monday, 2 June 2014 22:54:02 UTC