[rtcweb] Provisional answers in JSEP draft

["Rauschenbach, Uwe (NSN - DE/Munich)" <[e-mail]>]

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