Каков минимальный SDP-ответ для получения WebRTC Audio и видео?

Question

В настоящее время я пытаюсь передать WebRTC MediaStreams на свой сервер, где он будет записан. К сожалению, нет конечной точки Java webRTC, поэтому я хочу реализовать этот специальный случай сам.

Теперь, учитывая предложение sdp и общедоступный IP-адрес моего сервера, как мне создать минимальный ответ sdp, необходимый браузеру, чтобы начать квитирование DTLS, необходимое для SRTP?

Если вы хотите, чтобы объяснить на конкретном примере, пожалуйста, используйте SDP предложение ниже (вытекающие из хрома с одним видео MediaStream) и предположим, что сервера общественного IP, чтобы быть «12.34.56.78»:

v=0 
o=- 8782460735244849509 3 IN IP4 127.0.0.1 
s=- 
t=0 0 
a=group:BUNDLE video 
a=msid-semantic: WMS oHpG0QpIucmqjpjl26NElSfQfQD9Lnetl3Tn 
m=video 59183 RTP/SAVPF 100 116 117 96 
c=IN IP4 192.168.178.37 
a=rtcp:59183 IN IP4 192.168.178.37 
a=candidate:1833114227 1 udp 2122063615 192.168.178.37 59183 typ host generation 0 
a=candidate:1833114227 2 udp 2122063615 192.168.178.37 59183 typ host generation 0 
a=candidate:599844483 1 tcp 1518083839 192.168.178.37 0 typ host tcptype active generation 0 
a=candidate:599844483 2 tcp 1518083839 192.168.178.37 0 typ host tcptype active generation 0 
a=ice-ufrag:6iMBf9B5eBE6OQmW 
a=ice-pwd:cc+Og0UJeyl5aUAYHNU2ixY0 
a=ice-options:google-ice 
a=fingerprint:sha-256 5C:1C:0B:92:6C:E7:87:D1:E0:83:26:2E:D9:90:B2:58:B0:76:D6:AF:D1:E9:38:91:C0:AF:1D:92:13:45:13:AC 
a=setup:actpass 
a=mid:video 
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 
a=sendrecv 
a=rtcp-mux 
a=rtpmap:100 VP8/90000 
a=rtcp-fb:100 ccm fir 
a=rtcp-fb:100 nack 
a=rtcp-fb:100 nack pli 
a=rtcp-fb:100 goog-remb 
a=rtpmap:116 red/90000 
a=rtpmap:117 ulpfec/90000 
a=rtpmap:96 rtx/90000 
a=fmtp:96 apt=100 
a=ssrc-group:FID 2157921332 2260451967 
a=ssrc:2157921332 cname:36oaVisUAzbVEQm5 
a=ssrc:2157921332 msid:oHpG0QpIucmqjpjl26NElSfQfQD9Lnetl3Tn bdea0afa-598b-4829-9dfd-ceb9e8c6d23d 
a=ssrc:2157921332 mslabel:oHpG0QpIucmqjpjl26NElSfQfQD9Lnetl3Tn 
a=ssrc:2157921332 label:bdea0afa-598b-4829-9dfd-ceb9e8c6d23d 
a=ssrc:2260451967 cname:36oaVisUAzbVEQm5 
a=ssrc:2260451967 msid:oHpG0QpIucmqjpjl26NElSfQfQD9Lnetl3Tn bdea0afa-598b-4829-9dfd-ceb9e8c6d23d 
a=ssrc:2260451967 mslabel:oHpG0QpIucmqjpjl26NElSfQfQD9Lnetl3Tn 
a=ssrc:2260451967 label:bdea0afa-598b-4829-9dfd-ceb9e8c6d23d 

Answer 1

Вам нужно ответить с ip: port, где вы будете получать медиа и добавлять одного кандидата только с этой информацией. В приведенном ниже примере пусть порт будет 22222.

Вы можете отфильтровать кодек, который хотите использовать. Я выбрал VP8. Обратите внимание, что вам необходимо обновить строку m = video, чтобы включить только правильный тип полезной нагрузки (100 в случае VP8).

Если вы не поддерживаете расширения, вы должны также удалить их (а = extmap ...)

Если вы не поддерживаете сверток, (и вам не нужны для видео только вызов) вам нужно удалить атрибуты a = GROUP ... и a = mid .... Также в этом случае вам не нужно генерировать теги ssrc, поэтому вы можете просто удалить a = ssrc ... также.

Вы получили настройку: actpass, так что вам нужно ответить на настройку: пассивный или настроенный: активен в зависимости от того, хотите ли вы начать проверку подключения или позволить начать.

Хорошо, до сих пор вы удаляете только то, что не является обязательным. Теперь вам нужно добавить свою часть в SDP. Вам необходимо создать ледовые удостоверения и добавить их в ответ.

Наконец, вам необходимо иметь собственный сертификат на сервере (он может быть самозаверяющим) и делиться отпечатком на SDP.

v=0 
o=- 6548769878907123 4 IN IP4 127.0.0.1 
s=- 
t=0 0 
m=video 22222 RTP/SAVPF 100 
c=IN IP4 12.34.56.78 
a=rtcp:22222 IN IP4 12.34.56.78 
a=candidate:234234234 1 udp 768678678678 12.34.56.78 22222 typ host generation 0 
a=ice-ufrag:yourgeneratedufrag 
a=ice-pwd:yourgeneratedicepw 
a=ice-options:google-ice 
a=fingerprint:sha-256 YOUR_CERTIFICATE_FINGERPRINT_GOES_HERE 
a=setup:passive 
a=sendrecv 
a=rtcp-mux 
a=rtpmap:100 VP8/90000 
a=rtcp-fb:100 ccm fir 
a=rtcp-fb:100 nack 
a=rtcp-fb:100 nack pli 
a=rtcp-fb:100 goog-remb 

Пожалуйста, обратите внимание, что вам нужно обрабатывать и генерировать ICE (с проверкой подлинности запросов STUN) перед рукопожатием DTLS.

Таким образом, это не простая задача ...

Answer 2

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

Для преобразования СДП вы можете захотеть взглянуть на некоторый код от моего сервера WebRTC Echo, который делает что-то подобное: https://github.com/Innovailable/webrtc-echo/blob/master/src/echo.coffee

Answer 3

В то время как вы, например, имеет кандидатов с таким же IP, тем более общий случай, когда разные кандидаты из разных частей среды ICE.

2 Кандидаты от IP Application 2 кандидатов от STUN сервера 2 Кандидаты от TURN сервера

Latching на одну над другой основан на вашем предлагающей эквивалентный набор от вашего конца Media Server и затем Соединение ICE-пакетов происходит.В основном это конкретные маршруты, которые должны быть предприняты до того, как зацепить конечные точки, чтобы они могли установить двунаправленное рукопожатие, используя один конкретный набор. Медиа/RTP должны начинать поступать только по этому конкретному маршруту.

Предыдущий ответ был обычным вариантом ответа на предложение SDP, который больше не имеет отношения к ICE.