Datachannel: Port Numbers (#227)

Begin forwarded message:

From: pthatcherg <notifications@github.com<mailto:notifications@github.com>>
Date: August 24, 2015 at 09:15:01 PDT
To: openpeer/ortc <ortc@noreply.github.com<mailto:ortc@noreply.github.com>>
Cc: aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>>
Subject: Re: [ortc] Datachannel: Port Numbers (#227)
Reply-To: openpeer/ortc <reply+000c576b61db52e135e79cfdf76353a1ba5a7b2a3daf6ae792cf0000000111f3050592a16<mailto:reply+000c576b61db52e135e79cfdf76353a1ba5a7b2a3daf6ae792cf0000000111f3050592a16>>

Good point. Without specifying the port, it wouldn't be possible to attach
more than one SctpTransport to a single DtlsTransport. I'm not sure how
valuable that is, but there was some interest in such a thing at the last
IETF.

The port is per-SctpTransport, not per-DataChannel, so there is no conflict
with 1.0. It could go on either the constructor or in Start. Since it
acts as sort of an ID of the SctpTransport, I'd vote for the
constructor/readonly-attribute. If you don't specify one, it's chosen by
the browser.

On Sun, Aug 23, 2015 at 10:16 AM, aboba <notifications@github.com<mailto:notifications@github.com>> wrote:

> From Robin Raymond:
>
> We have an issue with the DataChannel API. There is we have no way to
> specify the SCTP port number associated with the data channel (but we do
> have a stream identifier) It is possible to make arbitrary assumptions
> about port numbers, such as assuming 5000, 5001,… based on “signalling”,
> i.e. SDP, and then the stream identifier is assigned to the port number to
> use (where multiple streams can be muxed into a single port).
>
> We have two options:
> 1) programmer must create an SCTP transport PER port then data channels
> are assigned to SCTP transport [thus DTLS transport would be a 1 to many
> SCTP transport relationship]… OR
>
> 2) we add an optional “port” number to the data channel so the data
> channel can go over a specified SCTP port number [and if not specified,
> then the system assigns one].
>
> The trouble with option #2 <https://github.com/openpeer/ortc/issues/2> is
> that the data channel API will include an additional param vs WebRTC 1.0
> (where the port number is inside the SDP).