Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rfc5245bis-00.txt

From: [email-masked]
Date: Mon, 15 Jul 2013 09:48:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
	Author(s)       : Ari Keranen
                          Jonathan Rosenberg
	Filename        : draft-ietf-mmusic-rfc5245bis-00.txt
	Pages           : 89
	Date            : 2013-07-15

Abstract:
   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based multimedia sessions established with
   the offer/answer model.  This protocol is called Interactive
   Connectivity Establishment (ICE).  ICE makes use of the Session
   Traversal Utilities for NAT (STUN) protocol and its extension,
   Traversal Using Relay NAT (TURN).  ICE can be used by any protocol
   utilizing the offer/answer model, such as the Session Initiation
   Protocol (SIP).

   This document obsoletes RFC 5245.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc5245bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-rfc5245bis-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ari Keränen <[email-masked]>
Date: Mon, 15 Jul 2013 20:48:07 +0300

Folks,

We've submitted the ICE drafts as WG documents, as agreed at the 
previous meeting. They also address the issues that were discussed 
during the meeting and/or on the list:
- clarified the use of short term credentials in connectivity checks
- not using deprecated IPv6 addresses or loop back addresses for candidates
- pairing IPv6 link-locals only with link-locals (wrt ULAs still more 
thinking and discussion is needed)
- ICE options for both session and media level 
(draft-ietf-mmusic-ice-sip-sdp-00)

Cheers,
Ari

On 7/15/13 7:48 PM, [email-masked] wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 15 Jul 2013 20:04:34 +0200

Very minor comment:

On Mon, Jul 15, 2013 at 7:48 PM, Ari Keränen <[email-masked]> wrote:
> Folks,
>
> We've submitted the ICE drafts as WG documents, as agreed at the previous
> meeting. They also address the issues that were discussed during the meeting
> and/or on the list:

Wouldn't it make sense to allow pairing loopback addresses with other
loopback addresses? The main use case that comes to mind is debug
sessions where both the transmitter and the receiver are on the same
host?

Emil

>>         Title           : Interactive Connectivity Establishment (ICE): A
>> Protocol for Network Address Translator (NAT) Traversal for Offer/Answer
>> Protocols
>>         Author(s)       : Ari Keranen
>>                            Jonathan Rosenberg

--
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Ari Keränen <[email-masked]>
Date: Tue, 16 Jul 2013 10:07:50 +0300

Hi Emil,

> sessions where both the transmitter and the receiver are on the same

Even on the same host debugging you should be able to use any IP address 
of the host for that purpose. That said, of course if you *only* have 
the loopback interface, then this might be useful. Perhaps it should be 
made "SHOULD NOT" strength?

Cheers,
Ari (as individual)

---

From: Emil Ivov <[email-masked]>
Date: Tue, 16 Jul 2013 12:35:31 +0200

On 16.07.13, 09:07, Ari Keränen wrote:
> the loopback interface, then this might be useful.

That's the case I was referring to. Someone made a comment in Orlando 
about how loopback addresses had helped them debug a WebRTC app while in 
the plane.

> Perhaps it should be made "SHOULD NOT" strength?

I think "MAY choose not to pair" would work even better. It's mostly an 
implementation choice and choosing one way or the other doesn't 
profoundly break things.

Emil

-- 
https://jitsi.org

---

From: Ari Keränen <[email-masked]>
Date: Tue, 16 Jul 2013 14:25:42 +0300

On 7/16/13 1:35 PM, Emil Ivov wrote:
>>>> previous

I wonder how common use case that's gonna be :)

> implementation choice and choosing one way or the other doesn't

While it doesn't profoundly break things, it may cause significant delay 
and hence I think it's a bad idea. If the default behavior would end up 
having the loopback address in the offers/answers and pairing it with 
all other candidates ("since it's only MAY strength - I don't need to 
implement that check"), that would generate a whole bunch of 
high-priority pairs that are almost 100% sure to fail. Moreover, both 
endpoints should do the same wrt pairing to keep the checks in sync, so 
IMHO it should be fairly strong do or don't (hence at least SHOULD).

Cheers,
Ari