[bfcpbis] Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

[Roman Shpount <[e-mail]>]

HI All,

Here is the first draft of changes proposed for this document:

1. In Section 3, we need to define an additional proto field value:
TCP/DTLS/BFCP, which is realized by running BFCP on top of DTLS as descibed
in this specification and running DTLS on top of TCP is realized using the
framing method defined in RFC4571, with DTLS packets being sent and
received instead of RTP/RTCP packets using the shim defined in RFC4571 so
that length field defined in RFC4571 precedes each DTLS message. All
sections of the document should be updated to include the TCP/DTLS/BFCP
transport.

2. References to RFC 5763 should be replaced with references to
draft-ietf-mmusic-dtls-sdp. Document should be updated to use procedures
from draft-ietf-mmusic-dtls-sdp including dtls-id.

3. References to RFC 4572 should be replaced with references to
draft-ietf-mmusic-4572-update. Document should be checked for compliance
with 4572 update.

4. Section 10.5.is redundant with draft-ietf-mmusic-dtls-sdp.

5. We should not be using SHA-1 fingerprints in examples, since they are
deprecated

6. The following section should be added which describes ICE support:

ICE Considerations

When BFCP is used with UDP based ICE candidates RFC5245 then the procedures
for UDP/TLS/BFCP are used.

When BFCP is used with TCP based ICE candidates RFC6544 then the procedures
for TCP/DTLS/BFCP are used.

In ICE environments, during the nomination process, end points go through
multiple ICE candidate pairs, until the most preferred candidate pair is
found. During the nomination process, data can be sent as soon as the first
working candidate pair is found, but the nomination process still continues
and selected candidate pairs can still change while data is sent.
Furthermore, if end points roam between networks, for instance when mobile
end point switches from mobile connection to WiFi, end points will initiate
an ICE restart, which will trigger a new nomination process between the new
set of candidates and likely result in the new nominated candidate pair.

Implementations MUST treat all ICE candidate pairs associated with an BFCP
session on top of a DTLS association as part of the same DTLS association.
Thus, there will only be one BFCP session setup and one DTLS handshake even
if there are multiple valid candidate pairs, and shifting from one
candidate pair to another, including switching between UDP to TCP candidate
pairs, will not impact the BFCP session or DTLS associations. If new
candidates are added, they will also be part of the same BFCP session and
DTLS associations. When transitioning between candidate pairs, different
candidate pairs can be currently active in different directions and
implementations MUST be ready to receive data on any of the candidates,
even if this means sending and receiving data using UDP/TLS/BFCP and
TCP/DTLS/BFCPat the same time in different directions.

In order to maximize the likelihood of interoperability between the end
points, all ICE enabled BFCP end points SHOULD implement support for
UDP/TLS/BFCP.

When an SDP offer or answer is sent with multiple ICE candidates during
initial connection negotiation or after ICE restart, UDP based candidates
SHOULD be included and default candidate SHOULD be chosen from one of those
UDP candidates. The proto value MUST match the transport protocol
associated with the default candidate. If UDP transport is used for the
default candidate, then 'UDP/TLS/BFCP' proto value MUST be used. If TCP
transport is used for the default candidate, then 'TCP/DTLS/BFCP' proto
value MUST be used. Note that under normal circumstances the proto value
for offers and answers sent during ICE nomination SHOULD be 'UDP/TLS/BFCP'.

When a subsequent SDP offer or answer is sent after ICE nomination is
complete and does not initiate ICE restart, it will contain only the
currently negotiated ICE candidate pair. In this case, the proto value MUST
match the transport protocol associated with the currently negotiated ICE
candidate pair. If UDP transport is used for the currently negotiated pair,
then 'UDP/TLS/BFCP' proto value MUST be used. If TCP transport is used for
the currently negotiated pair, then  'TCP/DTLS/BFCP' proto value MUST be
used. Please note that if an end point switches between TCP-based and
UDP-based candidates during the nomination process the end point is not
required to send an SDP offer for the sole purpose of keeping the proto
value of the
associated m- line in sync.

NOTE: The text in the paragraph above only applies when the usage of ICE
has been negotiated. If ICE is not used, the proto value MUST always
reflect the transport protocol used at any given time.

Regards,
_____________
Roman Shpount