discovery: Compare tranports (TCP vs UDP) while assigning remote foundations

address: add nice_address_equal_no_port() to compare addresses ignoring ports

agent: Add new-selected-pair-full

This signal include the whole candidate as the foundation is ambiguous.

signal

TODO: Update to match current state

gitignore: Add test-driver from recent automake

agent: Add new-candidate-full and new-remote-candidate-full signals

These signals include the actual candidate instead of just the foundation
which is not unique.

candidate: Add Boxed type

stunmessage: Accept NULL terminated buffers for fast speed validation

discovery: Differentiate socket creation failure from other errors

If the socket can't be bound, then trying another port makes sense,
otherwise it doesn't.

Add TCP server reflexive candidates

For TCP server reflexive candidates, since STUN can't work on TCP
candidates, we will use STUN on UDP or TCP and once we get an
externally mapped address, we will create a server reflexive candidate
for all local TCP candidates that share the same base address, and use
the same mapped port as the base addresse's port.

Signal reliable-transport-writable when ice-tcp socket is writable

Add a nice_socket_can_send and nice_socket_set_writable_callback APIs

Call g_socket_check_connect_result before g_socket_is_connected

If we don't call check_connect_result on an outbound connection,
then is_connected will always return FALSE. That's why we check
both conditions to make sure g_socket_is_connected returns the
correct result, otherwise we end up closing valid connections

Bind to a local random port for tcp-bsd

Change argument names for tcp-bsd

Set local address of TCP-BSD socket

nice_tcp_bsd_socket_new: rename addr -> remote_addr

Add a bytestream-tcp property that is read-only for now

Only enable ice-tcp for RFC and OC2007 compatibility modes

Add documentation for ice-udp and ice-tcp properties

Only generate ms-turn candidates for ice-tcp base host addresses

The issue here was that there would be a new turn discovery for UDP
and for TCP-ACTIVE host candidates and we'd get 2 relayed addresses
with the same base_addr causing two relayed candidates to have the
same foundation. This causes farstream to duplicate candidates
since we only expose the foundation when we signal new-candidate.
This will also help later for adding turn-tcp support.

Move the rfc4571 handling for OC2007 into udp-turn

In the case of OC2007, we must consider that the turn control messages
are framed with rfc4571 and udp-turn-over-tcp only adds a single guint16
to represent turn-control or end-to-end indication. Otherwise, we will
have issues with double-framing when we do the allocate directly on
the udp-turn-over-tcp but we'd have no framing once we add the udp-turn
socket layer on top of udp-turn-over-tcp

Do not parse turn data more than once if we have multiple relays

Do the recv on relayed socket

With OC2007 compat, doing a recv on the attached socket (udp-turn-over-tcp)
will cause the RFC4571 to be unframed before doing the parse_recv on the
udp-turn socket, which will fail. And even if that didn't fail, it
would still cause the resulting data to be rfc4571 since the unframing
in the agent happens before the parse_recv

Error tcp socket when it fails to connect

Return the right value in agent_socket_send when framing

Allocate request is sent on UDP-TURN-OVER-TCP socket and is also framed

The UDP-TURN socket layer is only added at the end after we discover
the relay candidate with Allocate, but until then, we use the
UDP-TURN-OVER-TCP socket layer directly, so we need to do the rfc
framing for that as well, otherwise, it won't work.

Only create one relay/upnp request for ice-tcp depending on active or passive type

Only use pseudossl for OC2007 if turn type is TLS

Wrap socket_send in udp-turn to avoid if/else on reliable everywhere

Check real received size for pseuddossl handshake

Send reliable-transport-writable on reliable ice-tcp and drop bogus 'ice-tcp unsupported'

Add some informative debug messaging

Add support for ICE-TCP

This is a massive commit that can't be split. We add ice-tcp support
into the agent by creating local host tcp-active/tcp-passive candidates.
We also need to find the local and remote candidates whenever we discover
a peer-reflexive because their data is important to setup the peer-reflexive
so a few changes were added to look for the local or remote candidate.
For TCP-ACTIVE remote peer-reflexive candidates, we can't add conncheck
pairs normally because TCP-PASSIVE (local) do not generate candidate pairs,
and we also can't have a connection from any local host, so we can only create
a single candidatepair with the local/remote that are connected.
The pair->socket of a candidate check pair will hold the connected tcp socket
(through connect for ACT or accept for PASS) and we will either have a
remote or a local peer-reflexive which will create a new candidate pair,
we cannot trigger checks on the initial candidate pair, we must only do it
on the new check pairs. but in the case of a tcp-passive, we don't get a new
local peer-reflexive candidate, so there is no new candidate with a new NiceSocket, so
when we get a triggered check, we need to match it to the candidate check pair
or when we select a pair, it will still use the original TCP-PASS socket.
We must store the new connected tcp socket in the peer reflexive candidates
since they represent that unique peer-reflx candidate's connection

Do not retransmit triggered checks if reliable transport

Small refactor for conncheck add_pair function

Print info on selected pair

Store connections in tcp-passive to allow sending

In the case of TCP-ACTIVE, we don't have a problem, because the new
socket will generate a  peer-reflexive candidate with the right
sockptr, and all sends will go through it, but for TCP-PASSIVE, there
is no peer reflexive candidates, so once the pair is selected, the local
candidate will point to the TCP-PASSIVE candidate with the TCP_PASSIVE
socket type which will cause all sends to fail, so we need to proxy
them to the child connections

Fix RFC4571 n_buffers when reading and frame outgoing STUN messages

Fix SDP generation for TCP candidates

Do not create a socket_source if fileno is NULL

Add support for RFC4571 framing (packetized mode) for ICE-TCP candidates

Disable reliable mode for test-fullmode, we already have pseudotcp unit tests

Add RFC4571 framing to ice-tcp for MS-TURN

Data and STUN messages sent over TCP MUST follow the framing method
specified in [RFC4571] section 2. We will frame every outgoing packet
and split it into 62KB frames when sending, and on reception, we will
unframe the rfc4571. For now, we only unframe for udp-turn tcp-act/pass
candidates, which means only for MS-TURN over TCP.
We still need to do the unframing for real ice-tcp candidates, then add
support for reading the data in a serialized way.

Set pair->sockptr when discovering peer-reflexive candidates

Fixes Issue #1

Add tcp-passive and tcp-active socket layers with unit test

Add a nice_socket_recv convenience function similar to nice_socket_send

Refactor tcp-bsd to ease integration of tcp-act/tcp-passive

Make socket reliable in case of tcp-act/tcp-pass and move logic for ms-turn

Factor out the add_to_be_sent into a helper API for sockets

The add_to_be_sent was duplicated in http/socks5/pseudossl/tcp-bsd and
had some small differences. It's better to factor it out so bug fixes
get applied to all of them and code is cleaner.

Do not allow message_offset to become negative when queuing messages

Use reliable TCP for ms-turn since it generates tcp candidates

Do not return the socket to the app if we use ice-tcp, even in unreliable case

Add support for MS-ICE2 candidate priorization for OC2007R2 compatibility

Rename turn files and API to be UDP specific

The TURN-TCP RFC is very different from TURN-UDP, the current turn and tcp-turn
files were only for UDP TURN RFC and UDP TURN using TCP transport.
When we implement TCP-TURN, we'll need a different algorithm, so I
renamed the files and API to avoid any confusion.

Fix crash when discovering peer reflexive candidates in RFC compat

test-fullmode: protect against ready->connected->ready state change and accept data reception on connected state

Make OC2007 relay candidates use TCP_ACTIVE and TCP_PASSIVE candidate types when using TCP TURN

Do not add server-reflexive from TURN if using a TCP connection

Remove priority functions from public header file and move to agent-priv.h

Change priority algorithm for better values

Now we will always give a handicap to UDP candidates, but still give
relays the lower priority. We have the following priorities now :
In reliable mode :
TCP Host : 120
TCP peer-refl : 110
TCP nat-assist : 105
TCP srv-refl : 100
UDP Host : 60
UDP peer-refl : 55
UDP nat-assist : 52
UDP srv-refl : 50
TCP relay : 10
UDP relay : 5

In unreliable mode :
UDP Host : 120
UDP peer-refl : 110
UDP nat-assist : 105
UDP srv-refl : 100
TCP Host : 60
TCP peer-refl : 55
TCP nat-assist : 52
TCP srv-refl : 50
UDP relay : 10
TCP relay : 5

test-priority: Unit test various configurations of candidate priorities

Fix peer reflexive priority depending on transport and compatibility

Add support for ice-tcp priorities, udp-tunneled and nat-assisted priorities

Use nice_candidate_ice_priority instead of _full variant when possible

Add support for MS-TURN in OC2007 compatibility turn usage

Do not enable keepalives for tcp candidates

do not set socket tos if fileno == NULL

Add support for tcp candidates in sdp generation

Add candidate type to debug

Add a sockptr to CandidateCheckPair, will be required for tcp-active

Do not attach to sockets with fileno == NULL (requires for tcp-active)

Only check selected pair for writability in gio outputstream

Do not retransmit connection checks on reliable transport

Use local candidate foundation as CANDIDATE-IDENTIFIER when creating
STUN_BINDING requests.

Candidate check pair foundation was used - a combination of local
and remote candidates' foundation, which does not correspond with
[MS-ICE2] 2.2.2.1 0x8054 CANDIDATE-IDENTIFIER

Disable TURN refresh in MSOC compatibility mode

At least temporary, maybe it is not used at all. TURN refresh messages
were not seen in the packet capture.

If allow_partial, then allow a return 0 from the socket

Once a ice-tcp connection is established, it should work like any other, so just send to it

Generate valid TCP connection check pairs

Refactor discovery/agent to add support for non-udp candidates

Fix indentation for _set_remote_candidates_locked

Small refactoring of agent, loop on component id from 1

Add support for MS-TURN in tcp-turn

Add support for MS Office Communicator pseudossl compatibility

Factor out pseudotcp so it's not used if the transport is already reliable

Add a nice_socket_send_reliable API for internal use.

One issue with tcp-bsd is that it will queue messages when the tcp socket
is not writable, but it will also drop messages when the queue is full.
If we want to do proper reliable ice-tcp, we need to make sure that
messages don't get dropped, also, this would affect http/socks5/pseudossl
if their messages get dropped. For ice-tcp, when the socket is not writable
we want to return 0, not queue the message.
The change here is to allow connchecks and other important protocol messages
to be sent as 'reliable' on tcp transports by queuing them and in the various
socket layers and to never drop them, but all user messages will be dropped.

if the tcp socket is not writable.

turn: In case of error, don't just pass through the data, return an error

Return number of sent messages in socket_send_messages when an error happens part-way

Fix return value of send_messages in socks5

Allow tcp-bsd to act as reliable or non reliable transport and fix is_reliable on other sockets

Add a socket type for socket layer

Some refactoring to allow for ice-tcp (non pseudotcp reliable)

Fix documentation in preparation for ice-tcp support

Add ICE-TCP candidate transport types

Small documentation fix

agent: Use 1280 instead of 65536 buffer size to send STUN Message

RFC 5389 says:
   All STUN messages sent over UDP SHOULD be less than the path MTU, if
   known.  If the path MTU is unknown, messages SHOULD be the smaller of
   576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
   IPv6 [RFC2460].

So sending 65536 bytes is always wrong

Version 0.1.7.1

Version 0.1.7

stunmessage: Revert another function to use sockaddr

The farstream unit tests were using it.