<div dir="ltr">Here's my situation: <div>* remote peer (ios) produces an sdp offer with h264. I negotiate with webrtcbin, and the remote peer sends in video.</div><div>* a second peer (ios) joins, and my media server creates a new webrtcbin instance, and depayloads/repayloads the h264 from the first webrtcbin to the 2nd</div><div>* webrtcbin instance 2 creates an offer. </div><div>* the 2nd remote peer rejects the offer with the message: "Failed to set remote offer sdp: Failed to set remote video description send parameters'.'</div><div><br></div><div>From what I've read, I *believe* the 2nd peer is rejecting the offer because of the h264 profile offered by webrtcbin.</div><div><br></div><div>The original offer from the video producing peer looks like this (relevant parameters):</div><div>a=rtpmap:98 H264/90000<br>a=rtcp-fb:98 goog-remb<br>a=rtcp-fb:98 transport-cc<br>a=rtcp-fb:98 ccm fir<br>a=rtcp-fb:98 nack<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1<br></div><div><br></div><div>And then when webrtcbin produces the offer for the second peer, it looks like this:</div><div>a=rtpmap:98 H264/90000<br>a=rtcp-fb:98 nack pli<br>a=fmtp:98 packetization-mode=1;profile-level-id=42001f;sprop-parameter-sets=J0IAH6tAUB7TUCAgKkG0EQjUAA==,KM48MA==<br></div><div><br></div><div>So the video sending peer offered profile level 42e01f. But for the same h264 stream, webrtcbin offered profile level 42001f.</div><div><br></div><div>What's going on here? What is the correct behavior?</div><div><br></div><div>Chrome accepts the offer and plays the video just fine. Safari does not. </div><div><br></div><div><br></div></div>