> On Apr 27, 2020, at 1:55 PM, Colin Perkins <c...@csperkins.org> wrote: > > > >> On 27 Apr 2020, at 12:38, Michael Welzl <mich...@ifi.uio.no> 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 <c...@csperkins.org> 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).
Ok; got it. >>> 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. Aha! (yes that’s allowed, I saw that text now) >>> 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). I think so. To me, as someone who only has a faint idea of how these things work, “establish a Connection” would have been way less than that. Or, something else: AFAIK STUN is only use to the STUN server, but one wouldn’t use STUN packets to then try to connect to the peer, right? Rather SIP, or something. VERY sorry if this is all a silly misunderstanding on my behalf, which is quite possible! >>> 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. … okay, so you’re saying the sender-side framer could supply that first type of message that is sent to the peer when rendezvous() is called (and the first one to expect from the peer)? That would sound reasonable to me - but, I thought framers are associated with a Message (or, rather, its messageContext) - but we’re not sending a Message yet. Shouldn't the rendezvous() Action have optional Message and messageContext parameters, 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 > > Cheers, > Colin > > > > -- > Colin Perkins > https://csperkins.org/ <https://csperkins.org/>
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
