~~в getUserData нет status: ESTABLISHED, этот статус возникает только на клиенте. поэтому ws.data: {status:ESTABLISHED} выглядит лишним.~~

статус есть в getUserData, хотя SDK поднимает статус ESTABLISHED наверх, не проверяя это значение, по факту получения и обработки getUserData

о каком другом протоколе речь? как воспроизвести кейс вручную?

Этот функционал вообще работает? Не помню такого метода в WebSDK, автоматической документации на него тоже нет, нужно проверифицировать

Этот функционал еще работает? Не вижу в WebSDK метода для отправки SIP сообщений. Нужно проверифицировать

WebRTC и Flash здесь нет, только SIP

состав параметров не соответствует хуку. RegistrationStatusEvent выглядит так (пример из логов сервера) OBJECT: { "nodeId" : "f02vkq9PbK9A8MrBnKatCK9clLbHbPyR@95.191.130.39", "appKey" : "defaultApp", "sessionId" : "/5.129.23.83:53866/95.191.130.39:8443-caab56ae-481a-484e-8ca6-ff8a47456080", "status" : "REGISTERED" }

о каком другом протоколе речь? как воспроизвести кейс вручную?

здесь должно быть Hook type: notify это работает не только для WebSDK, но и для других, там тоже есть метод sendData

Этот функционал вообще работает? Не вижу на стороне клиента каких-либо методов. Нужно проверифицировать.

ConnectionStatusEvent содержит разный состав полей для различных кейсов: WebRTC, Flash, SIP

и кейса Status там точно нет

рекомендуется протестировать вручную и посмотреть, как это работает

на диаграмме не хватает connect от клиента к серверу

иначе непонятно, откуда взялось SIP REGISTER

не TCP connect, просто connect, т.к. SIP REGISTER мы отправляем не только по факту websocket connect, там еще идет сигналинговое сообщение connection с параметрами регистрации

этот функционал вообще работает?

в документации, генерируемой по коду WebSDK, нет метода для отправки такого запроса. нужно проверифицировать, как он должен работать

если это легаси, лучше будет его из документации убрать вообще

это не информационное сообщение, это управление потоком (остановка потока на стороне сервера) документация здесь: https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Captured_stream_management/Stopping_the_video_stream_on_the_server_side/

нужно скорректировать описание и диаграмму

лучше показать пример остановки стрима: 1. верхняя стрелка оставляем только publishing stream 2. бэкенд отвечает 403 Forbidden 3. от клиента к серверу перечеркнутая стрелка publishing stream 4. от сервера к клиенту стрелка Notify stream status (FAILED)

если приходит 200 OK, сервер ничего с потоком не делает, но если приходит что-то иное (в клиентской доке мы рекомендуем 403, т.к. это ближе всего по смыслу), сервер останавливает медиасессию, клиент получает нотификацию StreamStatusEvent с FAILED

диаграмма:

1. Пунктирная стрелка от клиента к серверу Publishing stream
2. Пунктирная стрелка от сервера ко второму клиенту Playing stream
3. Стрелка от паблишера к серверу Mute stream audio
4. Стрелка от сервера к паблишеру audioMuted
5. POST /apps/DefaultApp/StreamEvent к бэкенду и т.д.

Вообще, зеленый квадратик желательно расшифровывать во всех случаях

Стрелка audioMuted должна быть от сервера к зрителю, а не к паблишеру

диаграмма:

Речь идет об отправке данных с одного клиента многим клиентам https://flashphoner.com/docs/api/WCS5/rest_api/latest/v3/#tag/Data/operation/sendData

1. От клиента к серверу POST /data/send
2. Рисуем второго клиента, к нему OnDataEvent
3. Дальше POST /apps/DefaultApp/DataStatusEvent на бэкенд и т.д.

Можно ли вынести тип хука в оглавление (как в доке по REST API v3 сделано с асинхронными запросами, у которых в оглавлении отмечено JOB)?

На диаграмме не хватает пунктирной стрелки от клиента к серверу Publishing stream

также Unpublish stream лучше заменить на Stop publishing

Метод WebSDK Session.submitBugReport() принимает на вход JSON объект. Не факт, что упаковка вообще поддерживается. Нужно проверить, как работает функционал, и скорректировать описание.

Здесь на диаграмме не хватает пунктирной стрелки от сервера к клиенту Playing stream

stopStream идет только доя PLAYING сессий, для PUBLISHING есть свой хук unPublishStream

На диаграмме выглядит так, что 200 OK в сторону REST клиента уходит (ну или статус задания меняется на DONE) только после срабатывания хука. Необходимо проверить, так это или нет, и, если не так, то скорректировать диграмму

Здесь на диаграмме можно уточнить, что на клиенте вызывается метод Session.startDebug

Этот хук предназначен только для аутентификации https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Playing_a_video_stream_from_the_server/In_a_player_via_RTSP/#rtsp_playback_authentication_via_rest_hook

URL, имя и другие параметры стрима при этом не меняются. В custom передаются параметры, которые должны проверяться (например, accessKey)

Этот хук предназначен только для аутентификации https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Playing_a_video_stream_from_the_server/In_a_browser_via_HLS/#hls_playback_authentication_using_rest_hook

URL, имя и другие параметры стрима при этом не меняются. В custom передаются параметры, которые должны проверяться (например, accessKey)

Этот хук работает не только для Websocket (DefaultApp), но и для cdnApp, и для falshStreamingApp. Во всех случаях триггером служит сам факт установки TCP соединения. Поэтому правильнее будет не заостряться именно на Websocket

диаграмма:

1. Open Websoket and sebd connect меняем на TCP connect

Неверно. call - это звонок, инициированный клиентом, а не входящий звонок. См метод WebSDK Call.call()

диаграмма:

1. Стрелка от PBX к серверу SIP INVITE
2. Стрелка от сервера к клиенту Incoming call notification
3. И т.д.

диаграмма:

1. Пунктирная стрелка от клиента к серверу Publishing stream
2. POST и 200 OK остаются
3. Notify stream status (PUBLISHING)

Claude не разобрался, откуда этот хук берется. надо разобраться и поправить формулировку и диаграмму

исходным событием должен быть вызов Session.startDebug() на стороне клиента (WebSDK). возможно, этот функционал уже и не работает, нужно проверифицировать.

диаграмма:

1. От клиента к серверу пунктирная стрелка Publishing stream
2. От клиента к серверу стрелка POST /recorder/startup
3. Далее POST /apps/DefaultApp/RecordingStatusEvent к бэкенду и т.д.

и надо проверифицировать, отправляется ли этот хук, не помню, чтобы видел его в логах сервера

диаграмма:

Send data меняем на POST /data/send

диаграмма: Перед ConnectionStatusEvent нужно показать какое-то событие сессии. Например, перечеркнутая стрелка от клиента к серверу с надписью Disconnect.

не показываем внутренние объекты, это внешняя документация

диаграмма: 1. Показываем от клиента к WCS /v3/call/startup 2. Показываем от WCS к PBX стрелку с подписью Call established 3. Дальше остается POST в сторону бэкенда и т.д.

не показываем внутренние объекты, это внешняя документация

диаграмма: 1. Убрать Create Connection instance. Мы не показываем внутренние процессы сервера. 2. После Apply backend updates пунктирная стрелка в сторону клиента с подписью Connected 3. Убрать Create Stream instance 4. После Apply backend updates пунктирная стрелка от клиента к серверу с подписью Publishing stream

to notify an external system...

координировать тут нечего, а управлением занимается как раз тот бэкенд, который мы оповещаем

не показываем внутренние объекты, это внешняя документация

vod://s3/bucket/sample.mp4 после s3 нет двоеточия

маршруты показываются и для профилей поэтому можно так: The name of the stream published to Origin, or stream name by profile to inspect its delivery route

в мастере примеры для текстовой ватермарки и картинки разделены, лучше, чтобы при мерже это не потерялось

в мастере примеры для текстовой ватермарки и картинки разделены, лучше, чтобы при мерже это не потерялось

в мастере примеры разделены для текстовой ватермарки и картинки, не потерять при мерже

body area -> mixed stream area

очень мелкая диаграмма

возможно, стрелка Playing stream1 должна быть выше, чем POST /inject2/startup. так нагляднее показывается, что поток заменяется у существующих зрителей, а не у новых

двойные стрелки между нодами на диаграмме можно с одной нодой показать incoming, с другой outgoing

это не сигналинговые каналы, а WebRTC каналы при cdn_agent=rtmp их показывать не будет

здесь решили диаграмму не дублировать?

обычно у нас с одной нодой один коннект: либо incoming, либо outgoing поэтому на диаграмме можно оставить только incoming connection

то же, что для reset_inbound: у нас не может быть двух коннектов с одной нодой для этого случая нужно еще одну ноду на диаграмму добавить

не грузится лого (в консоли 404 Failed to load resource)

на диаграмме нет REST запроса

нельзя ли уменьшить размер диаграммы? видимо, оттого, что мало элементов, ее сильно раздувает на экране