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

Iñaki Baz Castillo <> Sat, 15 October 2011 09:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19E3D21F849E for <>; Sat, 15 Oct 2011 02:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.101, 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 3gkqNtZxElSE for <>; Sat, 15 Oct 2011 02:20:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B33D21F8482 for <>; Sat, 15 Oct 2011 02:20:42 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so1901806vcb.31 for <>; Sat, 15 Oct 2011 02:20:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id e2mr12322964vdj.52.1318670441614; Sat, 15 Oct 2011 02:20:41 -0700 (PDT)
Received: by with HTTP; Sat, 15 Oct 2011 02:20:41 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sat, 15 Oct 2011 11:20:41 +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] 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: Sat, 15 Oct 2011 09:20:43 -0000

2011/10/15 Cullen Jennings <>:
> Jonathan and I submitted a new draft on setting up media based on the SDP Offer/Answer model. The ASCII flows are a bit hard to read so until I update them, I recommend reading the PDF version at
> Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.

Hi, thanks for this work. IMHO this is clearly the way to go, and the
proposal that could make everyone happy. Let me just a comment:

5.3.3.  OK
The OK message is used by the receiver of an ANSWER message to
indicate that it has received the ANSWER message. It has no contents
itself and is merely used to stop the retransmissions of the ANSWER

I wonder how much needed is the OK message taking into account that
the transport will always be reliable. So, instead of retransmiting
the ANSWER until an OK arrives, why not retransmit the OFFER until an
ANSWER arrives and drop the OK message from the spec?

Probably I miss something here as in the case the offered wants to
signal ringing (a 180 in SIP) it conveys no media so there would be no
ANSWER message for long time until the offered human user decides to
accept or reject the incoming call. If so, please forget this comment


Iñaki Baz Castillo