Negotiations in auth (P2P handshake)

[lgrahl]

Required Negotiations

Task

Specifies which task has to be fulfilled by SaltyRTC's signalling channel. The responder sends a list of tasks sorted by priority in descending order in its auth message. The initiator also holds such a task list and determines the best task match which it then sends in its auth message.

For example, the responder sends the list ['ortc', 'webrtc'] in its auth message. However, the initiator may not have ORTC support but it does support WebRTC. Its task list would be ['webrtc']. Therefore, it would send 'webrtc' in its auth message and both clients know that their task is to set up a WebRTC peer connection.

Optional Negotiations

None so far.

[lgrahl]

As mentioned in #3, we need to be able to negotiate various things (e.g. which id should be used for the handover to the data channel) for a specific task. For that purpose, I propose another field in the auth message named data which contains a dictionary where key is the task's name and value represents the additional parameters of that task.

The available tasks must define and provide these parameters when the auth message is being created. They also decide what to do with this data, in this case, how a negotiation takes place (for example, whether the initiator will have the final word or the responder). A task for ORTC could potentially send its capabilities and include the first few gathered ICE candidates which would allow for a rapid peer-to-peer connection set up.

An example:

{  
   "type": "auth",
   "tasks": ["simple-ortc-v1", "simple-webrtc-v1"],
   "data": {
      "simple-ortc-v1": {
         "exclude": [0, 1, 3],  // a list of data channel IDs that cannot be used for handover
         "dtls_parameters": dtlsTransport.getLocalParameters(),
         ...
      },
      "simple-webrtc-v1": [1, 2],  // a list of data channel IDs that cannot be used for handover
   },
   ...
}

@dbrgn Let me know what you think of this proposal. Note that the negotiation feature in auth requires that the initiator waits for the auth message of the responder before it can send its auth message.

[dbrgn]

Looks good to me. I'd probably require the "data values" to be objects, so that more options could be added later on:

"simple-webrtc-v1": {
    exclude: [1, 2],  // a list of data channel IDs that cannot be used for handover
}

[lgrahl]

Fine by me. Because WebRTC and ORTC Data Channels will require another cookie, let's exchange that cookie in their tasks as well:

{  
   "type": "auth",
   "tasks": ["simple-ortc-v1", "simple-webrtc-v1"],
   "data": {
      "simple-ortc-v1": {
         "exclude": [0, 1, 3],  // a list of data channel IDs that cannot be used for handover
         "cookie": b"6d656f776d656f776d656f776d656f77",
         "dtls_parameters": dtlsTransport.getLocalParameters(),
         ...
      },
      "simple-webrtc-v1": {
         "exclude": [1, 2],  // a list of data channel IDs that cannot be used for handover
         "cookie": b"6d656f776d656f776d656f776d656f77",
      }
   },
   ...
}

[lgrahl]

Possible duplicate: #31

[lgrahl]

Let's add whether to chunk or not to chunk (as soon as SCTP ndata is being used, chunking should not be necessary):

{  
   "type": "auth",
   "tasks": ["simple-ortc-v1", "simple-webrtc-v1"],
   "data": {
      "simple-ortc-v1": {
         "exclude": [0, 1, 3],  // a list of data channel IDs that cannot be used for handover
         "cookie": b"6d656f776d656f776d656f776d656f77",
         " max_chunk_size": 0, // no chunking required
         "dtls_parameters": dtlsTransport.getLocalParameters(),
         ...
      },
      "simple-webrtc-v1": {
         "exclude": [1, 2],  // a list of data channel IDs that cannot be used for handover
         "cookie": b"6d656f776d656f776d656f776d656f77",
         "max_chunk_size": 16348,
      }
   },
   ...
}

[dbrgn]

👍

[lgrahl]

Resolved by db40c2e
(Good reference point for upcoming ORTC task though)