Re: [tram] First post

[Oleg Moskalenko <[e-mail]>]

MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching
and I am going to implement. I wonder whether the authors of the draft may
be interested in the TURN evolution.


On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <
[e-mail]> wrote:

> All,
>
> Any objection against sending the following to rtcweb, pntaw, and behave?
> Any other lists that should be included?
>
> Simon
>
> ====================
>
> All,
>
> A few of us have been working on a proposal for a new working group that
> would focus on enhancements to STUN and TURN. The proposed name is TRAM
> (Turn Revised And Modernized) and discussion is happening in <
> [e-mail]>.
> Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>
>
> Here is the charter we have been working on. If you would like to comment
> and/or get involved, please do so on the TRAM mailing list.
>
> Simon (and many others!)
>
>  Turn Revised And Modernized (tram)
>> ----------------------------------
>>
>> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in
>> April
>> 2010.  Until recently the protocol had only a rather limited deployment.
>>  This
>> is primarily because its primary use case is as one of the NAT traversal
>> methods of the Interactive Connectivity Establishment (ICE) framework (RFC
>> 5245).  This inherent dependency on ICE combined with the fact that ICE
>> itself
>> was slow to achieve widespread adoption because other alternative
>> mechanisms
>> were historically used by the VoIP industry were the causes of the initial
>> lack of interest.  This situation has changed drastically as ICE, and
>> consequently TURN, are mandatory to implement in WebRTC, which is a set of
>> technologies developed at the IETF and W3C aiming to enable Real Time
>> Communication on the Web.
>>
>> Because of the ubiquity of the Web and of the new opportunities created
>> by the
>> arrival of WebRTC, there is a renewed interest in TURN and ICE, as
>> evidenced by
>> the recent work updating the ICE framework, as well as standardizing the
>> URIs
>> used to access a STUN [RFC7064] or TURN [RFC7065] server.
>>
>> The goal of the TRAM Working Group is to consolidate the various
>> initiatives
>> to update TURN and STUN, including the definition of new transport and
>> authentication mechanisms that make STUN and TURN more suitable for the
>> WebRTC
>> environment.  The Working Group will closely coordinate with the
>> appropriate
>> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.
>>
>> The current list of deliverable is:
>>
>> - DTLS transport for TURN
>>
>>   Candidate draft: draft-petithuguenin-tram-turn-dtls
>>
>>   TURN defines three transports: UDP, TCP, and TLS. A straightforward
>> extension
>>   of this set is DTLS, enabling secure datagram-oriented transport.
>>
>> - New authentication mechanism for TURN
>>
>>   Problem analysis: draft-reddy-behave-turn-auth
>>   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been
>> suggested
>>
>>   The current authentication mechanism for TURN, which is reused from
>> STUN, has
>>   been designed with a SIP account database in mind. The new RTCWEB
>> usages,
>>   which are mostly based on web applications, do not fit that model. A new
>>   authentication mechanism optimized for such web applications will be
>> created.
>>
>> - TURN server auto-discovery mechanism for enterprise and ISPs
>>
>>   Candidate draft: TBD
>>
>>   Current TURN server discovery is based on the presence of SRV and/or
>> NAPTR DNS
>>   records. These records are usually under the administrative control of
>> the
>>   application or service provider, not the enterprise or the ISP on whose
>>   network the client is situated. Enterprises or ISPs wishing to provide
>> their
>>   own TURN server, in an attempt to reduce so-called "triangle routing",
>> need a
>>   new auto-discovery mechanism.
>>
>> - STUN-bis
>>
>>   Candidate draft: TBD
>>
>>   A new revision of RFC 5389 will contain:
>>
>>   - Various bug fixes
>>   - STUN hash algorithm agility (currently only SHA-1 is allowed)
>>
>> - TURN-bis
>>
>>   Candidate draft: TBD
>>
>>   A new revision of RFC 5766 will contain:
>>
>>   - Various bug fixes
>>   - Support for multi-tenant servers
>>     (Servers always send the same REALM attribute. No realm negotiation
>> phase
>>      currently exists.)
>>
>> Goals and Milestones:
>>
>> [TBD]
>>
>
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>