Re: Issue 154: RTCP Port Control

I think the question is more about where createAssociated belongs. When local candidate gathering was moved from the ICE Transport to the ICE gatherer, should createAssociated have moved with it? That would leave RTCIceTransport.component undetermined until .start is called (at which time it would be inherited from the gatherer). But this seems like it wouldn't be a big problem. 



> On Oct 8, 2014, at 1:17 PM, Peter Thatcher <pthatcher@google.com> wrote:
> 
> The application can keep around state about which candidates go with
> RTP and which go with RTCP.  It's not that hard for a handler to have
> access to that state (it can even just be a closure, I think).  I
> don't think the platform needs to do anything special to help it.
> 
> On Wed, Oct 8, 2014 at 12:59 PM, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
>> A related issue is that currently the RTCIceGatherer does not have a "component" property as the RTCIceTransport does.  One awkward implication of this is that the onlocalcandidate Event handler cannot determine the component of the ICE candidate based on properties of the RTCIceGatherer object because there is no RTCIceGatherer.component attribute.
>> 
>> To get around this, the sample code creates RTCIceTransport objects with names corresponding to the names of the RTCIceGatherer objects.  However, prior to calling RTCIceTransport.start (which may only occur quite a bit after creation of the RTCIceTransport and RTCIceGatherer objects) there is no association between an RTCIceTransport and RTCIceGatherer.
>> 
>> A somewhat more straightforward way to handle this would be to have an RTCIceGatherer.createAssociatedGatherer method, as well as an RTCIceGatherer.component attribute.
>> If we did this, I don't think we would need an RTCIceTransport.createAssociatedTransport() method.  Instead, the RTCIceTransport component could be determined from RTCIceTransport.gatherer.component.
>> ________________________________________
>> From: Bernard Aboba
>> Sent: Wednesday, October 08, 2014 12:02 PM
>> To: public-ortc@w3.org
>> Subject: Issue 154: RTCP Port Control
>> 
>> While RFC 3605 defines the "a=rtcp:" SDP attribute which allows for control of the RTCP port, there are legacy RTP implementations that assume that RTCP uses a port of RTP + 1.
>> 
>> Currently there is no way to indicate a relationship between RTP and RTCP RTCIceGatherer objects, or to request that an RTCIceGatherer object created for TCP use the port + 1 of the object created for RTP.
>>

Received on Thursday, 9 October 2014 01:10:43 UTC