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... Thanks, -- Regards, Mirko
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@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...
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@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@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@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
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@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@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@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@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
-- Regards, Mirko
actually the answering leg responds with CONTROLING request On Thu, Sep 28, 2017 at 3:33 PM, Mirko Brankovic <mirkobrankovic@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@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@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@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@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
-- Regards, Mirko
-- Regards, Mirko
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@gmail.com> wrote:
actually the answering leg responds with CONTROLING request
On Thu, Sep 28, 2017 at 3:33 PM, Mirko Brankovic <mirkobrankovic@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@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@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@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@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
-- Regards, Mirko
-- Regards, Mirko
-- Regards, Mirko
Hi, did you solve your issue? I'm facing the similar issue, 4 seconds until the verto client to have sound, in my scenario i execute action playback in FS. I see the delay between DTLS handshakes: 06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:26.960555 [INFO] switch_rtp.c:3881 Changing audio DTLS state from OFF to HANDSHAKE .. 06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:30.060550 [INFO] switch_rtp.c:3251 Changing audio DTLS state from HANDSHAKE to SETUP .. 06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:30.080551 [INFO] switch_rtp.c:3200 Changing audio DTLS state from SETUP to READY On 02/10/2017 09:26, Mirko Brankovic wrote:
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@gmail.com <mailto:mirkobrankovic@gmail.com>> wrote:
actually the answering leg responds with CONTROLING request
On Thu, Sep 28, 2017 at 3:33 PM, Mirko Brankovic <mirkobrankovic@gmail.com <mailto:mirkobrankovic@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 <https://pastebin.freeswitch.org/view/33d30c7e>
On Sat, Sep 23, 2017 at 3:12 PM, Mirko Brankovic <mirkobrankovic@gmail.com <mailto:mirkobrankovic@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@jerris.com <mailto:mike@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@gmail.com <mailto:mirkobrankovic@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@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com>
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org <http://confluence.freeswitch.org> http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org
-- Regards, Mirko
-- Regards, Mirko
-- Regards, Mirko
_________________________________________________________________________ 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
-- Saludos / Regards / Cumprimentos António Silva
Hi Antonio, It is resolved for now, partially and not on purpose, so by accident. Make sure you have client and server side in dtls handshake, check if you see if freeswitch is changing role from passive to active in logs On Fri, Oct 25, 2019, 17:32 António Silva <asilva@wirelessmundi.com> wrote:
Hi,
did you solve your issue?
I'm facing the similar issue, 4 seconds until the verto client to have sound, in my scenario i execute action playback in FS.
I see the delay between DTLS handshakes:
06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:26.960555 [INFO] switch_rtp.c:3881 Changing audio DTLS state from OFF to HANDSHAKE
..
06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:30.060550 [INFO] switch_rtp.c:3251 Changing audio DTLS state from HANDSHAKE to SETUP
..
06004979-f208-1d2d-b6d2-330af10907b0 2019-10-25 16:53:30.080551 [INFO] switch_rtp.c:3200 Changing audio DTLS state from SETUP to READY
On 02/10/2017 09:26, Mirko Brankovic wrote:
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@gmail.com
wrote:
actually the answering leg responds with CONTROLING request
On Thu, Sep 28, 2017 at 3:33 PM, Mirko Brankovic < mirkobrankovic@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@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@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@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@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
-- Regards, Mirko
-- Regards, Mirko
-- Regards, Mirko
_________________________________________________________________________ Professional FreeSWITCH Consulting Services:consulting@freeswitch.orghttp://www.freeswitchsolutions.com
Official FreeSWITCH Siteshttp://www.freeswitch.orghttp://confluence.freeswitch.orghttp://www.cluecon....
FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershttp://www.frees...
-- Saludos / Regards / Cumprimentos António Silva
participants (3)
-
António Silva
-
Michael Jerris
-
Mirko Brankovic