[Freeswitch-users] ICE/DTLS handshake

Mirko Brankovic mirkobrankovic at gmail.com
Mon Oct 2 07:26:08 UTC 2017


And I was wrong, nothnig to do with STUN,
Problem is that engine state (switch_rtp_ready(engine->rtp_session) is
false) is not ready at the moment that STUN/ICE is starting.

Not to see what is holding Audio engine to get to ready state (I'm
suspecting the TRANSCODING_NECESSARY event)

On Thu, Sep 28, 2017 at 3:46 PM, Mirko Brankovic <mirkobrankovic at gmail.com>
wrote:

> actually the answering leg responds with CONTROLING request
>
> On Thu, Sep 28, 2017 at 3:33 PM, Mirko Brankovic <mirkobrankovic at gmail.com
> > wrote:
>
>> Looks like the problem lies in fact that both call legs/channels in refer
>> call scenario are in my case outgoing legs, and then they are sending
>> CONTROLED stun username requests, so I don't have CONTROLING side.
>>
>> while at the same time Video stun is negotiated immediately and correctly.
>> Log shows it I guess.
>> https://pastebin.freeswitch.org/view/33d30c7e
>>
>> On Sat, Sep 23, 2017 at 3:12 PM, Mirko Brankovic <
>> mirkobrankovic at gmail.com> wrote:
>>
>>> Thanks Mike,
>>> all clients are webrtc clients behind same freeswitch.
>>> At the same time video rtp/rtcp dtls is instant, but audio is waiting
>>> for something, my best guess is for rtcp from client to confirm correct
>>> ip.port or to do auto correct.
>>> Call scenario is A call B and B transfers(refer)  call to C.
>>> Also I see in those 5 seconds that first client, A sends total of 6 stun
>>> username requests and that C answers to them all at the same time, after 5s.
>>> Can this be rtcp problem.
>>> I was thinking to go through video ice thread and compare it to audio to
>>> see how that one works instantly.
>>> thanks,
>>> Mirko
>>>
>>>
>>>
>>> On Sep 21, 2017 19:55, "Michael Jerris" <mike at jerris.com> wrote:
>>>
>>> its not going to negotiate until we get the stun responses.  If we are
>>> not, you should look if the client is sending them and something is
>>> blocking, or why the client is waiting to send them.  Sounds broken on
>>> client side from the description.
>>>
>>> On Sep 21, 2017, at 7:53 AM, Mirko Brankovic <mirkobrankovic at gmail.com>
>>> wrote:
>>>
>>> HI,
>>> Has anyone experienced DTLS handshake takes 5s to get to SETUP state:
>>>
>>>> 2017-09-21 11:40:40.021178 [INFO] switch_rtp.c:3515 Changing audio DTLS
>>>> state from OFF to HANDSHAKE
>>>> 2017-09-21 11:40:45.319457 [INFO] switch_rtp.c:3172 Changing audio DTLS
>>>> state from HANDSHAKE to SETUP
>>>
>>>
>>> In network dump i see that answering side is not sending STUN for this
>>> 5s and then suddenly answers last 5 STUNs from A side.
>>>
>>> Has anyone encountered this kind of problem ?
>>>
>>> I have a pcap if necessary...
>>>
>>>
>>>
>>> ____________________________________________________________
>>> _____________
>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Mirko
>>
>
>
>
> --
> Regards,
> Mirko
>



-- 
Regards,
Mirko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171002/c055cf2d/attachment.html>


More information about the FreeSWITCH-users mailing list