[libnice] http reverse proxy
philip at tecnocode.co.uk
Tue Mar 10 05:20:24 PDT 2015
On Wed, 2015-02-25 at 11:58 +1300, Felix Schlitter wrote:
> I am using the reliable udp implementation that comes with libnice (pseudo tcp)
> and would like to enable browser access to a server hosted on the peer.
> I am thinking of creating a reverse proxy in front of the reliable udp transport
> and then forward data from and to the underlying udp socket.
> I am wondering, however, how multiplexing multiple connections would work in
> this scenario. I saw the pseudo tcp implementation replaces the src and dest
> ports in the tcp header with a conversation id, which is unique by component
> from what I understand. Components, however, need to be created up-front.
You are correct.
> I would appreciate any hints as to how to go about this.
I think this will require modifications to libnice to allow new
conversations to be created for an existing ICE session. Olivier and I
have been thinking about this recently, and think the following new API
GIOStream *nice_agent_add_io_stream (NiceAgent *agent,
The GIOStream would be a NiceIOStream with a
NiceIOStream:conversation-id property which you could send out-of-band
on your control connection to allow the peer to proxy out the correct
So you’d set up your ICE session as normal, with 1 stream and 1
component. You’d then call nice_agent_add_io_stream() on peer A, query
the conversation ID and send that to peer B over your control
connection. Peer B would call nice_agent_add_io_stream() itself and
match up the conversation ID, then reply over the control connection to
tell peer A to start sending using the new conversation.
The downside here is that you essentially have to implement a simple
handshake protocol to get the conversation ID set up — but that’s
consistent with the rest of libnice, which doesn’t implement control
communications for you.
Does that sound feasible? If you want to work on this, I can answer any
questions you have. Not sure when I will get time to work on it myself.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 213 bytes
Desc: This is a digitally signed message part
More information about the nice