One-way data channel -- is this possible?

[Feross Aboukhadijeh]

Is it possible to do a one-way data channel? My constraint is that Peer A has Peer B's session description, but Peer B cannot get Peer A's session description. Is it possible for Peer A to send data to Peer B, or vice versa?

Thanks,

Feross

[Vikas]

I am not sure if i quite understood the description below, but do you want to setup one-way data channel only, something like we do in dc1 demo?

/Vikas

[Feross Aboukhadijeh]

No, that example doesn't quite do what I want. What I want to happen is this:

- Peer 1 creates a session description S1 and sends it to a signaling server

- Peer 2 arrives later and asks the signaling server to send it S1.

- Peer 2 uses S1 to connect to Peer 1.

- Now, Peer 2 can send (but not receive) data to Peer 1. Hence a "one way" connection.

Note: Peer 2 *never* generates an answer offer in this example. This is useful for a project I'm working on where the signaling server can't forward offer answers to particular peers because I'm lacking the ability to "push" data to peers.

Is this "one way" data channel a supported use case?

Feross

feross.org | studynotes.org | peercdn.com

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Philipp Hancke]

I'd say no, because ICE requires the Peer1 to know Peer 2's ice-ufrag and ice-pwd values. It gets harder when you take the whole NAT issue into account.

[Max Jonas Werner]

Feross,

On 16.10.2013 07:23, Feross Aboukhadijeh wrote:
> No, that example doesn't quite do what I want. What I want to happen is
> this:
>
> - Peer 1 creates a session description S1 and sends it to a signaling server
> - Peer 2 arrives later and asks the signaling server to send it S1.
> - Peer 2 uses S1 to connect to Peer 1.
> - Now, Peer 2 can send (but not receive) data to Peer 1. Hence a "one way"
> connection.

This will not work with current implementations.

> Note: Peer 2 *never* generates an answer offer in this example. This is
> useful for a project I'm working on where the signaling server can't
> forward offer answers to particular peers because I'm lacking the ability
> to "push" data to peers.

I suspect with "answer offer" you actually mean "answer SDP". What I
find interesting in this use case is this: Couldn't Peer 2 use the offer
packet it has from Peer 1 to connect to Peer 2 and send its answer
through a "half-open" WebRTC connection? I mean, Peer 2 already knows
how to reach Peer 1 from its SDP. What would hinder a WebRTC impl. to
act like this?

Max

[Harald Alvestrand]

Feross, what you're asking is impossible the way the system is designed.

It's designed so that Peer 1 has to have some reassurance that the packets coming from Peer 2 are coming from someone he wants to associate with - the way that's done is that Peer 1 has the ICE password used by Peer 2 before packets from Peer 1 start arriving.

The concept of "connecting" involves packets travelling in both directions - whether you send data in one direction or in both direcctions doesn't really matter; packets still have to go in both directions.

[Feross Aboukhadijeh]

> It's designed so that Peer 1 has to have some reassurance that the packets coming from Peer 2 are coming from someone he wants to associate with

This guarantee isn't necessary for many valid use cases. For lots of applications, it's perfectly fine to connect first and then decide whether you're interested in maintaining communication with a particular peer. If you're not interested in talking to a certain peer, simply kill the connection.

Feross

[Feross Aboukhadijeh]

For example, in the BitTorrent DHT protocol peers "listen" for incoming connections and connect to anyone who sends a message to them. The initial incoming message contains some information that helps the receiving peer decide if he's interested in continuing to talk with this peer. If not, he kills the connection. But if he is interested, then he could use the SDP from the sending peer (which could be included in the incoming message) to connect.

This is valuable because it would enable several really cool use cases like BitTorrent in the browser, among other things. Specifically, if a peer wants to receive connections from ANY other peer in a network, it could generate dozens of SDPs and post them to a central directory so anyone who's interested can grab one and use it to connect. This has one really nice property for the signaling server. It no longer needs to keep an open connection to every peer since it doesn't need to push SDPs down to clients. This makes scaling the signaling server a lot easier. And makes building distributed systems a lot easier.

Feross

[Philipp Hancke]

On Wed, Oct 16, 2013 at 9:52 AM, Harald Alvestrand <h...@google.com> wrote:

Feross, what you're asking is impossible the way the system is designed.

It's designed so that Peer 1 has to have some reassurance that the packets coming from Peer 2 are coming from someone he wants to associate with - the way that's done is that Peer 1 has the ICE password used by Peer 2 before packets from Peer 1 start arriving.

Well, peer1 might hint peer2 which ice-ufrag and pwd to use. Assumes those are configurable, which is stated by JSEP.

While taking load from the signalling server, this would put more load on STUN and TURN servers to keep the NAT bindings alive. Which in the long run violates the "the internet must survive" rule.

Feross: let's talk about this in Portland :-)

[Max Jonas Werner]

On 16.10.2013 10:38, Feross Aboukhadijeh wrote:
> For example, in the BitTorrent DHT protocol peers "listen" for incoming
> connections and connect to anyone who sends a message to them. The initial
> incoming message contains some information that helps the receiving peer
> decide if he's interested in continuing to talk with this peer.

You can do that already today with WebRTC as long as you have some way
of receiving offers from other peers and sending back answers. You can
do this via some central signaling channel (WebSocket, XMPP, snail mail,
...) or use already established connections for that. We're doing the
latter in our application where we form a P2P network of WebRTC peers
and send offers/answers through this network. No signaling server needed.

> This is valuable because it would enable several really cool use cases like
> BitTorrent in the browser, among other things. Specifically, if a peer
> wants to receive connections from ANY other peer in a network, it could
> generate dozens of SDPs and post them to a central directory so anyone
> who's interested can grab one and use it to connect.

With Offer/Answer you'd just do it the other way round.

Max

[Silvia Pfeiffer]

I think you'd do that via the signalling channel rather than the PeerConnection.
Silvia.

[Feross Aboukhadijeh]

Silvia:

> I think you'd do that via the signalling channel rather than the PeerConnection.

To be clear, I understand how to connect 2 peers the normal way with a signaling server (I built https://peercdn.com)

I was asking about "one way" or "half open" data channels because (if they work) they would enable a bunch of new use cases for WebRTC. It would also help me optimize peerCDN by reducing the number of roundtrips I need to get a connection going, thereby reducing latency.

Feross

[Feross Aboukhadijeh]

Philipp:

> Well, peer1 might hint peer2 which ice-ufrag and pwd to use.

That is a neat idea. This actually might work then?

> this would put more load on STUN and TURN servers

This is actually not so bad. STUN servers are really easy to scale, since they're all interchangable (scale horizontally). Scaling a signaling server that needs to maintain open websockets with every peer is much harder and *way* more expensive.

Max:

> we form a P2P network of WebRTC peers and send offers/answers through this network. No signaling server needed.

This is actually what I'm planning to do. It's a really neat idea. It's cool that it's actually working for you in production. What are you using it on?

Feross

[Max Jonas Werner]

On 16.10.2013 11:19, Feross Aboukhadijeh wrote:

> Max:
>> we form a P2P network of WebRTC peers and send offers/answers through
> this network. No signaling server needed.
>
> This is actually what I'm planning to do. It's a really neat idea. It's
> cool that it's actually working for you in production. What are you using
> it on?

Have a look at https://github.com/boplish/core. The code there still
depends on sending O/A through the signaling channel for simplicity's
sake but we already have tested router code that routes O/A through the
network and we're actually currently implementing a DHT to replace the
full mesh. The PC doesn't care where the SDP came from.

Max

[Philipp Hancke]

On Wed, Oct 16, 2013 at 11:19 AM, Feross Aboukhadijeh <fer...@feross.org> wrote:

Philipp:

> Well, peer1 might hint peer2 which ice-ufrag and pwd to use.

That is a neat idea. This actually might work then?

Surprisingly it does even work out of the box. You can test using the munge file provided by brave @ https://code.google.com/p/webrtc/issues/detail?id=2507#c3

Replace the ice-ufrag and ice-pwd with something of your choice between CreateAnswer and SetAnswer

 

> this would put more load on STUN and TURN servers

This is actually not so bad. STUN servers are really easy to scale, since they're all interchangable (scale horizontally). Scaling a signaling server that needs to maintain open websockets with every peer is much harder and *way* more expensive.

Scalable signalling servers are a solved problem, not worth risking the wrath of the IETF's grey beards.

[Feross Aboukhadijeh]

A few more thoughts:

If it's possible to do a "half open" or "one way" datachannel, it should be trivial to upgrade it to a full two-way datachannel after that. So a better term would be "one way initiated" datachannel.

> Scalable signalling servers are a solved problem

Really? Scaling websockets has been nontrivial for me and I've heard similar things from others as well. What do you use?

> not worth risking the wrath of the IETF's grey beards

Why would the IETF care? Even 100x more STUN traffic wouldn't affect the internet at all.

Right now every web developer has to do their own signaling which is moderately hard and everyone keeps reinventing the wheel by building their own solution. If one could offload all the signaling to a DHT, then you could just use Google's STUN server and avoid thinking about signaling at all, which would be great for a certain class of application.

Philipp: Looking forward to talking more in Portland.

Feross

--

[Jesús Leganés Combarro]

What I
find interesting in this use case is this: Couldn't Peer 2 use the offer
packet it has from Peer 1 to connect to Peer 2 and send its answer
through a "half-open" WebRTC connection? I mean, Peer 2 already knows
how to reach Peer 1 from its SDP. What would hinder a WebRTC impl. to
act like this?

 

I did this some months ago for my DataChannel polyfill because I though they worked this way (Peer2 use the Peer1 SDP connection data to send its SDP, so Peer1 could connect back with Peer2 and later promote the connection to work on the DataChannel protocol) but they told me it was not possible, so I deprecated the idea. Anyway, doing this would be great, you'll only need one side connection info to create the connection, and looking at the API of ORTC, it seems it's proposed to work this way... :-)

[Jesús Leganés Combarro]

If one could offload all the signaling to a DHT, then you could just use Google's STUN server and avoid thinking about signaling at all, which would be great for a certain class of application.

Could this be possible? Is it possible (with current standards) for a browser to directly connect to that DHT? How could this be done? What's happens with the initial bootstrapping to the DHT? I'm interested on this things and investigating about them for my proyect (http://webp2p.io & http://shareit.es) 

[Martin Naumann]

Sorry for popping into a pretty old conversation, but I'm interested in this, too and I wonder if there's anything like this available.

My use case is sort of a "remote control" scenario, where I have a device like a Chromecast attached to a beamer and want to connect to an audience without having to have a "back channel" - and I want that to work without any particular signalling server and I won't need NAT traversal as all clients are spatially close and one the same network.

I can't run a websocket server on the Chromecast but I can create a PeerConnection and transport the offer one way (e.g. displaying a QR code)... my problem is that I don't seem to have a way to get the answer back to the Chromecast, except I'd have a signaling server running somewhere on the network to do this, but that seems like an uneccessary requirement here; the offer contains candidates to use to connect, so why do I have to get the answer back? Can't the other peer just try to connect to one of the candidates and that's it?

Thanks for patience with my edge case scenario and cheers,

Martin

[Benjamin Schwartz]

On Sun, Nov 9, 2014 at 12:18 AM, Martin Naumann <mr....@gmail.com> wrote:

the offer contains candidates to use to connect, so why do I have to get the answer back? Can't the other peer just try to connect to one of the candidates and that's it?

WebRTC requires that the parties be cryptographically identified to each other through a secure channel.  A PeerConnection will not accept incoming connections until it knows the public key fingerprint of the remote peer.  This requirement applies to both endpoints.

 

For more options, visit https://groups.google.com/d/optout.

[Frederik-Jan de Haas]

You should look into ORTC it will be implemented in the future probably and it doesn't need SIP so one way datachannels will work if I understood correctly.

[Martin Naumann]

I see, thanks to both of you.

I also understand the security implications that requre the cryptographical identification... but it'd be nice if one could disable that if the user allows unauthenticated connections - but I'll take a look at ORTC if that may give us these possibilities.

Cheers,

Martin

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/_VFJ0U6W6Wk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Alex Gouaillard]

Webrtc does not need sip either. It just chose to use sdp (as a format) and offer/answer (as a mechanism) to do the original handshake.

While ORTC does not force you to use sdp or o/a, you still need to exchange info somehow, there is no black magic.

Alex

Sent from my iPhone

[Martin Naumann]

Just clarifying: Obviously one needs to transfer connection information to the connecting party.

But for a standard TCP or UDP connection it's enough if one end knows how to establish a connection with the other end. That's what I am interested in, distributing the connection details *one way * and have peers use them to connect. Without having a dedicated server (like Web sockets).

A use case example would be a Smart TV browser showing a page with string or QR code and mobile devices directly connecting with it.

Cheers,
Martin

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/_VFJ0U6W6Wk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.