Re: Issue 154: RTCP Port Control

I think the big question you bring up in your email is:  does the
IceGatherer (aka IceListener) need to know if the candidates it is
gathering are for RTP or RTCP?  I think in general, the answer is
"no", the IceGatherer doesn't care.

However, you point out two use cases that could perhaps be solved with
IceGatherer knowing.  Once is "+1 port for RTCP" and the other is "UDP
demotion".  I don't see the "+1 port" use case as very compelling
since I don't think there are any PSTN gateways (or any legacy
clients, for that matter) that speak both ICE and DTLS but require
this RTCP port behavior.  Do you know of any?

The second use case you mention is "udp demotion".  I'm not familiar
with that one.  Can you explain what a JS app would need to do be able
do, or expect the browser to do, that it can't right now?




On Sat, Oct 11, 2014 at 9:44 AM, Jiannan Zheng
<jzheng@exchange.microsoft.com> wrote:
> With the move of candidate gathering callback to the ICE gatherer class, we accidentally introduced a behavior change in the RTP/RTCP demux.
>
> 6/15 spec says:
> "createAssociatedTransport
> Create an associated RTCIceTransport for RTCP, and implicitly create a newly associated RTCIceListener object as well for RTCP, or reusing an existing RTCP RTCIceListener if one is already associated with the existing RTP RTCIceListener. If called more than once for the same component, throw an InvalidStateError exception. If called when component is "RTCP", throw a SyntaxError exception.
> "
> We do not do the "implicitly create a newly associated RTCIceListener object as well for RTCP, or reusing an existing RTCP RTCIceListener if one is already associated with the existing RTP RTCIceListener" any more with the move.
>
> Assuming we still do offer/answer, with the callback in ice transport and createassociatedtrasnport() call, browsers knows the RTP/RTCP association before generating the initial offer. After the move, because ice transport start needs the remote ice parameters, browser can only know this RTP/RTCP association after the answer.  We pretty much mandate the RTP/RTCP local candidate gathering should not be associated. It closes the door to support extensions like UDP demotion,which is needed to call many existing PSTN gateways and some of them needs this +1 behavior.  This is not a minor behavior change and we may need more discussions if we indeed want to take this 6/15 "associated listener" behavior out.
>
> The suggestion to move createassociated* together with the onlocalcandidate callback can keep the association behavior the same and satisfy the onlocalcandidate move request. It sounds to me a better solution.
>
> thanks,
>
> -Jiannan
>
> ________________________________________
> From: Bernard Aboba <Bernard.Aboba@microsoft.com>
> Sent: Wednesday, October 08, 2014 6:10 PM
> To: Peter Thatcher
> Cc: public-ortc@w3.org
> Subject: 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 Tuesday, 14 October 2014 01:21:59 UTC