RTCSctpTransport lacks remote port

[lgrahl]

If I haven't overlooked something, there's no way to determine the SCTP port of the remote peer.

For WebRTC, the remote port can be found in the offer/answer SDP.

I'm proposing to add the remote port to RTCSctpCapabilities as a remotePort port attribute. port in the constructor should also be renamed to localPort to avoid confusion. Furthermore, we should discuss whether RTCSctpCapabilities could be renamed to RTCSctpParameters because an SCTP port is not really a 'capability'.

Edit: I've withdrawn my suggestion to rename the attributes as other transports that provide parameters do not prefix the attributes with local or remote either.

Cheers,
Lennart

[lgrahl]

On second thought, adding port to the capabilities would not be sufficient for the current specified behaviour. For that to work, we would also have to specify that the SCTP INIT is triggered when the RTCSctpTransport is being started, instead of triggering it when it is being created. To be fair, that would make more sense to me anyway.

[aboba]

Since getCapabilities is static, it can only return generic capabilities like maxMessageSize, and not things like the local port, which are specific to an RTCSctpTransport object.

Which makes me wonder whether it shouldn't be getLocalParameters() instead.

[lgrahl]

Oh, it's static. I haven't seen that.

I'd upvote changing it to a non-static getLocalParameters method and including the port there.

[taylor-b]

Something related I ran into recently: in WebRTC 1.0, the local/remote SCTP ports are technically allowed to change.

Mapping this to ORTC: If the remote port changes, you can just call start again, but if the local port changes, you need to create a new ORTC RTCSctpTransport. This means there's a difference between an ORTC RTCSctpTransport and a WebRTC one; an ORTC RTCSctpTransport is tied to a specific local port number, but a WebRTC RTCSctpTransport isn't.

Unless we do want a new WebRTC RTCSctpTransport when the local port changes, but that's not documented in the WebRTC spec currently. Thoughts, @aboba?

[lgrahl]

Can you give a reference to a related RFC/draft that clarifies how this works for WebRTC? Does it use SCTP multihoming to add an address/port pair to the association? I haven't found anything in Google's code or in Mozilla's code regarding this (no calls to sctp_bindx. Also, SCTP address reconfiguration support in WebRTC is optional as stated here).

Furthermore, ORTC doesn't really specify what's supposed to happen when calling start on the RTCSctpTransport instance. But passing the remote port as part of a parameters object on start would mean that we have to change the description of the start method anyway as the handshake would need to be triggered when start is being called (otherwise, the remote port is unknown which makes it impossible to initiate the SCTP handshake).

[taylor-b]

JSEP points to draft-ietf-mmusic-sctp-sdp which says:

In order to trigger the closure of an existing SCTP
association, and establishment of a new SCTP association, the SDP
'sctp-port' attribute [Section 5] is used to indicate a new
(different than the ones currently used) SCTP port. The existing
SCTP association is closed, and the new SCTP association is
established, if one or both endpoints signal a new SCTP port. The
'connection' attribute does apply to establishment of underlying TCP
connections.

So I think the whole association is just closed and recreated. Chrome doesn't quite do this properly, but it does happen if you change the "m=" section direction to "inactive" and then back.

[lgrahl]

I hope you don't mind me asking but do you know of a use case for this procedure?

To add support for this, we would have to move most of the description for the RTCSctpTransport constructor into the start method (to be precise, everything after the first sentence excluding the very last sentence). When calling start again, the current SCTP association would need to be shut down before going through the starting procedure again. Furthermore, we could either choose to update the local port via the attribute directly or by moving the local port into the start method as well (I'd prefer that). Thoughts?

[lgrahl]

Another question I have is: What are the implications for open data channels? What if I choose to send a message at the very same moment where no SCTP association is available. Do you know if this is specified somewhere @taylor-b? I'm especially interested in the SCTP and data channel state relationship. (Sorry if this is a little bit off-topic)

[taylor-b]

What if I choose to send a message at the very same moment where no SCTP association is available.

The data channel state wouldn't be "open" then, so you'd get an InvalidStateError.

I hope you don't mind me asking but do you know of a use case for this procedure?

I don't know a use case. Maybe the easiest solution is to just say "this isn't allowed" in JSEP. Or do what I mentioned earlier, and create a new SctpTransport for each association. I'll raise this question in the WebRTC working group: w3c/webrtc-pc#979

[aboba]

Some possibilities:

1. add a remotePort argument to the start method
2. add a remotePort argument to the constructor
3. add a getLocalParameters method returning a dictionary which includes the port and change the argument of the start method to RTCSctpParameters remoteParams rather than RTCSctpCapabilities remoteCaps.

Approach 1 allows the start method to be called again to change the remote port. Approach 2 would require a new object if either the local or remote port changes.

[lgrahl]

Option 1 opens up a new problem: The average user doesn't want to specify which local port is going to be used. Furthermore, no check can be made whether the local port is actually available before calling the constructor. But when the constructor is being called, the remote port must already be known. Effectively, two peers would have to announce their local port to each other before knowing whether that port can be used.

I'm voting for 3 as it seems much more consistent to the rest of the API to have a parameters dict for SCTP as well. Furthermore, I'm suggesting to keep the local port argument at the constructor but add it to the start method as an optional argument as well. The local port of the start method would supersede the local port specified in the constructor. Here's why:

In ORTC, RTCDataChannel instances are created by passing a RTCDataTransport instance to the constructor. This indicates that the data channels are bound to the data transport. In case I want to change the local port, creating a new RTCSctpTransport instance would permanently close all data channels that have been created using that transport instance. At least this is my understanding of ORTC's behaviour.

If I understand correctly (and please correct me if I'm wrong @taylor-b), this is different to WebRTC where the data channels are only temporarily closed until the local port has been changed and a new data transport instance has been established. Then, they are reopened.

So to maintain compatibility, we would have to be able to change both local and remote port without creating a new RTCSctpTransport instance. Is this making sense to you guys?

[taylor-b]

I'd vote for 3 too.

If I understand correctly (and please correct me if I'm wrong @taylor-b), this is different to WebRTC where the data channels are only temporarily closed until the local port has been changed and a new data transport instance has been established. Then, they are reopened.

Actually, I think WebRTC is the same in this respect:

An RTCDataChannel object's underlying data transport [aka an RTCSctpTransport] may be torn down in a non-abrupt manner by running the closing procedure. When that happens the user agent must, unless the procedure was initiated by the close method, queue a task that sets the object's readyState attribute to closing.

And there's no mention of it returning from "closing"/"closed".

So to maintain compatibility, we would have to be able to change both local and remote port without creating a new RTCSctpTransport instance. Is this making sense to you guys?

Unless we say "there's one RTCSctpTransport per association". That's what I'm leaning towards here: w3c/webrtc-pc#979

I don't think WebRTC specifies this behavior right now, unless I'm overlooking something.