Сервер - ретранслятор Coturn не работает
Я пытаюсь настроить сервер COTURN для моего приложения на основе WebRTC. Однако я застрял с парой сообщений об ошибках, которые я не в состоянии понять, и не могу найти никакой помощи на них в интернете.
Вот некоторые подробности о приложении:
Два пользователя входят в приложение, и один из них может поделиться своим экраном с другим-таким образом, поток идет только в одном направлении
Я могу заставить приложение работать в интрасети и на некоторых наружные сети. Поэтому я уверен, что приложение отлично работает везде, где достаточно режима оглушения.
Для некоторых сетей кандидаты на оглушение постоянно терпят неудачу, поэтому мне нужно получить сервер поворота для ретрансляции потока.
Я собрал некоторые журналы сервера с сервера, на случай, если кто-то сможет определить проблему на их основе:
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59942
handle_turn_command: STUN method 0x1 ignored
handle_udp_packet: New UDP endpoint: local addr <IP Address>:3478, remote addr <IP Address2>:59944
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
session 128000000000000097: realm <server URL> user <>: incoming packet message processed, error 401: Unauthorised
IPv4. Local relay addr: <IP Address>:64306
session 128000000000000096: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
IPv4. Local relay addr: <IP Address>:65384
session 128000000000000097: new, realm=<server URL>, username=<username>, lifetime=600
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
session 128000000000000097: realm <server URL> user <username>: incoming packet ALLOCATE processed, success
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
handle_turn_command: STUN method 0x1 ignored
session 128000000000000096: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000096: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000097: refreshed, realm=<server URL>, username=<username>, lifetime=0
session 128000000000000097: realm <server URL> user <username>: incoming packet REFRESH processed, success
session 128000000000000096: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59942, reason: allocation timeout
session 128000000000000096: delete: realm=<server URL>, username=<username>
session 128000000000000097: closed (2nd stage), user <username> realm <server URL> origin <>, local <IP Address>:3478, remote <IP Address2>:59944, reason: allocation timeout
session 128000000000000097: delete: realm=<server URL>, username=<username>
Вот как мой turnserver.conf файл выглядит так:
listening-port=3478
#tls-listening-port=443
realm=subdomain.domain.com
server-name=subdomain.domain.com
lt-cred-mech
userdb=/etc/turnserdb.conf
cert=/home/ubuntu/certificate.crt
pkey=/home/ubuntu/qc.key
pkey-pwd=L1ght!t
no-stdout-log
Verbose
Я есть особое беспокойство вызывают следующие моменты:
Должен ли я предполагать, что, поскольку мой код работает с сервером STUN, он будет работать и срабочим сервером TURN? Следовательно, ошибка означает, что проблема с сервером поворота?
Я вижу пару ошибок, указывающих на "тайм-аут выделения". Означает ли это, что вы ссылаетесь на любое выделение оперативной памяти / процессора / сети, которое может быть недостаточным?
В некоторых запросах часть имени пользователя пуста ''вместо", и за ним следует '401 несанкционированный', в то время как я трижды проверил конфигурации RTCPeerConnection - они действительно содержат имя пользователя и пароль.
Кроме журналов выше, я видел, что "438 неправильных nonce" приходили довольно часто. Я немного поискал об этом, но это не похоже на то, что я могу контролировать через JS. Связано ли это с какими-либо конфигурациями серверов?
Спасибо! Ценю вашу помощь.
3 ответов:
Как выглядит ваша конфигурация?
Мой рабочий пример использования webRTC:
Sudo nano / etc / turnserver.конф ->
listening-port=80 tls-listening-port=1133 fingerprint lt-cred-mech userdb=/etc/turnuserdb.conf realm=subdomain.domain.com server-name=subdomain.domain.com total-quota=100 bps-capacity=0 stale-nonce log-file=/var/log/turnserver/turn.log no-loopback-peers no-multicast-peersSudo nano / etc / turnuserdb.конф - >Имя Пользователя: Passwort
Вы также должны разрешить эти порты в брандмауэре, если они включены. Проверьте ваш сервер здесь: Trickle ICE
Обратите внимание, что вы всегда должны использовать ваш ip / url с портом, как 123.456.789.10: 80
У меня было несколько проблем с настройкой сервера поворота.
Во-первых, мы взяли его из блога, которому было около двух лет. В результате установка была также двухлетней давности-котурн Монца. Идеальным способом для начала было бы получить Coturn AMI (Amazon Machine Image)(версия 4.5.0.6 details) и использовать его для настройки сервера. В качестве альтернативы, мы должны были, по крайней мере, взять самую последнюю установку через репозиторий git.
Вторая проблема была с конфигурацией. Еще до размещения вопроса здесь, мы пропустили открытие необходимых портов на сервере. Как только мы это сделали, мы начали получать оглушающие ответы, но реле еще не работало.
Третья ключевая проблема была с конфигурациями в Turnserver.конфигурационный файл. Мы едва прошли через все конфигурации, и после ответа Поляриса мы сделали это. Конфигурационный файл содержит достаточное объяснение для каждой конфигурации, и проблема действительно была с конфигурации.
Последняя проблема была с тестовыми случаями. Мы хотели убедиться, что ретранслятор "работает", и на ранних этапах тестирования мы определили конкретную сетевую установку, которая потребует ретрансляции (т. е. только STUNs не сможет выполнить запрос.) В конце концов мы узнали, что даже сервер TURN не сможет пройти через эту настройку.
Мы потратили некоторое время, пробуя режим NOSTUN (он есть в turnserver.config), но из-за отсутствия из хороших тестовых случаев мы никогда не могли подтвердить, что реле работает.
Я не совсем понимаю тестовый код на страницеTrickle ICE , но я считаю, что результаты там надежны.
Вот несколько советов по устранению неполадок:
- убедитесь, что вы добавили опцию отпечатков пальцев, как упоминалось в Polaris
Попробуйте пока использовать только статическое имя пользователя и пароль, например:
User=username: test
Затем включите это в свой PeerConnectionConfig:
{'адрес URL': 'включить:сервер.ком:3478', учетных данных: "тест", имя пользователя: 'имя пользователя'}
Используйте расширение chrome "webrtc Network Limiter", чтобы заставить WebRTC использовать поворот сервер.
Прокомментируйте сертификат и pkey на данный момент.
Comments