Nope, it usually require some sort of SSL certificates magic, don't have time for it
On Tue, 22 Sep 2020 at 02:30, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > Have you tried configuring TLS ports for CoTurn ? > > Thanks > Seb > > Sebastian Wagner > Director Arrakeen Solutions > http://arrakeen-solutions.co.nz/ > > <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> > <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> > > > On Mon, 21 Sep 2020 at 18:19, Maxim Solodovnik <solomax...@gmail.com> > wrote: > >> >> >> On Mon, 21 Sep 2020 at 12:22, seba.wag...@gmail.com < >> seba.wag...@gmail.com> wrote: >> >>> Hi >>> >>> I have a more advanced setup with CoTurn, OpenMeetings and Kurento on >>> separate instances. >>> >>> Even in successful audio/video connections from one browser to another I >>> can see logs in CoTurn: >>> >>> 541: session 001000000000000038: realm <somecomp.com> user >>> <1600666426:3e9a27b2-4f1d-4852-95fe-c1a710d9bf59>: incoming packet >>> CHANNEL_BIND processed, success >>> >>> 543: handle_udp_packet: New UDP endpoint: local addr 10.0.0.239:3478, >>> remote addr 122.60.70.169:62901 >>> >>> 543: session 000000000000000048: realm <somecomp.com> user <>: incoming >>> packet message processed, error 401: Unauthorized >>> >>> 543: handle_udp_packet: New UDP endpoint: local addr 10.0.0.239:3478, >>> remote addr 122.60.70.169:50666 >>> >>> 543: session 000000000000000049: realm <somecomp.com> user <>: incoming >>> packet message processed, error 401: Unauthorized >>> >>> 543: session 000000000000000048: realm <somecomp.com> user <>: incoming >>> packet message processed, error 401: Unauthorized >>> >>> 543: session 000000000000000049: realm <somecomp.com> user <>: incoming >>> packet message processed, error 401: Unauthorized >>> >>> 544: IPv4. Local relay addr: 10.0.0.239:64580 >>> >>> 544: session 000000000000000048: new, realm=<somecomp.com>, >>> username=<1600666423:3e9a27b2-4f1d-4852-95fe-c1a710d9bf59>, lifetime=3600 >>> >>> 544: session 000000000000000048: realm <somecomp.com> user >>> <1600666423:3e9a27b2-4f1d-4852-95fe-c1a710d9bf59>: incoming packet ALLOCATE >>> processed, success >>> >>> 544: session 001000000000000038: refreshed, realm=<somecomp.com>, >>> username=<1600666426:3e9a27b2-4f1d-4852-95fe-c1a710d9bf59>, lifetime=0 >>> >>> 544: session 001000000000000038: realm <somecomp.com> user >>> <1600666426:3e9a27b2-4f1d-4852-95fe-c1a710d9bf59>: incoming packet REFRESH >>> processed, success >>> >>> And >>> => error 401: Unauthorized (among some success ones) >>> >>> When verifying via: >>> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ >>> => There is a similar issue, it will check the first part fine but then >>> can't trickle to the rest as the credentials are not correct >>> Logs in CoTurn look somewhat similar: >>> >>> 2438: session 000000000000000054: realm <somecomp.com> user <>: >>> incoming packet BINDING processed, success >>> >>> 2438: session 000000000000000054: realm <somecomp.com> user <>: >>> incoming packet message processed, error 401: Unauthorized >>> >>> >> I'm not sure how this app is working >> >> >> >>> Also in Kurento logs it still complains: >>> 0:12:49.408639108 1 0x7f8340033c90 INFO KurentoWebRtcEndpointImpl >>> WebRtcEndpointImpl.cpp:571:WebRtcEndpointImpl: TURN server not found in >>> config; remember that NAT traversal requires STUN or TURN >>> >>> => Even though it still seems to somehow work. But this error in Kurento >>> docs indicate: >>> >>> https://doc-kurento.readthedocs.io/en/6.14.0/user/faq.html#faq-stun-configure >>> A. configure turnURL in Kurento >>> B. Use Java or JS API >>> => I assume we opt for B? I can't see us using Java or JS API to supply >>> those credentials though. >>> >> >> we are not using TURN in KMS configs >> I was unable to make it work :((( >> We are passing TURN IT/credentials to client and then use it >> >> >>> >>> Also something is still wrong in the CoTurn auth. I'm sure it has to do >>> with the use-auth-secret settings in CoTurn, but neither OpenMeetings nor >>> myself seem to be able to calculate the correct pass. >>> => Is there any way to debug this further or validate CoTurn ? >>> >> >> This is the part I don't get :( >> Why and what are calculating something? >> >> you need to >> 1) specify `static-auth-secret=_some_pwd_` >> 2) specify `p:turnSecret="_some_pwd_"` in applicationContext.xml (same >> string, no changes) you can use arbitrary string as p:turnUser >> >> >>> >>> Thanks >>> Seb >>> >>> Sebastian Wagner >>> Director Arrakeen Solutions >>> http://arrakeen-solutions.co.nz/ >>> >>> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >>> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >>> >> >> >> -- >> Best regards, >> Maxim >> > -- Best regards, Maxim
