Wrong arguments order in candidate_from_sdp with Google Nest Cam WebRTC stream

I’m trying to read a WebRTC Stream from Google Nest Cam with the videostream-cli/cli.py example.

I’ve created an SDP offer with the following configuration:

pc.addTransceiver("audio", direction="recvonly")
pc.addTransceiver("video", direction="recvonly")
pc.createDataChannel(label="dataSendChannel")
await pc.setLocalDescription(await pc.createOffer())

And I got this SDP answer from Google: v=0\r\no=- 0 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE 0 2 1\r\na=msid-semantic: WMS 15858084926298797471\/3462220087 virtual-6666\r\na=ice-lite\r\nm=audio 19305 UDP\/TLS\/RTP\/SAVPF 96\r\nc=IN IP4 172.253.117.127\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=candidate: 1 udp 2113939711 2607:f8b0:400e:c0a::7f 19305 typ host generation 0\r\na=candidate: 1 tcp 2113939710 2607:f8b0:400e:c0a::7f 19305 typ host tcptype passive generation 0\r\na=candidate: 1 ssltcp 2113939709 2607:f8b0:400e:c0a::7f 443 typ host generation 0\r\na=candidate: 1 udp 2113932031 172.253.117.127 19305 typ host generation 0\r\na=candidate: 1 tcp 2113932030 172.253.117.127 19305 typ host tcptype passive generation 0\r\na=candidate: 1 ssltcp 2113932029 172.253.117.127 443 typ host generation 0\r\na=ice-ufrag:ICOZDGWXSEYVE\/1H\r\na=ice-pwd:redacted\r\na=fingerprint:sha-256 69:74:37:47:12:20:18:7B:2B:E1:A8:F0:6B:3A:81:08:CF:70:21:D9:35:A9:12:94:67:98:B6:85:C9:BC:D6:2E\r\na=setup:passive\r\na=mid:0\r\na=sendrecv\r\na=msid:virtual-6666 virtual-6666\r\na=rtcp-mux\r\na=rtpmap:96 opus\/48000\/2\r\na=fmtp:96 minptime=10;useinbandfec=1\r\na=ssrc:6666 cname:6666\r\nm=video 9 UDP\/TLS\/RTP\/SAVPF 97 98 101 102\r\nc=IN IP4 0.0.0.0\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=ice-ufrag:ICOZDGWXSEYVE\/1H\r\na=ice-pwd:redacted\r\na=fingerprint:sha-256 69:74:37:47:12:20:18:7B:2B:E1:A8:F0:6B:3A:81:08:CF:70:21:D9:35:A9:12:94:67:98:B6:85:C9:BC:D6:2E\r\na=setup:passive\r\na=mid:1\r\na=extmap:2 http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=sendrecv\r\na=msid:15858084926298797471\/3462220087 15858084926298797471\/3462220087\r\na=rtcp-mux\r\na=rtpmap:97 VP8\/90000\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 goog-remb\r\na=rtpmap:98 rtx\/90000\r\na=fmtp:98 apt=97\r\na=rtpmap:101 H264\/90000\r\na=rtcp-fb:101 ccm fir\r\na=rtcp-fb:101 nack\r\na=rtcp-fb:101 nack pli\r\na=rtcp-fb:101 goog-remb\r\na=fmtp:101 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f\r\na=rtpmap:102 rtx\/90000\r\na=fmtp:102 apt=101\r\na=ssrc-group:FID 3462220087 259725458\r\na=ssrc:3462220087 cname:3462220087\r\na=ssrc:259725458 cname:3462220087\r\nm=application 9 DTLS\/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:ICOZDGWXSEYVE\/1H\r\na=ice-pwd:redacted\r\na=fingerprint:sha-256 69:74:37:47:12:20:18:7B:2B:E1:A8:F0:6B:3A:81:08:CF:70:21:D9:35:A9:12:94:67:98:B6:85:C9:BC:D6:2E\r\na=setup:passive\r\na=mid:2\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n

The code crashes in the candidate_from_sdp function, and debugging it I found that in the following code:

    bits = sdp.split()
    assert len(bits) >= 8

    candidate = RTCIceCandidate(
        component=int(bits[1]),
        foundation=bits[0],
        ip=bits[4],
        port=int(bits[5]),
        priority=int(bits[3]),
        protocol=bits[2],
        type=bits[7],
    )

I have the candidate arguments in a different order than expected: sdp content: 1 udp 2113939711 2607:f8b0:400e:c0a::7f 19305 typ host generation 0 so the bits array contains: ['1', 'udp', '2113939711', '2607:f8b0:400e:c0a::7f', '19305', 'typ', 'host', 'generation', '0']

[juberti]

I’d actually suggest filing a bug at bugs.webrtc.org about this, Chrome really ought not to do this. I can route it to the right people once filed.

[danieleratti]

I managed to get this Nest stream working. In case, I’ve created the pull request #590 if you want to add this more relaxed version of the protocol in this project considering Google Chrome is accepting it.