Reviewer: Jörg Ott
Review result: Ready with Nits 

This is a re-review of draft-ietf-mmusic-trickle-ice-sip.  The previous review was on draft-ietf-mmusic-trickle-ice-sip-12.
Revision -14 of the draft largely addresses the issues on congestion-controlled transport.

Recap from the previous review for completeness:
I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the
transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised.  When
done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive. Please
always CC tsv-art@ietf.org if you reply to or forward this review.

The draft defines a how the Session Initiation Protocol (SIP) shall
make use the incremental discovery and exchange of IP addresses as
provided by tricke ICE; the main purpose is reducing call setup latency.

The draft defines address the SIP aspects comprehensively with all
necessary features.  From a transport perspective relevant is primarily
its use the SIP INFO method for carrying updates to the collected
addresses to notify the respective peer that further ones can now
be tried and inform when when the address gathering is complete. 

The revisions to section 10.9 largely address the congestion control
issues I raised before.  But there is new issue coming up: 

10.9 Rate of INFO Requests
   Given that IP addresses may be gathered rapidly a Trickle ICE Agent
   with many network interfaces might create a high rate of INFO
   requests if every newly detected candidate is trickled individually
   without aggregation.  Implementors MUST consider aggregating ICE
   candidates in case that UDP is used as transport protocol and sending send
   INFOs only at some configurable intervals.

The aggregation now raises the issue of SIP INFO messages exceeding MTU size.
Measurements in the wild have shown that SIP INVITE messages may easily be
larger than MTU size, so this should be factored in.  If an INFO requests exceeds
a reasonable MTU size (say, 1280 bytes),  it should be sent, but not earlier than
200ms after the previous INFO message was sent -- or something along these
lines.  Such a rare limit could be specified in general and, if aggregation is 
employed, too, probably not harm the call setup process.

Nit: Put the statement "Also, an endpoint may not be able to tell
that it has congestion controlled transport all the way." into its own paragraph
so that this stands out.