Wowza Community

WebRTC issue- SDP

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]/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. Windows-Mac-OS-and-Linux

If the files are too big for email transport (20mb) please send a downloadable link to the files.



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.



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 - 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\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\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