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

Stefan Håkansson LK <> Sat, 27 August 2011 04:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C794021F87C9 for <>; Fri, 26 Aug 2011 21:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.319
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7H8lut3rj8B6 for <>; Fri, 26 Aug 2011 21:49:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C0DA21F8557 for <>; Fri, 26 Aug 2011 21:49:20 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-df-4e58779d817e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FC.45.02839.D97785E4; Sat, 27 Aug 2011 06:50:37 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Sat, 27 Aug 2011 06:50:37 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
To: Randell Jesup <>, "" <>
Date: Sat, 27 Aug 2011 06:50:36 +0200
Thread-Topic: [rtcweb] Additional requirement - audio-only communication
Thread-Index: AcxkKLuw9oq+NNlRRam1uqB7CiAdiAASZxfY
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [rtcweb] Additional requirement - audio-only communication
X-Mailman-Version: 2.1.12
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: Sat, 27 Aug 2011 04:49:21 -0000

Randell wrote:
>Stefan wrote
>>Justing wrote
>>> Maybe I misunderstand, but it sounds like with these fields you are
>>> defining a new signaling protocol, which I think we want to avoid.
>> That's not how I see it. It is the same web app in both peers, and
>> they can communicate inbetween them in any way the app developer see
>> fit (using e.g. XHR via the web server). There is already a need for a
>> mechanism to pass the SDPs between the browsers, and that mechanism
>> could be used to pass other data.
>> So no new protocol needed!
>This is a new (application-specific) protocol. 

At least it is an application specific way to exchange information.

> It may be a simple one,
>but it is one, overlaid on top of the SDP saying "ignore this part of
>the SDP" effectively.  

I don't think it says anything along those lines. What the extra info says is what A expects B to set up. The SDP o/a initiated by A (caller) deals _only_ with the stream(s) flowing from A to B, it contains no info about what B should send to A (and then there is no need to say anything like "ignore part of SDP").

>As mentioned, you then have more problems when
>two different domains/apps want to talk to each other.  

Yes, that is right. Another problem Harald pointed out in another thread was the mapping to RTP sessions.

For the record, I'm not trying to say that the current API proposal is the final one that should not be changed. I think discussions will show that there will be a need to make adjustments and enhancements to it. I'm just trying to show how you could/would solve things with the current API proposal (as there seem to be some misconceptions).