Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications)

Harald Alvestrand <> Fri, 21 October 2011 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17E1021F8AEC for <>; Fri, 21 Oct 2011 04:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2QKaYYuEv3VN for <>; Fri, 21 Oct 2011 04:20:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A8F0621F8AE1 for <>; Fri, 21 Oct 2011 04:20:46 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F323139E08B for <>; Fri, 21 Oct 2011 13:20:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGC-Z90w7kd9 for <>; Fri, 21 Oct 2011 13:20:45 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id 4FBBD39E088 for <>; Fri, 21 Oct 2011 13:20:45 +0200 (CEST)
Message-ID: <>
Date: Fri, 21 Oct 2011 13:20:47 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Summary of Signaling Components in RTCweb (clarifications)
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: Fri, 21 Oct 2011 11:21:00 -0000

On 10/21/2011 11:38 AM, Tim Panton wrote:
> On 21 Oct 2011, at 09:26, Iñaki Baz Castillo wrote:
>> 2011/10/19 Iñaki Baz Castillo<>:
>>> Hi all,
>>> I've tryed to identify all the signaling components of a RTCweb
>>> communication ir order to identify each "signaling fragment" in all
>>> the path. There are various connotations for the "signaling" keyword
>>> in RTCweb and IMHO they are generating confusion.
>>> I've exposed it into the following URL:
>> Hi, I've made some changes to the document:
> Thanks for putting the time into the document and updates, it
> is very useful.
> It does highlight one area that I think is problematic , you say:
> "JS-Server Media Signaling (in-the-wire): This means carrying SDP (or like-SDP) bodies. In contrast to the JS-Server Routing Signaling this information MAY be treated as "blob" by the RTCweb server, by leaving it to pass verbatim to the destination of the message (which is indicated in the JS-Server Routing Signaling)."
> Which is right, the RTCWebserver could treat the the media and network info as blobs.
> The local JS Application however can't.
> It needs to know things that are in that SDP in order to render the application for the user.
> Examples include -
> 	is it a video or audio stream?
> 	is DTMF available (i.e. should it render a keypad) ?
> 	What is the screen size of the video?
> To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore.
Well..... maybe not.

When negotiation is done, there will be onstreamadd() callbacks 
informing one about the added streams; these will have clear indications 
on whether they are audio, video or both.

When the video is available, I suspect that there will have to be an 
interface that allows one to tell the resolution of the video; I don't 
know if this is available from the <video> object it's presumably 
connected to, or needs to be available through APIs on a 
MediaStreamTrack. (The video may also be resized after the connection's 

I don't have any idea what the APIs for DTMF are going to be; perhaps 
people will call SendDTMF("") (empty string) and see if it throws an 
exception; this may be simpler than detecting all 3 (or more?) ways of 
showing support for DTMF in SDP.

This theme can be carried further .... sometimes we can learn things by 
snooping on signalling; at other times, we may learn them by looking at 
the objects that results from the signalling. What is best in each 
situation? I don't know, and doubt that there is a single answer.
> What's more there is are examples where the server should be able to understand the JS-Server Media Signaling.
> I'm thinking of the simplest use-case, peer to peer calls within a single website. As I mentioned in an earlier email,
> the server can be told what the respective browsers support, and then make a determination of what the intersection of codecs is and then inform the browser's JSapp to use that. This has advantages in simplicity and
> lack of risk of deadlocks, retries, glare etc.
It is also functionally equivalent to the browsers all sending a ROAP 
OFFER to the server, and the server constructing a ROAP ANSWER according 
to its understanding of the intersection.

If we were not using ROAP, we would have to represent the codec sets and 
ICE candidates in some other form, and the server would still have to 
have the same understanding of the properties of the codecs in order to 
perform the intersection operation.
> So in short, I think that treating the SDP-like as a blob has significant disadvantages.
A point on which we agree .... Yes, I also think we need to have the 
ability to open the blob at the point that makes sense for the 
application - whether that's in the browser, the JS, the server, or 
somewhere else.