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

Iñaki Baz Castillo <> Fri, 21 October 2011 10:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9126121F8B3A for <>; Fri, 21 Oct 2011 03:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.634
X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KrNxUU1zoRLu for <>; Fri, 21 Oct 2011 03:30:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E85B821F8B47 for <>; Fri, 21 Oct 2011 03:30:33 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so3832605vcb.31 for <>; Fri, 21 Oct 2011 03:30:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id et7mr13897097vdc.35.1319193033348; Fri, 21 Oct 2011 03:30:33 -0700 (PDT)
Received: by with HTTP; Fri, 21 Oct 2011 03:30:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 21 Oct 2011 12:30:33 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Tim Panton <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 10:30:34 -0000

2011/10/21 Tim Panton <>:
> 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.

Hi, indeed that is out of the scope of the document, but honestly I
imagine that the JS Media API (i.e. ROAP) could include some JS
functions/helpers. For example RTCweb.ROAP.parsePlainSDP(sdp), which
receives a plain SDP and returns a ROAP object or some standarized
JSON object the high-user can insepct in order to determine codecs and
so (low leves access).

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

That's a possible choice, right. Just don't mandate it please ;)

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

That depends on each scenario. For example, I use SIP over WebSocket.
The RTCweb is a pure SIP proxy that speaks SIP over UDP, TCP and
WebSocket. It *never* inspects the SDP (the "JS-Server Media
Signaling" in my document), and it MUST NOT do it. I prefer the
intelligence to be in the UA (the SIP stack in JavaScript, which is
the "JS Application API" in my document).


Iñaki Baz Castillo