Re: Object RTC (ORTC) API for WebRTC

>> But on step 9, why is not possible to send the data from A to B? A has the B
>> connection data, with the IP and port. Is not included in the connection data the
>> ICE credentials? I though it was... Does it has any problem the scheme that I
>> proposed that prevent me for sugesting to add this data/feature?
>
> [MT] At one level, A CAN send to B.  However, the browser will insist on sending DTLS handshakes only.  Your application can't send anything until the DTLS handshake completes.
>
Ok, now I see where is the problem, thanks for the clarification. I
always agree with the "do the things easy, but not easier", maybe this
is one of the cases that things have been done too easier... :-/


>> > CU-RTC-Web would allow what you are describing, but only by adding custom
>> STUN parameters to connectivity checks.  That feature wasn't considered
>> important enough to retain.
>> >
>> Oh, sh*t... :-( By who? What was the reason? Could that use case being re-
>> considered?
>
> [MT] The WebRTC WG didn't like CU-RTC-Web, primarily because it was "too hard" to use or some crap about SDP being awesome.  The ORTC guys didn't want anything that low-level either.

I admit I was one of the guys that though CU-RTC-Web was too low level
and didn't like it in benefict of interoperability due to WebRTC made
mandatory a lot of required things and elements (video protocols and
so), but I'm surprised that ORTC guys hasn't considered this use case
too :-/ In fact, I don't think the sequence I showed earlier is "too
much low level" if I could be able to replicate it using WebSockets...
is it? :-/


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Wednesday, 16 October 2013 20:30:49 UTC