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

[Christer Holmberg <[e-mail]>]

Hi,

I have no problem with Roman’s must-support-UDP suggestion. I guess the question is whether the BFCP folks could accept that. Cullen did say that TCP-based BFCP deployments have been around for a decade. But, do they support ICE?

If we decide to move forward with such approach, we need to ask ourselves whether must-support-UDP should be an ICE requirement (in which case the suggestion should be brought to the ICE WG) or whether it should only be an ICE-using-SIP-SDP requirement.

Regards,

Christer

From: mmusic [mailto:[e-mail]] On Behalf Of Roman Shpount
Sent: 17 November 2016 00:52
To: [e-mail]
Subject: [MMUSIC] m= line protocol in case of ICE

Hi All,

I just wanted to return to the m= line protocol issue that Christer raised during the last MMUSIC session.

All the ICE implementations I've seen are primarily UDP based with support for tcp host candidates which are primarily used to connect to end points on public IP. If all ICE implementations are continue to be primarily UDP based, then the simplest solution would be to require UDP support when any given protocol is implemented over ICE. DTLS and RTP are already primarily UDP based so this is a non-requirement. Even more, all protocols that are implemented on top of ICE must assume that underling transports (including tcp candidates) are unreliable, since candidate pair can change at any time between reliable and unreliable transports, so this makes them different from protocols implemented on plain TCP or TLS.

So the first question I wanted to ask is anybody interested in TCP only ICE implementation where the protocol running on top of such implementation relies on the reliable delivery of underlying messages? By this I mean, does anybody wants implement TCP based ICE, with simultaneous open, reflexive and relay candidates in such a way that ICE implementation will run from behind NAT without ever needing a UDP candidate?

I understand that BFCP was used for a long time, but I do not think TCP/BFCP or TCP/TLS/BFCP can even be used with ICE. I think only UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP can even support ICE.

I think both rfc4582bis and rfc4583bis need a careful review and additional sections that describe ICE considerations. I think the most obvious thing would be to specify that ICE can only be supported by UDP/BFCP, UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will also mean in which case RFC4571 is used when tcp candidates are used. Furthermore, when tcp candidate is selected with UDP/BFCP transport, it is not the same thing as using TCP/BFCP and will need a different transport tag (something like TCP/UDP/BFCP). Alternatively we can require that only secure versions of BFCP are used with ICE and only allow ICE usage for UDP/DTLS/BFCP and TCP/DTLS/BFCP.

To conclude, I would argue that the simplest solution would be that for all protocols implemented on top of ICE, UDP MUST be supported and default candidates MUST be UDP based. This avoids building uncomfortable artificial constructs to avoid ICE mismatch and requires minimal changes to existing specifications.

Regards,
_____________
Roman Shpount