Re: [rtcweb] Filling in details on "trickle ICE"

[Bernard Aboba <[e-mail]>]

Francois said: 

> Wouldn't the same mechanism as XEP-0176 work with SIP too, by sending new offer/answers with new candidates?
> 
> In either cases, it is true that the "trapezoid" model makes this process more difficult than with the "triangle" model.
> 
> But you don't *have* to do trickle ICE don't you, in the trapezoid scenario (especially when involving protocol mapping).

[BA]  Looking at XEP-0176 Section 5.8, it does seem possible to use new offer/answers with new candidates to similar effect.  Here is what Section 5.8 says: 



Section 5.8 Negotiating a new candidate



Even after media has begun to flow, either party MAY continue to send 
additional candidates to the other party (e.g., because the user agent 
has become aware of a new media proxy or network interface card). Such 
candidates are shared by sending a transport-info message....  The 
receiving party MUST acknowledge receipt of the candidate. The parties 
would check the newly-offered candidate for 
connectivity, as described previously. If the parties determine that 
media can flow over the candidate, they MAY then use the new candidate 
in subsequent communications.  



[BA]  If ICE completed and media was already flowing, the controlling agent can generate a RE-INVITE with a candidate from the in-use pair as the default as well as additional candidates.  There is no need to do an ICE restart.  As described in RFC 5245 Section 8.1.2, if the additional candidate ends up in a highest-priority nominated candidate-pair, then an updated offer is sent: 



      *  If an agent is controlling, it examines the highest-priority
         nominated candidate pair for each component of each media
         stream.  If any of those candidate pairs differ from the
         default candidate pairs in the most recent offer/answer
         exchange, the controlling agent MUST generate an updated offer
         as described in Section 9.  If the controlling agent is using
         an aggressive nomination algorithm, this may result in several
         updated offers as the pairs selected for media change.  An
         agent MAY delay sending the offer for a brief interval (one
         second is RECOMMENDED) in order to allow the selected pairs to
         stabilize.

Details of the updated offer are described in RFC 5245 Section 9.1.2.2:


   If an agent generates an updated offer including a media stream that
   was previously established, and for which ICE checks are in the
   Completed state, the agent follows the procedures defined here.

   The default destination for media (i.e., the values of the IP
   addresses and ports in the m and c lines used for that media stream)
   MUST be the local candidate from the highest-priority nominated pair
   in the valid list for each component.  This "fixes" the default
   destination for media to equal the destination ICE has selected for
   media.

   The agent MUST include candidate attributes for candidates matching
   the default destination for each component of the media stream, and
   MUST NOT include any other candidates.

   In addition, if the agent is controlling, it MUST include the
   a=remote-candidates attribute for each media stream whose check list
   is in the Completed state.  The attribute contains the remote
   candidates from the highest-priority nominated pair in the valid list
   for each component of that media stream.  It is needed to avoid a
   race condition whereby the controlling agent chooses its pairs, but
   the updated offer beats the connectivity checks to the controlled
   agent, which doesn't even know these pairs are valid, let alone
   selected.  See Appendix B.6 for elaboration on this race condition.