Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 3 Jan 2017 19:43:55 +0000

Crickets…
If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best to state that as of this rev of the BFCP spec, BFCP with TCP candidates is not defined. Future updates to the spec may define this usage.

Cheers,
Charles

From: mmusic <[email-masked]> on behalf of Charles Eckel <[email-masked]>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE

I have no experience with ICE with TCP candidates so hopefully others can chime in as to what they think is a workable solution.

Cheers,
Charles

From: Roman Shpount <[email-masked]>
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <[email-masked]>
Cc: Alan Ford <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

Charles,

RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1) says that "The framing defined in RFC 4571<https://tools.ietf.org/html/rfc4571> MUST be used when sending media." This means the protocol used is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would prevent using TCP/BFCP directly with ice tcp candidates without redesign of either ICE TCP or TCP/BFCP.

Furthermore there are other implied ICE requirements that I outlined before (switching between udp and tpc candidates, existence of SBC which terminate ICE only but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and will require fragmentation support and re-transmit timers that are not part of TCP/BFCP.

Regards,

_____________
Roman Shpount

On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it does, but after a quick scan I am not sure why.

Cheers,
Charles

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <[email-masked]<mailto:[email-masked]>>
Cc: Alan Ford <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
It seems to me that the most straightforward approach would be to mandate support for BFCP over UDP when using ICE, use UDP as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would be even better.
Thoughts?

I agree.

The only issue that I still have, if DTLS is not used, what protocol is used when ICE tcp candidate is selected for transport. Is this TCP/BFCP (which goes against RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framing, what transport tag should be used in the re-INVITE which is sent after ICE nomination with only selected candidate? Should it be TCP/UDP/BFCP or something similar?

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Jan 2017 15:08:04 -0500

Charles,

I do not think not supporting ICE tcp candidates will quite work since it
will reduce the usability considerably. The simplest way to move forward is
to define a different transport tag for BFCP  with RFC 4571 over TCP not to
confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks strange
and I am open to other suggestions, such as calling all packet based
protocols DBFCP).

In general what I am proposing is:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/BFCP -- BFCP over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp
candidates
UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates
TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over ICE
tcp candidates

Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols
can work with NAT or ICE using normal ICE procedures.

If we call all packet based protocols DBFCP then transport tags will be:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/DBFCP -- DBFCP over UDP or ICE udp candidates
TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp candidates
UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates
TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over
ICE tcp candidates

Since BFCP over UDP (or other packet based protocols) is quite different
due to timers and transmission restrictions, it can have a different
transport tag and even be defined in a separate RFC.

Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) <[email-masked]>
wrote:

> Crickets…
>
> If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best
> to state that as of this rev of the BFCP spec, BFCP with TCP candidates is
> not defined. Future updates to the spec may define this usage.
>
>
>
> Cheers,
>
> Charles
>
>
>
> *From: *mmusic <[email-masked]> on behalf of Charles Eckel <
> [email-masked]>
> *Date: *Friday, December 2, 2016 at 4:01 PM
> *To: *Roman Shpount <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,
> Christer Holmberg <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE
>
>
>
> I have no experience with ICE with TCP candidates so hopefully others can
> chime in as to what they think is a workable solution.
>
>
>
> Cheers,
>
> Charles
>
>
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Thursday, December 1, 2016 at 12:34 PM
> *To: *Charles Eckel <[email-masked]>
> *Cc: *Alan Ford <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Christer Holmberg <[email-masked]>
> *Subject: *Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
>
>
>
> Charles,
>
>
>
> RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1) says
> that "The framing defined in RFC 4571
> <https://tools.ietf.org/html/rfc4571> MUST be used when sending media."
> This means the protocol used is not TCP/BFCP which is using application
> level framing. I believe that STUN/Media demultiplexing requirements would
> prevent using TCP/BFCP directly with ice tcp candidates without redesign of
> either ICE TCP or TCP/BFCP.
>
>
>
> Furthermore there are other implied ICE requirements that I outlined
> before (switching between udp and tpc candidates, existence of SBC which
> terminate ICE only but do not support the embedded protocol) because of
> which ice tcp is considered unreliable transport and will require
> fragmentation support and re-transmit timers that are not part of TCP/BFCP.
>
>
>
> Regards,
>
>
> _____________
> Roman Shpount
>
>
>
> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) <[email-masked]>
> wrote:
>
> Roman,
>
>
>
> Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it
> does, but after a quick scan I am not sure why.
>
>
>
> Cheers,
>
> Charles
>
>
>
> *From: *Roman Shpount <[email-masked]>
> *Date: *Tuesday, November 29, 2016 at 10:38 AM
> *To: *Charles Eckel <[email-masked]>
> *Cc: *Alan Ford <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Christer Holmberg <[email-masked]>
> *Subject: *Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE
>
>
>
> On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <
> [email-masked]> wrote:
>
> It seems to me that the most straightforward approach would be to mandate
> support for BFCP over UDP when using ICE, use UDP as the default candidate,
> and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the
> use of DTLS, that would be even better.
>
> Thoughts?
>
>
>
>
>
> I agree.
>
>
>
> The only issue that I still have, if DTLS is not used, what protocol is
> used when ICE tcp candidate is selected for transport. Is this TCP/BFCP
> (which goes against RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it
> is UDP/BFCP with RFC4571 framing, what transport tag should be used in the
> re-INVITE which is sent after ICE nomination with only selected candidate?
> Should it be TCP/UDP/BFCP or something similar?
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>
>
>
>

---

From: Alan Ford <[email-masked]>
Date: Tue, 3 Jan 2017 23:23:35 +0000

Roman,

Do any of those work for having both tcp and udp ICE candidates? I assume any with ICE (+ 4571 framing) would be acceptable for that case?

Ideally we need to support the case where an answer’s m-line protocol does not match any of the candidates, so that an answer could only support TCP (say) when the offerer supported both (and used a UDP m-line protocol). If Christer’s proposed change which permitted an answer not to match the m-line protocol in the ICE candidates was accepted, that would resolve this case. Do you see any problems here?

Regards,
Alan

> On 3 Jan 2017, at 20:08, Roman Shpount <[email-masked]> wrote:
> 
> Charles,
> 
> I do not think not supporting ICE tcp candidates will quite work since it will reduce the usability considerably. The simplest way to move forward is to define a different transport tag for BFCP  with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks strange and I am open to other suggestions, such as calling all packet based protocols DBFCP). 
> 
> TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp candidates
> TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates
> 
> Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work with NAT or ICE using normal ICE procedures.
> 
> TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates
> 
> Since BFCP over UDP (or other packet based protocols) is quite different due to timers and transmission restrictions, it can have a different transport tag and even be defined in a separate RFC.
> 
> Regards,
> 
> _____________
> Roman Shpount
> 
> On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
> Crickets…
> 
> From: mmusic <[email-masked] <mailto:[email-masked]>> on behalf of Charles Eckel <[email-masked] <mailto:[email-masked]>>
> To: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> To: Charles Eckel <[email-masked] <mailto:[email-masked]>>
> Cc: Alan Ford <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1 <https://tools.ietf.org/html/rfc6544#section-10.1>) says that "The framing defined in RFC 4571 <https://tools.ietf.org/html/rfc4571> MUST be used when sending media." This means the protocol used is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would prevent using TCP/BFCP directly with ice tcp candidates without redesign of either ICE TCP or TCP/BFCP.
> 
>  
> 
> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Roman,
> 
>  
> 
> From: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> To: Charles Eckel <[email-masked] <mailto:[email-masked]>>
> Cc: Alan Ford <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Jan 2017 18:44:54 -0500

Alan,

TCP/BFCP and TLS/BFCP will not work with ICE. Or, to be more precise, will
not work without some specification changes either in ICE tcp or in BFCP.

One pair of protocols which will work with ICE is UDP/DTLS/BFCP and
TCP/DTLS/BFCP.
It will support both tcp and udp candidates. I think this pair should be
recommended since it provides encryption.

Another pair that will work with ICE is UDP/BFCP and TCP/UDP/BFCP. It will
also support tcp and udp candidates. It is not something I would use over
public internet since it will transmit data in the clear text.

Finally, I prefer that any end point which implement BFCP and supports ICE
and DTLS, MUST support UDP/DTLS/BFCP and use it for default candidate. Any
endpoint which implements BFCP and ICE, but does not support DTLS, MUST
support UDP/BFCP and use it as a default candidate.

Once the ICE candidate pair is selected, the transport matching the
selected candidate pair should be used in the SDP.

There is no practical need for the asymmetric transport tags. I think the
whole thing is coming from  the confusion that TCP/BFCP can be used with
ICE tcp candidates. It cannot without some specification changes. Also,
there is no reason to use TCP/DTLS/BFCP or TCP/UDP/BFCP, unless ICE is
used. Because of this, there is no reason to use either of those transports
for default candidate, since default candidate is selected for interop with
end points not supporting ICE.

Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford <[email-masked]> wrote:

> Roman,
>
> Do any of those work for having both tcp and udp ICE candidates? I assume
> any with ICE (+ 4571 framing) would be acceptable for that case?
>
> Ideally we need to support the case where an answer’s m-line protocol does
> not match any of the candidates, so that an answer could only support TCP
> (say) when the offerer supported both (and used a UDP m-line protocol). If
> Christer’s proposed change which permitted an answer not to match the
> m-line protocol in the ICE candidates was accepted, that would resolve this
> case. Do you see any problems here?
>
> Regards,
> Alan
>
> On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) <[email-masked]
> > wrote:
>
>> Crickets…
>>
>> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) <

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 Jan 2017 20:17:03 +0000

Roman,

Thanks for sharing this very clear proposal. Unless someone sees an issue with it, I think it should be incorporated into draft-ietf-bfcpbis-rfc4583bis. Support for DTLS is required by draft-ietf-bfcpbis-rfc4582bis for transport of BFCP over UDP, so requiring support for UDP/DTLS/BFCP as the default candidate when using ICE and DTLS and requiring support for UDP/BFCP as the default candidate otherwise should be fine.

I believe the changes required to add your proposal are limited to draft-ietf-bfcpbis-rfc4583bis. Roman, can you work with Tom Kristensen to make sure your proposal is captured correctly in update to draft-ietf-bfcpbis-rfc4583bis?

Cheers,
Charles

From: Roman Shpount <[email-masked]>
Date: Tuesday, January 3, 2017 at 3:44 PM
To: Alan Ford <[email-masked]>
Cc: Charles Eckel <[email-masked]>, "[email-masked]" <[email-masked]>, Christer Holmberg <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bfcpbis] [MMUSIC] m= line protocol in case of ICE

Alan,

TCP/BFCP and TLS/BFCP will not work with ICE. Or, to be more precise, will not work without some specification changes either in ICE tcp or in BFCP.

One pair of protocols which will work with ICE is UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will support both tcp and udp candidates. I think this pair should be recommended since it provides encryption.

Another pair that will work with ICE is UDP/BFCP and TCP/UDP/BFCP. It will also support tcp and udp candidates. It is not something I would use over public internet since it will transmit data in the clear text.

Finally, I prefer that any end point which implement BFCP and supports ICE and DTLS, MUST support UDP/DTLS/BFCP and use it for default candidate. Any endpoint which implements BFCP and ICE, but does not support DTLS, MUST support UDP/BFCP and use it as a default candidate.

Once the ICE candidate pair is selected, the transport matching the selected candidate pair should be used in the SDP.

There is no practical need for the asymmetric transport tags. I think the whole thing is coming from  the confusion that TCP/BFCP can be used with ICE tcp candidates. It cannot without some specification changes. Also, there is no reason to use TCP/DTLS/BFCP or TCP/UDP/BFCP, unless ICE is used. Because of this, there is no reason to use either of those transports for default candidate, since default candidate is selected for interop with end points not supporting ICE.

Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford <[email-masked]<mailto:[email-masked]>> wrote:
Roman,

Regards,
Alan

On 3 Jan 2017, at 20:08, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

Charles,

Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) <[email-masked]<mailto:[email-masked]>> wrote:
Crickets…
If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best to state that as of this rev of the BFCP spec, BFCP with TCP candidates is not defined. Future updates to the spec may define this usage.

Cheers,
Charles

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Charles Eckel <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE

Cheers,
Charles

Charles,

Regards,

_____________
Roman Shpount

Cheers,
Charles

I agree.

Regards,
_____________
Roman Shpount

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis