Hi, I’m answering this email, but Magnus, consider yourself answered too with a big THANK YOU for your thorough explanation!
I agree that we want some (much!) of this functionality “under the hood” if possible. And, of course, I agree that we don’t want the application to be aware of e.g. UDP specifically if we can avoid it. I think we’re all on the same page on that; but I think that, indeed, the text in the API draft needs some fixing. Colin, thank you very much for outlining the 5 steps below: they give a very good context for this conversation. So, I answer in line below: > On Apr 27, 2020, at 12:23 PM, Colin Perkins <[email protected]> wrote: > > Hi, > > This is one of the areas where the drafts likely need expanding, but I think > the model is: > > 1) application configures STUN (and maybe also TURN) local endpoints > > 2) application calls Resolve() on these, to find server reflexive candidates These two steps are reflected in the API as it stands, and so this is already reasonably clear, I think. IMO, nothing to do here. > 3) application shares these candidates with its peer, via out-of-band means, > and receives remote endpoint candidates from the peer Based on Magnus’ email, I suppose that this *could* be done in standard ways with trickle, and hence theoretically put “under the hood” too. But, I think that keeping this in the application space for the sake of TAPS is quite reasonable. This step is perhaps implicit in the text, but I think it’s pretty obvious that it would need to happen. People doing rendezvous will have to be aware of this step anyway, so I see no real problem here. > 4) application adds remote endpoints for the peer’s candidates My first hiccup: I don’t see that this is supported in our current API - how would one add remote endpoints? I think, the way we have it, there’s only one for each Connection. Have I overlooked something? > 5) application calls Rendezvous(), which performs the ICE-style probing to > find a working path, based on the candidates, then returns s Connection THIS would be really good, but it’s not at all how I read the current text. It says: "The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous open, for example.” My interpretation of this sentence is that Rendezvous doesn’t do much more than listen + send something, using the same local ports. For TCP, I would have implemented this functionality by just doing an active connect, using a pre-configured local port (TCP will retry sending SYNs, and if both sides issue this call with the correct ports, I guess it all works out eventually). However, from below, it seems to me that such an implementation would be doing way too little! > This relies on the Endpoint abstraction supporting STUN, which is maybe > implicit in the drafts. Yes - there is text there about STUN configuration, but nothing about it in the Rendezvous text (unless I missed it, apologies if I have!). And it’s not just STUN, it’s the ICE-style probing, with various candidates supplied, that’s missing. > Also, as usual with TAPS, the application doesn’t say that it wants UDP. It > says it wants, e.g., RTP preferably over an unreliable connection, and this > higher-level protocool gives the de-framer the ability to distinguish the > STUN packets from the data packets. Okay, I understand this… but what happens if UDP *is* the protocol that is available (not e.g. RTP), and the application calls Rendezvous? (I guess failing, with a useful error code, is the best choice, then?) Again, just to be clear, I agree with everything you say here, and I thank you (and Magnus) again for explaining it to me! - I just want to get the text right. Actually, I was just trying to understand how to implement this call’s functionality, and was left puzzled. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
