BaseChannel::SendPacket is dying

[alfredj...@gmail.com]

Hi,

I have c++ app and web browser(chrome) acting as peers. If the c++ app initiates the connection, video streaming from and to both peers is happening as expected . If, however, web browser initiates the connection, c++ app dies with following call stack:

Org.WebRtc.dll!rtc::FatalMessage::~FatalMessage() Line 109

  Org.WebRtc.dll!cricket::BaseChannel::SendPacket(bool rtcp, rtc::CopyOnWriteBuffer * packet, const rtc::PacketOptions & options) Line 727

  Org.WebRtc.dll!cricket::BaseChannel::OnMessage(rtc::Message * pmsg) Line 1426

  Org.WebRtc.dll!cricket::VideoChannel::OnMessage(rtc::Message * pmsg) Line 2075

  Org.WebRtc.dll!rtc::MessageQueue::Dispatch(rtc::Message * pmsg) Line 516

  Org.WebRtc.dll!rtc::Thread::ProcessMessages(int cmsLoop) Line 521

  Org.WebRtc.dll!rtc::Thread::Run() Line 350

  Org.WebRtc.dll!rtc::Thread::PreRun(void * pv) Line 341

I see following log message:

(channel.cc:723): Can't send outgoing RTCP packet when SRTP is inactive and crypto is required

and just before this error happend, these messages were also in the logs:

Signaling state: HaveLocalOffer

(GlobalObserver.cc:217): OnIceGatheringChange

OnIceConnectionChange ice state changing to: Checking

(webrtcsession.cc:1426): OnTransportControllerCandidatesGathered: content name data not found

(openssladapter.cc:855): SSL_connect:SSLv3 read server session ticket A

(openssladapter.cc:855): SSL_connect:SSLv3 read change cipher spec

(openssladapter.cc:855): SSL_connect:SSLv3 read finished A

(GlobalObserver.cc:217): OnIceGatheringChange

Signaling state: HaveLocalOffer

(dtlstransportchannel.cc:546): Jingle:Channel[data|1|__]: DTLS handshake complete.

(transportcontroller.cc:567): data TransportChannel 1 writability changed to 1.

(call.cc:732): UpdateAggregateNetworkState: aggregate_state=up

(channel.cc:902): Channel writable (video) for the first time

(congestion_controller.cc:316): SignalNetworkState Up

(webrtcsession.cc:1383): Changing to ICE connected state because all transports are writable.

(paced_sender.cc:280): PacedSender resumed.

(webrtcsession.cc:1351): Changing IceConnectionState 1 => 2

(congestion_controller.cc:384): Bitrate estimate state changed, BWE: 300000 bps.

(webrtc_stats_observer.cpp:95): WebRTCStatsObserver enabling ETW stats

(webrtc_stats_observer.cpp:76): WebRTCStatsObserver starting

(channel.cc:910): Using Cand[:211232335:1:udp:2122260223:172.16.80.1:53194:local::0:r0Ub:Gh6gTybHrllB6JWhTbA7v3at:1:50:0]->Cand[:211232335:1:udp:2122194687:172.16.80.1:57877:local::0:eVcF:8R2oIUTWrVEdz74tQof4uuTT:1:0:0]

(channel.cc:965): No DTLS-SRTP selected crypto suite

(video_send_stream.cc:543): VideoSendStream::Stop

(video_send_stream.cc:772): VideoSendStream::Stop

(channel.cc:1938): Changing video state, send=0

(webrtc_stats_observer.cpp:135): WebRTCStatsObserver enabling connection health stats

(webrtc_stats_observer.cpp:150): WebRTCStatsObserver disabling rtc stats

(webrtc_stats_observer.cpp:103): WebRTCStatsObserver disabling sending stats to remote host

OnIceConnectionChange ice state changing to: Connected

(channel.cc:723): Can't send outgoing RTCP packet when SRTP is inactive and crypto is required

Debug Error!

Program: ...tc\windows\solutions\Debug\CameraFrames\AppX\CameraFrames.exe

abort() has been called

Could someone tell me what I am doing wrong ?

Thanks

AJ

[Taylor Brandstetter]

Sorry for the delay in responding, but this looks like https://bugs.chromium.org/p/chromium/issues/detail?id=711243.

Are you by any chance doing an initial negotiation with only a data channel? If so, this is already fixed, and you just need to upgrade to a more recent webrtc revision. Or as a workaround, do the initial negotiation with offer_to_receive_video.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a26b8732-916e-4c68-aaad-ab2fbcb0e86d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alfredj...@gmail.com]

Thanks for your response Taylor. No, I am not initiating negotiation with only a data channel though data channel is present. I will try the workaround you suggested to see if it makes any difference.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.