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

Yes, we could get along without having getorCreateTransport() for  RTCP IceGatherer objects.

For example, if RTCIceTransport had an rtcpTransport attribute, then the application could figure out whether a corresponding RTCP IceTransport existed, and if not, could create it:

var rtpTransport = rtpIceGatherer.getOrCreateTransport();
if (!rtpTransport.rtcpTransport){
  var rtcpTransport = rtpTransport.createAssociatedTransport();
} else {
  rtcpTransport = rtpTransport.rtcpTransport;
}



On Jul 6, 2015, at 1:52 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

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<mailto: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.