Re: [rtcweb] ICE-Lite, Was: I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt

"Karl Stahl" <> Sat, 12 April 2014 09:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0F801A02D3 for <>; Sat, 12 Apr 2014 02:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OQPAwIH2jNb9 for <>; Sat, 12 Apr 2014 02:57:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 071DD1A0179 for <>; Sat, 12 Apr 2014 02:57:06 -0700 (PDT)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201404121157033593; Sat, 12 Apr 2014 11:57:03 +0200
From: "Karl Stahl" <>
To: "'Christer Holmberg'" <>, "'Harald Alvestrand'" <>, "'Martin Thomson'" <>, "'Ram Mohan R \(rmohanr\)'" <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Sat, 12 Apr 2014 11:57:10 +0200
Message-ID: <024c01cf5635$92835650$b78a02f0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024D_01CF5646.560C2650"
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: sv
Subject: Re: [rtcweb] ICE-Lite, Was: I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Apr 2014 09:57:11 -0000

To avoid confusion…


Gateways are not mentioned in draft-ietf-rtcweb-transports-03


Under 3.5.  Middle box related functions 

It too simply says:

ICE [RFC5245] MUST be supported.  The implementation MUST be a full

   ICE implementation, not ICE-Lite.


It needs to be said that gateways, i.e. devices having a media port on a public IP address – never behind a NAT/firewall – SHOULD implement ICE-Lite. (which browsers implementing full ICE correctly are compatible with – and has to be – which we all have the same understanding of, I believe)






Från: rtcweb [] För Christer Holmberg
Skickat: den 12 april 2014 10:26
Till: Harald Alvestrand; Martin Thomson; Ram Mohan R (rmohanr)
Ämne: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt




It’s not about running a browser on ice-lite – it is about a browser being prepared to run with a remote endpoint that is running ice-lite (e.g. a gateway). Certain browser implementations have had some problems with that, afaik…






From: Harald Alvestrand [] 
Sent: 12 April 2014 08:59
To: Christer Holmberg; Martin Thomson; Ram Mohan R (rmohanr)
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-02.txt


Seems we have another reason why running a browser on ice-lite is a bad idea. Good that we do not allow that.

On 11. april 2014 22:37:55 CEST, Christer Holmberg <> wrote:


 With ICE-lite mode since the ICE-lite endpoint does not typically 
 generate any binding requests, it may not generate STUN consent as well.


Consent is generated by responding to connectivity checks.  An ICE-lite endpoint has to do that.

Sure, but I guess what is meant is that the ICE-lite endpoint does not generate STUN consent REQUESTS.




rtcweb mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.