Android-App basierend auf WebRTC mit Peerconnection-Server ohne Audio/Video ⇐ Android

[Anonymous]

Ich implementieren eine WebRTC-basierte Android-Anwendung und verwende die AppRtcDemo-Android-Anwendung als Referenz. Ich habe die Schnittstelle für „http://appspot.apprtc.com“ entfernt und Code hinzugefügt, um „peerconnection_server“ als Signalisierungsserver zu verwenden, der im Peer-Verbindungsbeispiel bereitgestellt wird.

Ich kann mich beim Server anmelden und auch SDP- und ICE-Kandidaten mit verbundenen Kollegen austauschen, aber ich kann kein Audio/Video hören/sehen.

Details sind wie folgt:

Code: Select all

Offer SDP:
{"type":"offer","sdp":"v=0\r\no=- 3083264015449675190 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS stream_label\r\nm=audio 1 RTP/SAVPF 103 111 9 102 0 8 106 105 13 127 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:v23o+LTxR1444+Ub\r\na=ice-pwd:uHXWxLYsx8Mzd2hyMjRIVtIh\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 A1:08:52:A1:6F:B8:5C:49:4A:28:1E:68:8E:48:92:8E:50:70:FC:9D\r\na=setup:actpass\r\na=mid:audio\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:9 G722/16000\r\na=rtpmap:102 ILBC/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:106 CN/32000\r\na=rtpmap:105 CN/16000\r\na=rtpmap:13 CN/8000\r\na=rtpmap:127 red/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:2317242907 cname:oUWOTva6C9Z+nlgN\r\na=ssrc:2317242907 msid:stream_label audio_label\r\na=ssrc:2317242907 mslabel:stream_label\r\na=ssrc:2317242907 label:audio_label\r\nm=video 1 RTP/SAVPF 100 116 117 96\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:v23o+LTxR1444+Ub\r\na=ice-pwd:uHXWxLYsx8Mzd2hyMjRIVtIh\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 A1:08:52:A1:6F:B8:5C:49:4A:28:1E:68:8E:48:92:8E:50:70:FC:9D\r\na=setup:actpass\r\na=mid:video\r\na=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:100 VP8/90000\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=rtcp-fb:100 goog-remb\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\na=rtpmap:96 rtx/90000\r\na=fmtp:96 apt=100\r\na=ssrc-group:FID 1729118744 991715775\r\na=ssrc:1729118744 cname:oUWOTva6C9Z+nlgN\r\na=ssrc:1729118744 msid:stream_label video_label\r\na=ssrc:1729118744 mslabel:stream_label\r\na=ssrc:1729118744 label:video_label\r\na=ssrc:991715775 cname:oUWOTva6C9Z+nlgN\r\na=ssrc:991715775 msid:stream_label video_label\r\na=ssrc:991715775 mslabel:stream_label\r\na=ssrc:991715775 label:video_label\r\n"}

Received Answer SDP:
{"type":"answer","sdp":"v=0\r\no=- 355590986358350998 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS UTyDi2fxFdwJMAVd74dfN8GUGyDzADaZGzFw\r\nm=audio 1 RTP/SAVPF 111 103 0 8 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:VVM+/WC3L91/+EQj\r\na=ice-pwd:tqnMLdOnmAZJjp1wKLX0GDrv\r\na=fingerprint:sha-256 49:97:15:F8:F4:57:3D:AE:20:FF:5F:D9:AE:0C:CD:5D:D9:E0:53:39:01:45:77:56:E6:84:C2:FF:BC:B9:A4:94\r\na=setup:active\r\na=mid:audio\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111 opus/48000/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:126 telephone-event/8000\r\na=maxptime:60\r\na=ssrc:1040365324 cname:812osY2x1QM1y9eA\r\na=ssrc:1040365324 msid:UTyDi2fxFdwJMAVd74dfN8GUGyDzADaZGzFw 95742eb0-ea65-489f-83e5-ab9c87eb63ab\r\na=ssrc:1040365324 mslabel:UTyDi2fxFdwJMAVd74dfN8GUGyDzADaZGzFw\r\na=ssrc:1040365324 label:95742eb0-ea65-489f-83e5-ab9c87eb63ab\r\nm=video 1 RTP/SAVPF 100 116 117\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:VVM+/WC3L91/+EQj\r\na=ice-pwd:tqnMLdOnmAZJjp1wKLX0GDrv\r\na=fingerprint:sha-256 49:97:15:F8:F4:57:3D:AE:20:FF:5F:D9:AE:0C:CD:5D:D9:E0:53:39:01:45:77:56:E6:84:C2:FF:BC:B9:A4:94\r\na=setup:active\r\na=mid:video\r\na=extmap:2 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:100 VP8/90000\r\na=rtcp-fb:100 ccm fir\r\na=rtcp-fb:100 nack\r\na=rtcp-fb:100 nack pli\r\na=rtcp-fb:100 goog-remb\r\na=rtpmap:116 red/90000\r\na=rtpmap:117 ulpfec/90000\r\na=ssrc:2450358247 cname:812osY2x1QM1y9eA\r\na=ssrc:2450358247 msid:UTyDi2fxFdwJMAVd74dfN8GUGyDzADaZGzFw 0e99314b-c8c8-4308-adb8-be7d0c647dff\r\na=ssrc:2450358247 mslabel:UTyDi2fxFdwJMAVd74dfN8GUGyDzADaZGzFw\r\na=ssrc:2450358247 label:0e99314b-c8c8-4308-adb8-be7d0c647dff\r\n"}

Beide Clients sind mit demselben WLAN-AP verbunden,

Es ist also nicht erforderlich, ICE zu verwenden, aber die Stun-URL wird dennoch als „stun:stun.l.google.com:19302“ bereitgestellt.

Code: Select all

Also in logs i see following print:
Changing voice state, recv=0 send=0
Changing voice state, recv=0 send=0
Changing voice state, recv=0 send=0
Changing voice state, recv=0 send=0
Changing voice state, recv=1 send=0
Changing voice state, recv=1 send=0
Changing voice state, recv=0 send=0
Changing voice state, recv=0 send=0

Clients verwenden peerconnection_server als Signalisierungsserver.

Ich kann nicht herausfinden, wo das Problem liegt.

Kann mir bitte jemand dabei helfen?