Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F181A027A for ; Sun, 18 May 2014 20:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymYnTwl6r_7g for ; Sun, 18 May 2014 20:38:05 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A08C1A0271 for ; Sun, 18 May 2014 20:38:05 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jz11so5722399veb.7 for ; Sun, 18 May 2014 20:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dkzV6EV0rsj4a1dOWvvFGfUGwl/QFrc8Ge8YQ+Am3UY=; b=kmzAqmEZB79XYFVZleOJyLo4eK2Fd2Ubv3DAH5Yuasyi4Yb1WtxhbSkwNqwCwkDx+W zbQGEYShb6l0V1il5MI8MboeVnlnENj1LLlv1rn5u81QEQiPGMS2yqaLmM8yxEAuEDL3 2JSYVFOyv63TVDzwcNQ1MSK9iceHqSYhBsgZnCoMN1ivkqyYwQo/+LbLEwN6OJ9DBnbs Kcgw2qBoYYrNeN4XgXg68B3gDeFGGiTCoWm66dODIsuRVYjNTJLyUR4zPEMAFCS37jeF a1xtrRkUg75dkckRzkaT5waCTJ+9HczW70RZpXbfpjNDofLP02jRpIfS/QLtuE/bj99i OPyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dkzV6EV0rsj4a1dOWvvFGfUGwl/QFrc8Ge8YQ+Am3UY=; b=AG/9KZ4DQKnj7BCNt+K1puVTiTqK3O/5EgAOFm2wVkfAso+R1S61KYxZtfmEoU7uPK Tioqr80k4a6mbK5JNyWRn9ratT3f4RFsjY1MeNrfRGEhPWydqtpXiFtlcA5cDFLPaXR1 0v8OcveRYjQqNzVsG0Cgeji9lFO3Wcb4OB1iqRVKQTXtoQPu05l2hJTJL+iYBrgyRdN2 ugvt93BlmLwSyURzTl4+0KVNWJG/GzRDQvB1zSKYEOjjEiokfGGTYY7Em/WBKOQ9WIHs WoEQO1JYkyCZqwDMDRJFyAnOUZn8DkKa7kpWSOytRrnOApSJ5t71cgKWJN7VM/5EvbCu wtTw== X-Gm-Message-State: ALoCoQnVlA0qqk28w90e0JpA2YoOwq1TWchT+1fTZL3XHx5vzVIpzk42Mo14FJxMQP5ysoemi0Bx X-Received: by 10.220.163.3 with SMTP id y3mr12031652vcx.7.1400470684864; Sun, 18 May 2014 20:38:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.145.105 with HTTP; Sun, 18 May 2014 20:37:44 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B1D2F672A@ESESSMB209.ericsson.se> From: Justin Uberti Date: Sun, 18 May 2014 20:37:44 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1133da66b0b0b004f9b87d20 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gmxwLLDfDbWqAzw28b4vaG8zAXU Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [rtcweb] [MMUSIC] m-line recycling X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 19 May 2014 03:38:08 -0000 --001a1133da66b0b0b004f9b87d20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One option could be to only reuse m=3D lines that both sides have stopped using (i.e. port=3D0, as opposed to a=3Dsendonly/recvonly). This provides m= ost of the benefits of recycling without having to deal with the notion of 'compatible'. On Mon, May 12, 2014 at 7:43 AM, Martin Thomson w= rote: > Yes, some words about being compatible and all that entails are required > if we intend to stipulate it being reused. Either that or we can say MAY. > The need for a strong definition diminishes then. > On May 11, 2014 11:54 PM, "Christer Holmberg" < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> I don=E2=80=99t think it should be a MUST =E2=80=93 at least not only ba= sed on the media >> type. Because, there may be other properties than the media type associa= ted >> with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it fo= r the specific MST. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Eric >> Rescorla >> *Sent:* 12. toukokuuta 2014 7:50 >> *To:* mmusic WG; rtcweb@ietf.org >> *Subject:* [MMUSIC] m-line recycling >> >> >> >> The JSEP spec specifies m-line recycling: >> >> >> >> >> >> >> >> o If any MediaStreamTracks have been added, and there exist m=3D >> >> sections of the appropriate media type with no associated >> >> MediaStreamTracks (i.e. as described in the preceding paragraph), >> >> those m=3D sections MUST be recycled by adding the new >> >> MediaStreamTrack to the m=3D section. This is done by adding the >> >> necessary "a=3Dmsid", "a=3Dssrc", and "a=3Dssrc-group" lines to th= e >> >> recycled m=3D section, and removing the "a=3Drecvonly" attribute. >> >> Based on the minutes from IETF 89, we were going to take this to mmusic. >> >> http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-rtcweb?useMonospaceF= ont=3Dtrue >> >> >> >> >> Thoughts? >> >> -Ekr >> >> >> >> https://github.com/rtcweb-wg/jsep/issues/21 >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1133da66b0b0b004f9b87d20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One option could be to only reuse m=3D lines that both sid= es have stopped using (i.e. port=3D0, as opposed to a=3Dsendonly/recvonly).= This provides most of the benefits of recycling without having to deal wit= h the notion of 'compatible'.


On Mon, May 1= 2, 2014 at 7:43 AM, Martin Thomson <martin.thomson@gmail.com>= ; wrote:

Yes, some words about being c= ompatible and all that entails are required if we intend to stipulate it be= ing reused. Either that or we can say MAY. The need for a strong definition= diminishes then.

On May 11, 2014 11:54 PM,= "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:

Hi,<= /p>

=C2=A0

I don=E2=80=99t think it = should be a MUST =E2=80=93 at least not only based on the media type. Becau= se, there may be other properties than the media type associated with the =E2=80=9Cm=3D=E2=80=9D line, why one does not want to use it for the speci= fic MST.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

From: mmusic [= mailto:mmusic-= bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 12. toukokuuta 2014 7:50
To: mmusic WG; = rtcweb@ietf.org
Subject: [MMUSIC] m-line recycling

=C2=A0

The JSEP spec specifies m-line recycling:=

=C2=A0

=C2=A0
=C2=A0
 o=C2=A0 If any MediaStreamTracks have been added, and there exi=
st m=3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sections of the appropriate media=
 type with no associated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTracks (i.e. as descri=
bed in the preceding paragraph),
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 those m=3D sections MUST be recyc=
led by adding the new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MediaStreamTrack to the m=3D sect=
ion.=C2=A0 This is done by adding the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 necessary "a=3Dmsid", &=
quot;a=3Dssrc", and "a=3Dssrc-group" lines to the<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 recycled m=3D section, and removi=
ng the "a=3Drecvonly" attribute.
Based=C2=A0o=
n the minutes from IETF 89, we were going to take this to mmusic.=

http://etherpad.tools.ietf.org:9000/p/notes-ietf=
-89-rtcweb?useMonospaceFont=3Dtrue




=C2=A0
Thoughts?<=
u>
-Ekr

=C2=A0


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb


_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic


--001a1133da66b0b0b004f9b87d20--