there was an email from Konstantin Kuzov with bullet-proof 2 Coturn servers and front-end Nginx might be interesting to provide TURN at port 443 only for extremely secured networks
On Tue, 22 Sep 2020 at 09:34, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > Yeah love the SSL certificate magic :) > Well I think the port 443 for CoTurn adds some advantages for certain > types of networks. > > I will have a look if I find some time. > > 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 Tue, 22 Sep 2020 at 13:20, Maxim Solodovnik <solomax...@gmail.com> > wrote: > >> 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 >> > -- Best regards, Maxim
