
<?xml version="1.0" encoding="utf-16"?>


<html>


<head>


<meta http-equiv="Content-Type" content="text/html; charset=utf-8">


<style><!--body


{font-family: 'Lucida Console'; font-size: 11pt;}


--></style>


</head>


<body>


Hello all,<br>


<br>


We can use the verto communicator client to join a conference handled by our own Freeswitch server.<br>


It works on Chrome, Firefox and Opera, on which we can connect ok and get audio+video.<br>


But it does NOT work on Edge.<br>


<br>


The candidates Edge provides are the following:<br>


<br>


candidate:1 1 UDP 2130706431 192.168.0.7 63832 typ host<br>


candidate:2 1 TCP 1684798975 192.168.0.7 63832 typ srflx raddr 192.168.0.7 rport 63832 tcptype active<br>


<br>


So for for every local IP, Edge generates 2 candidates: 1 host candidate, and 1 srflx candidate.<br>


The srvflx candidate is built wrong on purpose (transport address == related address).<br>


I guess they do that so that when the ICE connection checks take place, the server side can "learn" a new prflx candidate (see RFC5245, section 7.2.1.3)<br>


<br>


I have tested the same scenario using a server which makes use of the libnice library for the ICE implementation, and it works!!!<br>


No TURN server is being used, no STUN server is being used, the candidates Edge sends are the 2 above (which do not contain a public IP) and still the server generates a prflx candidate and the connection is established perfectly.<br>


<br>


But when using our Freeswitch server (which does not make use of the libnice library for ICE) the connection does not work.<br>


Then again, the funny thing is that if we use the cantina.freeswitch.org Freeswitch server, then it DOES work!<br>


So there must be something in the code/configuration that could be done so that the Freeswitch server can "learn" a prflx candidate from those Edge is sending out.<br>


<br>


Could anyone help us?<br>


Alex


</body>


</html>