Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A0621E8096 for ; Tue, 11 Dec 2012 15:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvDZq-PRAsga for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Received: from where.matthew.at (where.matthew.at [198.202.199.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449021E808D for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Received: from [10.252.226.81] (unknown [198.134.88.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by where.matthew.at (Postfix) with ESMTP id 69DC3148068 for ; Tue, 11 Dec 2012 15:16:29 -0800 (PST) Message-ID: <50C7BECB.7050802@matthew.at> Date: Tue, 11 Dec 2012 15:16:27 -0800 From: Matthew Kaufman User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000407000307080104090209" Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 23:16:30 -0000 This is a multi-part message in MIME format. --------------000407000307080104090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/8/2012 3:21 PM, Eric Rescorla wrote: > +rtcweb > > On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) > > wrote: > > > I was looking over everything that needs to be completed to finish > a fist cut of the WebRTC related work. There are a handful of big > SDP problems that are currently blocking some of the WebRTC work > and I'd like to figure out how to make some progress on them. > > Let me loosely characterize them as > > 1) If we have several video streams, how do theses map up to 1 or > more m lines. > > 2) if we are doing port multiplexing, what does the SDP look like > (the bundle problem) > > 3) How do we map the RTCWeb track and stream label concepts to > identifiers in SDP > > 3) SDP for application running over SCTP/DTLS > > > I don't want to speak for all the various chairs but I am under > the impression that most of chairs of related groups in W3C and > IETF believe these are issues that need to be resolved primarily > in the MMUSIC WG and that they impact both WebRTC and CLUE as well > as the general long term use of SDP in SIP and other protocols. > > I'd like to get some discussion going on how we can make some > progress on these. I don't think we are going to solve these in 20 > minutes of discussion at an IETF meeting so I think we probably > need some interim (virtual or face to face) to sort this out. > > Thoughts? > > > Wow, I'm totally confused here. > > I had assumed that the SDP-related issues were going to be the main > topics at the WebRTC/RTCWEB interim in January. Is that not the case? > > IMO the lack of clarity around how to encode various media > configurations into SDP is the major thing blocking progress here. In > particular, Firefox has opted not to implement multiplexing of media > streams over the same transport flow (whether of the bundle or > multiple m-line variety) until the SDP for it is well-defined. The > same thing applies to the question of how to map multiple m-lines to > incoming MediaStreams/Tracks. > > We really need to cover these issues in the interim. > > -Ekr > > We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful. I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0. Matthew Kaufman --------------000407000307080104090209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/8/2012 3:21 PM, Eric Rescorla wrote:
+rtcweb

On Sat, Dec 8, 2012 at 2:41 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

I was looking over everything that needs to be completed to finish a fist cut of the WebRTC related work. There are a handful of big SDP problems that are currently blocking some of the WebRTC work and I'd like to figure out how to make some progress on them.

Let me loosely characterize them as

1) If we have several video streams, how do theses map up to 1 or more m lines.

2) if we are doing port multiplexing, what does the SDP look like (the bundle problem)

3) How do we map the RTCWeb track and stream label concepts to identifiers in SDP

3) SDP for application running over SCTP/DTLS

I don't want to speak for all the various chairs but I am under the impression that most of chairs of related groups in W3C and IETF believe these are issues that need to be resolved primarily in the MMUSIC WG and that they impact both WebRTC and CLUE as well as the general long term use of SDP in SIP and other protocols.

I'd like to get some discussion going on how we can make some progress on these. I don't think we are going to solve these in 20 minutes of discussion at an IETF meeting so I think we probably need some interim (virtual or face to face) to sort this out.

Thoughts?

Wow, I'm totally confused here.

I had assumed that the SDP-related issues were going to be the main
topics at the WebRTC/RTCWEB interim in January. Is that not the case?

IMO the lack of clarity around how to encode various media
configurations into SDP is the major thing blocking progress here. In
particular, Firefox has opted not to implement multiplexing of media
streams over the same transport flow (whether of the bundle or
multiple m-line variety) until the SDP for it is well-defined. The
same thing applies to the question of how to map multiple m-lines to
incoming MediaStreams/Tracks.

We really need to cover these issues in the interim.

-Ekr



We only need to cover these issues soon if RTCWEB continues to insist that SDP is a good idea for an API *and* that changes to SDP are necessary in order for RTCWEB to then be successful.

I would posit that if SDP as used in (and referenced from) RFC3264 was the appropriate API surface for RTCWEB then NO ADDITIONAL WORK in mmusic would be required in order to ship RTCWEB 1.0.

Matthew Kaufman

--------------000407000307080104090209--