Video packets do not pass from turn server to media server for more than 40-50 seconds.

[hyuk]

Hi.
I am not sure if it is a turn server problem or a WCS problem, so I am writing this in frustration.
We are using an external turnserver to send data to the WCS media server.
Briefly, data is transmitted to Public IP -> Firewall -> L4 Switch -> Turn Server -> Network Connection Equipment -> WCS Media Server.
In the state that the L4 Switch IP and Turn Server port given as a test worked well, I changed the IP of L4 and changed only the port of Turn Server for the transition to commercial use.
However, after changing the L4 IP and Turn Server port, the video packet is not delivered to the WCS Media Server after 50 seconds.
(It worked normally before about 40-50 seconds, but the time was not constant.)
If you check the UDP packet using TCPDump, the data goes normally from Personal IP -> Firewall -> L4 Switch -> Turn Server, but after 50 seconds, there is no log of packet passing from Turn Server to the network-connected device.
If you change the test L4 switch IP and test turn server port again, it works normally.
If there was a problem in a similar case where the video transmission was interrupted in the middle, can you refer to it?
If there is no case, is there anywhere I can check further?

Attached as a text file is a part of the log of TCPDUMP at the moment when the packet is not delivered from the server with Turn Server.

 

[Max]

Good day.
You've changed L4 switch settings only. So it seems like the problem is in the switch setup. The text log you've prodided shows that only STUN packets go to Coturn Server periodically (this is normal behaviour), but sees like there is no video traffic on Coturn Server.
We recommend to check the switch setup, or change the switch.

 

[hyuk]

Thanks so much for the advice on network structure.
I'm asking because I don't understand L4 Switch.
If there is a problem with L4 and data has not been delivered to Coturn Server, isn't it true that there is no log of STUN packets coming in like the attached text log when using TcpDump on Coturn Server?
And we know that STUN packets usually contain video traffic. Looking at the STUN length, it looks like there is media traffic, isn't it?
I figured it wasn't an L4 problem, of course, as STUN packets with media traffic came in to the Coturn Server.
There was no problem with WebSocket or HTTP communication.

(For reference, the person in charge of the L4 switch is an external company, and the person in charge replied that only the IP of the test L4 equipment was changed and the settings were the same. If it is not a problem with Coturn Server or WCS, I think you should ask again. )

 

[Max]

Do the following to check if media packets are passed to WCS server:
1. Enable client debug logging and start traffic dump collection on WCS as described on this page
2. Publish a stream from client PC using all the chain as you mentioned in this post
3 After 60 seconds, stop publishing
4. Stop traffic dump collection
5. Find client log to detect a media port
6. Analize WebRTC traffic as described on this page.
If SRTP packets are not received by WCS after 50 seconds, the reason is somewhere before WCS: this may be L4 Switch, Turn server or network equipment between Turn server and WCS.

 

[hyuk]

Looking at the TCPDUMP text log, it seems that the media packet only goes to the Coturn Server and is not forwarded to the network equipment for unknown reasons.
If there is a problem with WCS, it sends a signal to Coturn Server that it will not receive any more data, so Coturn Server does not deliver media data to the network equipment, or should it be considered that there is no such thing?
There is no way to check now, so if you check the previous log, there is no media traffic in the WCS log. After a certain time, the logs "status" : "UNPUBLISHED", "info" : "Stopped by publisher stop" were recorded.
Unfortunately, it will be difficult to reduce the scope of debugging.
Thanks for the sincere reply.

 

[Max]

There is no way to check now, so if you check the previous log, there is no media traffic in the WCS log. After a certain time, the logs "status" : "UNPUBLISHED", "info" : "Stopped by publisher stop" were recorded.

For WCS, Coturn is publisher in this case. The Stopped by publisher stop message means that Coturn stopped stream publishing.
Seems like Coturn does not receive media traffic from client for some time before it stops publishing to WCS. Therefore, the problem is on client itself, on Firewall, or on L4 Switch.

 

[hyuk]

The error information in the previous question was wrongly checked by me.
Sorry for the misunderstanding.

I think I misread the server log of the client receiving the mediaSessionId where the problem occurred.
It was "parentMediaSession", not "mediaSessionId".
I remember that the video was probably stopped and I had to refresh the client.
"parentMediaSessionId": "eb819aa0-9529-11ec-b515-91b09f8969f7"

In fact, the first error that occurred in the session where the problem occurred was "Failed by RTP activity".

"status": "FAILED",
"audioCodec" : "opus",
"videoCodec": "H264",
"info" : "Failed by RTP activity",
"description" : "Video RTP activity",

The problematic mediaSessionId is as follows.
"mediaSessionId" : "eb819aa0-9529-11ec-b515-91b09f8969f7"

I am attaching the flashphoner log for reference.

 

[Max]

In fact, the first error that occurred in the session where the problem occurred was "Failed by RTP activity".

This confirms the issue: WCS stops publishing session, because there is no video packets received in 60 seconds.
So the problem is somewhere in chain: ClientPC - Filewall - L4 Switch - Coturn.