Re: getOrCreateTransport() method (Issues 223 and 170)

Can we just say that getOrCreateTransport doesn't work RTCP transports (ie
with RTCP-mux off)?   You get call forking or RTCP-mux off. Pick one.
Trying to support both at the same time seems like a lot of work for
something no one will ever need.

On Fri, Jul 3, 2015 at 1:01 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Peter Thatcher's proposed solution to Issue 170 is to add a
> getOrCreateTransport() method to the RTCIceGatherer:
>
> partial interface RTCIceGatherer : RTCStatsProvider {
>     RTCIceTransport           getOrCreateTransport (DOMString
> remoteUsernameFragment);
> };
>
> In addition, I believe it is also necessary to add a
> remoteUsernameFragment attribute to the RTCIceTransport:
>
> partial interface RTCIceTransport : RTCStatsProvider {
>     readonly    attribute DOMString?           remoteUsernameFragment;
> };
>
> One of the questions that has come up in attempting to define the
> operation of getOrCreateTransport() is the expected behavior when it is
> called on RTP and RTCP IceGatherer objects.
>
> In general, I believe that the desired behavior (for an IceGather with any
> component value) is as follows:
>
> Retrieve the associated RTCIceTransport with a matching
> remoteUsernameFragment value, or construct an RTCIceTransport iceTransport
> with iceTransport.remoteUsernameFragment set to the value passed in the
> argument.
>
> When called on an RTP IceGatherer object, this appears relatively
> straightforward (although it is not clear under what circumstances if any
> errors can occur).
>
> For an RTCP IceGatherer object, it is a bit trickier.  For example, what
> happens if there is no matching RTCP RTCIceTransport?  This could occur
> when there is an RTP RTCIceTransport with a matching
> remoteUsernameFragment, but no RTCP RTCIceTransport rtpIceTransport as been
> created yet (rtcpIceTransport =
> rtpIceTransport.createAssociatedTransport()).  Or there could be no
> matching RTP RTCIceTransport either (with or without an existing RTCP
> RTCIceTransport).  So there are a number of corner cases that need to be
> taken into account, and here it does appear that there is a need for one
> more exceptions to be thrown for some of those.
>
> Here is a strawman for the text describing the operation
> getOrCreateTransport().  Comments very welcome.
>
> Retrieve the associated RTCIceTransport with a matching
> remoteUsernameFragment value, or construct an RTCIceTransport iceTransport
> with iceTransport.remoteUsernameFragment set to the value passed in the
> argument. If component is "RTCP", and no matching associated
> RTCIceTransport can be found, determine the RTP RTCIceGatherer
> rtpIceGatherer that was used to create iceGatherer, and attempt to retrieve
> an RTCIceTransport rtpIceTransport with a matching remoteUsernameFragement.
> If no suitable rtpIceTransport is found, throw an "InvalidStateError"
> exception. If a suitable rtpIceTransport is found, and an associated RTCP
> RTCIceTransport rtcpIceTransport exists, return rtcpIceTransport. If no
> associated rtcpIceTransport exists, construct rtcpTransport by calling
> rtpTransport.createAssociatedTransport() set
> rtcpTransport.remoteUsernameFragement to the value passed in the argument,
> and return rtcpTransport.
>
>
>
>
>