W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

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

From: Justin Uberti <juberti@google.com>
Date: Thu, 16 Feb 2012 21:17:07 -0500
Message-ID: <CAOJ7v-2p86UMOynWEYNKqmRtm0y1J0XM5r4fEUR4_mhD1zRcnQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Feb 15, 2012 at 5:47 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
>          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.

> 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.

> 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.

I still need to review the other thread; there may be other ways of
handling this, but this seemed like the simplest to me.

> Regards,
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
Received on Friday, 17 February 2012 02:17:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC