Hi, Michael if you want an example of an API that contains the ICE related rendezvous aspects it is the WebRTC. https://www.w3.org/TR/webrtc/
You will find the ICEserver with configuration information. Note also how candidates are handled. I would also note the possibility to enable or disable trickling of candidates. Which is possibly something an application could want to indicate. I know the ICE parts is only a part of the complete WebRTC API so there is a lot to wade through here. I would also note that there might be an other aspect of embedding ICE under the hood is the potential to use this as a method to update the path used between two peers during an ongoing communication session. There are two takes on this. Either the more standards compliant way of triggering an ICE restart, which involved application interaction through a new candidate exchange. Or the less so which is to not really terminate ICE. And instead keep your checklist alive and continously verify what candidate pairs that actually work and use re-occuring nomination to move the application datagram flow between working candidate pairs ( https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/). I would recommend avoiding the later, but wanted to mention it for completeness. As I haven't been active in TAPS, I would appreciate any pointers to where the WG is in regards to the need for parameter exchange that need to be done by the application using the TAPS interface, rather than letting the lower layers handle that aspect. Cheers Magnus On Mon, 2020-04-27 at 13:38 +0200, Michael Welzl 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. > > > > 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 -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: [email protected] ----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
