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

["Charles Eckel (eckelcu)" <[e-mail]>]

Roman,

Thanks for this.
As an individual, your proposed changes look good to me. Please see two comments inline [cue]

From: Roman Shpount <[e-mail]>
Date: Thursday, March 2, 2017 at 2:14 PM
To: Charles Eckel <[e-mail]>
Cc: Gonzalo Camarillo <[e-mail]>, Tom Kristensen <[e-mail]>, Christer Holmberg <[e-mail]>, Tom Kristensen <[e-mail]>, Mary Barnes <[e-mail]>, Paul Jones <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Updates to draft-ietf-bfcpbis-rfc4583bis required to enable ICE

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.

[cue] We define the proto field value UDP/TLS/BFCP in this draft for BFCP over DTLS. Would it not be more straightforward and consistent to define the new proto value as TCP/UDP/TLS/BFCP instead of TCP/DTLS/BFCP?

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.

[cue] We previously decided to stick with RFC 5763 because draft-ietf-mmusic-dtls-sdp including dtls-id. Given the state of draft-ietf-mmusic-dtls-sdp including dtls-id at this time, I agree it is now appropriate to reference it instead of RFC 5763.
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<http://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

Cheers,
Charles