Re: [rtcweb] 答复: Where to specify ICE usage and the common transport

[Eric Rescorla <[e-mail]>]

On Fri, Jul 6, 2012 at 12:29 AM, Magnus Westerlund
<[e-mail]> wrote:
> On 2012-07-06 08:25, Sunyang (Eric) wrote:
>> Do we really need this?
>
> That is part of what I am trying to determine.
>
>> If we start a new specification about ICE, do
>> we need integrate the final part of ICE specification with JSEP, this
>> will need extra work to make them meet.
>
> My personal understanding of the relations are the following
>
> The basic functionality is to establish functional datagram transport
> flow or flows (depending on signalling) between WebRTC peers. The
> established datagram transport flow is used by the RTP session(s),
> DTLS-SRTP key-management establishment and SCTP over DTLS.
>
> The last part points to that we have 2 or 3 (depending on how you see
> DTLS-SRTP) users of the datagram transport flow. As co-author of one of
> those documents I would like to have a single point to reference.
>
> There is also the issue of ensuring that they can all operate on the
> same datagram flow. This however has been reduced to be STUN, RTP and
> DTLS. Where DTLS must separate DTLS-SRTP messages from the regular DTLS
> protected data flow which contains SCTP packets. But, the first is
> actually well described in the DTLS-SRTP spec.
>
> When it comes to JSEP it clearly is the signalling part that enables the
> establishment of the datagram transport flow. It is also crucial in the
> maintenance of it, for example re-establishing in case of used
> interfaces going down etc.
>
> In this we also have the question about the ICE variant we intended to
> use which supports trickle candidates. There are no IETF specification
> for it. That appears to be needed to be created. This is not work for
> this WG. The appropriate home for such work is most likely MMUSIC.

I fear that this is the case...

I don't think we actually need a new specification that defines
the consent testing, since AFAICT these are just configurable
parameters in the ICE spec. That said, we do need to write
a profile of that somewhere? Maybe we could turn draft-mutha
into that?


> In addition we still have the need for someone to define what ICE and
> what additional tools we need. We also have certain API requirements
> from this. Like the configuration of STUN and TURN and any additional
> relay like solution we have for the HTTP fallback.

Right. The API obviously has some support for the first two of these,
but any thoughts about how we would define the second from
a spec perspective? Is there a doc for it?

-Ekr