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

[Anthony Minessale]

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
☎ 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/e8a0d948/attachment.html