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 4A4141A01FB for ; Wed, 19 Feb 2014 10:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] 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 gtvBqklhSzI7 for ; Wed, 19 Feb 2014 10:12:41 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 697FB1A00B8 for ; Wed, 19 Feb 2014 10:12:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C38847C4E7E; Wed, 19 Feb 2014 19:12:37 +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 axJHRHL5QWfQ; Wed, 19 Feb 2014 19:12:37 +0100 (CET) Received: from [172.19.7.58] (unknown [216.239.45.90]) by mork.alvestrand.no (Postfix) with ESMTPSA id B8B817C4E63; Wed, 19 Feb 2014 19:12:36 +0100 (CET) Message-ID: <5304F413.1080208@alvestrand.no> Date: Wed, 19 Feb 2014 19:12:35 +0100 From: Harald Alvestrand 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 , "rtcweb@ietf.org" References: <52FDC17E.8070708@alvestrand.no>, <52FE5B37.80409@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1735EE@ESESSMB209.ericsson.se>, <5303EE53.1010405@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1A9B80@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040605080800050804080900" Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/C7xifZ2d6YYq6sP5hxCSjUkdhz8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:12:43 -0000 This is a multi-part message in MIME format. --------------040605080800050804080900 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit 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' > *Sent:* żWednesdayż, żFebruaryż ż19ż, ż2014 ż1ż:ż35ż żAM > *To:* Hans-Christer Holmberg , > 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. --------------040605080800050804080900 Content-Type: text/html; charset=windows-1256 Content-Transfer-Encoding: 8bit
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'
Sent: żWednesdayż, żFebruaryż ż19ż, ż2014 ż1ż:ż35ż żAM
To: Hans-Christer Holmberg, 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.
--------------040605080800050804080900--