PR for adding RTCSctpTransport, PeerConnection.getSctpTransports(), and RTCDataChannel.transport

According to rough consensus from TPAC 2014 and more refined consensus in
subsequent  discussion on the list, I have created PR 270 (
https://github.com/w3c/webrtc-pc/pull/270) which adds the following to
RTCDataChannel:

+        <dt>readonly attribute RTCSctpTransport</dt>
+
+        <dd>
+          <p>The SCTP transport over which data is send and received.</p>
+        </dd>

And this for RTCSctpTransport:

+      <section>
+        <h3>RTCSctpTransport Interface</h3>
+
+        <p>The <code>RTCSctpTransport</code> interface allows an
+        application access to information about the SCTP data channels
+        tied to a particular SCTP association.
+
+        <dl class="idl" title="interface RTCSctpTransport">
+          <dt>readonly attribute RTCDtlsTransport transport</dt>
+
+          <dd>
+            <p>The transport over which all SCTP packets for data
+              channels will be sent and received.
+          </dd>
+
+          <dt>readonly attribute unsigned int maxMessageSize</dt>
+          <dd>
+            <p>The maximum size of data that can be passed
+            to </code>RTCDataChannel.send</code>.</p>
+          </dd>
+        </dl>
+      </section>
+

After adding that, I realized that it might be wise to be consistent with
PC.getSenders() and PC.getReceivers and make PC.getSctpTransports():

+          <dt>sequence&lt;RTCSctpTransport&gt; getSctpTransports()</dt>
+
+          <dd>
+            <p>Returns a sequence of <code><a>RTCSctpTransport</a></code>
objects
+            representing the SCTP transports that are currently attached
to this
+            <code><a>RTCPeerConnection</a></code> object.</p>
+          </dd>


Now here is the interesting question:  Is it possible to have more than one
SctpTransport?  If not, we can change this to a readonly attribute of type
RTCSctpTransport.  But I believe the SDP in setLocalDescription and
setRemoteDescription allow for multiple m-lines of SCTP, so it could be
possible for us to support more than one SctpTransport per PeerConnection.
In fact, at IETF 93, there was some desire raised for such a thing to allow
for different priorities between them.

If we do allow more than one, it would also be useful to add an SCTP port
to the SctpTransport to differentiate between them:

+          <dt>readonly attribute unsigned int port</dt>
+
+          <dd>
+            <p>The SCTP "port" used to identify the SCTP association.
+            It is not related to a real network port.</p>
+          </dd>

And an SctpTransport.createDataChannel method to allow creating data
channels on a specific one:

+          <dt>RTCDataChannel createDataChannel([TreatNullAs=EmptyString]
+            DOMString label, optional RTCDataChannelInit
dataChannelDict)</dt>
+          <dd>
+            <p>Equivalent to PeerConnection.createDataChannel, except
+            tied to a particular SctpTransport.</p>
+            </p>
+          </dd>


I have added both of these to the PR to allow you to see what it would look
like.



So, the big questions for the WG are:

1.  Should we allow multiple SctpTransports per PeerConnection?
2.  Should we have PC.getSctpTransports (or PC.sctpTransport if the answer
to #1 is no)?
3.  Should we have SctpTransport.port?
4.  Should we have SctpTransport.createDataChannel?


My current opinion is "yes" to all of these.