about JUICE_CONCURRENCY_MODE_MUX mode.

[xicilion]

When the agent is set to JUICE_CONCURRENCY_MODE_MUX mode, only the first agent will create a UDP socket. Subsequent agents created in JUICE_CONCURRENCY_MODE_MUX mode, even if specifying different ports, will not create new UDP sockets.

This behavior may seem unexpected because each agent is configured with a different port.

[paullouisageneau]

This is expected. The principle of mux mode is that a new agent either joins the existing mux or creates it if there is none. As a result the port range is only used if a new socket needs to be created. Maintaining multiple muxes would make the architecture way more complicated for no reason as it partially defeats the purpose of the feature (the user can still create non-muxed agents in parralel).

[xicilion]

In my application, I need to connect to another peer in mux mode with different ufrag/pwd. Currently, con_mux identifies the peer by address/port, so when both peers are in mux mode, an error will be reported when trying to establish the second connection with different ufrag/pwd.

In the WebRTC Direct specification, the recommended approach is to identify connections using the address, port, and ufrag.

The ufrag in combination with the IP and port of A can be used by B to identify the connection, i.e. demultiplex incoming UDP datagrams per incoming connection.

If we stick to the current mux model, can we consider adding ufrag to the process of identifying connections?

[paullouisageneau]

In my application, I need to connect to another peer in mux mode with different ufrag/pwd. Currently, con_mux identifies the peer by address/port, so when both peers are in mux mode, an error will be reported when trying to establish the second connection with different ufrag/pwd.

Indeed, conn_mux needs to identify peers by address and port as only STUN datagrams carry the ufrag, the rest of datagrams don't, so if both peers are in mux mode they can only open a single connection. This is not an issue in practice as conn_mux is typically used on servers to scale without opening more UDP sockets and ports, while clients use the standard WebRTC mode. Note conn_mux breaks the ICE standard which mandates different UDP sockets for each agent for this reason.

In the WebRTC Direct specification, the recommended approach is to identify connections using the address, port, and ufrag.

The ufrag in combination with the IP and port of A can be used by B to identify the connection, i.e. demultiplex incoming UDP datagrams per incoming connection.

The WebRTC spec says that peer B should use the IP and port of peer A, which basically describes how mux mode works. It seems to assume that peer A uses a different address and port for each connection, i.e. that peer A uses standard mode.

If we stick to the current mux model, can we consider adding ufrag to the process of identifying connections?

The bottom line is that it is impossible, since non-ICE packets (DTLS for instance) don't carry the ufrag. The proper solution is that peer A must create its outgoing connection in standard mode, not in mux mode.

[xicilion]

I see. In that case, I might need to consider changing the design of the application.