subProtocol has no assignment

[chenwenti]

When I use DC channel to send data and want the subprotocol to be HTTP, but the subprotocol is null。I found in the function janus_ice_incoming_data There is no assignment to protocol in data。

void janus_ice_incoming_data(janus_ice_handle *handle, char *label, char *protocol, gboolean textdata, char *buffer, int length) {
	if(handle == NULL || buffer == NULL || length <= 0)
		return;
	janus_plugin_data data = { .label = label, .binary = !textdata, .buffer = buffer, .length = length };
	janus_plugin *plugin = (janus_plugin *)handle->app;
	if(plugin && plugin->incoming_data && handle->app_handle &&
			!g_atomic_int_get(&handle->app_handle->stopped) &&
			!g_atomic_int_get(&handle->destroyed))
		plugin->incoming_data(handle->app_handle, &data);
}

I changed the code and it can run normally.

janus_plugin_data data = { .label = label, .binary = !textdata, .buffer = buffer, .length = length, .protocol = protocol };

[atoppi]

It should not be an issue adding the subproto to DC messages.
Anyway please share the changes in a Pull Request and we will review it.

[lminiero]

Mh, when I added support for subprotocols I think I checked this and it seemed to be working at the time. I'll check if it's actually broken, and in case push a fix. Thanks for the heads up!

[lminiero]

I figured out why I thought this was working. When testing with the EchoTest by sending a datachannel message with a new label:

echotest.data({text: "ciao", label: "pippo", protocol: "http"})

the event on the incoming data message sent back by the plugin would have the protocol correctly set, so I thought this was working. Actually, the protocol field in this case was set by the browser, as the browser created the channel with that label/protocol, and so tagged the protocol accordingly on the incoming message. Modifying the plugin to display the protocol in incoming_data did confirm it wasn't being received, as you said. Creating labels with a custom protocol from a plugin does work, instead, so the problem is indeed only on incoming messages. I'll push a fix shortly.