Re: [rtcweb] JSEP-01: SDP_PRANSWER and FEDEX use-case

On Fri, Feb 17, 2012 at 3:33 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

>
> Hi,
>
> >>      Section 6.1.4 of jsep-01 says:
> >>
> >>              "SDP_PRANSWER indicates that a description should be
> parsed as an
> >>               answer, but not a final answer, and so should not result
> in the
> >>               starting of media transmission. A description used as a
> SDP_PRANSWER
> >>               may be applied as a response to a SDP_OFFER, or an update
> to a
> >>               previously sent SDP_PRANSWER."
> >>
> >>
> >>      Section 7.6 shows a SIP early media (FEDEX) use-case, where an SDP
> answer received in a SIP 18x response is provided to the browser as a
> SDP_PRANSWER.
> >>
> >>
> >>      Q1: Since SDP_PRANSWER is not supposed to start media
> transmission, how will the use-case work? As far as I know, media
> transmission is needed for the FEDEX use-case.
> >
> >
> > I think this is just me being unclear. When I say "start media
> transmission", I mean that when the browser gets a SDP_PRANSWER
> > in response to an offer, the browser will not start transmitting media.
> However, it will play out any media that is received
> > after the offer is installed, and the gateway can start sending media at
> any time after it gets the offer.
>
> Again, you could achieve that using SDP_ANSWER and a direction attribute
> (a=recvonly). I don't think we need SDP_PRANSWER for unidirectional media
> purpose.
>
> (And, as was mentioned, there may actually be a need to also transmit
> media for the FEDEX case)
>
>
> >> Q2: The draft doesn't really specify what SDP_PRANSWER is used for. I
> understand that it means that a "final" answer
> >> may be provided later, but it doesn't really say what the a browser
> would do with an SDP_PRANSWER - especially since
> >> it doesn't seem to enable media.
> >
> >
> > SDP_PRANSWER allows, among other things, the callee's ICE and SRTP info
> to be provided so that early media can
> > be received by the caller. I think it should make more sense given my
> answer to #1.
>
> As I replied to #1, I don't think we need SDP_PRANSWER to establish
> unidirectional media, so I would like to know what those "other things" are
> :)
>
>
> >> Q3: Assuming we would allow multiple SDP_ANSWER (see separate thread),
> is there a need for SDP_PRANSWER?
> >
> >
> > SDP_PRANSWER has slightly different semantics in that it is not intended
> to indicate consent by the callee, whereas SDP_ANSWER does.
>
> What does the browser do with that information?
>
> My understanding was that the browser is going to use media plane
> mechanisms (e.g. ICE) for callee consent.
>

When I say "consent" here, I mean the user has given permission to start
transmitting their media (i.e., "answered the call"). This is distinct from
the ICE-level "sending media to the right place" mechanisms.

Anyway, I went and looked at sendonly/recvonly/inactive handling and I
think I understand what you are suggesting. Let me see if I can distill
this into some rules:
- createOffer/Answer generates a=sendrecv offers/answers by default.
- Installing an a=sendonly/sendrecv description as an answer (via
setLocalDescription or setRemoteDescription) causes the browser to start
sending media from attached streams.
- Installing an a=recvonly/sendrecv description as an answer (via
setLocalDescription or setRemoteDescription) causes the browser to start
playing out received media.
- Multiple answers can be received; the most recent answer is the one that
is used.

Which allow for these scenarios:
- If an application wants to send an early response, but not start
sending/receving media (i.e. it is simply for faster call setup), it can
create, apply, and send an a=inactive answer.
- When that application sends its final response, indicating it wants to
send/receive media, it can apply/send an a=sendrecv answer.
- In the 1-800-FEDEX case, the answer received from 1-800-FEDEX may be a
"early response", but from the perspective of JSEP, it is a typical answer
with a=sendrecv.

Does this sound right to you? If so, I agree we can probably do away with
PRANSWER, unless others see something that we're overlooking.