Subject: Re: [rtcweb] Trickle ICE update and a new SIP usage draft.

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Jan 2013 20:39:26 -0800

> During the MMUSIC presentation and the mailing list discussions it was

> also pointed out that it is important for this work to happen in

> parallel with a SIP usage for trickle ICE. Enrico, Christer and I have

> therefore submitted the following document:

> http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-sip-00

> As always, comments are welcome!

Is my reading of the draft (see below) correct?

1. "half trickle" offers the possibility of backward compatibility, if
 the capabilities of the answerer aren't known and an RFC 5245 compliant
 offer is made, since the Recv-Info: trickle-ice header is included 
in the Offer per RFC 6086, as well as in a reliable 18x/2xx response.   

2. Section 3 suggests that the Offer in "half trickle" contains all 
candidates.  The Answer presumably includes host candidates (including just
 0.0.0.0 would not make much sense) in the response.  There seems to be no need for the Offerer to send a "trickle-ice" 
Info-Package since it sent all the candidates in the initial Offer.  

3. After the response is sent, then the Answerer starts the trickling via the "trickle-ice" INFO packages.  The Offerer knows to expect this since a Recv-Info trickle-ice header was included in the response. 

4. If a pair is selected that includes a candidate obtained from a "trickle-ice" Info-Package, is a 
conventional RFC 5245 offer/answer exchange (not using INFO) required to confirm it?

---

From: Emil Ivov <[email-masked]>
Date: Thu, 31 Jan 2013 05:51:59 +0100

Hey Bernard,

On 31.01.13, 05:39, Bernard Aboba wrote:
> <https://mail.microsoft.com/owa/redir.aspx?C=3VGH4No5_k2ygJZUBAGqaHOqinb40s8IH3huik5SiKQlOnEGGSlmxEBL6T_r-6o5l8oStCjQ6Vg.&URL=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ivov-mmusic-trickle-ice-sip-00>
>>
> 1. "half trickle" offers the possibility of backward compatibility, 

Yes.

> if
> offer is made, sincethe Recv-Info: trickle-ice header is included in the
> Offerper RFC 6086, as well as in a reliable 18x/2xx response.  

I am not sure I understand this part of the sentence.

Note that there's also the 'trickle' token in both the offer and the
answer (in the ice-options attribute).

> candidates.  The Answer presumably includes host candidates (including
> just 0.0.0.0 would not make much sense)in the response. 

Why not?

> There seems to
> be no need for the Offerer to send a "trickle-ice" Info-Package since it
> sent all the candidates in the initial Offer. 

Sending the 'trickle' token in the offer allows the answerer to trickle
even if the offerer didn't.

Note that subsequent offer/answers from either side, that belong to the
same session, would be full trickle since both agents have confirmed
support.

> 3. After the response is sent, then the Answerer starts the trickling
> via the "trickle-ice" INFO packages.  The Offerer knows to expect this
> since a Recv-Info trickle-ice header was included in the response.

Yes. And again, there's also the "trickle" token in the answer. I
suppose we should require both to be present.

> 4. If a pair is selected that includes a candidate obtained from a
> "trickle-ice" Info-Package, is a conventional RFC 5245 offer/answer
> exchange (not using INFO) requiredto confirm it?

I suppose it would be, yes: it wouldn't match the default candidate in
the o/a so ...

Emil

-- 
https://jitsi.org