Hi, Thanks again! I knew that WebRTC plays all these tricks but must admit to never having dug into the ICE details. Regarding “where the WG is in regards to…” - I think Colin’s previous email with the 5 steps is a good summary of what TAPS is intending to do wrt. rendezvous mechanisms.
Cheers, Michael > On Apr 27, 2020, at 2:59 PM, Magnus Westerlund > <[email protected]> wrote: > > 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] > ---------------------------------------------------------------------- > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
