Search results

Can we also close TCP ports 8445 and 8082 ? I don't think it's a Dos attack however because after we switch the traffic from our sites to the other server the logs do not grow that much. I will collect this tomorrow

I have uploaded an old log file via the form. Also included a link to a client log of which there are also a lot: bad-request-HLS-[id] which is weird because we don't use HLS. I'm not sure but on the manually installed server I think it was 5.2.1744 and on the Flashphoner AMI it was 5.2.1825...

This seems to be working on one of the servers (with the hourly AWS license). This TCP setting was missing in the predefined rules list. However, this TCP setting was/is present on the other (manually installed) EC2 server and besides the Flashphoner WCS update nothing changed there and it was...

This is the standard setting: media_port_from =31001 media_port_to =32000 So besides adding the TCP rule to AWS, I have to edit this configuration setting in flashphonen to set 31001 to 31000 and 32000 to 33000 ?

With this setting I get the following error: WebRTC: ICE failed, add a STUN server and see about:webrtc for more details

This is highly unexpected and has never happened before. It now happens on 2 different AWS servers. One with the AWS marketplace AMI with an hourly license and one with a regular EC2 image and FF manually installed. Both are on the latest FF version. I will try the ice_tcp_transport = true...

Unfortunately I spoke too soon. It appears the error is caused by 0 bytes free on the drive which is caused by a flooding of the flashphoner.log with these kinds of entries: 12:35:57,014 WARN StunUdpSocket - STUN-UDP-pool-43-thread-208 [id: 0x43a9e0a1, /172.31.12.52:31986] Failed to...

That fixed it. Thanks.

Webcall server 5.2.1847 on AWS EC2 A POST call to [server]:8444/rest-api/stream/snapshot results in 200 OK with no snapshot data. In the log file we can see a SNAPSHOT_COMPLETE with image data included but this is after the rest api request ended. For example: 20-12-2023 10:37:36...

Can't update WCS on server because the latest version is not available: sudo service webcallserver update >>> New version available: 5.2.1840 >>> Your version: 5.2.1825 >>> Version 5.2.1840 is not available

Thanks Max. Since it's not installed by Flashphoner, I've removed the okay-release package and now yum continues as expected.

Just launched an Amazon EC2 AMI with Flashphoner license. It started and is running but when trying to sudo yum update the instance, I get the following error: Transaction Summary...

Hi Max, Thank you for the fix. It works great.

use_strict_jitter_buffer=true jitter_buffer_capacity=30 Unfortunately this also makes no difference. What is the consequence of forcing publish to VP8 ? Doesn't that mean a lot of transcoding?

The two settings did not help. The issue remains the same.

Sorry about that, I already wondered why the log was so small. Forgot to include the pcap, which I sent via Wetransfer just now. Later today I will test the two settings mentioned above.

Also note that : 1. this issue does NOT happen on WCS 5.2.1299 (publishes and streams correctly at 320x240 H264 in FF) 2. publishing a 320x240 H264 stream on a server with WCS 5.2.1299 plays fine in the demo player in FF on a server with WCS 5.2.1431 3. the same issue happens with an external...

I've sent the report tar. Tested: FF publish and play (not displaying stream) with twowaystreaming demo FF publish and play 640x480 with Media Devices demo (works fine) Chrome publish and play with twowaystreaming demo (works fine) and display same stream in FF (works fine)

Video stats Codec: H264 Codec Rate: 90000 Bytes Sent: 717022 Packets Sent: 1002 Fir Count: 0 Nack Count: 0 Pli Count: 6 Height: 240 Width: 320 Bitrate: 389352 Audio stats Codec: opus Codec Rate: 48000 Bytes Sent: 37022 Packets Sent: 914 Nack Count: 0 Bitrate: 16888 ---...

Situation is reproduced on your demo server. Tested FF at 13:02 Amsterdam time, stream 6f1d - FAIL Tested Chrome at 13:04, stream d1db - OK Played stream d1fb on FF - OK Tested FF with Media Devices 640x480 at 13:06, stream eff6 - OK Tested FF with Media Devices 320x240 at 13:08 stream 9d9a -...