ICE Candidate - does it need a connection ID in the candidate structure?

[robin-raymond]

Not sure why you'd need it...

Is it informational only? Does it need to be set for the remote party?

[ibc]

Both peers must agree on the connection id, so when Alice tells Bob "I will send audio over connection 1234" and Bob tells Alice "I will send audio over connection 1234" they both know that "1234" points to an existing connection.

Why does the ICE candidate description include the connection-id? For the case in which multiple connections exist with different local sockets (so different set of ICE candidates that must be signaled to the party telling it which connection each candidate belongs to).

[ibc]

Both peers must agree on the connection id, so when Alice tells Bob "I will send audio over connection 1234" and Bob tells Alice "I will send audio over connection 1234" they both know that "1234" points to an existing connection.

I'm realizing that this is not entirely true. The id of each RTCConnection (in both sides) could be different since its value is signaled from Alice to Bob and vice versa, so the remote id is entereed in the local RTCConnection which does exist in the RTCMediaSession and thus the session is aware of the remote identifier of the connection (regardless does not match the local identifier for the same connection).

[robin-raymond]

The candidates are added to the connection object by the higher layer directly, so it's obvious which connection it belongs from the browser's perspective. The extra information is not needed, and if there is ambiguity the higher layer can signal which candidate came from which connection their own way but specifically in the API it's just not needed as far as I can see.

[ibc]

Given that candidates are generated on the RTCConnection (so they are aware of the connection id) is it to bad to include a connection-id attribute in their RTCIceCandidateDescripton? Just wondering. Of course it is not needed, but... well, it is free...

[robin-raymond]

Yes, there is a potential downside to leaving it in. Consider forking. If Alice sends a single offer containing the candidate connection ID goes out Bob on two devices, both devices will think they are connecting to 'connection-id: 1', but in fact only one is, and the other isn't since the second Bob device will require a new connection to be spun up even though the candidates from the original connection's offer work for the secondary Bob device.

[ibc]

Good point! I will remove it. But let me a question:
Assuming such a removal, will the rest of the current stuff work? This is:

• Alice creates a RTCConnection with id=1, get local candidates and adds tracks to the session so every track description (RTCTrackDescription) includes connection-id: 1.
• Alice signals the "session invite" to Bob containing all the information.
• Forks happens and the offer ends in Bob-1 and Bob-2.
• Both Bob-1 and Bob-2 see id=1 as Alice's connection identifier.
• Bob-1 gets the connection established, but Bob-2 no.

Same problem as above? Note that Alice should create a new RTCConnection (id=2) for the communication with Bob-2, but then Alice should also send a new full offer including connection-id: 2 in every track descriptions.

Do I miss something? or we have a desisgn issue?

[robin-raymond]

No, there's no issue. The candidates generated for Alice connection 1 vs Alice connection 2 before end-of-candidates event will be identical when the connection use the same socket object during construction. The only issue comes from "peer reflexive" candidates. Those only happen after the offer. It will be safe to add all local candidates fired from connection 2 back to connection 2, even though bob got the candidates from connection 1.

[ibc]

Yes, but that does not solve the problem I told about (correct me if I'm wrong):

• Both Bob-1 and Bob-2 see id=1 as Alice's connection identifier.
• Bob-1 gets the connection established, but Bob-2 no.

Note that Alice should create a new RTCConnection (id=2) for the communication with Bob-2, but then Alice should also send a new full offer including connection-id: 2 in every track descriptions.

[robin-raymond]

Right, it doesn't if you use connection ID. I wouldn't use connection ID, I would use a "local socket ID" which is stable no matter the connection and pair that with the "remote socket ID" to form the true connection ID.

[robin-raymond]

Which is why the connection ID is pretty useless, because you can't pre-know the remote connection ID. It's just a negotiated connection but it should be up the the higher layers to signal the mappings, which I think goes to Martin's point of not having "descriptions" as such.

[ibc]

Great! using a local-socket-id & remote-socket-id pair is the solution! Will modify it.

[robin-raymond]

@ibc you can't pre-know the remote socket ID though so that won't.

[ibc]

Why? if the call offer forks you will receive two responses (i.e. two SIP 183 with two different SDP) and thus each response includes its own socket ID, am I wrong?

[ibc]

Forget the last comment, the fact is that I do not know the remote socket ID before I make the full offer (for the SDP usage case, which I think is the most complex one).

[robin-raymond]

Think why the connection ID is even needed. It's just to define which track goes over which socket... So you should be perfectly able to map by socket ID. The only issue is if the same socket gets added twice to the same session. I'm not sure that should be legal anyway.

[ibc]

Exactly! that is the only problematic case:

• Alice uses two different connections with the same local socket to talk with Bob.
• Bob uses two different connections with different local sockets.

Then if Alice signals "this track goes over connection with local-socket-id=1234" then Bob has no way to know whether it comes from the first or the second connection.

Unfortunately the above (two different connections with the same local socket) is the solution for forking, but becomes a problem if both connections are handled by the same remote peer within the same RTCMediaSession, am I right?

[robin-raymond]

Alice -> Bob1 and Alice -> Bob 2 have two different RTCSession objects. There's no ambiguity since you use the RTCSession as the context for sending streams.

[ibc]

Sorry, in my example I meant "both use a single RTCMediaSession" ;)

So the problem just occurs in case you create a single session with two connections both connected to the same peer which uses a single session and the same local socket in both connections. Right? If so, that seems a complex constrain to document...

[robin-raymond]

The problem occurs when you use the same RTCSocket in two RTCConnection objects attached to the same RTCSession object. The issue then is the ambiguity in the mapping definition, but really a technical limitation as such. In such a case, allowing for the "connection ID" as part of the mapping definition to resolve that particular ambiguity would resolve it, but by default that connection ID would not be present or required since the socket ID is sufficient.

Really, the model should be the streams are sent over an RTCConnection, and not a RTCSession. The only reason that's not being done is because it's so difficult to auto-map audio vs video over one connection vs another and have it reassembled on the remote side properly without a coordinator like and RTCSession.

[ibc]

Not an issue anymore since 47057b4.