[rtcweb] RTCWEB Interim 80.5 Meeting Minutes - June 8, 2011

Cullen Jennings <fluffy@cisco.com> Tue, 28 June 2011 15:34 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8C07B21F85B1 for <rtcweb@ietfa.amsl.com>; Tue, 28 Jun 2011 08:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YxM72iYDqARY for <rtcweb@ietfa.amsl.com>; Tue, 28 Jun 2011 08:34:30 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 95C6A21F859F for <rtcweb@ietf.org>; Tue, 28 Jun 2011 08:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=8341; q=dns/txt; s=iport; t=1309275268; x=1310484868; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=dTrcpNtkDN3FXpqHxeKaZuZwIClE6jO1cyo6WIFOuCM=; b=Vl/HWRu9FUa8k3er455F5Ylbc2to+P64EMTrN2ye/RT2Ax2lrBlFfDDB EA0vo0y/i4PDtmvOsTNpnFKiCyaXQ335da1e1jBv+IhK49nuhEL8vXAFA BFpYR9zL0lQmIk86h2JZrE79mb3MvkVTaVV1dP10Vrc829asd27unO6co E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJjzCU6rRDoG/2dsb2JhbABFDadAd6tonjWDIIMQBIc0ilyEbotS
X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="723479974"
Received: from mtv-core-1.cisco.com ([]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2011 15:34:28 +0000
Received: from [] (rcdn-fluffy-8712.cisco.com []) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5SFYQ11022452; Tue, 28 Jun 2011 15:34:27 GMT
From: Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Jun 2011 09:34:26 -0600
Message-Id: <E04941F7-A0DB-4AEF-A6F3-E6BF0055891B@cisco.com>
To: rtcweb@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [rtcweb] RTCWEB Interim 80.5 Meeting Minutes - June 8, 2011
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jun 2011 15:34:32 -0000

RTCWEB Interim Meeting Minutes
June 8, 2011
Chairs: Magnus, Cullen, Ted
Session recording url: Will be provided in later email to list. 
Jabber: rtcweb@jabber.ietf.org
Materials: http://trac.tools.ietf.org/wg/rtcweb/trac/wiki


Architecture (discussion led by Harald)
Use Cases and Solution Requirements (discussion led by Christer)
Security (discussion led by EKR and Alan)
NAT Traversal (discussion led by Matthew)
RTP Usage (discussion led by Colin)
Non audio/video data (discussion led by Chairs)
Wrap Up

Note well reviewed
Harald reviewed slides at:

Question raised: Harald mentions “telephone events”. What does that mean?
Cullen replied that this is DTMF. It is mostly used in PSTN gateway situations.
Andy Hutton: Is interoperability in the motherhood and apple pie slide set?
Harald's response: if we get browser-to-browser running in high quality, then direct interoperability may not be a requirement (achieving interoperability with a gateway, rather than “cluttering up” the browser implementation).
Magnus asks whether anyone believes that Gear case 1 is possible to achieve, or are we looking at Gear case 2? Harald says that this is theoretically possible by software upgrade or for new phones. Cullen says that this may happen, but it is likely to be new/newer devices (capable of supporting ICE and the appropriate codecs). Those two things are the minimum capabilities, in Cullen's opinion. JDR notes that it is possible to use RTCP receive report in a way similar to a stun connectivity check, but Matthew notes that there are security issues with that substitution. The group agrees that avoiding Voice Hammer and cross-protocol attacks is required; if there are ways to do that without ICE, fine, but those are key requirements.

Christer presents the slides at:


Use case: Simple Video had no objections
Use case: Multiparty video had no objection on the core requirement, but clarification is needed.
	JDR: to be clear, this use case presumes the browser does audio mixing
	Christer: yes, but it does not re-emit the mixed stream.
	Cullen: is there a protocol difference from Simple Video?
	Christer: No, not much difference, but important to capture, because other use cases have more 	complexity in media streams (variable size, etc.) Assumption has full mesh of media 	connections.
	Keith Drage: does each browser set up each mesh independently, or does the protocol do 	something to set up the mesh?
	Christer: it is still pairwise set up.
	Markus Isomaki: Does the browser have a standard API for this?
	Christer: yes.
	Magnus: we need to clarify different parts of this use case. There are no big objections, but the 	difference between this and Simple Video is not that clear.
	EKR: There are transport issues and media issues. From the transport side, the mesh has 	characteristics similar to the Simple Video. The media mixing has more complexity, as it needs
	to describe how to the streams interact.
	Magnus: are there objects to the core requirement? None heard. More discussion of the scope 	needed.
	Markus: some kind of audio mixing API is needed. How do we get the W3C to agree?
	Christer: there is lots of stuff that has to be communicated.

AI: to the chairs to communicate the need for an audio mixing API to the W3C.

Use case: multiparty online game
 - Comments that this is very similar to previous use case where there is mixing of other sources of audio (the game in this case) 
- No objection to this use case 

Use Case: Video conference system with central server
Keith: How does this use case interact with existing IETF centralized conferencing solutions? How much is the centralized sever in this use expect to be consistent with existing IETF protocols?
Christer: this leads to a discussion about what protocols the browser might need to support, RTCP, BFCP, XCON, etc ... 
??? : The idea of sending two resolutions of video is not a very broad requirement

???: we need to specify things like how to map SSRC to speakers so we can see active speakers. We may need things like inter refresh. 

Conclusion: Need to refine this use case to so that we can get to the issues of what is key and what is not 

Usec ase: Hockey - skipped

Use case: Telephony terminal 

Moving on to Security Presentation from Eric Rescorla (at 1:48 in recording)
Comment from Dan Burnett: Need ability to revoke permission (on slide 13). No disagreement with this. 

At 2:16  discussion about wiretap support. JDR said some people want to LI some don’t. Ted pointed out existing Pen and Wire Tap law were not retrospective. 

Mathew - want to clarify slides that we should make it so if you trust your calling service, then you know your media is OK. (recording 2:28) 

Point raised that allowing a user to see some sort of fingerprint of the audio security is fine. If the users has some out of band method to communicate that to the far side, they can detect MITM. How they might communicate it to the far side not something we would figure out here. 

Multiple people  argued for support of RTP and SRTP. Then argued for SDES and DTLS-SRTP. There should be a way to get a string that fingerprints the media security and a way to display that in the browser chrome. 

Need to deal with tabbed browsing - so someone has a conversation open, switches tab, then forgets some tab is involved with a call. 

RTCWeb Media Privacy presentation: (starting at 3:02 in recording)

Alan, voice is sensitive and important. Also remember that we are defining the phone sevice for this century. A bit amazed that we are talking about doing non SRTP. Adds negotiation complexities. Going through his slides.

Kauffman: Can the signal channel authenticate the ZRTP exchange? 
Alan: Yes, the hash can be passed on the signal channel and verify the whole exchange.

EKR: Why is key-continute work better than a finger print?
Alan: Not in itself, with the SAS one can verify the key continuty chain in that instance.
EKR: Still an issue as key continuty will not work if you change devices. This enables the attacker to insert a new user identity that is similar and which isn’t is verified. Thus enabling doing a MITM. 

The SAS is an exceptionall mechanism for a small user group. 
Ted: Summarizing that there clearly are interest in the media privacy. But there are feedback and perceived issues with what can be accomplished. 

NAT Traversal Presentation: (Starting at time ~3:17 into session)
Kauffman presenting.

Magnus: How do you accomplish interoperability if the two end-points are using different applications? 
Kauffman: The services that interop needs to agree on what mechanism to use. 

Cullen: What about pacing? 
The pacing between multiple tabs doing pace are independent if there is ICE or just the proposal. 

EKR: It is not clearer that a global update is quicker with the proposal, rather than in the browser deployement. 

EKR: Can you actually do this accurately enough for this to work? 
No one has tested it.  Harald, show me the java script that can do this against a regular ICE.

Cullen: Moving on 

RTP Usage: Starting at time 3:35 of the session
Colin Perkins presenting.

Discussion about multiplexing of audio and video on the same RTP session. 

Arguments between keeping the architecture and have interoperability with legacy and saving port state for flows. 

If QoS is sacrificable then a explicit shimming layer is a solution that maintains the session separation. 

Some arguments for supporting a legacy mode with separate sessions and the possibility to put both on the same session. 

If the general issue of allowing multiple RTP sessions on the same transport flow, then this is a general issue and discussion should be in AVTCORE and not RTCWEB specific.