Bug 189716 – When "WebRTC Unified Plan" is enabled, pc.createOffer() produces SDP without m lines

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

[Iñaki Baz]

To reproduce it, enable "WebRTC Unified Plan" in the "Develop -> Experimental Features" menu of Safari (12.1), and run this code in the console:

-----------------------
const pc = new RTCPeerConnection({ iceServers: [] });

pc.addTransceiver('audio');
pc.addTransceiver('video');

pc.createOffer().then((offer) => console.warn(offer.sdp));
-----------------------

It prints the following output:

-----------------------
v=0
o=- 7225292094638875391 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS
-----------------------

Obviously it lacks the m=audio and m=video sections for receiving audio and video (this is, with a=recvonly as expected).

If we run the same code after disabling the "WebRTC Unified Plan", it prints:

-----------------------
v=0
o=- 8747258320683116984 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qTLo
a=ice-pwd:996s/s3CJPo0n9gq4l0o0cgB
a=ice-options:trickle
a=fingerprint:sha-256 E4:98:4D:51:04:23:31:D6:9E:62:E4:BA:EF:1B:6C:ED:FB:DD:E0:FE:0D:EC:7E:1B:DF:84:B5:8E:3D:EF:57:53
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:qTLo
a=ice-pwd:996s/s3CJPo0n9gq4l0o0cgB
a=ice-options:trickle
a=fingerprint:sha-256 E4:98:4D:51:04:23:31:D6:9E:62:E4:BA:EF:1B:6C:ED:FB:DD:E0:FE:0D:EC:7E:1B:DF:84:B5:8E:3D:EF:57:53
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=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/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=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 H264/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 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 red/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 ulpfec/90000
-----------------------

[Iñaki Baz]

I've tested the same in Chrome Canary by enabling Unified Plan as follows:

-----------------------
const pc = new RTCPeerConnection({ iceServers: [], sdpSemantics: 'unified-plan' });

pc.addTransceiver('audio');
pc.addTransceiver('video');

pc.createOffer().then((offer) => console.warn(offer.sdp));
-----------------------

It prints a proper SDP offer with m lines for receiving audio and video as expected (although there is a=recvonly, which may be a bug in Chrome):

-----------------------
VM42:6 v=0
o=- 968997957514326608 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:UPDo
a=ice-pwd:bl9PQhfmncY6aE3bDzh5NISI
a=ice-options:trickle
a=fingerprint:sha-256 76:07:ED:27:35:EA:6C:92:63:E4:2B:D5:6B:F7:CB:00:AE:3A:0B:32:76:BB:42:1B:68:F6:82:73:C6:59:A8:5E
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:- 26b44ab2-6c7d-48ba-830f-2fd5e112e7c5
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1463073274 cname:dJpJIP1j8p0MyEs5
a=ssrc:1463073274 msid: 26b44ab2-6c7d-48ba-830f-2fd5e112e7c5
a=ssrc:1463073274 mslabel:
a=ssrc:1463073274 label:26b44ab2-6c7d-48ba-830f-2fd5e112e7c5
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
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:UPDo
a=ice-pwd:bl9PQhfmncY6aE3bDzh5NISI
a=ice-options:trickle
a=fingerprint:sha-256 76:07:ED:27:35:EA:6C:92:63:E4:2B:D5:6B:F7:CB:00:AE:3A:0B:32:76:BB:42:1B:68:F6:82:73:C6:59:A8:5E
a=setup:actpass
a=mid:1
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:- 8e030833-9ed9-431f-92da-26ceba9f2bde
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 x-google-profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 H264/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 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
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=0;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=1;profile-level-id=42e01f
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=0;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=1;profile-level-id=4d0032
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=640032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:114 ulpfec/90000
a=ssrc-group:FID 1691811844 2956212778
a=ssrc:1691811844 cname:dJpJIP1j8p0MyEs5
a=ssrc:1691811844 msid: 8e030833-9ed9-431f-92da-26ceba9f2bde
a=ssrc:1691811844 mslabel:
a=ssrc:1691811844 label:8e030833-9ed9-431f-92da-26ceba9f2bde
a=ssrc:2956212778 cname:dJpJIP1j8p0MyEs5
a=ssrc:2956212778 msid: 8e030833-9ed9-431f-92da-26ceba9f2bde
a=ssrc:2956212778 mslabel:
a=ssrc:2956212778 label:8e030833-9ed9-431f-92da-26ceba9f2bde

-----------------------

[youenn fablet]

Hi Inaki,

Thanks for the report!
I reproduced the issue in latest STP.
I believe this is now fixed in WebKit ToT and should be fine in latest WebKit nightlies if you want to have a try.
Let me know any issue you may spot in that area, this will be very useful!
I'll close this bug, please reopen if needed.

[Iñaki Baz]

Hi, I won't be able to check this issue in webkit nightly build for a while, but trust you :)

However, when reporting this issue I've also found a bug in latest Chrome, which I've reported here:

https://bugs.chromium.org/p/webrtc/issues/detail?id=9765

Basically, in my example code (and if I'm not very wrong), both m=audio and m=video sections should have a=recvonly rather than a=sendrecv. If you think this may be a bug you may want to check what your latest Safari/webkit produces.

Thanks a lot.

[youenn fablet]

> Basically, in my example code (and if I'm not very wrong), both m=audio and
> m=video sections should have a=recvonly rather than a=sendrecv. If you think
> this may be a bug you may want to check what your latest Safari/webkit
> produces.

Reading https://w3c.github.io/webrtc-pc/#dom-rtcrtptransceiverinit, the default "direction" value is "sendrecv". This seems to be inline with what Chrome is generating.

[Iñaki Baz]

IMHO signaling a=sendrecv when you have nothing to send is a bug (or a bug in the spec). But, anyway, I hate SDP so will just try to live with it :)