[on-asterisk] WebRTC talk

[Simon Ditner]

Anyone interested in hearing about WebRTC, the new future of telephony? If
so, what aspects of it?



Simon P. Ditner <si...@uc.org>

http://www.facebook.com/spditner
http://www.linkedin.com/in/spditner

[Nabeel Jafferali]

I just watched a demo of WebRTC put on by another team within the company I
work for, and it seems pretty slick and seamless. The demo was, though,
showing the user side only.

I'd love to see more of the tech side, how it's coded, how it tunnels to
the server, overcomes NAT, etc.

--
Nabeel Jafferali

[Philip Mullis]

Perhaps a WebRTC workshop?
I can provide virtual servers for this if needed.

[James Knott]

On 05/08/2015 10:50 AM, Nabeel Jafferali wrote:
> I'd love to see more of the tech side, how it's coded, how it tunnels to
> the server, overcomes NAT, etc.

IIRC, the connection is initially set up with the server and then the 2
ends then talk directly over the established connection

---------------------------------------------------------------------
To unsubscribe, e-mail: asterisk-u...@uc.org
For additional commands, e-mail: asteri...@uc.org

[Ian Darwin]

On 2015-05-08 11:58, James Knott wrote:
> On 05/08/2015 10:50 AM, Nabeel Jafferali wrote:
>> I'd love to see more of the tech side, how it's coded, how it tunnels to
>> the server, overcomes NAT, etc.
> IIRC, the connection is initially set up with the server and then the 2
> ends then talk directly over the established connection
>
>

Sounds about right. https://en.wikipedia.org/wiki/WebRTC

The WP article says it usually does signal establishment via WebSocket,
which starts on port HTTP
and then uses an HTTP upgrade
(https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header)
to run the actual communication.

[Simon Ditner]

It is surprisingly old school when doing video and audio. You pass SDP over
a signalling channel, which is most commonly SIP over WebRTC (I kid you
not!) or XMPP over WebRTC. There are some newer standards like ORTC, which
apparently has more awesome and less cruft.

The major difference though is that the WebRTC standard mandates support
for SRTP for encrypted audio and ICE for NAT busting, so you are not
dealing with clients that do not have NAT traversal capabilities.

In the 'guaranteed to work' scenario, two clients would talk to a 3rd party
service handling peer discovery -- like a typical SIP server, or
Jabber/XMPP server -- and a TURN server (which is also a superset of STUN)
to assist in ICE negotiation and offer RTP relay in the event that the two
peers can't establish an RTP channel directly between themselves.

Note there that WebRTC does not solve the problem of peer discovery, that's
left to existing technology like SIP and XMPP, or decentralized peer
discovery techniques like DHT's (distributed hash table).

So despite this fancy new connection technology, we are still left with
islands of clients with no universal way to discover each other, and
generally rely on centrally controlled peer discovery services for that
discovery.

Closing points:
- I can talk ad nauseam about any of these pieces, and it's applications.
Ask more questions!
- Any particular workshop topics you'd like covered?

Simon P. Ditner <si...@uc.org>

http://www.facebook.com/spditner
http://www.linkedin.com/in/spditner

[James Knott]

On 05/17/2015 09:54 PM, Simon Ditner wrote:
> and a TURN server (which is also a superset of STUN)
> to assist in ICE negotiation and offer RTP relay in the event that the two
> peers can't establish an RTP channel directly between themselves.

Don't you just love all the crap sticking with IPv4 forces us to use!
With IPv6 many of those problems disappear.

[Simon Ditner]

What do you see disappearing with IPv6?

Two reasons I see it staying as it is are that we would still have
firewalls to contend with in a pure IPv6 world, and multiple interfaces
with addresses on a single client is now common rather than exceptional
(i.e. a cellphone with Bluetooth, Wifi, and LTE, all having IPv6
addresses). So we would still need ICE for address candidate selection, and
in the case of aggressive firewalls, need a TURN server for RTP relay.

Cheers,
spd

Simon P. Ditner <si...@uc.org>

http://www.facebook.com/spditner
http://www.linkedin.com/in/spditner

On Sun, May 17, 2015 at 10:00 PM, James Knott <james...@rogers.com>
wrote:

[James Knott]

On 05/17/2015 10:25 PM, Simon Ditner wrote:
> What do you see disappearing with IPv6?

STUN etc. are necessary due to NAT. The purpose of STUN is to let the
other end know the real "public" address of the device, which can only
know the local NAT address. No NAT, no need to work around it.
Firewall rules will still have to be configured appropriately, but that
has nothing to do with NAT, STUN etc. With SIP, there a "server" or
gateway that a device is associated with. When A calls B, A's gateway
calls B's. The call is negotiated and the gateway then drops off,
leaving the devices to communicate directly. NAT breaks that because
the 2 devices do not know the real address of the other. To fix it, we
need STUN etc. So, with IPv6, no NAT needed due to more than sufficient
addresses available and no NAT means no STUN.