I’m participating in the WebRTC free preview and experiencing the following error:
DOMException: Failed to set remote offer sdp: Session error code: ERROR_CONTENT. Session error description: Failed to set remote video description send parameters…
I have my 443 streaming port and port 9443 secured with streamlock. My IP in not public as this server is internal only.
Hello @Christopher Kang
So we can get a better look at your WebRTC setup, I would recommend opening a support case here
with including the below info:
Are you using WebRTC publish to WebRTC play or another scenario?
What browser versions you are testing with?
[install-dir]/conf
[install-dir]/logs (only latest logs showing a server restart and connection attempts is needed)
[install-dir]/htdocs (if using)
If you are not sure how to get this information please see the following tutorial.
https://www.wowza.com/docs/how-to-create-a-compressed-zip-file-in-windows-os-x-and-linux Windows-Mac-OS-and-Linux
If the files are too big for email transport (20mb) please send a downloadable link to the files.
Regards,
Jason
Hi Christopher,
Did you manage this problem?
I’m faced with this error after upgrading Chrome to version 57, in version 55 WebRTC worked fine.
Hello @Oleksandr Bohonis
I would recommend making sure that you are on the latest webrtc package. The link to this is in the WebRTC package that was sent to you under, “url.text”.
If that does not help, I would recommend opening a support case with the above info, as this should work in the latest Chrome version.
Regards,
Jason
What is the SDP that is being sent from Wowza? I had some similar issues and it was related to the encoding profile of the content.
Aaron
Aaron - Yes this was ultimately the issue we were experiencing. A main profile was being used to encode. Switching to baseline fixed it.
I tried to change profile to Baseline, but unfortunately it didn’t help me.
Here is my SDP:
sdp: {“type”:“offer”,“sdp”:“v=0\r\no=WowzaStreamingEngine-next 258819460 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 90:DE:C3:2B:D7:F2:1E:A8:69:DF:10:74:2C:5A:3D:87:51:FD:C2:B2:E3:8D:92:3C:39:B9:29:63:42:35:2F:66\r\na=group:BUNDLE video\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=video 9 RTP/SAVPF 97\r\na=rtpmap:97 H264/90000\r\na=fmtp:97 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHuKQFAe2AtwEBAaQeJEV,aM48gA==\r\na=cliprect:0,0,480,640\r\na=framesize:97 640-480\r\na=control:trackID=1\r\nc=IN IP4 0.0.0.0\r\na=sendrecv\r\na=ice-pwd:0d962064aaad498ce4a78f39b7f7d6df\r\na=ice-ufrag:ed9e75c7\r\na=mid:video\r\na=msid:{797cf3cd-8d09-4e59-8912-c769da88efb5} {d9448709-01d1-4fa0-a550-75bdf4111b09}\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-mux\r\na=setup:actpass\r\na=ssrc:1963131891 cname:{39453f88-e972-41b1-bc86-8cfd9e8fb95f}\r\n”}
Configuring the stream for baseline solved my issue. Looks like that’s what you’re using there