Subject: [rtcweb] The meaning of SDP_PRANSWER

From: "Henry Lum" <[email-masked]>
Date: Mon, 16 Apr 2012 08:52:56 -0700

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

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Apr 2012 23:02:11 -0400

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 <[email-masked]>wrote:

>  It’s unclear to me what the purpose of SDP_PRANSWER is really for and
> processing ICE candidates so I don’t see a need to have provisional
> answers. ****
>
> ** **
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 25 Apr 2012 08:52:44 -0700

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:[email-masked]] 
Sent: April-23-12 11:02 PM
To: Henry Lum
Cc: [email-masked]
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 <[email-masked]> 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