Re: [rtcweb] The meaning of SDP_PRANSWER

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