Hello everybody,
I was installing in a new VM openvidu server 2.13 (with its respective kms version). The OpenVidu Call app is working for me. So, I want to try to update my openvidu-browser and openvidu-node-client in my openvidu apps v2.11.0 (the front is based in openvidu call 2.11.0) . I was updating package.json and npm-shrinkwrap.json to openvidu-browser-2.13.0 and openvidu-node-client-2.13.0. I was deleting node_modules and running again npm install.
After that I was starting node in my local environment:
node server.js https://OPENVIDU_URL:4443 MY_SECRET (pointing to my VM with openvidu 2.13 version working)
And I was starting front part:
ng serve
My application (front and back) works fine until arriving to openvidu requests. In this point node part is breaking with this log:
https://pastebin.com/fzqbMyLd
_currentUrl: ‘https://xxxx.i2cat.net:4443/api/sessions’,
[Symbol(kCapture)]: false
}
Error: [object Object]
at /home/geeksha/Vídeos/vcnton/server/node_modules/openvidu-node-client/lib/Session.js:421:28
It seems that thr URL https://xxx.i2cat.net:4443/api/sessions is not ok for the dockerized openvidu version ? Is it like that? Pointing like this in openvidu server v2.11.0 with an ubuntu server deployment was always ok. How should I point to my new openvidu server 2.13.0 infrastructure?
Thanks in advance,
Beka
OpenVidu 2.13 is deployed in 443 port by default.
In OpenVidu 2.14 the https can be configured.
Why you don’t use latest version?
I am not using OpenVidu 2.14 because I was trying, your OpenVidu Call app was not working for me (I was reporting in Openvidu-Call is not working properly thread in this forum. So, I was trying OpenVidu 2.13, your OpenVidu Call app was working correctly, so I continued to update my own apps (openvidu-browser and openvidu-node-client) and trying to connect with the updated openvidu server. Maybe it’s interesting too a progressive migration between 2.11 to 2.14, but the main reason was that OpenVidu 2.14 demo app was not working properly for me.
OpenVidu 2.13 is deployed in 443 port by default.
It means that can I point my node back from another VM (with angular and node parts configured with nginx as reverse proxy served in 443 and 5000) and node pointing to openvidu server with this command node server.js https://xxxx.i2cat.net? I have already VM’s with this configuration. I will be able to try.
But, in OpenVidu 2.13 where is exactly Openvidu Server? Is not possible to point directly to it?It’s true that I can’t access the /dashboard supplying this route for domain:4443 as before…
Thanks in advance. A lot of changes from my last inmersion in OpenVidu 
We will take a look. It can be due to your network doesn’t allow hairpinning. I’ll respond you in the other thread.
Yes.
It should be located in https://domain/dashboard
Can you try?
Best
Ok, I have already asked details about hairpinning in our cloud to the administrator (I am root in my VM’s but I need to request port rules and networks details to the cloud administrator). Any explanation regarding that in the another thread will be welcome.
I was not needing to try in my VM’s with angular and node front and back served through a reverse proxy in 443 and 5000 respectively (I have two VM’s with this configuration but my local environment is not like that). I was trying in my local environment running node back-end with node server.js https://xxx.i2cat.net/dashboard and this works. Pointing to https://xxx.i2cat.net/dashboard instead of https://xxx.i2cat.net:4443 as until now was enough to establish connection between local and remote video from my local environment. I should test my developed advanced features (silence user, ban user etc), but it seems that I can develop new features in my local environment pointing to the 2.13 openvidu server-kms.
I see good quality in videos. The issue that I found upgrading to 2.12 version is not happening now. And this is all what I am be able to report right now
Thanks for the answer and for your work
2 Likes
This is the answer from our cloud administrator regarding hair-pinning. I was already answering with the explanation about several containers in the same public IP etc. But it will be useful to understand what is the difference between 2.13.0 and 2.14.0 in the dockerization (because one is working well and another one not with your demo app in the same network conditions).
I can only see that 2.13.0 is with a front-end app (dockerized) connecting directly to ov server and 2.14.0 is with a front and back app (dockerized) communicating with ov server. And 2.13 is working well with a front and back app (our app) which is pointing from another public IP in another machine (and without container).
“I doubt that there where any problem with hairpining/NATloopback. I tried to connect though SSH from one machine with a public IP to another machine with a public IP without problem. I tried to connect to the same machine through SSH (a loop) without hassle. From a machine with no public IP to a machine with public SSH, no problem …”
Hello Beka,
We are going to release a new OpenVidu version the next week with some tweaks in OpenVidu Call to OpenVidu Server communication to avoid certain problems.
OpenVidu Call 2.13 is very different from 2.14 because 2.14 has backend.
Hello Micael,
Yes, I was developing in my local env against openvidu server 2.13 (with an app with angular front and node back not dockerized) and this works fine. Possibly developing in local against openvidu 2.14 would work (I was not testing). I supposed that the problems in openvidu call 2.14 were relating to this back-end dockerization and communication with openvidu-server but I was prefering not use openvidu 2.14 until your openvidu call example app is working for me I will try in the next release
If it’s useful for your actual work avoiding some problems in Open Vidu Call to OpenVidu Server communication that I try to point my local env (front and back not dockerized) against openvidu 2.14 server and report this test for you, make me know.
Thanks,
Beka
Let’s wait to 2.15 version as it can fix bugs… then if you have problems, let us know.
1 Like