RE: Issue 154: RTCP Port Control

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 Wednesday, 8 October 2014 19:59:50 UTC