Re: [rtcweb] Why SDP answer needs and ack … was Re: SDP Offer/Answer draft-jennings-rtcweb-signaling

Iñaki Baz Castillo <> Tue, 18 October 2011 19:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 562F921F8DCA for <>; Tue, 18 Oct 2011 12:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JsXvR6of9FVt for <>; Tue, 18 Oct 2011 12:44:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CC0F21F8DBA for <>; Tue, 18 Oct 2011 12:44:07 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1044122vcb.31 for <>; Tue, 18 Oct 2011 12:44:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a11mr4096809vdg.1.1318967046614; Tue, 18 Oct 2011 12:44:06 -0700 (PDT)
Received: by with HTTP; Tue, 18 Oct 2011 12:44:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 18 Oct 2011 21:44:06 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Cullen Jennings <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Rosenberg <>,,
Subject: Re: [rtcweb] Why SDP answer needs and ack … was Re: SDP Offer/Answer draft-jennings-rtcweb-signaling
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 19:44:08 -0000

2011/10/18 Cullen Jennings <>:
> Hi - glad to hear you see this going the right direction. On the topic of why we have an OK, let me provide a bit of the motivation.
> When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send things or user interface that provides feedback about the status of the other side. We are also dealing with a web transaction model where transaction are not guarantee to happen even if they are sent over TCP. So you need to get back a response to request. It also helps with mapping to SIP but even if you were not mapping to another protocol, I suspect you would still need to be able to have an confirmation than and answer was received.

Hi Cullen. Let me put an example:

- alice: JS client implementing pure SIP over WebSocket.
- A proxy implementing SIP over UDP and WebSocket.
- bob: SIP UDP client.

The flows:

- alice sends INVITE to bob with an empty body (no SDP).
- bob replies a 200 with the SDP offer.
- alice receives the 200. Its JS code internally generates a ROAP Offer.
- alice generates a ROAP Answer and inserts its SDP into an ACK to be
sent to bob.
- In SIP we have ended. So how is supposed alice will receive the ROAP
OK message?

I don't understand yet if such ROAP OK message is mandatory to be sent
to the RTCweb stack. If so, the JS code in alice could auto-generate
it after sending the ACK, so the RTCweb stack becomes happy. But
obviously the advantage of such auto-generated ROAP OK is null.


Iñaki Baz Castillo