RTCPeerConnection dataChannelForLabel is causing assertion failure

[Suman Cherukuri]

Hi,

I am trying to create a data channel on peer connection on iOS with the following code;

                RTCDataChannelConfiguration *datainit = [[RTCDataChannelConfiguration alloc] init];

                @try {

                    datainit.isNegotiated = YES;

                    datainit.isOrdered = YES;

                    datainit.maxRetransmits = 30;

                    datainit.maxPacketLifeTime = 30000;

                    datainit.channelId = 100;

                    

                    _dataChannel = [_peerConnection dataChannelForLabel:@"MyDataChannel" configuration:datainit];

                    _dataChannel.delegate = self;

                    

                    RTCDataBuffer *buffer = [[RTCDataBuffer alloc] initWithData:[@"Hello" dataUsingEncoding:NSUTF8StringEncoding] isBinary:NO];

                    [_dataChannel sendData:buffer];

                }

                @catch(NSException *nse) {

                    NSLog(@"%@", nse);

                }

I tried to run the above code when I got the client connection and also when I got the remote track.  It fails either way with the following assert;

When dataChannelForLabel is executed, I am getting;

2017-01-20 18:05:26.546181 Telepix[12826:5098212] *** Assertion failure in -[RTCDataChannel initWithNativeDataChannel:], ../../webrtc/sdk/objc/Framework/Classes/RTCDataChannel.mm:170

Please let me know what I am doing wrong.

Thanks in advance

--Suman

[Taylor Brandstetter]

This is happening because you're not allowed to set both maxRetransmits and maxPacketLifeTime; if you want an unreliable data channel, you need to choose one of the two mechanisms, either packet lifetime or retransmit count.

The fact that this is triggering an assert is a bug though; someone else reported a similar issue recently: https://groups.google.com/forum/#!topic/discuss-webrtc/Z7hinqqIqSU

--

---
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/83d8fbb8-16fe-4608-9936-ad472a99857e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Suman Cherukuri]

Thanks you aylor!  It took care of the assert failure.  However, I am not getting any RTCDataChannelDelegate callbacks.  Trying to debug it now but if you have any info on why datachannel wouldn't communicate the data, I would really appreciate it.

Thanks

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

[Taylor Brandstetter]

Since you're setting "isNegotiatied" to YES, this disables in-band negotiation of the data channel. Which means that instead of calling "createDataChannel" on one side, and having the "didOpenDataChannel" callback invoked on the other side, you need to call "createDataChannel" with identical arguments on both sides.

If you're already doing that, then maybe the issue is that ICE isn't completing, or the DTLS handshake is failing. You should check the ICE state you reach (from "didChangeIceConnectionState").

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/6a789b13-b89b-4495-8423-a631565bc715%40googlegroups.com.

[Suman Cherukuri]

Hi Taylor,

It's the same code that runs on both local and remote devices.  I am not even getting

(void)peerConnection:(RTCPeerConnection *)peerConnection

    didOpenDataChannel:(RTCDataChannel *)dataChannel.

I will take a look at didChangeIceConnectionState and let you know if I find anything.  As you may already guessed, I am new to WebRTC, so, I am just fumbling around the code.

Thanks,

--Suman

[Suman Cherukuri]

RTCIceConnectionState is RTCIceConnectionStateCompleted.  Video and Audio work fine except the messages through data channel.

Thanks,

[Suman Cherukuri]

HI Taylor,

Another piece of info is [_dataChannel readyState] stays at RTCDataChannelStateConnecting through out the session  Not sure why it is not changing to RTCDataChannelStateOpen

[Taylor Brandstetter]

Are you creating the data channel before or after calling createOffer? You need to create the data channel beforehand, or else the data "m=" section in the offer won't be generated.

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/1270ade2-4420-43f0-b56c-61ac405fb392%40googlegroups.com.

[Suman Cherukuri]

createOffer is new to me.  I am using ARDAppClient's connectToRoomWithId API.  Once both devices connect to the same room, I get the _peerConnection instance.  Then I call

 _dataChannel = [_client.peerConnection dataChannelForLabel:@"TelepixDataChannel" configuration:config];

I tried creating the datachannel right after _peerConnection is created and also when I received the remote video track.  I used default configuration, with and without channel id etc.  Also tried isNegotiated = YES and NO.  In all attempts, the dataChannel ready state stays at RTCDataChannelStateConnecting

Thanks, 

[Suman Cherukuri]

Hi Taylor,

Thanks for the tip on createOffer.  I found where offer is created in ARDAppClient;

[_peerConnection offerForConstraints:[self defaultOfferConstraints]

I created the data channel before that.  Now my dataChannel state is open when a peer is connected.  However, data is not getting received.  The default offer constraints used in the code are;

    @"OfferToReceiveAudio" : @"true",

    @"OfferToReceiveVideo" : @"true"

Should I pass any other constraints for data?

[Suman Cherukuri]

I just tried

@"internalSctpDataChannels": @"true" but it didn't help.

[Suman Cherukuri]

Thanks for all your help Taylor!

It is working now. As I have been trying various things, I commented out the channelId.  So, local and remove devices are creating different channels I guess.  When I hardcoded the channel ID, I started receiving the data.

--Suman