"status": "NOT_ENOUGH_BANDWIDTH",
- Thread starter pride
- Start date
В соседней теме есть этот же вопрос
Это событие инициируется если на канале между WCS сервером и зрителем обнаружено 5% и более потерь.
Можно повысить этот порог настройкой (приводится значение по умолчанию)
Это событие инициируется если на канале между WCS сервером и зрителем обнаружено 5% и более потерь.
Можно повысить этот порог настройкой (приводится значение по умолчанию)
Code:
webrtc_cc2_bitrate_overuse_event_threshold=0.05
pride
Member
При частых попытках просмотреть стрим (Эмитируем так: Клиент пытается получить стрим, мы проверяем кастом поля, и рубим его через terminate), на сервере возникает вот такое "status": "STOPPED". И висит некоторое время , потом прибивается. Но у клиента. не возникает событие FAILD или STOPED .
В чем может быть проблема?
В чем может быть проблема?
Это не совсем удачная реализация.
Так как вы даете стриму запуститься, инициализироваться и в это же время его убиваете. Возможно в процессе инициализации, когда уже идет ICE и DTLS.
Лучше сразу реджектить стрим на этапе запроса stream.play().
В новой документации по REST-методам показано как это сделать и есть примеры здесь.
Мы постараемся воспроизвести проблему с последними сборками и исправить, если она есть. т.к. terminate так или иначе, должен работать корректно. Но прямо сейчас можно обойти эту проблему, не используя terminate в самом начале стрима.
Кстати, мы выпустили вторую версию REST API. Там более упорядочены методы и есть документация с примерами:
https://flashphoner.com/docs/wcs5/wcs_docs/html/ru/wcs-rest-api
pride
Member
Ок. Спасибо будем ждать. Но нам неудобно рубить пользователя на стадии stream.play(). Ибо с NodeJS будет идти запрос на стороний сервер который будет пытаться снять со счета пользователя средства. И если вдруг после stream.play() в streamStatusEvent придет ошибка (по какой либо причине). Мы не в состоянии вернуть средства пользователю.
ПЫСЫ: так же хотел задать вопрос по поводу DEV лицензии, имеется ли такая ? Ибо обновлять каждые 14 дней, сертификат еще и с строгой привязкой к корпоративному домену , не очень удобно.
В процессе разработки, не удобно использовать сервер продакшена)
ПЫСЫ: так же хотел задать вопрос по поводу DEV лицензии, имеется ли такая ? Ибо обновлять каждые 14 дней, сертификат еще и с строгой привязкой к корпоративному домену , не очень удобно.
В процессе разработки, не удобно использовать сервер продакшена)
Понятно. Значит в вашем случае вы сначала убеждаетесь что стрим у пользователя появился и только после этого снимаете деньги.
В этом случае действительно поможет terminate.
Обойти terminate в этом случае можно, отправив пользователю команду, по которой он вызовет stream.stop()
Но после этого все равно придется вызывать terminate на случай, если пользователь заблокировал stream.stop(), что маловероятно, но возможно.
Т.е. для воспроизведения проблемы нужно сделать stream.play(), а потом быстро сделать terminate(). Верно? Как это можно быстрее всего воспроизвести?
Напишите письмо на sales@flashphoner.com
Мы планируем ввести dev-лицензии и когда будет готово, сообщим по почте.
Сейчас триалы доступны 30 дней и не лимитированы доменом. Поэтому триал тоже вариант.
pride
Member
Code:
Понятно. Значит в вашем случае вы сначала убеждаетесь что стрим у пользователя появился и только после этого снимаете деньги.
В этом случае действительно поможет terminate.
Обойти terminate в этом случае можно, отправив пользователю команду, по которой он вызовет stream.stop()
Но после этого все равно придется вызывать terminate на случай, если пользователь заблокировал stream.stop(), что маловероятно, но возможно.
Code:
Т.е. для воспроизведения проблемы нужно сделать stream.play(), а потом быстро сделать terminate(). Верно? Как это можно быстрее всего воспроизвести?
Code:
Еще вопрос. Какой у вас номер билда?Относительно REST terminate.
Мы провели тесты и обнаружили, что такое поведение получается только в тех случаях, когда одновременно вызывается stream.stop() и REST terminate.
Если
1) Дождаться StreamStatusEvent STOPPED и сделать REST terminate после этого события, то все работает корректно.
2) Не делать stream.stop(), а сделать только REST terminate, то тоже все работает корректно.
Т.е. попробуйте просто не вызывать stream.stop() и REST terminate одновременно или не вызывать stream.stop() совсем.
Мы провели тесты и обнаружили, что такое поведение получается только в тех случаях, когда одновременно вызывается stream.stop() и REST terminate.
Если
1) Дождаться StreamStatusEvent STOPPED и сделать REST terminate после этого события, то все работает корректно.
2) Не делать stream.stop(), а сделать только REST terminate, то тоже все работает корректно.
Т.е. попробуйте просто не вызывать stream.stop() и REST terminate одновременно или не вызывать stream.stop() совсем.