I am not sure if this is the expected behavior, but it was a breaking change when going from 2.14 to 2.16
If you enter a value for the data property of the body of the https://YOUR_OPENVIDUSERVER_IP/openvidu/api/sessions/SESSION_ID/connection
https://docs.openvidu.io/en/2.16.0/reference-docs/REST-API/#body_1
See image body_data.PNG
It seems to return the that value appended to %%
See image connection_object.PNG
Which then goofs up the sendNicknameSignal routine when the first remote pubisher-subscriber connects.
See image sendNicknameSignal.PNG
This took many hours to figure out while second guessing the upgrade process.
Hopefully this might save someone some time if they run across this issue.
Hi,
If you have updated your client side to 2.16 while keeping your backend at 2.14.0, you may encounter these problems. Even though we try to always respect semver versioning, we only guarantee compatibility with the server side using the same client side version, or just one less minor number. For example: OpenVidu Server 2.16.0 is 100% compatible with openvidu-browser (or any openvidu client-side library) 2.16.0 and 2.15.0. The problem here is pretty clear: openvidu-browser must follow openvidu-server version. As you are using openvidu-webcomponent, if you update it to 2.16.0 while not doing the same with openvidu-server, then the internal openvidu-browser version used by the webcomponent will not be compatible with openvidu-server.
Semver is respected from the API perspective. Not from the client-side/server-side perspective. You must always keep both sides updated.
Best regards.
I am appreciate your response, but this is after upgrading both the client to 2.16.0 as well.
If you look at the screen shot you will notice the file version 2.16.0
Also the browser-2.16.0 was referenced. no mix matching of versions.
As mentioned if you leave that data value blank everything works.
As soon as you enter something it breaks the client.
Just to clarify both server and client is on 2.16 and if a string value is entered in on the very first image in my original post it pukes when 2 separate clients connect. Perhaps its expecting an json object instead of a string. I was using a string guid in 2.14 with no issues, but as mentioned that puked on version 2.16.