Как исправить проблему «m=audio 0 UDP/TLS/RTP/SAVPF 0» для включения потоковой передачи объемного звука (5.1 и 7.1-канальный)

Я создаю потоковое приложение с поддержкой объемного звука, в настоящее время поддерживается стерео и работает потоковая передача. Кодек - Opus, Браузер - Google Chrome

Когда я передаю предложение SDP в браузер, он возвращает меня с помощью m=audio 0 UDP/TLS/RTP/SAVPF 0, затем я загружаю полученный SDP из браузера со следующими изменениями (также это то, что я передаю в предложении sdp с сервера в браузер).

Для 7.1 канала

m=audio 9 UDP/TLS/RTP/SAVPF 111\r\n
a=rtpmap:111 multiopus/48000/8\r\n
a=rtcp-fb:111 transport-cc\r\n
a=fmtp:111 channel_mapping=0,6,1,2,3,4,5,7;num_streams=8;coupled_streams=0;maxaveragebitrate=510000;minptime=10;useinbandfec=1\r\n

Для 5.1 канала

m=audio 9 UDP/TLS/RTP/SAVPF 111\r\n
a=rtpmap:111 multiopus/48000/6\r\n
a=rtcp-fb:111 transport-cc\r\n
a=fmtp:111 a=fmtp:111 channel_mapping=0,4,1,2,3,5;num_streams=4;coupled_streams=2;maxaveragebitrate=510000;minptime=10;useinbandfec=1\r\n

Но в конце потоковое аудио не работает !!!

Предложение SDP с сервера

a=group:BUNDLE 0 1 2
m=audio 47998 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:47998 IN IP4 0.0.0.0
a=candidate:1 1 udp 2122260223 10.40.102.152 47998 typ host
a=mid:0
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=sendonly
a=msid:second_stream_id audio
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 multiopus/48000/8
a=rtcp-fb:111 transport-cc
a=fmtp:111 channel_mapping=0,6,1,2,3,4,5,7;num_streams=8;coupled_streams=0;maxaveragebitrate=510000;minptime=10;useinbandfec=1
a=ptime:10
a=ssrc:1 cname:odrerir
m=video 47998 UDP/TLS/RTP/SAVPF 96 97 101 102 98
c=IN IP4 0.0.0.0
a=rtcp:47998 IN IP4 0.0.0.0
a=candidate:1 1 udp 2122260223 10.40.102.152 47998 typ host
a=mid:1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendonly
a=msid:stream_id fbc-video-0
a=rtcp-mux
a=rtcp-rsize
...

Обрабатывается SDP из браузера после прохождения через функцию setRemoteDescription

a=group:BUNDLE 1 2
m=audio 0 UDP/TLS/RTP/SAVPF 0
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:HSRB
a=ice-pwd:xzh/4T2ENxA4tO4mUMlTN42s
a=ice-options:trickle
a=fingerprint:sha-256 5A:71:54:A8:A4:82:58:AD:1E:73:7B:65:2E:FC:D6:E0:CA:47:76:D1:FA:B9:33:F4:90:FE:77:74:64:C5:08:02
a=setup:active
a=mid:0
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=recvonly
a=rtcp-mux
a=ssrc:3852651172 cname:4sZE5ap0JbPq4Is1
m=video 9 UDP/TLS/RTP/SAVPF 96 97 101 102 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Z8bB
a=ice-pwd:hOiAOMEYMZlPVLZYrcvQCIH6
a=ice-options:trickle
a=fingerprint:sha-256 5A:71:54:A8:A4:82:58:AD:1E:73:7B:65:2E:FC:D6:E0:CA:47:76:D1:FA:B9:33:F4:90:FE:77:74:64:C5:08:02
a=setup:active
a=mid:1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=recvonly
a=rtcp-mux
a=rtcp-rsize
...

Munge Sdp, который мы снова отправляем в браузер

a=group:BUNDLE 0 1 2
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Z8bB
a=ice-pwd:hOiAOMEYMZlPVLZYrcvQCIH6
a=ice-options:trickle
a=fingerprint:sha-256 5A:71:54:A8:A4:82:58:AD:1E:73:7B:65:2E:FC:D6:E0:CA:47:76:D1:FA:B9:33:F4:90:FE:77:74:64:C5:08:02
a=setup:active
a=mid:0
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=recvonly
a=rtcp-mux
a=rtpmap:111 multiopus/48000/8
a=rtcp-fb:111 transport-cc
a=fmtp:111 channel_mapping=0,6,1,2,3,4,5,7;num_streams=8;coupled_streams=0;maxaveragebitrate=510000;minptime=10;useinbandfec=1
a=ssrc:3852651172 cname:4sZE5ap0JbPq4Is1
m=video 9 UDP/TLS/RTP/SAVPF 96 97 101 102 98
c=IN IP4 0.0.0.0
b=AS:19440
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Z8bB
a=ice-pwd:hOiAOMEYMZlPVLZYrcvQCIH6
a=ice-options:trickle
a=fingerprint:sha-256 5A:71:54:A8:A4:82:58:AD:1E:73:7B:65:2E:FC:D6:E0:CA:47:76:D1:FA:B9:33:F4:90:FE:77:74:64:C5:08:02
a=setup:active
a=mid:1
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=recvonly
a=rtcp-mux
a=rtcp-rsize
...

Я заметил, что при обратном вызове setRemoteDesription переданный sdp имеет дополнительное ледяное имя пользователя/пароль

a=ice-ufrag:Z8bB
a=ice-pwd:hOiAOMEYMZlPVLZYrcvQCIH6

которые не те, которые я получил от сервера.