IETF Logo Mail Archive

Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted

Harald Alvestrand <harald@alvestrand.no> Tue, 18 February 2014 23:36 UTC

Return-Path: <harald@alvestrand.no>
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 EB2AC1A02BB for <rtcweb@ietfa.amsl.com>; Tue, 18 Feb 2014 15:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.344
X-Spam-Level:
X-Spam-Status: No, score=0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793] autolearn=no
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 iI5aux8GySFf for <rtcweb@ietfa.amsl.com>; Tue, 18 Feb 2014 15:35:57 -0800 (PST)
Received: from mork.alvestrand.no (unknown [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39E1A0470 for <rtcweb@ietf.org>; Tue, 18 Feb 2014 15:35:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8FBB17C4BC5; Wed, 19 Feb 2014 00:35:50 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITB0WV5phnDn; Wed, 19 Feb 2014 00:35:50 +0100 (CET)
Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id 68F5E7C4BAC; Wed, 19 Feb 2014 00:35:49 +0100 (CET)
Message-ID: <5303EE53.1010405@alvestrand.no>
Date: Wed, 19 Feb 2014 00:35:47 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9LWj3fTdZAwej255jkpFLLb4pyA
Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Feb 2014 23:36:02 -0000

One thing I did not add in my previous reply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to
be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald

v2.23.0 | Report a Bug | By Email