Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)

Matthew Kaufman <matthew.kaufman@skype.net> Fri, 02 November 2012 18:31 UTC

From: Matthew Kaufman <matthew.kaufman@skype.net>
To: "Dale R. Worley" <worley@ariadne.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
Thread-Index: AQHNuRJLzVnrRqz+kEerz/qLVogJ7pfW3JiQ
Date: Fri, 02 Nov 2012 18:30:52 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A484160FFB04@tk5ex14mbxc272.redmond.corp.microsoft.com>
References: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> (trac+rtcweb@grenache.tools.ietf.org) <201211021552.qA2Fq8l1207997@shell01.TheWorld.com>
In-Reply-To: <201211021552.qA2Fq8l1207997@shell01.TheWorld.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
Precedence: list

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Dale R. Worley
> Sent: Friday, November 2, 2012 3:52 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
> 
> > #3: JSEP-02 Review (from Andy Hutton)
> >
> >  6. Section 4.2. Session Descriptions and State Machine states:
> >
> >  "Lastly, while the exact media parameters are only known only after a
> > offer and an answer have been exchanged, it is possible for the
> > offerer to  receive media after they have sent an offer and before
> > they have received  an answer. To properly process incoming media in
> > this case, the offerer's  media handler must be aware of the details
> > of the offerer before the  answer arrives."
> >
> >  I don't see the relevance of the statement "it is possible for the
> > offerer  to receive media after they have sent an offer and before
> > they have  received an answer". Why is the purpose of this statement?
> 
> Unless one is familiar with how offer/answer works in SIP, one might easily
> assume that media can only be sent after the offer/answer cycle is complete.

And if one *is* familiar with how offer/answer works in SIP, one might easily assume that media can be successfully received and played out by the offering side if the answering side were to send some before sending an answer. An assumption which often holds in SIP but which I believe cannot hold in RTCWEB. While you can create the unidirectional *sending* MediaStreams and hook them up, there is no way for the receive MediaStreams to "pop out" of the RTCPeerConnection prior to an answer (provisional or final) being received, and thus no way to "hook up" the video and audio tags in advance of those RTP packets potentially arriving from the answering side.

> >  14. Section 5.2.3 SessionDescriptionType
> >
> >  ""pranswer" indicates that a description should be parsed as an
> > answer,  but not a final answer, and so should not result in the freeing of
> >  allocated resources.  It may result in the start of media   transmission,
> >  if the answer does not specify an inactive media direction".
> 
> Do we have any need for "pranswer"?

Standard Answer #22 applies.

Matthew Kaufman

[rtcweb] #3: JSEP-02 Review (from Andy Hutton) rtcweb issue tracker
Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) Dale R. Worley
Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) Matthew Kaufman
Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) Stefan Håkansson LK
Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton) Martin Thomson