jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ice-trickle

Commentary: Changed " media stream " to " media stream and component " in one place , and made some grammatical changes to the definition of an ICE generation .
All of the candidates sent within an ICE session; these are the
candidates that are associated with a local/remote ufrag pair
(which will change on ICE restart, if any).
All of the candidates sent within an ICE session; these are the
candidates that are associated with a specific local/remote ufrag
pair (which will change on ICE restart, if any occurs).
Once the candidate has been sent to the remote party, the agent
checks if any remote candidates are currently known for this same
stream.  If not, the new candidate will simply be added to the list
of local candidates.
Once the candidate has been sent to the remote party, the agent
checks if any remote candidates are currently known for this same
stream and component.  If not, the new candidate will simply be added
to the list of local candidates.
Draft: draft-ietf-ice-trickle

Commentary: and had an editors ' discussion ( see ) about how to specify the handling of ICE restarts in the context of Trickle ICE . One possible approach would be to send a new ufrag and pwd without triggering a full offer / answer exchange , because Trickle ( and ICE itself ) can be used with application protocols that are not tied to O / A. There is an SDP dependency on the a= line , but we 've disengaged Trickle ICE from SDP , too . Also , if the sender does n't include a media description then a new offer might not be necessary anyway . I 'm hoping that can propose text ... 
 At IETF 95 , there was support for explicitly indicating which ufrag / pwd the candidate applies to . But the specifics are signaling - specific . So perhaps we should just update the text to say " SHOULD be explicit " in some way . 
 I am fine also adding to the spec a sample way of labeling them ( the way Trickle for SIP does ) Emil ,   wrote : 
 By the way , this came up in the JSEP work recently , that with ICE restarts being roll - back - able , the explicit ufrag is really needed for edge cases there . We think the right solution is using a ufrag on the JS object , not on the SDP ( since we also need to include it on the end of candidates message , and since it would look weird being duplicated in so many lines in the current remote description ) . 
 It looks like we already have a paragraph that indicates an implementation should have an explicit ufrag ( or other correlation ) . Great ! So , I made a PR to add some examples : 
 resolved
Also, candidate trickling needs to be correlated to a specific ICE
negotiation session, so that if there is an ICE restart, any delayed
updates for a previous session can be recognized as such and ignored
by the receiving party.
Also, candidate trickling needs to be correlated to a specific ICE
negotiation session, so that if there is an ICE restart, any delayed
updates for a previous session can be recognized as such and ignored
by the receiving party.  For example, applications that choose to
signal candidates via SDP may include a ufrag value in the SDP that
represents candidates (such as "a=candidate ... ufrag abc").  Or as
another exmaple, WebRTC implementations may include a ufrag in the
JavaScript objects that represent candidates.