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

Saúl Ibarra Corretgé <> Fri, 21 October 2011 09:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2384D21F8B63 for <>; Fri, 21 Oct 2011 02:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jTcOAnRazsj7 for <>; Fri, 21 Oct 2011 02:50:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 68F9921F8B4F for <>; Fri, 21 Oct 2011 02:50:16 -0700 (PDT)
Received: by (Postfix, from userid 5001) id 65606B01B5; Fri, 21 Oct 2011 11:50:15 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 8D6BAB01A0; Fri, 21 Oct 2011 11:50:14 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Saúl Ibarra Corretgé <>
In-Reply-To: <>
Date: Fri, 21 Oct 2011 11:50:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Tim Panton <>
X-Mailer: Apple Mail (2.1084)
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:50:17 -0000

Hi Tim,

> 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.

Assuming this SDP-like thing is ROAP, for example, an API could be produced for this purpose. If one wants low level access it ma extract the blob and parse it himself.

> 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.

Notice the MAY ;-) 

Saúl Ibarra Corretgé
AG Projects