Re: [rtcweb] Non-media data service consensus and requirements

[Emil Ivov <[e-mail]>]

На 28.06.11 01:14, Bernard Aboba написа:
>> Well, if ICE is part of the browser we could condition sending such data
>> on the successful termination of ICE processing with the intended
>> destination. Same as with RTP. Wouldn't this work?
> 
> It depends on the exact requirements.
> 
> There has already been discussion of relaxing the ICE requirement so as
> to better enable backward compatibility with legacy implementations

I supposed I missed the discussion on dropping ICE. However, I don't
quite understand the issue with legacy implementations. If they are not
using ICE then they are most probably relying on server-side relaying
techniques such as latching. If that's the case then rtcweb clients
would establish sessions with a server which would be the one required
to do ICE (or ICE lite) rather than talking directly to the remote party.

This does indeed require the server to support ICE (lite) but is this
really an issue?

> (e.g. using RTCP instead). 

Not sure I understand. Is someone using RTCP for NAT traversal and
connectivity establishment?

> There is also a potential backward compatibility requirement for
> non-media data, which will be even more difficult, since ICE (or Jingle
> or SDP) is not routinely used today (think online gaming), and the
> volume is potentially quite heavy so that gateways may represent a
> significant burden.

Same as above. If they weren't using ICE before then they were either
relaying through a server that can now take care of ICE (lite), or they
were using a home-grown ICE variant which wouldn't be compatible anyway.
Am I missing something?

> So before saying that ICE would "solve the problem", it's important to
> understand what exactly the problem is.
> 
> Are we talking about sending arbitrary data-grams in transactional
> exchanges?   Or perhaps text encoded in RTP?  Or maybe data in a
> specified encoding (e.g. not RTP or arbitrary datagrams) so as to
> prevent spoofing?
> 
> Are there multiple use cases here, each with slightly different
> requirements?

Right. Can we then agree that most use cases would be similar to a
regular VoIP session without the limitation of putting RTP inside packets?

Emil


-- 
http://jitsi.org