Wanted to mention that one of our clients are reporting the same issue on their PC (windows 10)

Additionaly, there are more methods, we did disable extensions. Pretty much, we did all of the possible troubleshooting methods from this link: 

http://troubleshooter.xyz/wiki/aw-snap-google-chrome-error/

I managed to capture the logs via terminal:

Alexanders-MacBook-Pro:~ alexandersenesac$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging --v=1
[10193:85251:0305/114556.385418:ERROR:browser_gpu_channel_host_factory.cc(121)] Failed to launch GPU process.
2018-03-05 11:45:56.588 Google Chrome[10193:4627233] *** Owner supplied to -[NSTrackingArea initWithRect:options:owner:userInfo:] referenced a deallocating object. Tracking area behavior is undefined. Break on NSTrackingAreaDeallocatingOwnerError to debug.
[10193:85251:0305/114556.861153:ERROR:browser_gpu_channel_host_factory.cc(121)] Failed to launch GPU process.
[10193:775:0305/114557.016380:ERROR:gpu_process_transport_factory.cc(1009)] Lost UI shared context.
[10208:34387:0305/114629.887433:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}
[10208:775:0305/114629.887583:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN
[10208:34387:0305/114630.010355:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}
[10208:775:0305/114630.010542:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN


#
# Fatal error in ../../third_party/webrtc/modules/rtp_rtcp/source/rtp_format_h264.cc, line 296
# last system error: 0
# Check failed: payload_size_left >= fragment->length (1188 vs. 1210)
# Payload size left 1188, fragment length 1210, packetization mode SingleNalUnit

Crash I'd: 0d6a116bf3540ac7

Stack trace
============

Thread 29 (id: 4623549) CRASHED [0x00000000 / 0x00000000 @ 0x00007fff59d6be3e ] MAGIC SIGNATURE THREAD
Stack Quality84%Show frame trust levels
0x00007fff59d6be3e	(libsystem_kernel.dylib + 0x0001be3e )	__pthread_kill
0x00007fff59cc8311	(libsystem_c.dylib + 0x0005d311 )	abort
0x0000000103476274	(Google Chrome Framework -checks.cc:110 )	rtc::FatalMessage::~FatalMessage()
0x0000000103476288	(Google Chrome Framework -checks.cc:103 )	rtc::FatalMessage::~FatalMessage()
0x0000000106a1392e	(Google Chrome Framework -rtp_format_h264.cc:296 )	webrtc::RtpPacketizerH264::PacketizeSingleNalu(unsigned long)
0x0000000106a136c7	(Google Chrome Framework -rtp_format_h264.cc:178 )	webrtc::RtpPacketizerH264::GeneratePackets()
0x0000000106a1364f	(Google Chrome Framework -rtp_format_h264.cc:170 )	webrtc::RtpPacketizerH264::SetPayloadData(unsigned char const*, unsigned long, webrtc::RTPFragmentationHeader const*)
0x0000000106a2aa09	(Google Chrome Framework -rtp_sender_video.cc:377 )	webrtc::RTPSenderVideo::SendVideo(webrtc::RtpVideoCodecTypes, webrtc::FrameType, signed char, unsigned int, long long, unsigned char const*, unsigned long, webrtc::RTPFragmentationHeader const*, webrtc::RTPVideoHeader const*, long long)
0x0000000106a25d2b	(Google Chrome Framework -rtp_sender.cc:436 )	webrtc::RTPSender::SendOutgoingData(webrtc::FrameType, signed char, unsigned int, long long, unsigned char const*, unsigned long, webrtc::RTPFragmentationHeader const*, webrtc::RTPVideoHeader const*, unsigned int*, long long)
0x0000000106a23df1	(Google Chrome Framework -rtp_rtcp_impl.cc:443 )	webrtc::ModuleRtpRtcpImpl::SendOutgoingData(webrtc::FrameType, signed char, unsigned int, long long, unsigned char const*, unsigned long, webrtc::RTPFragmentationHeader const*, webrtc::RTPVideoHeader const*, unsigned int*)
0x0000000106b21281	(Google Chrome Framework -payload_router.cc:219 )	webrtc::PayloadRouter::OnEncodedImage(webrtc::EncodedImage const&, webrtc::CodecSpecificInfo const*, webrtc::RTPFragmentationHeader const*)
0x0000000106b3efdf	(Google Chrome Framework -video_send_stream.cc:1007 )	webrtc::internal::VideoSendStreamImpl::OnEncodedImage(webrtc::EncodedImage const&, webrtc::CodecSpecificInfo const*, webrtc::RTPFragmentationHeader const*)
0x0000000106b42b2f	(Google Chrome Framework -video_stream_encoder.cc:848 )	non-virtual thunk to webrtc::VideoStreamEncoder::OnEncodedImage(webrtc::EncodedImage const&, webrtc::CodecSpecificInfo const*, webrtc::RTPFragmentationHeader const*)
0x0000000106b5c7e2	(Google Chrome Framework -generic_encoder.cc:409 )	webrtc::VCMEncodedFrameCallback::OnEncodedImage(webrtc::EncodedImage const&, webrtc::CodecSpecificInfo const*, webrtc::RTPFragmentationHeader const*)
0x0000000106b72759	(Google Chrome Framework -h264_encoder_impl.cc:395 )	webrtc::H264EncoderImpl::Encode(webrtc::VideoFrame const&, webrtc::CodecSpecificInfo const*, std::__1::vector<webrtc::FrameType, std::__1::allocator<webrtc::FrameType> > const*)
0x0000000106b5b962	(Google Chrome Framework -generic_encoder.cc:94 )	webrtc::VCMGenericEncoder::Encode(webrtc::VideoFrame const&, webrtc::CodecSpecificInfo const*, std::__1::vector<webrtc::FrameType, std::__1::allocator<webrtc::FrameType> > const&)
0x0000000106b6eb9f	(Google Chrome Framework -video_sender.cc:340 )	webrtc::vcm::VideoSender::AddVideoFrame(webrtc::VideoFrame const&, webrtc::CodecSpecificInfo const*)
0x0000000106b42876	(Google Chrome Framework -video_stream_encoder.cc:826 )	webrtc::VideoStreamEncoder::EncodeVideoFrame(webrtc::VideoFrame const&, long long)
0x0000000106b44b9a	(Google Chrome Framework -video_stream_encoder.cc:147 )	webrtc::VideoStreamEncoder::EncodeTask::Run()
0x0000000103c0ab51	(Google Chrome Framework -task_queue.cc:26 )	(anonymous namespace)::RunTask(std::__1::unique_ptr<rtc::QueuedTask, std::__1::default_delete<rtc::QueuedTask> >)
0x0000000103c0aceb	(Google Chrome Framework -bind_internal.h:149 )	base::internal::Invoker<base::internal::BindState<void (*)(std::__1::unique_ptr<rtc::QueuedTask, std::__1::default_delete<rtc::QueuedTask> >), base::internal::PassedWrapper<std::__1::unique_ptr<rtc::QueuedTask, std::__1::default_delete<rtc::QueuedTask> > > >, void ()>::Run(base::internal::BindStateBase*)
0x0000000104cf098b	(Google Chrome Framework -callback.h:65 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x0000000104d14fd3	(Google Chrome Framework -message_loop.cc:391 )	base::MessageLoop::RunTask(base::PendingTask*)
0x0000000104d154e8	(Google Chrome Framework -message_loop.cc:403 )	base::MessageLoop::DoWork()
0x0000000104d17309	(Google Chrome Framework -message_pump_mac.mm:452 )	base::MessagePumpCFRunLoopBase::RunWork()
0x0000000104d08e59	(Google Chrome Framework + 0x01d70e59 )	base::mac::CallWithEHFrame(void () block_pointer)
0x0000000104d16c2e	(Google Chrome Framework -message_pump_mac.mm:428 )	base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x00007fff32323720	(CoreFoundation + 0x000a3720 )	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00007fff323dd0ab	(CoreFoundation + 0x0015d0ab )	__CFRunLoopDoSource0
0x00007fff3230625f	(CoreFoundation + 0x0008625f )	__CFRunLoopDoSources0
0x00007fff323056dc	(CoreFoundation + 0x000856dc )	__CFRunLoopRun
0x00007fff32304f42	(CoreFoundation + 0x00084f42 )	CFRunLoopRunSpecific
0x0000000104d176be	(Google Chrome Framework -message_pump_mac.mm:670 )	base::MessagePumpCFRunLoop::DoRun(base::MessagePump::Delegate*)
0x0000000104d1674d	(Google Chrome Framework -message_pump_mac.mm:179 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x0000000104d397f3	(Google Chrome Framework -run_loop.cc:114 )	<name omitted>
0x0000000104d6b76a	(Google Chrome Framework -thread.cc:338 )	base::Thread::ThreadMain()
0x0000000104d66086	(Google Chrome Framework -platform_thread_posix.cc:75 )	base::(anonymous namespace)::ThreadFunc(void*)
0x00007fff59ea76c0	(libsystem_pthread.dylib + 0x000036c0 )	_pthread_body
0x00007fff59ea756c	(libsystem_pthread.dylib + 0x0000356c )	_pthread_start
0x00007fff59ea6c5c	(libsystem_pthread.dylib + 0x00002c5c )	thread_start
0x0000000104d6602f	(Google Chrome Framework + 0x01dce02f )	

Link to the list of the builds
==============================

https://goto.google.com/mkspb

65.0.3325.146	2.51%	7    Current Stable
64.0.3282.186	28.32%	79   Previous Stable

Note:
This Crash is first observed in M61

CC'ing related dev from the file rtp_format_h264.cc

CL: https://webrtc.googlesource.com/src.git/+/7a3006bae7f1c61371581ddfa320524041119f20

@asapersson: Could you please take a look at this and help 

Thanks!!

Ilya, can you take a look at this?

Looking into it. But it looks like hardware h264 encoder just created a NALU, larger than configured MTU. 

Now, the question is why there is not enough space in the packet. Maybe all the new added extensions eaten all the headroom we had before.

It's still strange, that usually we have 1400+ bytes there. 200+ were eaten by something. I am investigating where they went.

Maybe FEC was enabled there?

+sprang, ssilkin
Do you know, where is max NALU size configured in h264 encoders? 

Not sure about H264 specifics, but you can probably follow the code path for the configuration parameter for max packet size: https://cs.chromium.org/chromium/src/third_party/webrtc/call/video_send_stream.h?sq=package:chromium&l=157
I believe this is 1200 bytes by default.

Re #8: I've already looked there. It's 1400+ usually: https://cs.chromium.org/chromium/src/third_party/webrtc/call/video_send_stream.h?sq=package:chromium&l=144

In local tests I see it's 1438 (-16 for additional extensions at the last packet). Still ~230 bytes disappeared somewhere. In full stack tests with fec we have 1411(-16) of bytes available. In the crash there are only 1188 available somehow.

In the offline discusison with Stefan@ and Brandtr@, we decided that using SingleNalUnit is a very bad idea, especially with hardware encoders. We need to find there's it set and change it to NonInterleaved. 

Erik, I was wrong and you were right. The packet size is set to 1200 here:
https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/webrtcvideoengine.cc?sq=package:chromium&l=1575

So having 1188 bytes available in the packet makes total sense. Thus having Nalu 1210 bytes long would never work even with no header extensions.

The troubling fact I found here is that max_payload_size is simply ignored by chrome h264 encoder:
https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/rtc_video_encoder.cc?dr=CSs&l=804

Also, even if it isn't ignored, it's set to the same value here:
https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_send_stream.cc?dr=C&l=588

And here we calculate available capacity subtracting rtp header size from that value:
https://cs.chromium.org/chromium/src/third_party/webrtc/modules/rtp_rtcp/source/rtp_sender_video.cc?q=rtp_sender_video&dr=C&l=357

This means, that if encoder hits max_payload_size, it will exceed packet_capacity anyway. Thus singleNalu packetization was just a ticking bomb all along.

The problem is that it's set in the SDP. should we just refuse that mode on receive side somehow? Should we ignore the SDP and just disable it completely?

I was able to reproduce the problem locally in webrtc_perf_tests by changing kDefaultMaxPacketSize to something smaller (450) and forcing SingleNalUnit packetization mode. The smaller size is needed because open h264 tends to under-utilize available capacity.

Good news are, SingleNalUnit is not used by default:
https://cs.chromium.org/chromium/src/third_party/webrtc/media/base/codec.cc?q=codec.cc&sq=package:chromium&dr&l=239

But if some unfortunate website sets it in SDP somehow (you can see them here: https://goto.google.com/mkspb ), it may experience the crash.

Possible solutions:
1) Force correct constraints on encoders. This involves updating rtc_video_encoder in chrome, and adding some headroom for headers in webrtc codec configuration. But some hardware encoders may just ignore the limit anyway.

2) Deprecate and disable SingleNalu packetization.

3) Increase kVideoMtu in hope that h264 encoders will not overshoot it. This will not guarantee no crashes in the future.

4) Reimplement SingleNalu packetization to split huge fragments and gather them back. It will be undocumented, non-standardized behavior, but it's better than crashing.

I am leaning to the second option, but it will mean some SDP configured parameter is ignored, which is a huge API change. 

WDYT?

First, I don't think Chromoting should be using single nalu mode.

Second, I  think we should fix the bug here if it doesn't set the size available for the encoder to use, but the packet size? https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_send_stream.cc?dr=C&l=588

Third, we should probably fix RtcVideoEncoder.

I also think that SingleNalu mode never has been correctly implemented, and perhaps should be disabled until these issues are resolved.

+Harald who might have some comments around this as I think he spent some time on it at some point.

Found the error message:

# Check failed: payload_size_left >= fragment->length (1188 vs. 1210)
# Payload size left 1188, fragment length 1210, packetization mode SingleNalUnit

There's some interesting calculation just above it:

  size_t payload_size_left = max_payload_len_;
  if (fragment_index + 1 == input_fragments_.size())
    payload_size_left -= last_packet_reduction_len_;

1188 seems like an awfully small max_payload_len, but I don't remember ever seeing how last_packet_reduction_len_ got set, or why.
Seems to have been added in this CL:

https://codereview.webrtc.org/2871173008

By the logic, it seems that we should have reduced the max NALU size for the encoder by the same amount as the possible last-packet reduction. (This will hurt quality, of course.)

@linik, how much testing did we manage to do of this feature together with packetization mode 0?

Re 17#, surely it wasn't tested well enough - SingleNalu mode isn't tested quite well at all, but this is not the main problem here. The last_packet_reduction_len_ is at most 13+2+3. The problem is that max_payload_len_ is 1200 - <rtp header length>, yet the fragment length is 1210. Even with no extra header extensions, it wouldn't fit.

There are 2 separate problems here: encoder is not configured with max_payload_size at all (or ignoring it) and not leaving enough room there for the extensions (even in the first packet, without last_packet_reduction_len_) - currently we just use max_payload_size in InitEncode without accounting for rtp header at all.

What codec is being used when it fails? Is it OpenH264?

The max packet size for OpenH264 is set here:

https://cs.chromium.org/chromium/src/third_party/webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc?type=cs&q=max+packet+size+openh264+file:webrtc&sq=package:chromium&l=467

It's set to max_payload_size_  - seems that it should have been reduced by last_packet_reduction_len_ - but another problem is that we have both max_payload_size_ and max_payload_len_ floating around in this part of the codebase, and I'm not sure we're keeping them straight.

Do insert a log statement in the place we're setting the max size, so that we know what we're telling the codec.

Re 19: From the logs in #3 and stack trace in #4 it looks like it's in-webrtc implementation of h264 (we do use open h264).

It's being set there, but max_payload_size there doesn't account for rtp headers.
I checked in the local build, if I set kVideoMtu to 500 and log there, I see that max_packet_size used in open264 configuration is 498. But in rtp_sender_video we calculate available capacity as 498 - <header length>. And on top of that there's a last_packet_reduction.

I didn't found the place there 2 bytes are subtracted yet.

I am working on the fix which will:
1) gracefully drop the frame instead of failing in such situation (too huge fragments can't fit in the packet). It will cause freezes in the video stream, but it's better than crash.

2) configure encoder with some headroom for all the extensions (including last packet extra extensions).

Our business provides a third party webRTC using google chrome and will need a optimum video quality. Please ensure that it will not affect the video quality since most of our clients are deaf and rely on good video quality delivery. I just wanted to note it here. Thanks! 

Alex, the fix shouldn't affect the video quality. But you already can (and i would recommend to do so to ensure better quality) switch from SingleNalu packetization mode to NonInterleaved mode. The latter is actually the default setting, so you are somewhere setting SingleNalu mode in SDP. 

This will remove all the crashes like that and will let the encoder to be more flexible, since it will not be required to keep NALUs at a certain size. It will also produce less packets of a more consistent size, which will make it less sensitive to bad networks.

The fix is up for review now.

Meanwhile I confirmed, that the crash will not happen while using chrome hardware encoders because they always use Non-Interleaved packetization mode:
https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/rtc_video_encoder_factory.cc?dr=CSs&l=85

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/1d037ae704b0941769623eb6a4a9787e40070615

commit 1d037ae704b0941769623eb6a4a9787e40070615
Author: Ilya Nikolaevskiy <ilnik@webrtc.org>
Date: Thu Mar 15 15:42:57 2018

Don't crash in SingleNalu packetization for h264 if no space in packet

Also, pass correct max payload data size to encoders: now accounting for
rtp headers.

Bug:  chromium:819259 
Change-Id: I586924e9246218fab6072e05eca894925cfe556e
Reviewed-on: https://webrtc-review.googlesource.com/61425
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22460}
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_format_h264.cc
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_format_h264.h
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_format_h264_unittest.cc
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_sender.cc
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_sender.h
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/rtp_rtcp/source/rtp_sender_video.cc
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/modules/video_coding/codecs/h264/h264_encoder_impl.cc
[modify] https://crrev.com/1d037ae704b0941769623eb6a4a9787e40070615/video/video_send_stream.cc

Since the crash happens quite rarely (1-2 times per day) I will not merge the fix to M66. Starting from M67, instead of crash there will be a warning message and video frame would be dropped. 

Encoders are configured correctly now.

Workaround for M66 and below would be not to use SingleNalu packetization mode.

What is the workaround since we will wait until M67? Do we have a walkthrough how to set by disabling SingleNalu packetization mode? Please advise. Thanks!

Alex, I am working at the much lower lever, so I am not sure where you might be setting it. I will come back to you later, when I find someone to help. It's probably somewhere in your js code: you either mange SDP offer manually, or set some parameter somewhere.

It may also help us, if you could run your application and from the chrome://webrtc-internals page paste a SDP string from setLocalDescription section.

Alex, most probably, somewhere in your JS code you take the result of RTCPeerConnection.createOffer() and then replace "a=fmtp:100 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f" with something with "packetization-mode=0". Some more modifications might be made to prioritize h264. 

First, confirm that "packetization-mode=0" is present in setLocalDescription in "chrome://webrtc-internals", then search all your code for where you might set it.

Here is the data coming from setLocalDescription section while running the application, I copied and pasted the whole section so you can see the full picture:

type: answer, sdp: v=0
o=- 6261374912879113930 2 IN IP4 127.0.0.1
s=-
t=0 0
a=msid-semantic: WMS pDRcUxkyhSNBdTAohdBpsW5663Z21TC7sugA
m=audio 9 RTP/SAVPF 9 101
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:wsJ5
a=ice-pwd:+/3IkR10eREXdnUDnscFsnz4
a=ice-options:trickle
a=fingerprint:sha-256 A8:C4:CD:56:EC:5F:67:92:1C:A7:68:4B:B2:4D:71:98:3B:D0:FF:BE:60:73:90:74:63:BE:91:BF:96:32:4B:9C
a=setup:active
a=mid:audio
a=sendrecv
a=rtcp-mux
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=ssrc:2676656107 cname:3bobCyLlQ8dY2JH2
a=ssrc:2676656107 msid:pDRcUxkyhSNBdTAohdBpsW5663Z21TC7sugA 2234b404-0559-4196-8c2a-18f127ebc667
a=ssrc:2676656107 mslabel:pDRcUxkyhSNBdTAohdBpsW5663Z21TC7sugA
a=ssrc:2676656107 label:2234b404-0559-4196-8c2a-18f127ebc667
m=video 9 RTP/SAVPF 102
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:TojS
a=ice-pwd:lez1F4nCkECp6oRErrGfjRdb
a=ice-options:trickle
a=fingerprint:sha-256 A8:C4:CD:56:EC:5F:67:92:1C:A7:68:4B:B2:4D:71:98:3B:D0:FF:BE:60:73:90:74:63:BE:91:BF:96:32:4B:9C
a=setup:active
a=mid:video
a=sendrecv
a=rtcp-mux
a=rtpmap:102 H264/90000
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=1;profile-level-id=42e01f
a=ssrc:355678136 cname:3bobCyLlQ8dY2JH2
a=ssrc:355678136 msid:pDRcUxkyhSNBdTAohdBpsW5663Z21TC7sugA a0c83f03-20dd-4de8-8e7d-b05258781625
a=ssrc:355678136 mslabel:pDRcUxkyhSNBdTAohdBpsW5663Z21TC7sugA
a=ssrc:355678136 label:a0c83f03-20dd-4de8-8e7d-b05258781625

sorry about the confusion - it's likely the setREMOTEdescription we need to look at.

M	
setRemoteDescription
type: offer, sdp: v=0
o=FreeSWITCH 1521117072 1521117073 IN IP4 104.196.50.243
s=FreeSWITCH
c=IN IP4 104.196.50.243
t=0 0
a=msid-semantic: WMS zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vw
m=audio 21960 RTP/SAVPF 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fingerprint:sha-256 96:41:69:44:37:2E:E0:29:46:F3:1A:2E:87:01:54:51:1C:4E:72:A5:D8:68:12:99:2E:AE:0C:85:25:DD:B2:0B
a=setup:actpass
a=rtcp-mux
a=rtcp:21960 IN IP4 104.196.50.243
a=ssrc:797098704 cname:gCSNFIjoyMIuYcUR
a=ssrc:797098704 msid:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vw a0
a=ssrc:797098704 mslabel:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vw
a=ssrc:797098704 label:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vwa0
a=ice-ufrag:jxK6wkFvVtqTqbgw
a=ice-pwd:EZa9xjnVVVgKY1r7o13Lcz6Y
a=candidate:7859627785 1 udp 659136 104.196.50.243 21960 typ host generation 0
a=candidate:7859627785 2 udp 659136 104.196.50.243 21960 typ host generation 0
a=ptime:20
m=video 28894 RTP/SAVPF 102
b=AS:500
a=rtpmap:102 H264/90000
a=fingerprint:sha-256 96:41:69:44:37:2E:E0:29:46:F3:1A:2E:87:01:54:51:1C:4E:72:A5:D8:68:12:99:2E:AE:0C:85:25:DD:B2:0B
a=setup:actpass
a=rtcp-mux
a=rtcp:28894 IN IP4 104.196.50.243
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 ccm tmmbr
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=ssrc:36550164 cname:gCSNFIjoyMIuYcUR
a=ssrc:36550164 msid:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vw v0
a=ssrc:36550164 mslabel:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vw
a=ssrc:36550164 label:zjQvHcZGT0Ct6lEA2gM3W8KJ9KY476Vwv0
a=ice-ufrag:77aiKpuiXzNEeLfD
a=ice-pwd:zPtJF8oS7Ig8PobNmcWWsg4f
a=candidate:1833539635 1 udp 659136 104.196.50.243 28894 typ host generation 0
a=candidate:1833539635 2 udp 659135 104.196.50.243 28894 typ host generation 0
a=end-of-candidates

Thank you. The critical part is what isn't there - there is no a=fmtp:102 line, meaning that the parameters are all defaulted, which means packetization-mode 0 and profile-level = baseline profile level 1 according to https://tools.ietf.org/html/rfc6184#section-8.1 - level 1 is max bitrate of 64 Kbit/second, so I suspect this is not what you want.

Please check your FreeSWITCH configuration.