Search results

Good day. Since build 5.2.1751 a characters encoded at client side by encodeURIComponent() may be decoded using the following parameter in offline-mixer.json { ..., "mixerDecodeStreamName": true }

Good day. 1. RoomApi is already using a custom data when establishing a connection, the data is used to identify a room and a user. Also, RoomApi uses an internal REST hooks based backend, so you should proxy all the hooks to the standard backend if you want to use your own one. Otherwise...

Seems like both ip and ip_local addresses are in local network: In this case, you cannot play anything from external network by WebRTC at all. Please set ip to an external IP address (and set up ports routing) and add the following parameter to the settings: rtc_ice_add_local_interface=true...

You can use jstack tool to get current Java Threads state: jstack tool, then analyze it and found blocked threads.

We checked the report. RTSP stream itself is captured correctly and can be played successfully from traffic dump in the latest WCS build 5.2.1759. But in the server log there is Failed by ICE timeout message for the client session: So you should check media ports availablility (31000-32000/udp...

4 by default. This value can be changed: Recording perfomance tuning under high load Yes. Seems like threads blocking caused not by CPU load, but by a network drive unavailablity. WCS rebooting periodically is not a good solution. Please change the records dir to a local folder on a fast SSD...

We checked the server. Seems like the server is too weak to write more then 1 file simultaneosly (only 2 vCPU), so recording queues are grow. In case of room streams recording, there can be a much streams in room, so use more powerful server. Also we see a blocked recording threads. This can...

Good day. Seems like in external-bad.txt the camera closes the connection by some network reason. Please collect a report as described here, including client debug logs and traffic dump (mandatory): 1. Enable client debug logs client_log_level=debug 2. Restart WCS 3. Start a traffic dump...

You can use MKV container for VP8 streams: MP4, WebM, MKV containers support. But browsers cannot play MKV directly. We checked jstack.log from previous reports and did not found any suspicious thread locks. If the problem occur again, it would be ideal to get SSH access to the server. Anyway...

We fixed the report form, you can use it now.

Temporary dir is not used when recording streams in VP8, WEBM files are recording directly to the record dir. So if it's not available recording file will not be created at all, and hook script will not be called. Please do not use a network drive as we recommended above.

Your report contains no server configuration. Please collect it using report.sh script: Getting logs with report.sh script sudo ./report.sh --sysinfo --conf --tar In the logs we see you're recording streams published via RoomApi in VP8 codec. In this case, WEBM container is used by default...

Place the archive to a cloud drive (Google Drive, OneDrive, Yandex.Disk etc) and send the link using this form. If sending via form does not work, please send the link to support@flashphoner.com with this topic URL in Subject field

Good day. We fixed the issue in build 5.2.1755. Please update WCS and add the following settings: sip_force_tcp=true allow_outside_codecs=false generate_av_for_ua=all rtp_generator_start_timeout=100 periodic_fir_request=true periodic_fir_request_interval=2000 profiles=42e01f,640028

Yes. In this case, there should be a message in server logs Problem to move file /tmp/stream-ca00d7d0-52c2-11ee-ba8e-e9beb144939a-94brlh973bo9nlpe228922hort.mp4 to /usr/local/FlashphonerWebCallServer/records/stream-ca00d7d0-52c2-11ee-ba8e-e9beb144939a-94brlh973bo9nlpe228922hort.mp4 and...

Good day. WCS does not check any network conditions when writing stream recordings to disk. It even does not know what the disk is: hard drive or network mounted drive. Linux file system should care about it. So temporary files are always created in record_tmp_dir if the folder exists and...

Please provide a links to test. Please look at Player example using custom volume slider and Embed Player example using standard controls.

There is no a solution without a real user action. You can provide some landing page where user has to interact with your site or click something before playback.

This is autoplay policy issue. The user action is required to unmute video: click a button or move a volume slider. You can use the method Stream.unmuteRemoteAudio() when click event occurs. Also, in last Web SDK builds you can enable standard video controls using the stream option useControls...

Good day. This is Chrome autoplay policy issue. Video element should be muted to play video automatically. Please update Web SDK to the latest build 2.0.233 (or via NPM) and set the following stream option var options = { ..., unmutePlayOnStart: false }; var stream =...