This should be of interest for INT area folks as well: Begin forwarded message:
> From: Lars Eggert <[EMAIL PROTECTED]> > Date: May 19, 2008 12:03:53 GMT+03:00 > To: TSV Area <[EMAIL PROTECTED]> > Subject: non-SIP usage of ICE > > Hi, > > the MMUSIC WG is discussing whether they should take on a work item > on using ICE in non-SIP/RTP environments. This subset of ICE > specified in draft-rosenberg-mmusic-ice-nonsip (called NICE) would > be a general-purpose NAT traversal mechanism, and is for example > being considered by the HIP WG as a NAT traversal solution for HIP. > > I strongly encourage transport-area folks to join this discussion on > the MMUSIC mailing list. The proponents of ICE argue to develop it > into the IETF-preferred NAT traversal protocol, for which it IMO is > currently not sufficiently developed. > > There are some challenges here that are of immediate interest to > transport folks. One is that ICE-for-SIP had been pacing its > connectivity checks such that they use bandwidth in way that is not > more aggressive than a following RTP media stream. With NICE, this > approach is no longer possible, because NICE has no knowledge of the > transmission behavior of arbitrary flows. > > Another is that if NICE chooses candidates that it has obtained via > STUN and TURN, non-RTP traffic may be tunneled through such relays, > which is currently (at least to me) not a well-understood operation. > > Because ICE handles gathering of candidate IP addresses and ports, > it is undefined how ICE/NICE would intersect with layer-3 mobility > and multihoming solutions, or transport protocols like SCTP. > > Finally, ICE has so far mostly focused on relaying UDP traffic, with > a draft on relaying TCP still under WG discussion (draft-ietf-mmusic- > ice-tcp), which so far is still SIP/RTP-specific. There is currently > no possibility to relay SCTP or DCCP with ICE. > > Lars _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
