Re: [MMUSIC] SDP work needed for WebRTC stuff

Martin Thomson <martin.thomson@gmail.com> Tue, 11 December 2012 01:29 UTC

Return-Path: <martin.thomson@gmail.com>
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 BFDE121F8713; Mon, 10 Dec 2012 17:29:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.745
X-Spam-Level:
X-Spam-Status: No, score=-4.745 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 g4Bm2kmR5eXb; Mon, 10 Dec 2012 17:29:28 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEEEF21F871D; Mon, 10 Dec 2012 17:29:27 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id d3so2721943lah.31 for <multiple recipients>; Mon, 10 Dec 2012 17:29:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sJMdp6+ksJ7rH4SC7PlUk2PwFObJNNWZkptMdZoT9ls=; b=nA0/S/Hc7f1owTI6hR/MKWUr11McHpqEWICK4cGYS8MtzAwX2WbJmpMvbW5yZiiKm2 kt9V8yZtwjEIMJchfXlQowoPn7oeTuvVOdBgxL6VCqwmI6alwPABYVN7R+Ioo58RFwPM PTf+EVAlXdkhtAJmkGXvMheXoSJNmCnLFe62LAP98NvVWyDRTjwjqrQM4o+F54I3Ye27 fxnqoceR6+5GIJIb4xgbnxONuMPuQzzzJ9cA5M2K81FhG5ujw4OXOpYfbavXHIdvNsgR dw7mDJaBrKT/YqMBgSc3k3EGuQ8Bqr7tEjgqOfapssVpl/Fe25FYLt75Tg8OpL+DXnrX 6mlQ==
MIME-Version: 1.0
Received: by 10.152.106.212 with SMTP id gw20mr15662525lab.8.1355189366774; Mon, 10 Dec 2012 17:29:26 -0800 (PST)
Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST)
Received: by 10.112.98.200 with HTTP; Mon, 10 Dec 2012 17:29:26 -0800 (PST)
In-Reply-To: <CABcZeBMjREPNVAg3UvEdink89qk+bwmbARK431wLLwv=gK6yhg@mail.gmail.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB1132A380B@xmb-aln-x02.cisco.com> <CABcZeBPfhKoDvHceNLo_Ab9rRDD0V-mMok4H4y_FitYcBZ7vTA@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1132A5D53@xmb-aln-x02.cisco.com> <EDC0A1AE77C57744B664A310A0B23AE20D74247E9C@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CA+9kkMASrAGvAEY7aU5H1CjVqBj0bQfkXr3XdBmO8M-FQNGS0Q@mail.gmail.com> <CABcZeBMjREPNVAg3UvEdink89qk+bwmbARK431wLLwv=gK6yhg@mail.gmail.com>
Date: Mon, 10 Dec 2012 17:29:26 -0800
Message-ID: <CABkgnnXyyX9jbjaExVh9J9SLnRE=soqNfvfwX+N6bj4-5ikW8g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="f46d0420a695cf5d7e04d0899c81"
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, mmusic@ietf.org, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "&lt, rtcweb@ietf.org&gt, " <rtcweb@ietf.org>, "&lt, public-webrtc@w3.org&gt, " <public-webrtc@w3.org>
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 <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 01:29:29 -0000

If there is a way to make this happen, that would be good.  If not, then I
think the only realistic option available to rtcweb would be to drop
bundle, etc... That wouldn't be popular.
On Dec 10, 2012 5:19 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:

> I feel like the priorities here are kind of confused.
>
> It seems to me that the purpose of having a physical interim is to resolve
> issues that are hard to resolve on the list or teleconferences. As I
> mentioned
> earlier, the SDP issues are the most important to resolve now and have
> also proven to be among the most intractable. How does it make sense
> to try to resolve those at a "virtual" interim while having people fly
> to a "physical" interim for three days?
>
> I would strongly encourage the chairs to figure out how to have at least
> one of the days of this interim devoted solely to resolving the SDP
> issues (really, my preference would be to take these issues one at
> a time and do nothing else until they are resolved!). I'm not expert
> enough at the RAI WG mechanics to know what's required, so perhaps
> this requires making this also an MMUSIC interim or a mini-RAI interim,
> but if so that's what we should do, even if it means we need to reschedule
> or move it.
>
> Best,
> -Ekr
>
> On Mon, Dec 10, 2012 at 9:36 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
>> On Mon, Dec 10, 2012 at 5:16 AM, DRAGE, Keith (Keith) <
>> keith.drage@alcatel-lucent.com> wrote:
>>
>>> This is not just MMUSIC, there are bits of AVTCORE and AVTEXT
>>> responsibility in there as well.
>>>
>>> And I don't see how you can suddenly extend the interim of RTCWEB to the
>>> scope of other working groups, without even having a discussion with all
>>> the relevant chairs.
>>>
>>>
>> That's not how I read the overall sentiment--people are simply saying
>> that they need this work done and are willing to put in the effort to get
>> it done.  It would, in fact, be ideal if some of the MMUSIC questions were
>> resolve *before* an RTCWEB/WEBRTC interim, as we can then work through what
>> is decided.
>>
>> Put another way, I take it as encouragement to MMUSIC folks that they
>> would find a January virtual interim very well received/attended.
>>
>> Ted
>>
>>
>>
>>> I'd further note that Jonathan Lennox has an action (with the support of
>>> quite a number of other people) to produce an internet draft on trying to
>>> sort out the terminology concents that exist within RTP at the moment. This
>>> would be the basis for progressing a number of these issues. That would
>>> probably have to be an RAI wide draft.
>>>
>>> There has been some progress on this - maybe Jonathan can report on
>>> where this now is. I know he was waiting on volunteers for some of the
>>> sections and on input from others where volunteers already existed.
>>>
>>> Keith
>>>
>>> > -----Original Message-----
>>> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>>> Behalf
>>> > Of Cullen Jennings (fluffy)
>>> > Sent: 09 December 2012 00:20
>>> > To: Eric Rescorla
>>> > Cc: <rtcweb@ietf.org>; mmusic WG; <public-webrtc@w3.org>
>>> > Subject: Re: [MMUSIC] SDP work needed for WebRTC stuff
>>> >
>>> >
>>> > On Dec 8, 2012, at 4:21 PM, Eric Rescorla <ekr@rtfm.com> 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?
>>> >
>>> > So far the interim was only talking about being a WebRTC & RTCWeb so
>>> this
>>> > SDP stuff would be out of scope. Perhaps it would be better to have
>>> some
>>> > of the time for mmusic topics?
>>> >
>>> >
>>> > >
>>> > > 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
>>> > >
>>> > >
>>> >
>>> > _______________________________________________
>>> > mmusic mailing list
>>> > mmusic@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/mmusic
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>