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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 20 February 2014 20:31 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 5F65C1A0281 for <rtcweb@ietfa.amsl.com>; Thu, 20 Feb 2014 12:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 xTSCb8TkqtYf for <rtcweb@ietfa.amsl.com>; Thu, 20 Feb 2014 12:31:31 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id E02C31A0283 for <rtcweb@ietf.org>; Thu, 20 Feb 2014 12:31:27 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-99-5306661b2874
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 15.DC.23809.B1666035; Thu, 20 Feb 2014 21:31:23 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 20 Feb 2014 21:31:23 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Harald Alvestrand' <harald@alvestrand.no>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted
Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1SABo2kgIAAovSRgACVFICAADzpYoAAKnyAgAFieno=
Date: Thu, 20 Feb 2014 20:31:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1ACAA5@ESESSMB209.ericsson.se>
References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se>, <5304F413.1080208@alvestrand.no> <pi22myx9puvcw80lbn1s1ktu.1392843033581@email.android.com>, <53054ACF.6030601@alvestrand.no>
In-Reply-To: <53054ACF.6030601@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1ACAA5ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvja50GluwwcQpUhbH+rrYLNb+a2d3 YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJWzG5jKnjvX3G5axdjA+Nply5GTg4JAROJ 00unskPYYhIX7q1nA7GFBA4xSpxYa9TFyAVkL2GUaNraBlTEwcEmYCHR/U8bxBQRCJVYtFIb pFxYwEHi3qGpzCC2iICjxJyty5kg7CSJi4fOMoLYLAKqEnfeTQYbzyvgK7Fp/RI2iPGfmSRm rf0O1swpoCvx8d1yFhCbEeie76fWgA1iFhCXuPVkPhPEnQISS/acZ4awRSVePv7HClGTL/Hv /zFGiAWCEidnPmGZwCg8C0n7LCRls5CUQcQNJL68vw1la0ssW/iaGcLWl+h+f5oJWXwBI/sq RvbcxMyc9HKjTYzACDm45bfqDsY750QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8 iJGJg1OqgbHBTZnRuNDl1ALXqAMK96+vPLfy/nZl/WBR9iDxjGNiPqdyAuc1r5x7YE3a8ipm 4x07r5VeX2xlHFr/VCTA+J9Z+8Tzh6W27/p7fVfIi6JXvI0s6yf3tYWGqFlYfypen3J12hMZ oZNRvvr+7yWPzi/1a/t6WfaNg+DqJNYSy0vne2KW1qadmajEUpyRaKjFXFScCACU8gKZXgIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/4t_GJYlmHR7Kllvvau9pjb_yAbk
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: Thu, 20 Feb 2014 20:31:34 -0000

Hi,

My suggestion was to omit something else. But, at the moment I don’t have the drafts in front of me, so I can’t suggest anything specific.

Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'<mailto:harald@alvestrand.no>
Sent: ‎Thursday‎, ‎February‎ ‎20‎, ‎2014 ‎2‎:‎22‎ ‎AM
To: Hans-Christer Holmberg<mailto:christer.holmberg@ericsson.com>, rtcweb@ietf.org<mailto:rtcweb@ietf.org>

On 02/19/2014 09:50 PM, Christer Holmberg wrote:

Hi,

If the indication is NOT permanent, can't we use the existing direction attributes (sendrecv, sendonly etc)?


We could - but how would we then indicate "permanent"?

Omitting the direction attribute means the same as "sendrecv", if I'm not mistaken. So you can't have meant omitting that.

So what were you suggesting?



Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Harald Alvestrand <harald@alvestrand.no><mailto:harald@alvestrand.no> wrote:



On 02/19/2014 09:19 AM, Christer Holmberg wrote:
Hi,

If the indication is “permanent”, rather than using a new msid-control attribute, could it be indicated by NOT including some information in the Answer?

Certainly, but then you have to include some information in the answer when the indication is not permanent.

Which information were you thinking of utilizing as a signal?



Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'<mailto:harald@alvestrand.no>
Sent: ‎Wednesday‎, ‎February‎ ‎19‎, ‎2014 ‎1‎:‎35‎ ‎AM
To: Hans-Christer Holmberg<mailto:christer.holmberg@ericsson.com>, rtcweb@ietf.org<mailto:rtcweb@ietf.org>

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




--
Surveillance is pervasive. Go Dark.




--
Surveillance is pervasive. Go Dark.