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

Tim Panton <> Fri, 21 October 2011 09:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C47521F8BD3 for <>; Fri, 21 Oct 2011 02:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bXqaAyM97Rvi for <>; Fri, 21 Oct 2011 02:38:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A825E21F8B5A for <>; Fri, 21 Oct 2011 02:38:20 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTP id A76DE37A902; Fri, 21 Oct 2011 10:51:05 +0100 (BST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: Tim Panton <>
In-Reply-To: <>
Date: Fri, 21 Oct 2011 10:38:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Iñaki Baz Castillo <>
X-Mailer: Apple Mail (2.1251.1)
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 09:38:21 -0000

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.

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.

So in short, I think that treating the SDP-like as a blob has significant disadvantages.