Here is what I am thinking about for a revision of the NICE document.
I think we have agreed we don't want to define an ICE subset or a new
protocol. It also looks like each using protocol will have to make its
own decisions about how to do various things - what features they
need, which they don't, etc. So I think the best we can do is write a
document that provides guidelines about the various parts of ICE,
which ones might or might not be applicable to other specs, and gives
some guidance on how to make use of the ICE spec.
I'd probably break this up into something like this:
1. ICE applicability
what kind of protocols can benefit from ICE - you need to be a
session-establishing type of protocol, have a signaling mechanism
through a central intermediarty that everyone can reach, etc.
2. gathering phase
talk about applying this part of ICE - its important to use exactly
the same stun/turn protocols to reuse the server infrastructure. Might
be different pacing, different prioritization
3. offer/answer
talk about generally what data needs to be exchanged, how each
protocol will need to incorporate this into their own signaling protocols
4. connectivity checks
talk about how you should just reuse this part of ICE verbatim -
including state machinery and stun messaging - that this is the KEY
interop component if we ever want to do things like RTSP to SIP
gateways or something, so we want this to be the same.
What might differ is pacing; talk about role selection and how that is
kind of specific to sip but how to be compatible with it
point out what sections of the ICE spec you need to basically reference
5. subsequent signaling
discuss what the drivers are for this and when its needed and when its
not
Does this seem like:
a. its useful to folks producing protocols that make use of ICE,
b. its a good direction
Thanks,
Jonathan R.