Re: [rtcweb] Summary of ICE discussion

<> Thu, 13 October 2011 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06C7D21F8AAA for <>; Thu, 13 Oct 2011 06:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iRD5F9SP0W7O for <>; Thu, 13 Oct 2011 06:22:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2624E21F8A64 for <>; Thu, 13 Oct 2011 06:22:51 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 9797EB58C06; Sun, 9 Oct 2011 11:58:35 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 9135FB58B7A; Sun, 9 Oct 2011 11:58:35 +0200 (CEST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Sun, 9 Oct 2011 11:49:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 09 Oct 2011 11:48:59 +0200
Message-ID: <>
Thread-Topic: [rtcweb] Summary of ICE discussion
Thread-Index: AcyCorfYEOy7oXJvRF2NDEycgSphrQChiXRwAE+CiBAAAD10gA==
References: <>
X-OriginalArrivalTime: 09 Oct 2011 09:49:00.0448 (UTC) FILETIME=[ABD4EA00:01CC8668]
Subject: Re: [rtcweb] Summary of ICE discussion
X-Mailman-Version: 2.1.12
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: Thu, 13 Oct 2011 13:22:52 -0000

Hi there,

Re Magnus's call for proposal (If anyone can find a solution that fulfill
 the security goals and have improved legacy interoperability people would 
be interested in that solution. So far RTCP has been discarded as insufficient.) 
on media consent verification, here is below a suggestion for the group:

Basically, the idea, compared to Hadriel's RTCP proposal, relies on the use 
of the signalling path instead of RTCP as a feedback channel for media 
consent verification.

Here are the steps I foresee before allowing the establishment of a media session:
- Let's consider A (a RTC-Web compliant browser) connected to server S and 
wishing to share real-time media with destination B (potentially a SIP 
endpoint or a browser)
- A & B learn via the signalling channel the triple @IP, transport proto and 
associated listening port of the remote media
- A sends a few RTP packets to B (3 as in RFC 2833/4733 or more?).- This would
 allow the mechanism to resist against packet loss -   
- Assuming B receives these packets, it then sends via the signalling channel 
an information from the media path unknown from S (i.e. not accessible via JS). 
I propose to use the min of the sequence number of the RTP packets received 
(which is random per RFC 3550)
- A receives via S this info granting B's consent to receiving media from A
- A now can start sending media to B

When B uses SIP as its signalling channel, Step 4 would probably require a 
SDP extension to convey this info, as well as possibly extended H.248/Diameter
 informations would be required in a decoupled sig./media architecture.  
Of course, a solution avoiding extensions would be more than welcome.

The benefit of this mechanism largely relies on the assumption that the 
transmission of information from the media termination of the destination 
to its associated signalling channel is less costly than implementing ICE connectivity 
checks. Which is still to be checked.

This mechanism provides basic media consent verification and if it turns out 
that it provides less security properties than ICE or other drawbacks (e.g. 
increasing media session establishment delay, issues with the few initial RTP 
packets,..), it could be seen as a fallback media consent verification 
when ICE is not implemented at each end of media terminations. 

Looking forward to hearing feedbacks from the group on this.


-----Message d'origine-----
De : [] De la part de Magnus Westerlund
Envoyé : mardi 4 octobre 2011 16:33
À :
Objet : [rtcweb] Summary of ICE discussion


I have bellow tired to summarize the result of the ICE discussion. This
is intended as furthering this discussion and form a basis for going
forward in the consensus process. I do expect people that disagree with
my summary of the discussion to speak up.

Major requirements

- Need for data transmission consent for protocols using UDP as the
traffic receiver needs to consent to receiving the data

- Perform NAT and FW traversal when ever needed

- Support IPv4 to IPv6 transition

Desired behavior:

- Be interoperable with deployed legacy systems as SIP Trunk, PSTN
gateways, VoIP phones.

WG chairs conclusion of discussion so far:

- ICE is so far the only solution that provides the security goals and
have any legacy deployment.

- ICE usage will require that STUN connectivity MUST have succeeded
prior to any data transmission to fulfill security goals.

  * The Browser will enforce this requirement to prevent being an attack
vector in all cases.

- If anyone can find a solution that fulfill the security goals and have
improved legacy interoperability people would be interested in that
solution. So far RTCP has been discarded as insufficient.

- Media Gateway can support a reduced functionality set from Full ICE


Magnus Westerlund
as WG chair

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto:

rtcweb mailing list