One way communication with libjuice

[rcvangemert]

still quietly working with libjuice and have my app streaming mpegts between devices.

If I only need to connect to a remote device and receive a transport stream can I remove the second handshake? I have confirmed that it does work but want to be sure there are no side effects.

FYI, it would have been nice to have rtp encoding/decoding as part of juice. but maybe I should have used libdatachannel!

[paullouisageneau]

I already answered you in #192 (reply in thread)

There is no one way communication mode, you are just abusing the lack of timeout to get the description. You must forward both descriptions, otherwise the connection will typically fail when the first peer is behind a firewall or NAT.

If you don't want to carry out the signaling process, there is no point in using ICE, just send UDP packets from one peer to the other (you won't get firewall or NAT traversal capabilities, however).

[rcvangemert]

Thanks.

…

On Mon, 26 June 2023, 18:40 Paul-Louis Ageneau, ***@***.***> wrote: I already answered you in #192 (reply in thread) <#192 (reply in thread)> There is no one way communication mode, you are just abusing the lack of timeout to get the description. You must forward both descriptions, otherwise the connection will typically fail when the first peer is behind a firewall or NAT. If you don't want to carry out the signaling process, there is no point in using ICE, just send UDP packets from one peer to the other (you won't get firewall or NAT traversal capabilities, however). — Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGSW3GQQ3SJIM5JF4B6LM3XNFDI5ANCNFSM6AAAAAAZTT2EAQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>