我正在开发使用Wowza创建呼叫的WebRTC流应用程序。我遇到了两个客户端之间的连接问题，其中一个正在使用iOS 12或iOS 11，另一个正在使用PC上的Chrome浏览器。
[我在wowza日志中注意到，即使我将SDP合并为仅包含H264基本配置文件，它在服务器上仍显示为a=fmtp:97 packetization-mode=1;profile-level-id=64C01F;sprop-parameter-sets=J2QAH6xWgKA9puBAQEDaCIRqAA==,KO48sA==。
我发现Webkit雷达https://bugs.webkit.org/show_bug.cgi?id=195124中的错误与上述行为匹配。
我仍然想知道是否可以解决此问题，并迫使另一侧的Chrome浏览器解码视频？
这里是本地SDP：
o=- 9001760195467366328 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS 5113e7f1-363b-406e-bc68-3ae57daa0d1a
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:n8Ba
a=ice-pwd:2NwRnFdR5IvWpNRPiA9UqL6Q
a=ice-options:trickle
a=fingerprint:sha-256 C3:B0:13:62:B2:96:27:6F:4B:F6:97:B4:BE:3C:46:00:98:D1:98:ED:57:80:96:E9:6E:9C:33:9F:3F:2A:70:22
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=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:97 apt=96
a=fmtp:100 apt=99
a=ssrc-group:FID 138058512 1765676750
a=ssrc:138058512 cname:1qSotaZJYR/SLq+u
a=ssrc:138058512 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:138058512 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:138058512 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 cname:1qSotaZJYR/SLq+u
a=ssrc:1765676750 msid:5113e7f1-363b-406e-bc68-3ae57daa0d1a 6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
a=ssrc:1765676750 mslabel:5113e7f1-363b-406e-bc68-3ae57daa0d1a
a=ssrc:1765676750 label:6f3574c4-06ca-49fe-812f-f4e9b9d3cdbf
远程端：
o=WowzaStreamingEngine-next 2021784490 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=msid-semantic: WMS *
m=video 9 UDP/TLS/RTP/SAVPF 99
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:55de6aa9
a=ice-pwd:60187779305a687c507cef701c99a6d2
a=ice-options:trickle
a=fingerprint:sha-256 35:5A:C1:C8:57:EB:46:2C:1E:98:9D:14:B8:4F:80:59:CF:7A:35:4D:57:71:47:8C:6A:9B:76:CA:EE:A9:E5:BC
a=setup:passive
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=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:99 H264/90000
a=rtcp-fb:99 ccm fir
a=rtcp-fb:99 nack
a=rtcp-fb:99 nack pli
a=rtcp-fb:99 goog-remb
a=rtcp-fb:99 transport-cc
a=fmtp:99 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
似乎无论用户选择什么，在调用supportedCodecs方法时都会无条件选择第一个配置文件。就我而言，我通过修改Google WebRTC框架的RTCVideoEncoderFactoryH264.mm文件中的supportedCodecs方法来解决该问题，以使基本配置文件首先出现。但是，我解决了这个问题，因为我只需要支持基线配置文件，但是还需要进行一些修改才能使配置文件成为可选。