You are looking at the code for when the ice is initialized it has nothing to do with your problem.
It always starts out 0 since it was just setup.  I think you are hyper-focused on there being something wrong with the code.

It will set ice.ready to 1 when you get an ice packet that matches what was negotiated and ice.rready when it gets a response to an ice packet.

We prefer not to have lengthy discussions about user-issues on this list.  Its not designed for tracking issues.
Make sure you are running the latest master code and file a JIRA with appropriate details like what browser what exactly you are trying to do, the trace of the debug log etc.

You might want to try https://cantina.freeswitch.org/verto  and dial "decode" or "vid_awesome1.mp4" or "3500"
This server is constantly kept up to date with the latest master branch code.




On Mon, Jun 1, 2015 at 5:07 PM, Jon Lederman <jonlederman@gmail.com> wrote:
Hi,

We are seeing STUN packets.  The code I was referring to earlier is this in switch_rtp_activate_ice:
if ((type & ICE_VANILLA)) {
switch_snprintf(ice_user, sizeof(ice_user), "%s:%s", login, rlogin);
switch_snprintf(user_ice, sizeof(user_ice), "%s:%s", rlogin, login);
switch_snprintf(luser_ice, sizeof(user_ice), "%s%s", rlogin, login);
ice->ready = ice->rready = 0;
} else {
switch_snprintf(ice_user, sizeof(ice_user), "%s%s", login, rlogin);
switch_snprintf(user_ice, sizeof(user_ice), "%s%s", rlogin, login);
ice->ready = ice->rready = 1;
}

It appears that we are getting ICE_VANILLA.  In that case, ice.ready and ice.rready are both set to 0 and DTLS negotiation cannot proceed until ice.ready and ice.rready are 1.  Can ice.ready be set to 1 elsewhere (I noticed in rtp_common_read for example).  However, it is not clear whether that can happen since it requires ice negotiation to start the media flow in the first place.  Please confirm whether switch_rtp_activate_ice requires non ICE_VANILLA in order for ice activation to occur (will switch_rtp_activate_ice be called multiple times until this happens)?



Thanks.

-Jon

On Jun 1, 2015, at 12:43 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

tshark -Y stun

Look on the wire for stun packets being sent to/from your client and your box.


On Mon, Jun 1, 2015 at 11:23 AM, Michael Jerris <mike@jerris.com> wrote:
make sure you are using latest code from git master.

On Jun 1, 2015, at 12:07 PM, Jon Lederman <jonlederman@gmail.com> wrote:

Yes.  This is webrtc on chrome latest version.  We are pretty certain packets making it to FS and will do a wireshark trace to confirm.  ICE setup is failing and the ice.ready remains false for reasons we don’t understand.  However, packets are flowing.  
On Jun 1, 2015, at 12:03 PM, Michael Jerris <mike@jerris.com> wrote:

What is the client? Is this webrtc?  Did you confirm that the packets are actually making it to freeswitch like I reccomended?

On Jun 1, 2015, at 11:57 AM, Jon Lederman <jonlederman@gmail.com> wrote:

Hi,

The problem we are encountering is that ICE is never established and/or ready.  
In the function switch_rtp_activate_ice in switch_rtp.c, we notice that it detects VANILLA ICE and thus sets ice.ready=0.  As far as we can tell, there are only a handful other places where ice.ready (or ice.rready for RTCP) can be set to true including the function rtp_common_read.  However, in rtp_common_read, *bytes is 0 and therefore ice.ready remains 0.  Further, is it true that ICE must be ready and negotiated before RTP packets can even begin to flow via rtp_common_read?

The main questions are:

1) Is this VANILLA ICE detection, which causes ice.ready to be 0 in switch_rtp_activate_ice problematic?  That is, is the 1.6 branch operative with VANILLA ICE and what is causing VANILLA ICE to be negotiated?  Do we need to change something in the SDP for example?

2) It appears switch_rtp_activate_ice is called multiple times to no avail, as ice.ready remains 0.  Must ICE establishment and setup be achieved in switch_rtp_activate_ice before any media can flow OR can ice.ready be set to true later somehow?

3) If ICE is not being activated properly, what would be your recommendations on debugging why this is?  

Thanks in advance.

-Jon
On Jun 1, 2015, at 10:38 AM, Anthony Minessale <anthony.minessale@gmail.com> wrote:

Ice must negotiate, then dtls.  The ice is not encrypted.


On Sunday, May 31, 2015, Michael Jerris <mike@jerris.com> wrote:
Typically this happens when the traffic isn't making it back to FreeSWITCH.

On Sunday, May 31, 2015, Jon Lederman <jonlederman@gmail.com> wrote:
Hi,

We are having trouble getting WebRTC working with 1.6.  I have tracked the problem down to the do_dtls function in switch_rtp.c (shown partially below).  Two things we have noticed:

1) It appears that ice.ready and ice.ready are always 0.
2) DTLS negotiation never completes the handshake.

Does ice have to be operative in order for dtls negotiation to proceed or the other way around?  What should I look for, which may prevent the ice setup and/or dtls handshake.
We are running on google cloud.  Are there networking/NAT issues running on cloud servers that might interfere with either ICE or DTLS?

Thanks in advance.

-Jon


static int do_dtls(switch_rtp_t *rtp_session, switch_dtls_t *dtls)
{
        int r = 0, ret = 0, len;
        switch_size_t bytes;
        unsigned char buf[4096] = "";
        int ready = rtp_session->ice.ice_user ? (rtp_session->ice.rready && rtp_session->ice.ready) : 1;



        if (!dtls->bytes && !ready) {
                //switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(rtp_session->session), SWITCH_LOG_ALERT, "Ice not ready");
                return 0;
        }

…




_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



--
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org



--
Anthony Minessale II       ♬ @anthmfs  ♬ @FreeSWITCH  ♬

ClueCon Weekly Development Call 
☎ sip:888@conference.freeswitch.org  ☎ +19193869900