Original text:
The combination of an IP address and transport protocol (such as UDP or TCP) port. <del> When ICE is used to setup multimedia sessions, the data is transported using some protocol.  Media data is usually transported over RTP, and a media data stream composes of a stream of RTP packets.  Data session refers to data packets that are exchanged between the peer on the path created and tested with ICE. </del>  A transport address that is a potential point of contact for receipt of data.  Candidates also have properties -- their type A component is a piece of a data stream.  A data stream may require multiple components, each of which has to work in order <del> for the data stream as a while for work.  For media data streams based on RTP, unless RTP and RTCP are multiplexed in the same port, there are two components per media data stream -- one for RTP, and one for RTCP.  A component has a candidate pair, which cannot be used by other components </del>  A candidate obtained by binding to a specific port from an IP address on the host.  This includes IP addresses on physical a specific component for which it is a candidate. Each component has an ID assigned to it, called the component ID. <del> For RTP-based media data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP a component ID of 2.  In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP. </del>  When candidates are obtained, unless the agent knows for sure that RTP/RTCP multiplexing will be used (i.e. the agent knows that the However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. <del> For other than RTP-based streams, use of multiple components is </del>  discouraged since using them increases the complexity of ICE processing.  If multiple components are needed, the component IDs SHOULD start with 1 and increase by 1 for each component. Allocate response will provide the agent with a server reflexive candidate (obtained from the mapped address) and a relayed candidate in the XOR-RELAYED-ADDRESS attribute.  If the Allocate request is <del> rejected because the server lacks resources to fulfil it, the agent </del>  SHOULD instead send a Binding request to obtain a server reflexive candidate.  A Binding response will provide the agent with only a server reflexive candidate (also obtained from the mapped address). determine whether to use one address or the other. Each component has an ID assigned to it, called the component ID. <del> For RTP-based media data streams, unless RTCP is multiplexed in the same port with RTP, the RTP itself has a component ID of 1, and RTCP a component ID of 2.  If an agent is using RTCP without multiplexing, </del>  it MUST obtain candidates for it.  However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. 7.3.1.4. <del> Next, the agent constructs a pair whose local candidate is equal to the transport address (as seen by the agent) on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be the peer reflexive remote candidate that was just learned).  The local candidate will either be a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay).  The local candidate can never be a server reflexive candidate.  Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority.  This pair is then looked up in the check list.  There can be one of several outcomes: </del>  If the pair is already on the check list: If the controlled agent receives a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent accepts the request, <del> the agent constructs a candidate pair whose local candidate is equal to the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received.  This candidate pair is assigned an arbitrary priority, and placed into the valid list of the associated check list.  The agent sets the nominated flag for that pair to true. </del>  Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component.  See sec-conclude. Eventually, if the nominations succeed, both the controlling and controlled agents will have a single nominated pair in the valid list for each component of the data stream.  Once an ICE agent sets the <del> state of the check list is set to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent, and is used for sending and receiving data for that component of the data stream. </del>  If an agent is not able to produce selected pairs for a data stream, the agent MUST take proper actions for informing the other agent, and selected pairs have been produced for a data stream. It is RECOMMENDED that, when an agent receives an RTP packet with a <del> new source or destination IP address for a particular media data </del>  stream, that the agent re-adjust its jitter buffers. RFC 3550 RFC3550 describes an algorithm in Section 8.2 for detecting synchronization source (SSRC) collisions and loops.  These algorithms are based, in part, on seeing different source transport addresses with the same SSRC.  However, when ICE is used, such changes will <del> sometimes occur as the media data streams switch between candidates. An agent will be able to determine that a media data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission.  Thus, if there is a change in source transport address, but the media data packets come from the same peer agent, this MUST NOT be treated as an SSRC collision. </del>  14.

Reviewer comments:
Fix spelling: Replace “fulfil” with “fulfill” Fix grammar: “agent sets the state…is set to Completed“ with “agent sets the state…to Completed” Make consistent with recent changes: Replace “candidate is equal to the transport address” with “candidate has the transport address” Replace “multimedia session” with “data session” Replace “media data stream” with “RTP/RTCP data stream” or just “data stream” Replace “media data” with “data”

Revised text:
The combination of an IP address and transport protocol (such as UDP or TCP) port.  <ins> When ICE is used to setup data sessions, the data is transported using some protocol.  Media is usually transported over RTP, composed of a stream of RTP packets.  Data session refers to data packets that are exchanged between the peer on the path created and tested with ICE. </ins> A transport address that is a potential point of contact for receipt of data.  Candidates also have properties -- their type A component is a piece of a data stream.  A data stream may require multiple components, each of which has to work in order  <ins> for the data stream as a whole to work.  For RTP/RTCP data streams, unless RTP and RTCP are multiplexed in the same port, there are two components per data stream -- one for RTP, and one for RTCP.  A component has a candidate pair, which cannot be used by other components </ins> A candidate obtained by binding to a specific port from an IP address on the host.  This includes IP addresses on physical a specific component for which it is a candidate. Each component has an ID assigned to it, called the component ID.  <ins> For RTP/RTCP data streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself has a component ID of 1, and RTCP a component ID of 2.  In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP. </ins> When candidates are obtained, unless the agent knows for sure that RTP/RTCP multiplexing will be used (i.e. the agent knows that the However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used.  <ins> For other than RTP/RTCP streams, use of multiple components is </ins> discouraged since using them increases the complexity of ICE processing.  If multiple components are needed, the component IDs SHOULD start with 1 and increase by 1 for each component. Allocate response will provide the agent with a server reflexive candidate (obtained from the mapped address) and a relayed candidate in the XOR-RELAYED-ADDRESS attribute.  If the Allocate request is  <ins> rejected because the server lacks resources to fulfill it, the agent </ins> SHOULD instead send a Binding request to obtain a server reflexive candidate.  A Binding response will provide the agent with only a server reflexive candidate (also obtained from the mapped address). determine whether to use one address or the other. Each component has an ID assigned to it, called the component ID.  <ins> For RTP/RTCP data streams, unless RTCP is multiplexed in the same port with RTP, the RTP itself has a component ID of 1, and RTCP a component ID of 2.  If an agent is using RTCP without multiplexing, </ins> it MUST obtain candidates for it.  However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. 7.3.1.4.  <ins> Next, the agent constructs a pair whose local candidate has the transport address (as seen by the agent) on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be the peer reflexive remote candidate that was just learned).  The local candidate will either be a host candidate (for cases where the request was not received through a relay) or a relayed candidate (for cases where it is received through a relay).  The local candidate can never be a server reflexive candidate.  Since both candidates are known to the agent, it can obtain their priorities and compute the candidate pair priority.  This pair is then looked up in the check list.  There can be one of several outcomes: </ins> If the pair is already on the check list: If the controlled agent receives a Binding request with the USE- CANDIDATE attribute set, and if the ICE agent accepts the request,  <ins> the agent constructs a candidate pair whose local candidate has the transport address on which the request was received, and whose remote candidate is equal to the source transport address of the request that was received.  This candidate pair is assigned an arbitrary priority, and placed into the valid list of the associated check list.  The agent sets the nominated flag for that pair to true. </ins> Once the nominated flag is set for a component of a data stream, it concludes the ICE processing for that component.  See sec-conclude. Eventually, if the nominations succeed, both the controlling and controlled agents will have a single nominated pair in the valid list for each component of the data stream.  Once an ICE agent sets the  <ins> state of the check list to Completed (when there is a nominated pair for each component of the data stream), that pair becomes the selected pair for that agent, and is used for sending and receiving data for that component of the data stream. </ins> If an agent is not able to produce selected pairs for a data stream, the agent MUST take proper actions for informing the other agent, and selected pairs have been produced for a data stream. It is RECOMMENDED that, when an agent receives an RTP packet with a  <ins> new source or destination IP address for a particular RTP/RTCP data </ins> stream, that the agent re-adjust its jitter buffers. RFC 3550 RFC3550 describes an algorithm in Section 8.2 for detecting synchronization source (SSRC) collisions and loops.  These algorithms are based, in part, on seeing different source transport addresses with the same SSRC.  However, when ICE is used, such changes will  <ins> sometimes occur as the data streams switch between candidates.  An agent will be able to determine that a data stream is from the same peer as a consequence of the STUN exchange that proceeds media data transmission.  Thus, if there is a change in source transport address, but the media data packets come from the same peer agent, this MUST NOT be treated as an SSRC collision. </ins> 14.