Ошибка 1006 bigbluebutton iphone

Тайм — аут вызова (ошибка 1006) — bigbluebutton

Я установил bigbluebutton на свой сервер, и он работал правильно, но вдруг микрофон больше не может подключаться, и через некоторое время, будучи застрявшим в «echo test», я получу ошибку 1006, и я протестировал:

но это не решает проблему.

это выход bbb-conf —check :

Я проверил все, что нашел, и проблема все еще существует. есть ли какой-нибудь способ? Заранее спасибо.

1 ответ

Из транзакции EJB я звоню на удаленный сайт, используя SOAP. Удаленный сервер не отвечает. Я получил тайм-аут транзакции. Но я хочу получить тайм-аут от удаленного вызова. Как я могу установить тайм-аут для запроса SOAP глобально? Как я могу установить тайм-аут для запроса SOAP для конкретного.

в настоящее время я использовал следующий код для обработки таймаута: var request = http.request(options); request.setTimeout(30000, function()< //when timeout, this callback will be called >); request.on(‘error’, function(e)< //on error when request, this callback will be called >); Проблема в.

sudo нано /etc/bigbluebutton/nginx/sip.nginx

что-то вроде этого откроется:

измените строку (proxy_pass http://. ) на следующую:

Похожие вопросы:

В чем разница между wait() и wait (тайм-аут)?В любом случае wait() должен ждать вызова уведомления, но почему у нас есть ожидание (тайм-аут)? Так в чем же разница между сном(тайм-аут) и.

Я вызываю веб-сервис, используя клиент RestEasy. Одним из требований является прерывание / тайм-аут вызова, если он выполняется более 5 секунд. Как бы я добился этого с клиентом RestEasy? Я видел.

Я звоню во внешнюю службу, используя веб-ссылку. IP-Е являются динамическими, поэтому я называю их один за другим, и все работает нормально. Периодически некоторые из IP не будут доступны, и я.

Из транзакции EJB я звоню на удаленный сайт, используя SOAP. Удаленный сервер не отвечает. Я получил тайм-аут транзакции. Но я хочу получить тайм-аут от удаленного вызова. Как я могу установить.

в настоящее время я использовал следующий код для обработки таймаута: var request = http.request(options); request.setTimeout(30000, function()< //when timeout, this callback will be called >);.

PROBLEM Я искал тайм-ауты запроса/ответа для Express.js, но все, похоже, связано с соединением, а не с самим запросом/ответом. Если запрос занимает много времени,он должен быть тайм-аут. Очевидно .

Мне нужно обернуть функцию в тайм-аут, используя ACE в C++. Эта функция ждет ответа от OS, а иногда и не возвращается. Я не могу изменить функцию, поэтому я не могу поместить в нее условие.

Я использую WSO2 ESB 4.9.0 для вызова серверной службы с помощью блокирующего вызова. Я должен использовать блокирующий вызов из-за транзакции jms. Иногда сеть между ESB и серверной службой работает.

Источник

detect one problem with 1006 #9948

Comments

aztrock commented Jun 26, 2020

Describe the bug
When try activated mic in bbb-html, bbb-html send error 1006, FreeSwitch return Bad From Header, is because have two ‘:’ in the name bbb build From header bad

To Reproduce

1, Join to conference whit name 1 ❌ 1
2. Tray activate mic

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

BBB version (optional):
BigBlueButton continually evolves. Providing the version/build helps us to pinpoint when an issue was introduced.
Example:
$ sudo bbb-conf —check | grep BigBlueButton
BigBlueButton Server 2.2.18 (2040)

Desktop (please complete the following information):

• OS: Windows, Linux
• Browser: Chrome, Firefox
• Version unknown, Firefox Dev

The text was updated successfully, but these errors were encountered:

Источник

Как исправить ошибку 1006 на WebSocket

October 03, 2020

Эта статья рассчитана на тех, кто при использовании веб сокетов уже столкнулся с ошибкой 1006 или на тех, кто хочет узнать немного о нюансах работы сокетов на nodejs.

Исходя из документации stackoverflow (ну ладно, на MDN тоже можно почитать), ошибка 1006 означает “Abnormal Closure”, то есть нештатное закрытие соединения, а на практике это может означать ping timeout, во всяком случае именно такая причина этой ошибки была в моем случае.

Здесь, правда, стоит упомянуть еще один нюанс. В моем случае сокет сервер был написан с помощью библиотеки ws и логика пингования клиентов строилась на том, что в случае, если мы не дождались pong, мы вызываем ws.terminate() , что, по идее, и есть Abnormal Closure, так как в документации к этому методу написано, что соединение будет закрыто без каких либо церемоний. В этом случае ошибка 1006 вполне логична, так как перед закрытием соединения не отправлялся соответствующий фрейм.

Причин у ошибки может быть несколько (мое субъективное мнение):

• неправильно настроены таймауты на ws сервере или на nginx, если он у вас используется как прокси
• нехватка CPU
• загруженная очередь отправки сообщений

Вот об этих проблемах мы и пообщаемся в посте.

Настройка корректных таймаутов на ws и nginx серверах

Сперва стоит проверить всю логику (как на клиенте так и на сервере), которая может привести к закрытию подключения. Скорее всего в эту категорию попадает логика связанная с ping/pong подключения. Обычно фрейм ping отправляет сервер, а клиент, согласно протоколу, должен ответить на такое сообщение фреймом pong.

Этот опрос используется сервером для того, чтобы отследить мертвые подключения, которые были оборваны не по протоколу. Каждые N секунд, сервер рассылает всем клиентам сообщение (фрейм) ping и ждет ответа pong . Если pong не приходит в течении определенного времени (или, например, до следующего опроса клиентов) — соединение с клиентом считается поломанным и обычно это называют ошибкой Ping Timeout. Кроме ping/pong, клиент/сервер вполне могут использовать любые данные приходящие “с того конца” для того, чтобы выставлять подключению флаг “alive” (то есть отмечать, что подключение живое и не было разорвано).

Клиент тоже имеет право отправлять ping на сервер и ожидать от него в ответ pong. Однако обычно пингованием занимается именно сервер. Точно также никто не запрещает кому-либо отправлять фрейм pong не смотря на то, что запроса ping не было.

На этом с теоретическим экскурсом, пожалуй закончим. Надеюсь мое пояснение было хоть немного понятным. Далее задача изучить код как клиента так и сервера, а так же документацию используемых библиотек для работы с WebSocket. Надо узнать какие именно таймауты установлены для пингов и убедиться, что ping/pong отправляются достаточно часто, чтобы не происходили таймауты.

Кроме того, довольно часто перед сокет серверами ставят сервер nginx (reverse proxy) для роутинга и балансинга коннектов. Если у вас тоже используется такой подход, то нужно глянуть какие таймауты установлены на стороне nginx и убедиться, что nginx не режет ваши подключения. За это отвечают следующие опции:

Детальную документацию можно почитать на официальном сайте nginx. Так как nginx просто проксирует, он не умеет отправлять ping и, соответственно таймауты считаются от момента получения/отправки данных. Это означает, что ваш сокет сервер должен отправлять ping достаточно часто, чтобы не сработал таймаут на стороне nginx.

В случае, если ошибка вылазит в первые секунды после коннекта, это может означать проблему во время Upgrade запроса. В этом случае есть смысл проверить настройки прокси (если такие используются) или, возможно на сервере присутствует какой-то middleware, который приводит к ошибкам или обрезает часть заголовков при первых запросах перед переходом на WebSocket соединение. Но это тема другого поста.

В случае, если клиенту или WebSocket серверу не хватает CPU, это будет приводить к тому, что в Event Loop ноды/браузера будет накапливаться слишком большая очередь из команд ожидающих выполнения. В том числе, команд/колбеков связанных с обработкой ping/pong.

Чтобы исправить эту проблему, необходимо использовать профайлер, чтобы найти узкие места в вашем коде и оптимизировать их. В более сложных случаях нужно будет разделять ваше приложение на несколько воркеров (или веб воркеров), чтобы разгрузить основной поток и дать возможность обрабатывать пинг.

Чтобы решить что анализировать первым — сервер или клиент, необходимо изучить их детали имплементации, но, я бы начинал с клиента, так как именно на клиенте вероятнее всего будут проблемы с тем, что пинг получен, а до отправки понга дело доходит слишком поздно.

Очень большой поток исходящих сообщений

А вот здесь начинается самое интересное. Именно этот случай стал причиной несколькодневной дебаг сессии.

Сначала давайте очень простенько рассмотрим как происходит отправка данных по сокетам от сервера. В случае с nodejs, сокет соединение — это просто стрим. То есть при каждом вызове socket.send(data) , сервер складывает данные для отправки в стрим. А стрим, в свою очередь передает это дело операционной системе для отправки клиенту. Однако, если ОС уже занята отправкой данных, стрим буфферизирует новые данные и ожидает, когда ОС освободится. Чем больше объем данных и чем медленнее соединение, тем дольше эти данные будут стримиться на клиент.

А теперь давайте представим, что клиент в первые 10 секунд соединения отправляет более тысячи очень мелких запросов серверу, а сервер в ответ должен отправить тысячи пачек данных, вот только размер данных ответа в разы больше, чем размер соответствующего запроса. То есть на ответ серверу потребуется значительно больше времени. В случае с сокет сервером ситуация выглядит довольно безобидно, все данные быстро складываются в стрим и нода свободна, процессор простаивает и ожидает новых задач. Излишнего потребления ресурсов нету, все работает как часы. В том числе и запрос ping , который отправляется по расписанию.

Вот только ответ от клиента не вложится в таймаут. Проблема в том, что прежде чем ОС отправит ping клиенту, она сначала должна отправить все те тысячи сообщений, которые запросил клиент и только потом очередь дойдет до ping . Но ведь время до таймаута отсчитывается не с момента получения команды ping клиентом, а с момента, как выполнился код на стороне nodejs, отправивший пинг в очередь на отправку на клиент.

Как же справиться с этой проблемой? У меня есть два решения этой проблемы. Быстрое и правильное.

Ручная отправка pong (быстрое решение)

Начать отправлять команду pong с клиента каждые Х секунд не дожидаясь пинга от сервера. Если ваша библиотека не позволяет отправлять понг, можно отправлять любое легковесное сообщение, которое даст понять вашему серверу, что с соединением все ок. Примерная имплементация может выглядеть так (библиотека ws ):

Контроль RPS (правильное решение)

Нужно улучшить имплементацию клиента и сервера таким образом, чтобы ограничить количество запросов, размеры ответов и их частоту. Если ограничить максимальный размер отправляемых в одном фрейме данных, это даст возможность с большой вероятностью отправить ping в паузе между ответами.

Кроме того, надо ограничить количество ответов в секунду для каждого подключения (rps). Это количество должно быть таким, чтобы, опять же, гарантировать, наличие окна для отправки pong в перерывах между ответами. Для имплементации ограничения скорости можно попробовать использовать библиотеку на подобии bottleneck, async.

И напоследок бонус. Пока я искал кое-какую инфу для этого поста, я наткнулся на информацию о свойстве сокета socket.bufferedAmount , которое хранит текущий объем буферизированных данных, ожидающих отправки по сети. Это свойство можно использовать, чтобы понимать действительно в данный момент есть смысл добавлять новую порцию данных в стрим отправки. Можно использовать дополнительные библиотеки для работы с очередями, но вот так могла бы выглядеть имплементация “на коленке”:

В этой статье я поделился своим опытом борьбы с ошибкой 1006 при работе с WebSocket. В моем случае причиной ошибки был пинг таймаут, который был исправлен путем ручной отправки понг фреймов со стороны клиента. Теперь мои сокеты больше не падают! Также в статье были рассмотрены другие кейсы, которые могут стать причиной Ping Timeout как по вине сервера/прокси, так и по вине клиента.

Возможно мой случай был весьма специфичным и я не изобрел универсальный рецепт решения проблем с ошибкой 1006, но все же надеюсь кому-то эта информация окажется полезной.

Источник

[2.4 RC-2]: Install by bbb.install.sh, but 1006 or 1007 error. #13489

Comments

nikkei00 commented Oct 14, 2021 •

Describe the bug
This morning, our server 2.2 crashed after the reboot command. I inserted another hard drive in order to install a new version of ubuntu 18.04 + bbb 2.4.
That is, bbb 2.2 worked with these router settings for TWO YEARS, THERE WERE NO PROBLEMS. The hardware has not changed either, the IP addresses have not changed — ONLY the SERVER’S HARD DRIVE has been replaced. Next, I installed ubuntu 18.04 and bbb 2.4-rc2 using a script.

Everything started to start right away, except for connecting as a MICROPHONE. (1006\1007)

Connection diagram:
White static IP address + domain name >>>> Mikrotik router >>>> bbb server

*All blurred ip addresses are white static ip addresses

Router settings (port forwarding) HAVE NOT CHANGED FOR TWO YEARS while the server 2.2 was running

Following the instructions:

Updating Kurento
nano /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini

Update FreeSWITCH
nano /opt/freeswitch/conf/vars.xml

nano /opt/freeswitch/conf/sip_profiles/external.xml

nano /etc/bigbluebutton/nginx/sip.nginx

Configure FreeSWITCH for using SSL

nano /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml

nano /opt/freeswitch/conf/sip_profiles/external.xml

nano /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml

grep enableListenOnly /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml

Step again /usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml

After making the above changes, restart BigBlueButton.

Connecting via Mozilla Firefox
MICROPHONE

Just listen — everything is ok
Webcams and screen demonstrations work!

bbb-conf —check

000.000.000.000 — White static IP address
192.168.88.61 — Local IP

BigBlueButton Server 2.4-rc-2 (2539)
Kernel version: 4.15.0-159-generic
Distribution: Ubuntu 18.04.6 LTS (64-bit)
Memory: 32797 MB
CPU cores: 8

/etc/bigbluebutton/bbb-web.properties (override for bbb-web)
/usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties (bbb-web)
bigbluebutton.web.serverURL: https://bbb.SITE.org
defaultGuestPolicy: ALWAYS_ACCEPT
svgImagesRequired: true
defaultMeetingLayout: SMART_LAYOUT

/etc/nginx/sites-available/bigbluebutton (nginx)
server_name: bbb.SITE.org
port: 80, [::]:80
port: 443 ssl

/opt/freeswitch/etc/freeswitch/vars.xml (FreeSWITCH)
local_ip_v4: 192.168.88.61
external_rtp_ip: 000.000.000.000
external_sip_ip: 000.000.000.000

/opt/freeswitch/etc/freeswitch/sip_profiles/external.xml (FreeSWITCH)
ext-rtp-ip: $$
ext-sip-ip: $$
ws-binding: 000.000.000.000:5066
wss-binding: 000.000.000.000:7443

/usr/local/bigbluebutton/core/scripts/bigbluebutton.yml (record and playback)
playback_host: bbb.SITE.org
playback_protocol: https
ffmpeg: 4.2.4-1ubuntu0.1bbb2

/etc/bigbluebutton/nginx/sip.nginx (sip.nginx)
proxy_pass: 000.000.000.000
protocol: https

/usr/local/bigbluebutton/bbb-webrtc-sfu/config/default.yml (Kurento SFU)
/etc/bigbluebutton/bbb-webrtc-sfu/production.yml (Kurento SFU — override)
kurento.ip: 000.000.000.000
kurento.url: ws://127.0.0.1:8888/kurento
kurento.sip_ip: 000.000.000.000
recordScreenSharing: true
recordWebcams: true
codec_video_main: VP8
codec_video_content: VP8

/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml (HTML5 client)
/etc/bigbluebutton/bbb-html5.yml (HTML5 client config override)
build: 2323
kurentoUrl: wss://bbb.SITE.org/bbb-webrtc-sfu
enableListenOnly: true
sipjsHackViaWs: true

/usr/share/bbb-web/WEB-INF/classes/spring/turn-stun-servers.xml (STUN Server)
stun: stun.3cx.com:3478

/etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini (STUN Server)
stun: 54.37.20.144:3478

CHANGE

nano /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml
sipjsHackViaWs TO FALSE

Now it looks like an adequate job (This message has been on the bb 2.2 server for 2 years)

Connecting via Mozilla Firefox
MICROPHONE:

about:WebRTC

Just listen — everything is ok
Webcams and screen demonstrations work!

There is no result
sudo ufw disable
reboot

I do not know what else to do to make the connection through the microphone work. I tried to connect from the organization’s Internet, via 4G from my phone, from home, and asked colleagues.

The text was updated successfully, but these errors were encountered:

Источник