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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sat, 03 November 2012 13:54 UTC

Message-ID: <50952214.4030409@ericsson.com>
Date: Sat, 03 Nov 2012 14:54:28 +0100
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <066.b5060d6f1c778a37ddaaeadfa120da84@trac.tools.ietf.org> (trac+rtcweb@grenache.tools.ietf.org) <201211021552.qA2Fq8l1207997@shell01.TheWorld.com> <AE1A6B5FD507DC4FB3C5166F3A05A484160FFB04@tk5ex14mbxc272.redmond.corp.microsoft.com>
In-Reply-To: <AE1A6B5FD507DC4FB3C5166F3A05A484160FFB04@tk5ex14mbxc272.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
Precedence: list

On 2012-11-02 19:30, Matthew Kaufman wrote:
>> -----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.

I have the same understanding. But I have also been told that the DTLS 
handshake cannot complete until the answer is provided to the offering 
side RTCPeerConnection, so the media could anyway not be decoded before 
the answer is available. I might have gotten this wrong though.

[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