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'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 -----------------------
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.
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.
> 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.
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 :)