[Freeswitch-users] DTLS ICE and WebRTC using Freeswitch 1.6

[Michael Jerris]

make sure you are using latest code from git master.

> On Jun 1, 2015, at 12:07 PM, Jon Lederman <jonlederman at 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 at jerris.com <mailto:mike at 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 at gmail.com <mailto:jonlederman at 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 at gmail.com <mailto:anthony.minessale at gmail.com>> wrote:
>>>> 
>>>> Ice must negotiate, then dtls.  The ice is not encrypted.
>>>> 
>>>> 
>>>> On Sunday, May 31, 2015, Michael Jerris <mike at jerris.com <mailto:mike at jerris.com>> wrote:
>>>> Typically this happens when the traffic isn't making it back to FreeSWITCH.
>>>> 
>>>> On Sunday, May 31, 2015, Jon Lederman <jonlederman at gmail.com <javascript:_e(%7B%7D,'cvml','jonlederman at 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;
>>>>         }
>>>> 
>>>> …
>>>> 
>>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150601/e012b760/attachment-0001.html