W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Alternative to the offer/answer mechanism

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 20 Jun 2013 16:45:54 -0700
Message-ID: <CABkgnnXGdLHvefuTy9foYaWYK_NWApXdVXg7+co7tBGtDrgnbA@mail.gmail.com>
To: "piranna@gmail.com" <piranna@gmail.com>
Cc: public-webrtc <public-webrtc@w3.org>
On 20 June 2013 14:57, piranna@gmail.com <piranna@gmail.com> wrote:
>> navigator.getUserMedia({ audio: true }, function(media) {
>>     var track = media.audioTracks[0];
>>     var description = new RealtimeMediaDescription(track);
>>     var localRtStream = new LocalRealtimeMediaStream(track, description,
>> realtimeTransport);
>>     signalingChannel.send(description.toDictionary());
>> });
>>
> On CU-WebRTC, would this allow to stablish the connection, or you
> would need to send back the remote peer description (the "answer" on
> WebRTC)? I hope no, or we would be on almost the same situation...

That piece of code:
 - acquires local media,
 - generates a default description of that media,
 - attaches it to an *existing* transport (established in other parts
of the code), and
 - sends the description to the peer via signaling so that the peer
can play out the stream.

As a result of attaching the media to the transport, packets begin
flowing.  This example does not require any permission from the peer,
other than the consent ICE establishes for packet transmission.
Received on Thursday, 20 June 2013 23:46:21 UTC

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