[rtcweb] Provisional answers in JSEP draft

"Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com> Sun, 03 November 2013 23:11 UTC

Return-Path: <uwe.rauschenbach@nsn.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C8821E8127 for <rtcweb@ietfa.amsl.com>; Sun, 3 Nov 2013 15:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkRxi-pt9MQl for <rtcweb@ietfa.amsl.com>; Sun, 3 Nov 2013 15:11:46 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3461921E8126 for <rtcweb@ietf.org>; Sun, 3 Nov 2013 15:11:32 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA3NBRMJ008194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Nov 2013 00:11:27 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA3NBQfF030040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Nov 2013 00:11:26 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Nov 2013 00:11:26 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 00:11:26 +0100
From: "Rauschenbach, Uwe (NSN - DE/Munich)" <uwe.rauschenbach@nsn.com>
To: "fluffy@iii.ca" <fluffy@iii.ca>, ext Justin Uberti <juberti@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Provisional answers in JSEP draft
Thread-Index: Ac7YvPftdbBA+IsbQWCmW52pP7Z6Ww==
Date: Sun, 3 Nov 2013 23:11:25 +0000
Message-ID: <56C2F665D49E0341B9DF5938005ACDF813E01D@DEMUMBX005.nsn-intra.net>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.124]
Content-Type: multipart/alternative; boundary="_000_56C2F665D49E0341B9DF5938005ACDF813E01DDEMUMBX005nsnintr_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 10196
X-purgate-ID: 151667::1383520287-00005753-D7EC8993/0-0/0-0
Subject: [rtcweb] Provisional answers in JSEP draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2013 23:11:52 -0000

Hi,

I have some questions regarding section 4.1.3.1 (Use of Provisional Answers) in the JSEP-05 draft.

The text reads as follows:

 4.1.3.1 Use of Provisional Answers

Most web applications will not need to create answers using the
"pranswer" type. The preferred handling for a web application would
be to create and send an "inactive" answer more or less immediately
after receiving the offer, instead of waiting for a human user to
physically answer the call. Later, when the human input is received,
the application can create a new "sendrecv" offer to update the
previous offer/answer pair and start the media flow. This approach
is preferred because it minimizes the amount of time that the offer/answer
exchange is left open, in addition to avoiding media clipping
by ensuring the transport is ready to go by the time the call is
physically answered. However, some applications may not be able to
do this, particularly ones that are attempting to gateway to other
signaling protocols. In these cases, "pranswer" can still allow the
application to warm up the transport.

Consider a typical web application that will set up a data channel,
an audio channel, and a video channel. When an endpoint receives an
offer with these channels, it could send an answer accepting the data
channel for two-way data, and accepting the audio and video tracks as
inactive or receive-only. It could then ask the user to accept the
call, acquire the local media streams, and send a new offer to the
remote side moving the audio and video to be two-way media. By the
time the human has accepted the call and sent the new offer, it is
likely that the ICE and DTLS handshaking for all the channels will
already be set up.


I have two questions:

1) What is meant here by "the offer-answer exchange is left open"? In another place in the document, it is stated that in fact pranswer is like any answer except that resources (I assume from previous pranswers) are not freed until the final answer arrives. So, what's the actual drawback here? Is there a performance penalty? This should be stated more clearly.

2) I do not understand why "pranswer" supposedly leads to media clipping but "answer" does not. AFAIU, if the pranswer from the callee contains sendrecv media sections, ICE runs immediately after the pranswer has been installed in the caller's browser, and media pathes are set up both ways without delay. If, as recommended above, the callee sends a recvonly answer first, ICE will initially only create a media path for the direction from the caller to the callee, and then create a media path in the other direction after the new offer from the callee has been received by the caller's application. So there may be clipping in the path from the callee to the caller. This conflicts with what is stated in the text. Do I overlook something? Does the text need an update?


Kind regards,
Uwe