Re: [MMUSIC] Do We Need an ICE Alternative ?

["Hutton, Andrew" <[e-mail]>]

Hi,

My understanding of previous discussion.

During IETF77 we discussed both the altc draft (http://tools.ietf.org/html/draft-boucadair-mmusic-altc-03) and the alternative ICE-microlite draft (http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02). 

The conclusion of this discussion was that there was no way forward for either of these drafts as stated in the minutes of this meeting (http://www.ietf.org/proceedings/77/minutes/mmusic.html).

However I notice that draft-boucadair-mmusic-altc continues to be updated although there has been no discussion or even notification of updates on the MMUSIC list. 

Therefore I would like to know what is the current status and intention regarding the altc draft?

During IETF80 draft http://tools.ietf.org/html/draft-elwell-mmusic-ice-updated-offer-01 was presented with the intention of starting a discussion on some of the barriers to deploying ICE. The feedback we obtained was that the requirement for an updated offer in ICE was not really that strict, even though it is mandatory in the draft, and implementations are not always implementing this anyway.  The conclusion I understood was to continue to document and discuss the problems and if necessary if there are enough issues raised update ICE.


Regards
Andy



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Flemming Andreasen
> Sent: 15 November 2011 20:49
> To: mmusic
> Subject: [MMUSIC] Do We Need an ICE Alternative ?
> 
> 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)
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic