Re: [rtcweb] The meaning of SDP_PRANSWER

"Henry Lum" <Henry.Lum@genesyslab.com> Wed, 25 April 2012 15:52 UTC

Return-Path: <Henry.Lum@genesyslab.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 5A59D21F875B for <rtcweb@ietfa.amsl.com>; Wed, 25 Apr 2012 08:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.298
X-Spam-Level:
X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Fc2xsk1EBSx2 for <rtcweb@ietfa.amsl.com>; Wed, 25 Apr 2012 08:52:48 -0700 (PDT)
Received: from relay-out1.dc.genesyslab.com (relay-out1.dc.genesyslab.com [198.49.180.220]) by ietfa.amsl.com (Postfix) with ESMTP id A340A21F86D9 for <rtcweb@ietf.org>; Wed, 25 Apr 2012 08:52:48 -0700 (PDT)
Received: from g2.genesyslab.com (g2.genesyslab.com [192.168.20.138]) by relay-out1.dc.genesyslab.com (8.13.8+Sun/8.13.8) with ESMTP id q3PFqlQP019696; Wed, 25 Apr 2012 08:52:47 -0700 (PDT)
Received: from NAHALD.us.int.genesyslab.com ([192.168.20.92]) by g2.genesyslab.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 08:52:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD22FB.75BC4A84"
Date: Wed, 25 Apr 2012 08:52:44 -0700
Message-ID: <059AF07365DC474393A19A3AF187DF74086DF8D0@NAHALD.us.int.genesyslab.com>
In-Reply-To: <CAOJ7v-0tCX7=VzCkXLy+camY7RPsFqYxrW+UM_+Q0xxJCm5iHw@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] The meaning of SDP_PRANSWER
Thread-Index: Ac0hxrHpCXnr83/kSDukNrwKE03C7gBMQ3Ow
References: <059AF07365DC474393A19A3AF187DF74086657DB@NAHALD.us.int.genesyslab.com> <CAOJ7v-0tCX7=VzCkXLy+camY7RPsFqYxrW+UM_+Q0xxJCm5iHw@mail.gmail.com>
From: "Henry Lum" <Henry.Lum@genesyslab.com>
To: "Justin Uberti" <juberti@google.com>
X-OriginalArrivalTime: 25 Apr 2012 15:52:47.0102 (UTC) FILETIME=[75BC41E0:01CD22FB]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The meaning of SDP_PRANSWER
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: Wed, 25 Apr 2012 15:52:49 -0000

You mentioned that the final answer can be on a different endpoint, does that mean you have to process ICE on both PRANSWER and ANSWER? It’s unclear to me how you can change the endpoint from PRANSWER to ANSWER for ICE negotiation. Does the offerer expects to receive new candidates and calls pc.processIceMessage on the new endpoint?

 

Thanks

Henry

 

From: Justin Uberti [mailto:juberti@google.com] 
Sent: April-23-12 11:02 PM
To: Henry Lum
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] The meaning of SDP_PRANSWER

 

It's needed to indicate to the offerer that the answer is not final; any resources associated with the offer should not yet be released.

 

One example where this may be useful is when using RTCP mux; the initial answer may indicate that mux is to be used, but the final answer may come from a different endpoint and choose not to use mux. Using SDP_PRANSWER allows the offerer to honor the second answer, since the RTCP transport is not discarded by the first answer.

On Mon, Apr 16, 2012 at 11:52 AM, Henry Lum <Henry.Lum@genesyslab.com> wrote:

It’s unclear to me what the purpose of SDP_PRANSWER is really for and why it needs to be there. Originally I thought it was meant for early media, but section 6.1.4 paragraph 3 says that it should not result in starting of media transmission. Is there a reason to provide an answer before media is ready to be transmitted? There are separate handles for processing ICE candidates so I don’t see a need to have provisional answers. 

 

I am not proposing PRANSWER for handling early media though, since I believe early media is more of an application level issue (it’s more like late-billing on the application side) and should be considered as a separate offer/answer if needed.

 

Regards,

Henry 


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb