[MMUSIC] Do We Need an ICE Alternative ?

[Flemming Andreasen <[e-mail]>]

Greetings

Over the past several years, the MMUSIC WG has developed and 
standardized ICE (RFC 5245) as the mechanism to enable NAT traversal and 
IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). 
Alternative NAT traversal mechanisms exist, and others have been 
proposed, however they have either been limited to specific deployment 
topologies (e.g. symmetric RTP or STUN by itself) or required some level 
of network support (e.g. an ALG of some sort). Similarly, for IPv4/IPv6 
transition, RFC 4091/4092 (ANAT) defined an alternative solution that 
was deprecated following MMUSIC and SIPPING WG discssion and consensus 
at IETF68 (in 2007):

     http://www.ietf.org/proceedings/68/minutes/mmusic.txt
     http://www.ietf.org/proceedings/68/minutes/sipping.txt

Several years have passed and we have been getting more implementation 
and deployment experience with ICE. However, we have also seen 
suggestions for alternative solutions, with recent examples including 
the ALTC draft for IPv4/IPv6 transition and the latching mechanism for 
NAT traversal:

     Link to ALTC draft:
     https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/

     Link to latching mechanism (Section 5.7 in old version of loopback 
draft):
     http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt


Alternatives, that generally have a more limited scope than ICE, keep 
popping up every now and then, and it seems that at least some set of 
people are not happy with the current ICE solution. So, we would like to 
understand from the working group if there are issues with ICE and if we 
need to explore alternative solutions for NAT traversal and/or for 
IPv4/IPv6 transition.

Our goal as a standards organization is to enable interoperable 
products, and having multiple different standards for the same problem 
or multiple different standards for specific instances of a general 
problem is not conducive to that. If we have to revisit one of the 
standards for a given problem space, we ought to be careful and 
understand what are the issues that we have with that standard. 
Furthermore, if we are to come with alternative solutions for that 
problem space, we have to ensure a clear understanding of what has 
changed since the last time we created the standard, what are the new 
set of requirements to satisfy, and which of the old requirements no 
longer apply.

So, we would like to sense the WG for opinions in this matter

Thanks

     Flemming and Miguel (MMUSIC chairs)