Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope

Iñaki Baz Castillo <> Tue, 18 October 2011 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACACD21F84B0 for <>; Tue, 18 Oct 2011 03:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.629
X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, 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 pNHy6UNpF8H5 for <>; Tue, 18 Oct 2011 03:36:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A408421F87E2 for <>; Tue, 18 Oct 2011 03:36:17 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so422991vcb.31 for <>; Tue, 18 Oct 2011 03:36:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a11mr1746172vdg.1.1318934177121; Tue, 18 Oct 2011 03:36:17 -0700 (PDT)
Received: by with HTTP; Tue, 18 Oct 2011 03:36:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 18 Oct 2011 12:36:17 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Christer Holmberg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Rosenberg <>, "" <>, "" <>
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - Scope
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: Tue, 18 Oct 2011 10:36:19 -0000

2011/10/18 Christer Holmberg <>:
>>No, this is not a draft about a "default signaling protocol"
>>for RTCweb. Wrong. This is just a protocol for communication
>>between the JavaScript code and the RTCweb stack in the
>>browser. It does NOT mandate how the signaling messages are
>>sent on-the-wire.
> Eventhough the draft does not suggest a default signaling protocol, I don't think that is completely true that it is only between the JS app and broswer. At least it's not very clear.
> - Section 5.1 says: "ROAP messages are typically carried over a **reliable transport** (likely HTTP via XMLHttpRequest or WebSockets),..."

Yes, that is because JavaScript code running in a browser can only
communicate via HTTP or WebSocket.

> - Section 5.3.3 defines an "OK" message, which is used to cease **re-transmissions** of the ANSWER.

I expect that is a "guideline" for the signaling protocol implementor.
There is no need for such "OK" message to be received from the peer or
server. The own JS code could generate it when appropriate and pass it
to its RTCweb stack.

> - In addition, there is text talking about **ROAP signaling messages** (and gateways translating between those and SIP messages).

That just means that, of course, ROAP must be carried within some
signaling protocol (obvious) so, in case of interoperating with a SIP
network a gateway is required (unless you use SIP over WebSocket).

> So, while I support and offer/answer based approach, I think we need to get a clearer understanding of the scope.

IMHO "ROAP" draft just suggests a generic signaling guidelines for
future RTCweb protocol developers. It does define the communication
between the JS code and its own RTCweb stack, but not the signaling
on-the-wire (for that guidelines are provided).


Iñaki Baz Castillo