<br><br><div class="gmail_quote">On Sat, Jan 1, 2011 at 10:04 PM, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 12/30/10 16:52, <a href="mailto:Markus.Isomaki@nokia.com" target="_blank">Markus.Isomaki@nokia.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
A couple of questions and comments on draft-alvestrand-dispatch-rtcweb-datagram-00:<br>
<br>
* Section 4 defines four channel types: UDP, TCP, TLS and DTLS. Is it expected that all clients MUST support all of these? I suppose the reason why both UDP and TCP are included is that depending on the types of middleboxes the peers are behind, they may get just one or the other working. I.e. first try out UDP, if it does not work, attempt TCP. Is that correct?<br>
</blockquote></div>
I started out by defining the types I thought might be needed - so this is not the "must implement" list. The "Must implement" list is still a matter for discussion - not having UDP in there is certainly a non-starter, so UDP has to be "must implement". For others, I'd like to see arguments.<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Section 4.5 states that TURN and relaying are needed. How about things like HTTP/TLS tunneling? In many cases that is the only way to get the transport channel working. TURN may be helpful in some, hopefully increasing, amount of cases, but that alone will still leave a lot of corporate users unserved.<br>
</blockquote></div>
At Google, we've implemented a form of HTTP/TLS tunnelling using a TURN variant (see libjingle source for details), so I didn't differentiate between those options - I see HTTP/TLS as a form of relaying; I don't believe simultaneous-open TCP is going to work reliably enough for our purposes.<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Section 3 mentions that things like pseudoTCP can be run over the datagram transport. In case only UDP works end-to-end that seems useful. However, if we can get a "native" TCP connection up, it seems natural to use that as is rather than via some kind of generic datagram abstraction layer. I think we probably should define both datagram and bytestream services separately. Bytestream would be either TCP or pseudoTCP/UDP. If we only do datagram service, leave the whole pseudoTCP reference out.<br>
</blockquote></div>
I agree with your way of putting it. The reference is intended as informative; bytestream COULD be layered over the datagram service, but doesn't need to be.<br></blockquote><div><br></div><div>The issue with a "native" TCP connection is that we need to perform ICE-y checks on it to enforce the same-origin policy. When using PseudoTCP, the ICE checks are done automatically as part of the datagram protocol. However, as Harald points out, if we are using the "native" TCP for a connection to a relay or conference server, we can simply run our datagram protocol over top of the native TCP connection. </div>
<div><br></div><div>Basically what I am saying is that while we may use "native" TCP connections internally for handling scenarios where UDP is blocked, I'm not sure we can expose them from the API.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Background: I had a discussion with a coworker who wanted to have a single API to both streaming and datagram service; I believe it makes more sense to define an API to a datagram service and an API to a streaming service separately - the big argument for PseudoTCP is the client-to-client connection case, where one often finds that UDP works and TCP doesn't.<br>
</blockquote><div><br></div><div>I had been thinking the datagram and streaming services should use a single API - much of the API ends up being the same, and that's how BSD sockets work. There are a few differences for streaming services, but they are mostly (entirely?) additive (flow control being the main one).</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The argument for defining TCP over datagram, rather than TCP over UDP, is that we might easily find ourselves needing functions like ICE establishment or TURN relaying for client-to-client TCP sessions; doing it this way saves us one duplicate reference set. (The concept of pseudoTCP running over datagrams tunneled over HTTP/TLS somewhat boggles the mind, though....)<div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Section 6 defines a URI with a number of IP address:transport:port candidates. I'm not too clear on how that URI would be used. It looks to me as something that is received as a result of gathering the candidates (with STUN, TURN etc.) as the first step of ICE. If Jingle or SDP offer/answer or some proprietary protocol were used to pass the candidate information to the other peer, that information would be encoded according to that particular protocol. So is this specific URI just meant for local representation at the API and not something that is passed over the network as such? What's the need or benefit of making it a URI?<br>
</blockquote></div>
This is an example of speculative standardization, or "trial balloon" - W3C folks have had a habit of using URIs for any form of structured parameter in APIs; if that is what the W3C effort concludes that they want, this is intended to show that it can be given to them.<br>
That said - the fact that this is intended to represent, exactly, the semantics of a=candidate lines from SDP needs to be made clear (as I said in another thread). Let's not have more different semantics than we need to.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Markus<br>
</blockquote>
Thanks for the review1<div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
RTC-Web mailing list<br>
<a href="mailto:RTC-Web@alvestrand.no" target="_blank">RTC-Web@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtc-web" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtc-web</a><br>
</div></div></blockquote></div><br>