Draft: draft-ietf-ice-rfc5245bis

Commentary: 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 ”
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.
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.
Each component has an ID assigned to it, called the component ID.
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.
Each component has an ID assigned to it, called the component ID.
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.
For other than RTP-based streams, use of multiple components is
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.
For other than RTP/RTCP streams, use of multiple components is
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.
The agent will receive a Binding or Allocate response.  A successful
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
rejected because the server lacks resources to fulfil it, the agent
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).
The base of the server reflexive candidate is the host candidate from
which the Allocate or Binding request was sent.  The base of a
relayed candidate is that candidate itself.  If a relayed candidate
is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded.
The agent will receive a Binding or Allocate response.  A successful
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
rejected because the server lacks resources to fulfill it, the agent
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).
The base of the server reflexive candidate is the host candidate from
which the Allocate or Binding request was sent.  The base of a
relayed candidate is that candidate itself.  If a relayed candidate
is identical to a host candidate (which can happen in rare cases),
the relayed candidate MUST be discarded.
Each component has an ID assigned to it, called the component ID.
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,
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.
Each component has an ID assigned to it, called the component ID.
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,
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.
If the controlled agent receives a Binding request with the USE-
CANDIDATE attribute set, and if the ICE agent accepts the request,
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.
If the controlled agent receives a Binding request with the USE-
CANDIDATE attribute set, and if the ICE agent accepts the request,
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.
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
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.
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
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.
It is RECOMMENDED that, when an agent receives an RTP packet with a
new source or destination IP address for a particular media data
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
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.
It is RECOMMENDED that, when an agent receives an RTP packet with a
new source or destination IP address for a particular RTP/RTCP data
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
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.