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

Tue Jun 2 02:35:44 MSD 2015

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 at 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 at 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 at jerris.com> wrote:
>
>> 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> 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> 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> wrote:
>>
>> Ice must negotiate, then dtls.  The ice is not encrypted.
>>
>>
>> On Sunday, May 31, 2015, Michael Jerris <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> 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 at 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 at 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  ♬
>
> ☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞
> http://twitter.com/FreeSWITCH
> ☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
> <http://freeswitch.org/g+>*
>
> ClueCon Weekly Development Call
> [image: ☎] sip:888 at conference.freeswitch.org  [image: ☎] +19193869900
>
> https://www.youtube.com/watch?v=9XXgW34t40s
> https://www.youtube.com/watch?v=NLaDpGQuZDA
>  _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 at 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 at 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 at 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  ♬

☞ http://freeswitch.org/  ☞ http://cluecon.com/  ☞
http://twitter.com/FreeSWITCH
☞ irc.freenode.net #freeswitch ☞ *http://freeswitch.org/g+
<http://freeswitch.org/g+>*

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

https://www.youtube.com/watch?v=9XXgW34t40s
https://www.youtube.com/watch?v=NLaDpGQuZDA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150601/94367053/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1668 bytes
Desc: not available
Url : http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150601/94367053/attachment-0001.png 