[MMUSIC] m= line protocol in case of ICE

[Roman Shpount <[e-mail]>]

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