Re: [rtcweb] Please require user consent for data channels

[Sergio Garcia Murillo <[e-mail]>]

On 18/07/2015 1:09, Justin Uberti wrote:
>     Next, the agent uses STUN or TURN to obtain additional candidates.
>     These come in two flavors: translated addresses on the public side of
>     a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
>     (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
>     candidates are obtained from the TURN server.  If only STUN servers
>     are utilized, only server reflexive candidates are obtained from
>     them.  The relationship of these candidates to the host candidate is
>     shown in Figure 2.  In this figure, both types of candidates are
>     discovered using TURN.  In the figure, the notation X:x means IP
>     address X and UDP port x.
>
> In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS.
>
> It is pretty clear from the diagram on page 10 that for each host 
> candidate X:x, the agent will gather a srflx candidate X1':x1' and 
> relay candidate Y:y. This is also spelled out in the text underneath 
> the diagram:
>
>    When the agent sends the TURN Allocate request from IP address and
>    port X:x, the NAT (assuming there is one) will create a binding
>    X1':x1', mapping this server reflexive candidate to the host
>    candidate X:x.
>
> Ergo, one tries to gather srflx and relay candidates for each host 
> candidate X:x.

Agree, for each HOST candidate, it should send a STUN request to the 
turn server from that IP:port. But shouldn't the VPN configuration 
prevent the non-VPN-host-candidate STUN request to be sent via the 
non-VPN-interface? (i.e. applying default route based on dest?)

Best regards
Sergio