Mon Feb 6 01:07:42 2023
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2017-02-01

LEARN

2023-02-06 | 2023-01-06 | 2022-12-06 | 2022-11-06 | 2022-10-06 | 2022-09-06 | 2022-08-06 | 2022-07-06 | 2022-06-06 | 2022-05-06 | 2022-04-06 | 2022-03-06 | 2022-02-06 | 2022-01-06 | 2021-12-06 | 2021-11-06 | 2021-10-06 | 2021-09-06 | 2021-08-06 | 2021-07-06 | 2021-06-06 | 2021-05-06 | 2021-04-06 | 2021-03-06 | 2021-02-06 | 2021-01-06 | 2020-12-06 | 2020-11-06 | 2020-10-06 | 2020-09-06 | 2020-08-06 | 2020-07-06 | 2020-06-06 | 2020-05-06 | 2020-04-06 | 2020-03-06 | 2020-02-06 | 2020-01-06 | 2019-12-06 | 2019-11-06 | 2019-10-06 | 2019-09-06 | 2019-08-06 | 2019-07-06 | 2019-06-06 | 2019-05-06 | 2019-04-06 | 2019-03-06 | 2019-02-06 | 2019-01-06 | 2018-12-06 | 2018-11-06 | 2018-10-06 | 2018-09-06 | 2018-08-06 | 2018-07-06 | 2018-06-06 | 2018-05-06 | 2018-04-06 | 2018-03-06 | 2018-02-06 | 2018-01-06 | 2017-12-06 | 2017-11-06 | 2017-10-06 | 2017-09-06 | 2017-08-06 | 2017-07-06 | 2017-06-06 | 2017-05-06 | 2017-04-06 | 2017-03-06 | 2017-02-06 | 2017-01-06 | 2016-12-06 | 2016-11-06 | 2016-10-06 | 2016-09-06 | 2016-08-06 | 2016-07-06 | 2016-06-06 | 2016-05-06 | 2016-04-06 | 2016-03-06 | 2016-02-06 | 2016-01-06 | 2015-12-06 | 2015-11-06 | 2015-10-06 | 2015-09-06 | 2015-08-06 | 2015-07-06 | 2015-06-06 | 2015-05-06 | 2015-04-06 | 2015-03-06 | 2015-02-06 | 2015-01-06 | 2014-12-06 | 2014-11-06 | 2014-10-06

Key: Value:

Key: Value:

MESSAGE
DATE 2017-02-11
FROM Ruben Safir
SUBJECT Subject: [Learn] WebRTC coding in html5
From learn-bounces-at-nylxs.com Sat Feb 11 19:02:26 2017
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: from www.mrbrklyn.com (www.mrbrklyn.com [96.57.23.82])
by mrbrklyn.com (Postfix) with ESMTP id 1566F16131E;
Sat, 11 Feb 2017 19:02:26 -0500 (EST)
X-Original-To: learn-at-nylxs.com
Delivered-To: learn-at-nylxs.com
Received: from [10.0.0.62] (flatbush.mrbrklyn.com [10.0.0.62])
by mrbrklyn.com (Postfix) with ESMTP id 9F114160E77;
Sat, 11 Feb 2017 19:02:20 -0500 (EST)
To: Hangout , "learn-at-nylxs.com"
From: Ruben Safir
Message-ID: <528bc14e-51d0-f6e2-a9e5-5d7edbfc8683-at-mrbrklyn.com>
Date: Sat, 11 Feb 2017 19:02:20 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.6.0
MIME-Version: 1.0
Subject: [Learn] WebRTC coding in html5
X-BeenThere: learn-at-nylxs.com
X-Mailman-Version: 2.1.17
Precedence: list
List-Id:
List-Unsubscribe: ,

List-Archive:
List-Post:
List-Help:
List-Subscribe: ,

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Errors-To: learn-bounces-at-nylxs.com
Sender: "Learn"

https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/


WebRTC enables peer to peer communication.

BUT...

WebRTC still needs servers:

For clients to exchange metadata to coordinate communication:
this is called signaling.
To cope with network address translators (NATs) and firewalls.

In this article we show you how to build a signaling service, and
how to deal with the quirks of real-world connectivity by using STUN and
TURN servers. We also explain how WebRTC apps can handle multi-party
calls and interact with services such as VoIP and PSTN (aka telephones).

If you're not familiar with the basics of WebRTC, we strongly
recommend you take a look at Getting Started With WebRTC before reading
this article.

What is signaling?

Signaling is the process of coordinating communication. In order for a
WebRTC application to set up a 'call', its clients need to exchange
information:

Session control messages used to open or close communication.
Error messages.
Media metadata such as codecs and codec settings, bandwidth and
media types.
Key data, used to establish secure connections.
Network data, such as a host's IP address and port as seen by the
outside world.

This signaling process needs a way for clients to pass messages back and
forth. That mechanism is not implemented by the WebRTC APIs: you need to
build it yourself. We describe below some ways to build a signaling
service. First, however, a little context...
Why is signaling not defined by WebRTC?

To avoid redundancy and to maximize compatibility with established
technologies, signaling methods and protocols are not specified by
WebRTC standards. This approach is outlined by JSEP, the JavaScript
Session Establishment Protocol:

The thinking behind WebRTC call setup has been to fully specify and
control the media plane, but to leave the signaling plane up to the
application as much as possible. The rationale is that different
applications may prefer to use different protocols, such as the existing
SIP or Jingle call signaling protocols, or something custom to the
particular application, perhaps for a novel use case. In this approach,
the key information that needs to be exchanged is the multimedia session
description, which specifies the necessary transport and media
configuration information necessary to establish the media plane.

JSEP's architecture also avoids a browser having to save state: that is,
to function as a signaling state machine. This would be problematic if,
for example, signaling data was lost each time a page was reloaded.
Instead, signaling state can be saved on a server.
JSEP architecture diagram
JSEP architecture

JSEP requires the exchange between peers of offer and answer: the media
metadata mentioned above. Offers and answers are communicated in Session
Description Protocol format (SDP), which look like this:

v=3D0
o=3D- 7614219274584779017 2 IN IP4 127.0.0.1
s=3D-
t=3D0 0
a=3Dgroup:BUNDLE audio video
a=3Dmsid-semantic: WMS
m=3Daudio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=3DIN IP4 0.0.0.0
a=3Drtcp:1 IN IP4 0.0.0.0
a=3Dice-ufrag:W2TGCZw2NZHuwlnf
a=3Dice-pwd:xdQEccP40E+P0L5qTyzDgfmW
a=3Dextmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=3Dmid:audio
a=3Drtcp-mux
a=3Dcrypto:1 AES_CM_128_HMAC_SHA1_80
inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe
a=3Drtpmap:111 opus/48000/2
=E2=80=A6

Want to know what all this SDP gobbledygook actually means? Take a look
at the IETF examples.

Bear in mind that WebRTC is designed so that the offer or answer can be
tweaked before being set as the local or remote description, by editing
the values in the SDP text. For example, the preferAudioCodec() function
in apprtc.appspot.com can be used to set the default codec and bitrate.
SDP is somewhat painful to manipulate with JavaScript, and there is
discussion about whether future versions of WebRTC should use JSON
instead, but there are some advantages to sticking with SDP.
RTCPeerConnection + signaling: offer, answer and candidate

RTCPeerConnection is the API used by WebRTC applications to create a
connection between peers and communicate audio and video.

To initialise this process RTCPeerConnection has two tasks:

Ascertain local media conditions, such as resolution and codec
capabilities. This is the metadata used for the offer and answer mechanism.
Get potential network addresses for the application's host, known as
candidates.

Once this local data has been ascertained, it must be exchanged via a
signaling mechanism with the remote peer.

Imagine Alice is trying to call Eve. Here's the full offer/answer
mechanism in all its gory detail:

Alice creates an RTCPeerConnection object.
Alice creates an offer (an SDP session description) with the
RTCPeerConnection createOffer() method.
Alice calls setLocalDescription() with his offer.

Alice stringifies the offer and uses a signaling mechanism to send
it to Eve.
Eve calls setRemoteDescription() with Alice's offer, so that her
RTCPeerConnection knows about Alice's setup.
Eve calls createAnswer(), and the success callback for this is
passed a local session description: Eve's answer.
Eve sets her answer as the local description by calling
setLocalDescription().
Eve then uses the signaling mechanism to send her stringified answer
back to Alice.

Alice sets Eve's answer as the remote session description using
setRemoteDescription().


-- =

So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
_______________________________________________
Learn mailing list
Learn-at-nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/learn

  1. 2017-02-02 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] NP Complete
  2. 2017-02-06 Wayne Callahan <callahans2-at-msn.com> Subject: [Learn] [dinosaur] ISPH 2017
  3. 2017-02-07 James E Keenan <jkeen-at-verizon.net> Subject: [Learn] ny.pm tech meeting next Monday; TPC call for presentations
  4. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Immigration Executive Order Update
  5. 2017-02-08 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] Immigration Executive Order Update
  6. 2017-02-08 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Justine Bateman
  7. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] Does this look like a Euler Path to you?
  8. 2017-02-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] Does this look like a Euler Path to you?
  9. 2017-02-09 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] Does this look like a Euler Path to you?
  10. 2017-02-09 Christopher League <league-at-contrapunctus.net> Re: [Learn] Does this look like a Euler Path to you?
  11. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] =?utf-8?q?Fwd=3A_An_Evening_for_Educators_with_Dr=2E_B?=
  12. 2017-02-09 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Does this look like a Euler Path to you?
  13. 2017-02-10 Ruben Safir <ruben.safir-at-my.liu.edu> Re: [Learn] Choosing a programming language
  14. 2017-02-10 Christopher League <league-at-contrapunctus.net> Subject: [Learn] Choosing a programming language
  15. 2017-02-10 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Alternatives to Syntax Trees
  16. 2017-02-10 ruben safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: Compiler positions available for week ending January 29
  17. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [Accu-contacts] Software engineer position
  18. 2017-02-10 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Fwd: [dinosaur] Euchambersia (Therapsida) envenoming
  19. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] lions and tigers and snow leopards
  20. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] New Neuronet theory
  21. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Researchers use artificial neural network to simulate a
  22. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Robotics
  23. 2017-02-11 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] WebRTC coding in html5
  24. 2017-02-12 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] fellowship positition
  25. 2017-02-15 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Starting with R
  26. 2017-02-15 Rick Moen <rick-at-linuxmafia.com> Subject: [Learn] [conspire] [svlug] AnC side-channel attack: In which ASLR
  27. 2017-02-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [Learn] are you here
  28. 2017-02-16 ruben <ruben-at-mrbrklyn.com> Subject: [Learn] chew on this
  29. 2017-02-16 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] ct scan
  30. 2017-02-16 Christopher League <league-at-contrapunctus.net> Subject: [Learn] Should I name "makefile" or "Makefile"?
  31. 2017-02-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] overloading operator== and casting
  32. 2017-02-20 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Vector Documentation
  33. 2017-02-22 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Network Patterns
  34. 2017-02-24 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] decision making tree for a euler walk
  35. 2017-02-24 Christopher League <league-at-contrapunctus.net> Re: [Learn] decision making tree for a euler walk
  36. 2017-02-24 Christopher League <league-at-contrapunctus.net> Re: [Learn] decision making tree for a euler walk
  37. 2017-02-24 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] decision making tree for a euler walk
  38. 2017-02-27 Ruben Safir <ruben-at-mrbrklyn.com> Subject: [Learn] Computational Phylogenies and fossil scanning
  39. 2017-02-28 Christopher League <league-at-contrapunctus.net> Re: [Learn] decision making tree for a euler walk
  40. 2017-02-28 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] decision making tree for a euler walk
  41. 2017-02-28 Nicholas Rodin <nikbbwil-at-icloud.com> Re: [Learn] thesis update
  42. 2017-02-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [Learn] thesis update
  43. 2017-02-28 Don Brinkman <Don.Brinkman-at-gov.ab.ca> Re: [Learn] visit
  44. 2017-02-28 Ruben Safir <ruben-at-mrbrklyn.com> Re: [Learn] [Hangout-NYLXS] Peer Review

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!