> On 27 Apr 2020, at 12:38, Michael Welzl <[email protected]> wrote: > > 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.
This has to be done by the applications, since it will involve the signalling protocol (SIP, WebRTC, etc). >> 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? They go on the Preconnection. The allow multiple remotes there. >> 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! It sends the STUN packets to probe connectivity. I read this as “establish a Connection”, but we maybe need to clarify the wording (or just give an additional example). >> 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?) Applications don’t use raw UDP or TCP – they always run some protocol, however trivial inside it, so there’s a framer. > 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 Cheers, Colin -- Colin Perkins https://csperkins.org/ _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
