Icecast2 не работает с терминатором SSL контейнеров Azure

Я хочу запустить экземпляр Icecast в Azure, используя контейнеры и функции завершения SSL, предоставляемые Azure.

Для тех, кто не знает, Icecast — это медиа-сервер HTTP, состоящий из веб-сервера, обеспечивающего UI/UX, и службы потоковой передачи на одной конечной точке.

Я могу настроить мультимедийное программное обеспечение, такое как Traktor Studio, для прямой трансляции на сервер Icecast.

За последние дни (я могу воссоздать пример и экспортировать шаблон ARM по запросу) я создал экземпляр веб-приложения Azure на основе контейнеров, для которого указан контейнер, ссылка на который указана в сообщении. Установив переменные env, я смог запустить контейнер через HTTP и HTTPS. UX сработал.

Однако потоковая передача — это другое дело. У меня не было и, вероятно, не будет подробного журнала исходной трансляции, но «Трактору» с треском не удалось запустить прямой эфир, поэтому музыка из Icecast не воспроизводится. Если я запускаю тот же контейнер локально в Docker, я могу транслировать на локальный хост как шарм.

Я попробовал использовать Wireshark, отключив HTTPS для поиска реальных данных, и обнаружил, что Traktor (и другие источники, совместимые с Icecast) взаимодействуют с Icecast с помощью необычного метода HTTP.

      SOURCE /thestream.ogg HTTP/1.1
Host: icecasthostexample.azureapp.net
User-Agent: Traktor and version UA
//Some multimedia headers including bitrate
Connection: close

[the ogg stream with music]

Я обнаружил, что Azure отвечаети музыка в Icecast не отправляется. Icecast отображает наличие потока, но попытка его воспроизведения приводит к отсутствию контента.

Судя по моим выводам , приложения-контейнеры Azure — не лучший выбор дляметод, поскольку встроенная в веб-приложение конечная точка HTTP (также работающая как терминатор SSL), вероятно, хочет интерпретировать HTTP-вызов, поэтому с этим не работает. Чтобы уточнить, на этом этапе я не мог запустить Icecast ни через HTTP, ни через HTTPS, потому что веб-приложения для контейнеров ведут себя так по HTTP (и я пробовал HTTP, чтобы отслеживать, что происходит в сети).

В конце концов, мне придется развернуть Icecast через HTTPS, потому что прослушивающие клиенты должны работать через HTTPS. Однако я могу вести трансляцию по протоколу, который предпочитаю. Icecast, как медиа-сервер, может принимать входящую музыку по протоколу HTTP и обслуживать исходящую музыку по протоколу https.

Итак, мой вопрос разделен на две части:

1. Является ли задокументированное поведение нормальным? Каковы ограничения терминатора http(s) в веб-приложениях PaaS? Разве они не могут вести мультимедийные разговоры? Им нужно работать только с основными методами HTTP? (Да, это один вопрос)
2. За исключением виртуальных машин, где я устанавливаю Icecast или развертываю Docker с помощью IaaS, как правильно завершить* трафик HTTP/SSL и направить необработанный TCP-трафик в службу Azure PaaS Docker?

По запросу могу предоставить информацию для воспроизведения сценария.

• Это означает, что я либо снимаю шифрование и маршрутизирую TCP, либо просто маршрутизирую TCP нетронутым.