[webrtc-pc] Missing CNAME in RID based simulcast offer (#2114)

ibc has just created a new issue for https://github.com/w3c/webrtc-pc:

== Missing CNAME in RID based simulcast offer ==
Just wondering if the simulcast video SDP m= section should signal the `CNAME` into it or not.

### Firefox

This is a video m= section with simulcast produced by Firefox:

<details>

```
m=video 51480 UDP/TLS/RTP/SAVPF 120 121 126 97
c=IN IP4 88.21.227.155
a=bundle-only
a=sendonly
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:121 max-fs=12288;max-fr=60
a=ice-pwd:6542d3c9d4f263a124f4754980c4cdb6
a=ice-ufrag:b5b7831a
a=mid:1
a=msid:- {edaf93d8-5f50-0a49-9cf6-9dbf7e1c7caf}
a=rid:high1 send
a=rid:medium1 send
a=rid:low1 send
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:121 VP9/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=simulcast: send rid=high1;medium1;low1
a=ssrc:3444738190 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
a=ssrc:1693134513 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
a=ssrc:3248117645 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
```

</details>


It signals the `CNAME` value in `a=ssrc` lines:

```
a=ssrc:3444738190 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
a=ssrc:1693134513 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
a=ssrc:3248117645 cname:{a35cb30a-6d20-3147-b3aa-b156114b1552}
```


### Chrome M74

However, since in [Chrome M74 with `rid` based simulcast there is no `a=ssrc` lines](https://github.com/w3c/webrtc-pc/issues/1174) (ok not needed since `mid` and `rid` do the work) we get no `CNAME` at all:

<details>

```
v=0
o=- 4475402510119283512 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS ux6BnSURfcW7X6XyQIQGzpTQC9EIz7ZUCVXv
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 122 127 121 125 107 108 109 124 120 123 119 114 115 116
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:SDCL
a=ice-pwd:/QejtpsepgzkUiGHdCj49NcL
a=ice-options:trickle
a=fingerprint:sha-256 05:18:EE:03:06:36:C5:E1:1F:BB:FA:1C:29:8A:5E:24:63:3D:0E:E4:EF:00:53:2B:6A:B0:D7:30:92:9E:24:13
a=setup:actpass
a=mid:0
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:12 urn:3gpp:video-orientation
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:ux6BnSURfcW7X6XyQIQGzpTQC9EIz7ZUCVXv 0a9aeb9a-f7bd-457a-a4ab-ac06e4b21f86
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 H264/90000
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:114 red/90000
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 ulpfec/90000
a=rid:0 send
a=rid:1 send
a=rid:2 send
a=simulcast:send 0;1;2
```

</details>

One may think that we can get the CNAME later by inspecting `rtpSender.getParameters()`, but it does not "work" (this may be a bug in libwebrtc M74):

```js
videoRtpSender.getParameters().rtcp

// => {cname: "", reducedSize: true}
```


### Spec and CNAME

[JSEP](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-26) does not mention `CNAME` at all. The only it says is:

> Changes in draft-11:
>
>   o  Clarified handling of RTP CNAMEs.

(well, it's not "clarified" at all, it's just that the word "CNAME" no longer appears in the draft...).

How is this supposed to work? Must the SDP offer include the used `CNAME` somewhere? If so, do we need some kind of new `a=cname:xxxxxxx`? Or is it just that signaling the `CNAME` is just optional and the remote is supposed to learn it by inspecting RTCP SDES packets and matching the media `ssrc` into them (which should have be learnt before via `rid` matching)?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2114 using your GitHub account

Received on Tuesday, 5 March 2019 10:59:44 UTC