IETF Logo Mail Archive

Re: [MMUSIC] What is an m-line?

Martin Thomson <martin.thomson@gmail.com> Thu, 16 May 2013 17:12 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 7EE3321F8AD5 for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 10:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGQTVPYY-wfq for <mmusic@ietfa.amsl.com>; Thu, 16 May 2013 10:12:08 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id C736421F8AA8 for <mmusic@ietf.org>; Thu, 16 May 2013 10:12:07 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id b13so2809659wgh.6 for <mmusic@ietf.org>; Thu, 16 May 2013 10:12:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=DaCkUO2YK57QXg4wzL2mOFSS8/5jck5oPPo7TLdqLA4=; b=MjjRjiBjAAS5WdlMIVI0Qis4KUSUJIGXFZpi+bmBFRIxRHFWjbUYjWhvo1gS275Y8m rv5V9Ei10N3FajqPogyiTvr8AuhZmFwnmwpnslL3k5AMt0xX8bG9VPOtydksYKLc0z8U ApcEcJ7GpxLJQdMlUDLWGKf492VXLO8a5NHQli2P3c4ce1LOvL2XwUENqLyt5iKFO0kx efR9DNB07/fvk1JAO53gGTdScrqvRq1L+gvEnkDo8dMag05H0nilgi0GLksIIYAjprq5 6jTADJSkuEsHgSKP0z2sLoVem9V1aREJztYrBSDdEVkQs9EWtsYqGQGFPvlO+KMvCZ91 fUOQ==
MIME-Version: 1.0
X-Received: by 10.180.20.148 with SMTP id n20mr26329801wie.8.1368724326930; Thu, 16 May 2013 10:12:06 -0700 (PDT)
Received: by 10.194.20.135 with HTTP; Thu, 16 May 2013 10:12:06 -0700 (PDT)
In-Reply-To: <51950CED.6020305@jitsi.org>
References: <CABkgnnWPWMLEecfqksGJrWrqvsu44gts48igUiLyiVV0iPhwQQ@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1134E782F@xmb-aln-x02.cisco.com> <5193B1DB.2070308@alum.mit.edu> <1922EE35-127D-459C-AC7A-D2E98A0CDBA0@csperkins.org> <BLU169-W119163BAE68316B331EE12193A20@phx.gbl> <5193EA5C.7050905@alvestrand.no> <BLU169-W743682718AEA906C0F3C2A93A20@phx.gbl> <CABkgnnULK4Af+G4sg8Nnsa27v8wtB3fF3Ei2=x9Q7vDf+5Ak9Q@mail.gmail.com> <51950CED.6020305@jitsi.org>
Date: Thu, 16 May 2013 10:12:06 -0700
Message-ID: <CABkgnnUiWZnbC1vbs2qAUOB-HEr-CQYynS4wrzwpMFA5PB=Q3Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Emil Ivov <emcho@jitsi.org>
Content-Type: text/plain; charset="UTF-8"
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] What is an m-line?
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: Thu, 16 May 2013 17:12:08 -0000

On 16 May 2013 09:44, Emil Ivov <emcho@jitsi.org> wrote:
>> I think that is a perfectly pragmatic conclusion to reach.  However,
>> it still leaves the issue open.  I'd like to at least reach a point
>> where there is agreement on just one model for interpreting the SDP
>> that is output and input to the WebRTC API.
>
> If we agree that basing design decisions on legacy devices and their
> view of what an m= line is (or rather isn't). Then is there any reason
> not to accept the RTP-centric description of an m= line that Colin
> described?

Yes, it might be premature.  I'm not sure that we've explored all of
the implications of that statement.  For instance, no one has even
discussed call transfer scenarios yet.  We haven't explored the
consequences of SSRC collision.

We have to agree that the model we use actually fits the sorts of
things that need to fit.

v2.23.0 | Report a Bug | By Email