Re: [rtcweb] Additional requirement - audio-only communication

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 26 August 2011 15:03 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1E521F8745 for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 08:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.319
X-Spam-Level:
X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 ah2FxixtycFe for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 08:03:56 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9427621F84ED for <rtcweb@ietf.org>; Fri, 26 Aug 2011 08:03:56 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-ad-4e57b6285c72
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6D.8A.02839.826B75E4; Fri, 26 Aug 2011 17:05:12 +0200 (CEST)
Received: from ESESSCMS0362.eemea.ericsson.se ([169.254.1.112]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 26 Aug 2011 17:05:12 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Justin Uberti <juberti@google.com>
Date: Fri, 26 Aug 2011 17:05:11 +0200
Thread-Topic: [rtcweb] Additional requirement - audio-only communication
Thread-Index: AcxkAGMKe8g0/VPPR8SmiScQAFpDGwAABZes
Message-ID: <BBF498F2D030E84AB1179E24D1AC41D61C1BCA8047@ESESSCMS0362.eemea.ericsson.se>
References: <4E539A1F.109@alvestrand.no> <4E53B80C.20304@ericsson.com> <4E53E0C8.6010304@alvestrand.no> <BBF498F2D030E84AB1179E24D1AC41D61C1BCA7F62@ESESSCMS0362.eemea.ericsson.se> <4E54ADC7.8030407@jesup.org> <4E54CC05.1040705@alvestrand.no> <4E54CE29.2060605@ericsson.com> <4E54D867.4060706@alvestrand.no> <4E54D9C2.6000205@ericsson.com> <4E54DE8E.9080207@alvestrand.no> <4E54DFCF.4000805@ericsson.com> <4E54E24F.7060906@alvestrand.no> <4E56707B.104@skype.net> <4E567737.6020101@jesup.org> <4E5680B0.6070702@skype.net> <CAOJ7v-0DnVKYD2gd4os3R-LuzN1mu4qZqjndDEJcJXwY7U-FnA@mail.gmail.com> <4E56E264.8000600@mozilla.com> <CAOJ7v-2kEByX3mq7dRFuo7wEqaEGz597aWuFpEZK9zE_eS6U4A@mail.gmail.com> <4E5747E7.2050605@ericsson.com> <CAOJ7v-1ccLPZhqCDW0ngFkm23TeDSLjNCMUJj-k7wwdg+tTnhg@mail.gmail.com> <4E57AC5C.1020406@ericsson.com>, <CAOJ7v-1r5stCamNxgMZg9M0sNqB_aKz6T9H2JgDjQwYXBuEFgQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-1r5stCamNxgMZg9M0sNqB_aKz6T9H2JgDjQwYXBuEFgQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Additional requirement - audio-only communication
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 26 Aug 2011 15:03:57 -0000

On 2011-08-26, Justin Uberti wrote:

>How will this work if it is not the same web app in both peers, i.e. an interop scenario? Clearly if it is the same app we can pass along whatever meta-info we want to instruct the remote side on what to do.
I agree that this specific case would not work without defining some kind protocol. Then, on the other hand, do all 'advanced' features have to be supported also in interop? Perhaps "you get what you send" or "you get audio and video (unless the user at the sending side opts out of one component)" is OK in interop cases. I guess we need to discuss this.

Br,
Stefan