Re: Increase my understanding of turn/stun

[Ali Alhaidary]

/etc/turnserver.conf

##
# These are the two network ports used by the TURN server which the client
# may connect to. We enable the standard unencrypted port 3478 for STUN,
# as well as port 443 for TURN over TLS, which can bypass firewalls.
#listening-ip=104.248.142.226

listening-port=3478
tls-listening-port=443

server-name=rooms.the5stars.org
mobility

# If the server has multiple IP addresses, you may wish to limit which
# addresses coturn is using. Do that by setting this option (it can be
# specified multiple times). The default is to listen on all addresses.
# You do not normally need to set this option.
#listening-ip=104.248.142.226

# If the server is behind NAT, you need to specify the external IP address.
# If there is only one external address, specify it like this:
external-ip=104.248.142.226

# If you have multiple external addresses, you have to specify which
# internal address each corresponds to, like this. The first address is the
# external ip, and the second address is the corresponding internal IP.
#external-ip=104.248.142.226/10.0.0.11
#external-ip=104.248.142.226/10.0.0.12

# Fingerprints in TURN messages are required for WebRTC
fingerprint

# The long-term credential mechanism is required for WebRTC
lt-cred-mech

# Configure coturn to use the "TURN REST API" method for validating 
time-limited credentials.

# You can generate a new random value by running the command:
#   openssl rand -hex 16
use-auth-secret
static-auth-secret=

# user=
stale-nonce=0

# If the realm value is unspecified, it defaults to the TURN server 
hostname.

# You probably want to configure it to a domain name that you control to
# improve log output. There is no functional impact.
realm=rooms.the5stars.org

# Configure TLS support.
# Adjust these paths to match the locations of your certificate files
cert=/etc/letsencrypt/live/rooms.the5stars.org/fullchain.pem
pkey=/etc/letsencrypt/live/rooms.the5stars.org/privkey.pem

# Limit the allowed ciphers to improve security
# Based on https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
cipher-list="ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS"

# Enable longer DH TLS key to improve security
dh2066

# All WebRTC-compatible web browsers support TLS 1.2 or later, so disable
# older protocols
no-tlsv1
no-tlsv1_1

# Log to a single filename (rather than new log files each startup). You'll
# want to install a logrotate configuration (see below)
log-file=/var/log/coturn/coturn.log

# To enable single filename logs you need to enable the simple-log flag
simple-log

proc-user=nobody
proc-group=nogroup

##

On 12/17/20 7:13 AM, Ali Alhaidary wrote:


For us, and since I had long discussion and research, I removes the 
'user' entry from all files:


 /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini
 /opt/opt510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties
 /etc/turnserver.conf

so we are using only STUN service, all working well

On 12/17/20 7:08 AM, Maxim Solodovnik wrote:



On Thu, 17 Dec 2020 at 00:36, kaffeesurrogat 
mailto:kaffeesurro...@posteo.de>> wrote:


now i am ashamed, it was me who asked this question a while ago
and you
did answer it.

sorry for that 

this means i should leave the line in
/opt/open510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties

like this:

kurento.turn.user=


you can put any user-name to this line :)
for ex.

    kurento.turn.user=kaffeesurrogat

(I guess it can be used while log checking)
or can leave it empty :)



Commenting it out doesn't work .

I find some error in openmeetings.log
(Could not resolve placeholder kurento.turn.user .)
and the webfrontend is not reachable 






On 16/12/2020 17:12, Maxim Solodovnik wrote:
> I would recommend to remove the `user` from coturn config
> (/etc/turnserver.conf)
> please search mailing lists, I've shared my config (as well as
others
> ... :)))
>
> On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat
mailto:kaffeesurro...@posteo.de>
> >> wrote:
>
>
>
>     On 16/12/2020 16:39, Maxim Solodovnik wrote:
>     >
>     >
>     > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat
>     mailto:kaffeesurro...@posteo.de>
>
>     > 
>          >
>     >     Dear list,
>     >
>     >     just trying to understand things a little better.
>     >
>     >     I tried to check if my turn/stun server is 

Re: Increase my understanding of turn/stun

[Ali Alhaidary]

For us, and since I had long discussion and research, I removes the 
'user' entry from all files:


 /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini
 /opt/opt510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties
 /etc/turnserver.conf

so we are using only STUN service, all working well

On 12/17/20 7:08 AM, Maxim Solodovnik wrote:



On Thu, 17 Dec 2020 at 00:36, kaffeesurrogat > wrote:


now i am ashamed, it was me who asked this question a while ago
and you
did answer it.

sorry for that 

this means i should leave the line in
/opt/open510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties

like this:

kurento.turn.user=


you can put any user-name to this line :)
for ex.

    kurento.turn.user=kaffeesurrogat

(I guess it can be used while log checking)
or can leave it empty :)



Commenting it out doesn't work .

I find some error in openmeetings.log
(Could not resolve placeholder kurento.turn.user .)
and the webfrontend is not reachable 






On 16/12/2020 17:12, Maxim Solodovnik wrote:
> I would recommend to remove the `user` from coturn config
> (/etc/turnserver.conf)
> please search mailing lists, I've shared my config (as well as
others
> ... :)))
>
> On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat
mailto:kaffeesurro...@posteo.de>
> >> wrote:
>
>
>
>     On 16/12/2020 16:39, Maxim Solodovnik wrote:
>     >
>     >
>     > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat
>     mailto:kaffeesurro...@posteo.de>
>
>     > 
>          >
>     >     Dear list,
>     >
>     >     just trying to understand things a little better.
>     >
>     >     I tried to check if my turn/stun server is working
correctly.
>     >
>     >     my turnserver.conf contains the line
>     >
>     >     user=nobody:PASSWORD
>     >
>     >
>     > Why have you added this line to coturn config?
>
>     That was mentioned in
>
>
 
Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf
>
>
>
>
>
>     >
>     >
>     >
>     >     Now i'm using
>     >
>     >
>     >
>
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
>   
 
>     >
>   
     
 >
>     >
>     >     to check my turn server.
>     >
>     >     The entries on trickle are:
>     >
>     >     turn:MYIP:3478
>     >     turn username: nobody
>     >     turn password: PASSWORD
>     >
>     >
>     >     The test result is negativ.
>     >
>     >
>     > I guess this is expected
>     >
>     >
>     >     My log file shows
>     >
>     >
 ##
>     >
>     >     80: handle_udp_packet: New UDP endpoint: local addr
>     MYIP:3478, remote
>     >     addr 149.224.83.188:43949
 
>     >
>     >     80: session 002001: realm  user <>:
>     incoming packet
>     >     message processed, error 401: Unauthorized
>     >     80: handle_udp_packet: New UDP endpoint: local addr
>     MYIP:3478, remote
>     >     addr 149.224.83.188:32997
 
>     >
>     >     80: session 002002: realm  user <>:
>     incoming packet
>     >     message processed, error 401: Unauthorized
>     >     80: check_stun_auth: Cannot find credentials of user

>     >     80: session 002001: realm  user
:
>     incoming
>     >     packet message processed, error 401: Unauthorized
>     >     80: check_stun_auth: Cannot find credentials of user

>     >     80: session 002002: realm  user
:
>     incoming
>     >     packet message processed, error 401: Unauthorized
>     >     83: handle_udp_packet: New UDP endpoint: local addr
>     MYIP:3478, remote
>     >     addr 149.224.83.188:46559
 

Re: Increase my understanding of turn/stun

[Maxim Solodovnik]

On Thu, 17 Dec 2020 at 00:36, kaffeesurrogat 
wrote:

> now i am ashamed, it was me who asked this question a while ago and you
> did answer it.
>
> sorry for that 
>
> this means i should leave the line in
> /opt/open510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties
>
> like this:
>
> kurento.turn.user=
>

you can put any user-name to this line :)
for ex.

kurento.turn.user=kaffeesurrogat

(I guess it can be used while log checking)
or can leave it empty :)


>
> Commenting it out doesn't work .
>
> I find some error in openmeetings.log
> (Could not resolve placeholder kurento.turn.user .)
> and the webfrontend is not reachable 
>
>
>
>
>
>
> On 16/12/2020 17:12, Maxim Solodovnik wrote:
> > I would recommend to remove the `user` from coturn config
> > (/etc/turnserver.conf)
> > please search mailing lists, I've shared my config (as well as others
> > ... :)))
> >
> > On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat  > > wrote:
> >
> >
> >
> > On 16/12/2020 16:39, Maxim Solodovnik wrote:
> > >
> > >
> > > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat
> > mailto:kaffeesurro...@posteo.de>
> > >  > >> wrote:
> > >
> > > Dear list,
> > >
> > > just trying to understand things a little better.
> > >
> > > I tried to check if my turn/stun server is working correctly.
> > >
> > > my turnserver.conf contains the line
> > >
> > > user=nobody:PASSWORD
> > >
> > >
> > > Why have you added this line to coturn config?
> >
> > That was mentioned in
> >
> >
>  
> Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf
> >
> >
> >
> >
> >
> > >
> > >
> > >
> > > Now i'm using
> > >
> > >
> > >
> >
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> > <
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/>
> > >
> >  <
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> > <
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/>>
> > >
> > > to check my turn server.
> > >
> > > The entries on trickle are:
> > >
> > > turn:MYIP:3478
> > > turn username: nobody
> > > turn password: PASSWORD
> > >
> > >
> > > The test result is negativ.
> > >
> > >
> > > I guess this is expected
> > >
> > >
> > > My log file shows
> > >
> > > ##
> > >
> > > 80: handle_udp_packet: New UDP endpoint: local addr
> > MYIP:3478, remote
> > > addr 149.224.83.188:43949 
> > >
> > > 80: session 002001: realm  user <>:
> > incoming packet
> > > message processed, error 401: Unauthorized
> > > 80: handle_udp_packet: New UDP endpoint: local addr
> > MYIP:3478, remote
> > > addr 149.224.83.188:32997 
> > >
> > > 80: session 002002: realm  user <>:
> > incoming packet
> > > message processed, error 401: Unauthorized
> > > 80: check_stun_auth: Cannot find credentials of user 
> > > 80: session 002001: realm  user :
> > incoming
> > > packet message processed, error 401: Unauthorized
> > > 80: check_stun_auth: Cannot find credentials of user 
> > > 80: session 002002: realm  user :
> > incoming
> > > packet message processed, error 401: Unauthorized
> > > 83: handle_udp_packet: New UDP endpoint: local addr
> > MYIP:3478, remote
> > > addr 149.224.83.188:46559 
> > >
> > > 83: session 002003: realm  user <>:
> > incoming packet
> > > message processed, error 401: Unauthorized
> > > 83: handle_udp_packet: New UDP endpoint: local addr
> > MYIP:3478, remote
> > > addr 149.224.83.188:37545 
> > >
> > > 83: session 005002: realm  user <>:
> > incoming packet
> > > message processed, error 401: Unauthorized
> > > 83: check_stun_auth: Cannot find credentials of user 
> > > 83: session 002003: realm  user :
> > incoming
> > > packet message processed, error 401: Unauthorized
> > > 83: check_stun_auth: Cannot find credentials of user 
> > > 83: session 005002: realm  user :
> > incoming
> > 

Re: Safari

[Maxim Solodovnik]

Well,

according to my tests Safari 13.X.Y and Safari 14.0.X were not working
Developer preview version (most probably 14.1) was working

On Thu, 17 Dec 2020 at 00:53, Daniel Ascher 
wrote:

> Thanks Maxim. Does this mean it's okay for users as long as they don't use
> Safari 13?
>
> On Tue, Dec 15, 2020 at 10:22 PM Maxim Solodovnik 
> wrote:
>
>> Hello Daniel,
>>
>> While investigating (and remote debugging, thanks to Jason)
>> We were able to find out the issue is in Safari browser (and I found no
>> way to work around this)
>>
>> According to my tests `Safari 12` and `Safari 14.1` should work as
>> expected
>> Not sure is 14.1 is released :(( (I've tested developer preview ...)
>>
>> On Wed, 16 Dec 2020 at 01:45, Daniel Ascher 
>> wrote:
>>
>>> Hi all. I can't remember if the issues with using Safari for OM have
>>> been resolved. Can someone let me know? Thanks.
>>>
>>> Dan
>>>
>>>
>>
>> --
>> Best regards,
>> Maxim
>>
>
>
> --
> Daniel Ascher
>
> President, A+ Test Prep and Tutoring
> Phone: 215-886-9188
> Email: aplusad...@aplustutoring.com
> Address: 505 York Road, Suite 6
> Jenkintown, PA 19046
> Website: aplustutoring.com
>   
> 
> 
>   Click to schedule a phone call
> 
> 
>


-- 
Best regards,
Maxim

Перестал подключаться плагин Openmeetings из Moodle

[Игорь Швачко]

Добрый день, Максим!
Спасибо за ответ.
Да, плагин 4.1.1   и moodle 3.9.2+ .
 
С этим разобрался, была ошибка в букве, в названии приложения,
была введена заглавная, вместо маленькой.
Подключается.
Но теперь при подключении  пользователя moodle начинается подключение,
а затем  выдается сообщение: 
«Неверный код
  Доступ запрещён. У вас нет прав для входа в эту комнату.»
 
На сервере Openmeetings формируется пользователь EXTERNAL с одним правом  ROOM. 
В предыдущем случае, при использовании ОМ 5.0.1  я добавлял DASHBOARD  и  SOAP
и тогда  подключение проходило нормально.  При подключении к ОМ 5.1.0  делал 
аналогично,
но это не привело к нормальному подключению и выдало сообщение о неверном коде.
Да, кеши и куки очищены.
 
Подскажите, пожалуйста, что надо сделать для исправления ситуации с 
подключением. 
И как сделать, чтобы при формировании пользователя EXTERNAL   ему давались все
необходимые права? 
 
С уважением
Игорь Швачко
 

Re: Increase my understanding of turn/stun

[Ali Alhaidary]

No shame in learning :-)

But, we need to agree (and update if needed) on what is written in the 
installation manual, as these lines are there


Ali

On 12/16/20 8:36 PM, kaffeesurrogat wrote:

now i am ashamed, it was me who asked this question a while ago and you
did answer it.

sorry for that 

this means i should leave the line in
/opt/open510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties

like this:

kurento.turn.user=


Commenting it out doesn't work .

I find some error in openmeetings.log
(Could not resolve placeholder kurento.turn.user .)
and the webfrontend is not reachable 






On 16/12/2020 17:12, Maxim Solodovnik wrote:

I would recommend to remove the `user` from coturn config
(/etc/turnserver.conf)
please search mailing lists, I've shared my config (as well as others
... :)))

On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat mailto:kaffeesurro...@posteo.de>> wrote:



 On 16/12/2020 16:39, Maxim Solodovnik wrote:
 >
 >
 > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat
 mailto:kaffeesurro...@posteo.de>
 > >> wrote:
 >
 >     Dear list,
 >
 >     just trying to understand things a little better.
 >
 >     I tried to check if my turn/stun server is working correctly.
 >
 >     my turnserver.conf contains the line
 >
 >     user=nobody:PASSWORD
 >
 >
 > Why have you added this line to coturn config?

 That was mentioned in

 
Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf





 >
 >
 >
 >     Now i'm using
 >
 >
 >
  https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
 
 >
  >
 >
 >     to check my turn server.
 >
 >     The entries on trickle are:
 >
 >     turn:MYIP:3478
 >     turn username: nobody
 >     turn password: PASSWORD
 >
 >
 >     The test result is negativ.
 >
 >
 > I guess this is expected
 >
 >
 >     My log file shows
 >
 >     ##
 >
 >     80: handle_udp_packet: New UDP endpoint: local addr
 MYIP:3478, remote
 >     addr 149.224.83.188:43949 
 >
 >     80: session 002001: realm  user <>:
 incoming packet
 >     message processed, error 401: Unauthorized
 >     80: handle_udp_packet: New UDP endpoint: local addr
 MYIP:3478, remote
 >     addr 149.224.83.188:32997 
 >
 >     80: session 002002: realm  user <>:
 incoming packet
 >     message processed, error 401: Unauthorized
 >     80: check_stun_auth: Cannot find credentials of user 
 >     80: session 002001: realm  user :
 incoming
 >     packet message processed, error 401: Unauthorized
 >     80: check_stun_auth: Cannot find credentials of user 
 >     80: session 002002: realm  user :
 incoming
 >     packet message processed, error 401: Unauthorized
 >     83: handle_udp_packet: New UDP endpoint: local addr
 MYIP:3478, remote
 >     addr 149.224.83.188:46559 
 >
 >     83: session 002003: realm  user <>:
 incoming packet
 >     message processed, error 401: Unauthorized
 >     83: handle_udp_packet: New UDP endpoint: local addr
 MYIP:3478, remote
 >     addr 149.224.83.188:37545 
 >
 >     83: session 005002: realm  user <>:
 incoming packet
 >     message processed, error 401: Unauthorized
 >     83: check_stun_auth: Cannot find credentials of user 
 >     83: session 002003: realm  user :
 incoming
 >     packet message processed, error 401: Unauthorized
 >     83: check_stun_auth: Cannot find credentials of user 
 >     83: session 005002: realm  user :
 incoming
 >     packet message processed, error 401: Unauthorized
 >
 >
 >     ##
 >
 >
 >     user nobody with PASSWORD is not found . ;-(
 >
 >     loging into my om room, activating my camera gives:
 >
 >     ##
 >
 >     863: handle_udp_packet: 

Re: Safari

[Daniel Ascher]

Thanks Maxim. Does this mean it's okay for users as long as they don't use
Safari 13?

On Tue, Dec 15, 2020 at 10:22 PM Maxim Solodovnik 
wrote:

> Hello Daniel,
>
> While investigating (and remote debugging, thanks to Jason)
> We were able to find out the issue is in Safari browser (and I found no
> way to work around this)
>
> According to my tests `Safari 12` and `Safari 14.1` should work as expected
> Not sure is 14.1 is released :(( (I've tested developer preview ...)
>
> On Wed, 16 Dec 2020 at 01:45, Daniel Ascher 
> wrote:
>
>> Hi all. I can't remember if the issues with using Safari for OM have been
>> resolved. Can someone let me know? Thanks.
>>
>> Dan
>>
>>
>
> --
> Best regards,
> Maxim
>


-- 
Daniel Ascher

President, A+ Test Prep and Tutoring
Phone: 215-886-9188
Email: aplusad...@aplustutoring.com
Address: 505 York Road, Suite 6
Jenkintown, PA 19046
Website: aplustutoring.com
  


  Click to schedule a phone call

Re: Increase my understanding of turn/stun

[kaffeesurrogat]

now i am ashamed, it was me who asked this question a while ago and you
did answer it.

sorry for that 

this means i should leave the line in
/opt/open510/webapps/openmeetings/WEB-INF/classes/openmeetings.properties

like this:

kurento.turn.user=


Commenting it out doesn't work .

I find some error in openmeetings.log
(Could not resolve placeholder kurento.turn.user .)
and the webfrontend is not reachable 






On 16/12/2020 17:12, Maxim Solodovnik wrote:
> I would recommend to remove the `user` from coturn config
> (/etc/turnserver.conf)
> please search mailing lists, I've shared my config (as well as others
> ... :)))
>
> On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat  > wrote:
>
>
>
> On 16/12/2020 16:39, Maxim Solodovnik wrote:
> >
> >
> > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat
> mailto:kaffeesurro...@posteo.de>
> >  >> wrote:
> >
> >     Dear list,
> >
> >     just trying to understand things a little better.
> >
> >     I tried to check if my turn/stun server is working correctly.
> >
> >     my turnserver.conf contains the line
> >
> >     user=nobody:PASSWORD
> >
> >
> > Why have you added this line to coturn config?
>
> That was mentioned in
>
> 
> Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf
>
>
>
>
>
> >  
> >
> >
> >     Now i'm using
> >
> >
> >   
>  https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> 
> >   
>   
> >
> >
> >     to check my turn server.
> >
> >     The entries on trickle are:
> >
> >     turn:MYIP:3478
> >     turn username: nobody
> >     turn password: PASSWORD
> >
> >
> >     The test result is negativ.
> >
> >  
> > I guess this is expected 
> >
> >
> >     My log file shows
> >
> >     ##
> >
> >     80: handle_udp_packet: New UDP endpoint: local addr
> MYIP:3478, remote
> >     addr 149.224.83.188:43949 
> >
> >     80: session 002001: realm  user <>:
> incoming packet
> >     message processed, error 401: Unauthorized
> >     80: handle_udp_packet: New UDP endpoint: local addr
> MYIP:3478, remote
> >     addr 149.224.83.188:32997 
> >
> >     80: session 002002: realm  user <>:
> incoming packet
> >     message processed, error 401: Unauthorized
> >     80: check_stun_auth: Cannot find credentials of user 
> >     80: session 002001: realm  user :
> incoming
> >     packet message processed, error 401: Unauthorized
> >     80: check_stun_auth: Cannot find credentials of user 
> >     80: session 002002: realm  user :
> incoming
> >     packet message processed, error 401: Unauthorized
> >     83: handle_udp_packet: New UDP endpoint: local addr
> MYIP:3478, remote
> >     addr 149.224.83.188:46559 
> >
> >     83: session 002003: realm  user <>:
> incoming packet
> >     message processed, error 401: Unauthorized
> >     83: handle_udp_packet: New UDP endpoint: local addr
> MYIP:3478, remote
> >     addr 149.224.83.188:37545 
> >
> >     83: session 005002: realm  user <>:
> incoming packet
> >     message processed, error 401: Unauthorized
> >     83: check_stun_auth: Cannot find credentials of user 
> >     83: session 002003: realm  user :
> incoming
> >     packet message processed, error 401: Unauthorized
> >     83: check_stun_auth: Cannot find credentials of user 
> >     83: session 005002: realm  user :
> incoming
> >     packet message processed, error 401: Unauthorized
> >
> >
> >     ##
> >
> >
> >     user nobody with PASSWORD is not found . ;-(
> >
> >     loging into my om room, activating my camera gives:
> >
> >     ##
> >
> >     863: handle_udp_packet: New UDP endpoint: local addr MYIP:3478,
> >   

Re: Increase my understanding of turn/stun

[Maxim Solodovnik]

I would recommend to remove the `user` from coturn config
(/etc/turnserver.conf)
please search mailing lists, I've shared my config (as well as others ...
:)))

On Wed, 16 Dec 2020 at 22:49, kaffeesurrogat 
wrote:

>
>
> On 16/12/2020 16:39, Maxim Solodovnik wrote:
> >
> >
> > On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat  > > wrote:
> >
> > Dear list,
> >
> > just trying to understand things a little better.
> >
> > I tried to check if my turn/stun server is working correctly.
> >
> > my turnserver.conf contains the line
> >
> > user=nobody:PASSWORD
> >
> >
> > Why have you added this line to coturn config?
>
> That was mentioned in
>
>
> Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf
>
>
>
>
>
> >
> >
> >
> > Now i'm using
> >
> >
> >
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> > <
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/>
> >
> > to check my turn server.
> >
> > The entries on trickle are:
> >
> > turn:MYIP:3478
> > turn username: nobody
> > turn password: PASSWORD
> >
> >
> > The test result is negativ.
> >
> >
> > I guess this is expected
> >
> >
> > My log file shows
> >
> > ##
> >
> > 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> > addr 149.224.83.188:43949 
> > 80: session 002001: realm  user <>: incoming packet
> > message processed, error 401: Unauthorized
> > 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> > addr 149.224.83.188:32997 
> > 80: session 002002: realm  user <>: incoming packet
> > message processed, error 401: Unauthorized
> > 80: check_stun_auth: Cannot find credentials of user 
> > 80: session 002001: realm  user : incoming
> > packet message processed, error 401: Unauthorized
> > 80: check_stun_auth: Cannot find credentials of user 
> > 80: session 002002: realm  user : incoming
> > packet message processed, error 401: Unauthorized
> > 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> > addr 149.224.83.188:46559 
> > 83: session 002003: realm  user <>: incoming packet
> > message processed, error 401: Unauthorized
> > 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> > addr 149.224.83.188:37545 
> > 83: session 005002: realm  user <>: incoming packet
> > message processed, error 401: Unauthorized
> > 83: check_stun_auth: Cannot find credentials of user 
> > 83: session 002003: realm  user : incoming
> > packet message processed, error 401: Unauthorized
> > 83: check_stun_auth: Cannot find credentials of user 
> > 83: session 005002: realm  user : incoming
> > packet message processed, error 401: Unauthorized
> >
> >
> > ##
> >
> >
> > user nobody with PASSWORD is not found . ;-(
> >
> > loging into my om room, activating my camera gives:
> >
> > ##
> >
> > 863: handle_udp_packet: New UDP endpoint: local addr MYIP:3478,
> > remote
> > addr REMOTEIP:41039
> > 863: session 005003: realm  user <>: incoming
> > packet
> > BINDING processed, success
> > 863: session 005003: realm  user <>: incoming
> > packet
> > message processed, error 401: Unauthorized
> > 863: IPv4. Local relay addr: MYIP:63505
> > 863: session 005003: new, realm=,
> > username=<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>,
> > lifetime=600
> > 863: session 005003: realm  user
> > <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> > ALLOCATE processed, success
> > 863: session 005003: peer MYIP lifetime updated: 300
> > 863: session 005003: realm  user
> > <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> > CREATE_PERMISSION processed, success
> > 863: session 005003: realm  user
> > <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> > CREATE_PERMISSION processed, error 403: Forbidden IP
> > 863: session 005003: realm  user
> > <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> > message processed, error 403: Forbidden IP
> >
> > ##
> >
> >
> > gives a user name with a long number .. ?
> >
> >
> > Special hash of user and password is being used by OM
> >
> >
> >
> >
> > 

Re: Increase my understanding of turn/stun

[kaffeesurrogat]

On 16/12/2020 16:39, Maxim Solodovnik wrote:
>
>
> On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat  > wrote:
>
> Dear list,
>
> just trying to understand things a little better.
>
> I tried to check if my turn/stun server is working correctly.
>
> my turnserver.conf contains the line
>
> user=nobody:PASSWORD
>
>
> Why have you added this line to coturn config?

That was mentioned in

Installation_SSL_certificates_and_Coturn_for_OpenMeetings_5.1.0_on_Ubuntu_18.04.pdf





>  
>
>
> Now i'm using
>
>
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> 
>
> to check my turn server.
>
> The entries on trickle are:
>
> turn:MYIP:3478
> turn username: nobody
> turn password: PASSWORD
>
>
> The test result is negativ.
>
>  
> I guess this is expected 
>
>
> My log file shows
>
> ##
>
> 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:43949 
> 80: session 002001: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:32997 
> 80: session 002002: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 80: check_stun_auth: Cannot find credentials of user 
> 80: session 002001: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 80: check_stun_auth: Cannot find credentials of user 
> 80: session 002002: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:46559 
> 83: session 002003: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:37545 
> 83: session 005002: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 83: check_stun_auth: Cannot find credentials of user 
> 83: session 002003: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 83: check_stun_auth: Cannot find credentials of user 
> 83: session 005002: realm  user : incoming
> packet message processed, error 401: Unauthorized
>
>
> ##
>
>
> user nobody with PASSWORD is not found . ;-(
>
> loging into my om room, activating my camera gives:
>
> ##
>
> 863: handle_udp_packet: New UDP endpoint: local addr MYIP:3478,
> remote
> addr REMOTEIP:41039
> 863: session 005003: realm  user <>: incoming
> packet
> BINDING processed, success
> 863: session 005003: realm  user <>: incoming
> packet
> message processed, error 401: Unauthorized
> 863: IPv4. Local relay addr: MYIP:63505
> 863: session 005003: new, realm=,
> username=<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>,
> lifetime=600
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> ALLOCATE processed, success
> 863: session 005003: peer MYIP lifetime updated: 300
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> CREATE_PERMISSION processed, success
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> CREATE_PERMISSION processed, error 403: Forbidden IP
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> message processed, error 403: Forbidden IP
>
> ##
>
>
> gives a user name with a long number .. ?
>
>
> Special hash of user and password is being used by OM
>  
>
>
>
> There are two questions :
>
> 1) why do i need a user nobody:password in my config lines if the
> username generated by om is a long hash but not nobody ... ?
>
>
> your config is your responsibility :
> I guess you can google 
> Or check this
> doc https://github.com/coturn/coturn/blob/master/README.turnserver
>  for ex.
will read this doc. One day i will understand this turn server thing 

Re: MaxThreads for kurento

[Maxim Solodovnik]

Please search archives
this topic was discussed

On Wed, 16 Dec 2020 at 22:00, kaffeesurrogat 
wrote:

> Dear list,
>
> today my kurento-media-server crashed, because i had three guests + me
> in one room.
>
> All of them tried tu use cam+mic.
>
> sudo watch -n 10 systemctl status kurento-media-server
>
> gave me a number of tasks which was close to the limit and i found the
> following in my logs:
>
> (openmeetings.log)
>
> ARN 12-16 10:18:16.279 o.a.o.c.r.KurentoHandler:139 [Thread-10] - Media
> Server is not accessible
>
>
> (kurento-media-server)
>
>   creating thread 'KmsLoop': Error creating thread: Resource temporarily
> unavailable
>
>
> according to
>
>
> https://doc-kurento.readthedocs.io/en/latest/user/troubleshooting.html
>
>
> this is due to the limit of threads given.
>
>
> I changed the line
>
>
> #DefaultTasksMax=
>
>
> to
>
>
> DefaultTasksMax=600
>
>
> in
>
>
> /etc/systemd/system.conf
>
>
> After
>
> |systemctl daemon-reexec
>
>
> I did a check with all my machines. Now the number of threads is well
> below the limit.
>
> Wondering what is going to happen, if i add more than four users and if
> it is  a good thing to do, to increase the number of tasks systemwide 
> ?
>
>
> In the docs they mention a way to set the limit on a per user bases, but
> i didn't figure out how to do this ..
>
>
> Greetings,
>
> kafeesurrogat
> |
>


-- 
Best regards,
Maxim

Re: Increase my understanding of turn/stun

[Maxim Solodovnik]

On Wed, 16 Dec 2020 at 21:28, kaffeesurrogat 
wrote:

> Dear list,
>
> just trying to understand things a little better.
>
> I tried to check if my turn/stun server is working correctly.
>
> my turnserver.conf contains the line
>
> user=nobody:PASSWORD
>

Why have you added this line to coturn config?


>
> Now i'm using
>
>
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
>
> to check my turn server.
>
> The entries on trickle are:
>
> turn:MYIP:3478
> turn username: nobody
> turn password: PASSWORD
>
>
> The test result is negativ.
>

I guess this is expected


> My log file shows
>
> ##
>
> 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:43949
> 80: session 002001: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:32997
> 80: session 002002: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 80: check_stun_auth: Cannot find credentials of user 
> 80: session 002001: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 80: check_stun_auth: Cannot find credentials of user 
> 80: session 002002: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:46559
> 83: session 002003: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr 149.224.83.188:37545
> 83: session 005002: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 83: check_stun_auth: Cannot find credentials of user 
> 83: session 002003: realm  user : incoming
> packet message processed, error 401: Unauthorized
> 83: check_stun_auth: Cannot find credentials of user 
> 83: session 005002: realm  user : incoming
> packet message processed, error 401: Unauthorized
>
>
> ##
>
>
> user nobody with PASSWORD is not found . ;-(
>
> loging into my om room, activating my camera gives:
>
> ##
>
> 863: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote
> addr REMOTEIP:41039
> 863: session 005003: realm  user <>: incoming packet
> BINDING processed, success
> 863: session 005003: realm  user <>: incoming packet
> message processed, error 401: Unauthorized
> 863: IPv4. Local relay addr: MYIP:63505
> 863: session 005003: new, realm=,
> username=<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>, lifetime=600
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> ALLOCATE processed, success
> 863: session 005003: peer MYIP lifetime updated: 300
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> CREATE_PERMISSION processed, success
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> CREATE_PERMISSION processed, error 403: Forbidden IP
> 863: session 005003: realm  user
> <1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet
> message processed, error 403: Forbidden IP
>
> ##
>
>
> gives a user name with a long number .. ?
>

Special hash of user and password is being used by OM


>
>
> There are two questions :
>
> 1) why do i need a user nobody:password in my config lines if the
> username generated by om is a long hash but not nobody ... ?
>

your config is your responsibility :
I guess you can google
Or check this doc
https://github.com/coturn/coturn/blob/master/README.turnserver for ex.
Or search mailing-list archives for working configurations :)))



> 2) why does my trickle test fail or why does it not find the credentials
> ... ?
>

I believe your configuration might be wrong ...


>
>
> Many thanks,
>
> kaffeesurrogat
>
>
>
>

-- 
Best regards,
Maxim

Re: Перестал подключаться плагин Openmeetings из Moodle

[Maxim Solodovnik]

здравствуйте Игорь,

точно версия плагина 3.9?
Вам надо версию 4.1.1 чтобы 5.0.1 работало ...

"Error While signing into OpenMeetings, please check credentials"
обычно такое бывает если данные пользователя SOAP неверные
а что в логе? (openmeetings.log)

On Wed, 16 Dec 2020 at 22:13, Игорь Швачко  wrote:

>
> Добрый день, Максим!
>
> У меня установлены moodle 3.9.2+   с плагином Openmeetings 3.9  и
> Openmeetings 5.0.1
> Из moodle подключается видеоконференция, и все нормально работает.
> Установил Openmeetings 5.1.0  и плагин перестал подключаться при
> одинаковых настройках
> Openmeetings.
> Переустановил плагин в moodle и все равно не подключается.
> Выдается сообщение в moodle:
> Error While signing into OpenMeetings, please check credentials; message:
> Учетные данные проверены, все одинаково и в Openmeetings 5.0.1  и в moodle
>
> Это связано с переходом на версию 5.1.0 ? Что-то поменялось?
> Как это исправить?
>
> С уважением
> Игорь Швачко



-- 
Best regards,
Maxim

Перестал подключаться плагин Openmeetings из Moodle

[Игорь Швачко]

Добрый день, Максим!
 
У меня установлены moodle 3.9.2+   с плагином Openmeetings 3.9  и  Openmeetings 
5.0.1    
Из moodle подключается видеоконференция, и все нормально работает.
Установил Openmeetings 5.1.0  и плагин перестал подключаться при одинаковых 
настройках
Openmeetings.
Переустановил плагин в moodle и все равно не подключается.
Выдается сообщение в moodle:
Error While signing into OpenMeetings, please check credentials; message:
Учетные данные проверены, все одинаково и в Openmeetings 5.0.1  и в moodle
 
Это связано с переходом на версию 5.1.0 ? Что-то поменялось?
Как это исправить?
 
С уважением
Игорь Швачко

MaxThreads for kurento

[kaffeesurrogat]

Dear list,

today my kurento-media-server crashed, because i had three guests + me 
in one room.


All of them tried tu use cam+mic.

sudo watch -n 10 systemctl status kurento-media-server

gave me a number of tasks which was close to the limit and i found the 
following in my logs:


(openmeetings.log)

ARN 12-16 10:18:16.279 o.a.o.c.r.KurentoHandler:139 [Thread-10] - Media 
Server is not accessible



(kurento-media-server)

 creating thread 'KmsLoop': Error creating thread: Resource temporarily 
unavailable



according to


https://doc-kurento.readthedocs.io/en/latest/user/troubleshooting.html


this is due to the limit of threads given.


I changed the line


#DefaultTasksMax=


to


DefaultTasksMax=600


in


/etc/systemd/system.conf


After

|systemctl daemon-reexec


I did a check with all my machines. Now the number of threads is well 
below the limit.


Wondering what is going to happen, if i add more than four users and if 
it is  a good thing to do, to increase the number of tasks systemwide  ?



In the docs they mention a way to set the limit on a per user bases, but 
i didn't figure out how to do this ..



Greetings,

kafeesurrogat
|

Increase my understanding of turn/stun

[kaffeesurrogat]

Dear list,

just trying to understand things a little better.

I tried to check if my turn/stun server is working correctly.

my turnserver.conf contains the line

user=nobody:PASSWORD

Now i'm using


https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

to check my turn server.

The entries on trickle are:

turn:MYIP:3478
turn username: nobody
turn password: PASSWORD


The test result is negativ.

My log file shows

##

80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote 
addr 149.224.83.188:43949
80: session 002001: realm  user <>: incoming packet 
message processed, error 401: Unauthorized
80: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote 
addr 149.224.83.188:32997
80: session 002002: realm  user <>: incoming packet 
message processed, error 401: Unauthorized

80: check_stun_auth: Cannot find credentials of user 
80: session 002001: realm  user : incoming 
packet message processed, error 401: Unauthorized

80: check_stun_auth: Cannot find credentials of user 
80: session 002002: realm  user : incoming 
packet message processed, error 401: Unauthorized
83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote 
addr 149.224.83.188:46559
83: session 002003: realm  user <>: incoming packet 
message processed, error 401: Unauthorized
83: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote 
addr 149.224.83.188:37545
83: session 005002: realm  user <>: incoming packet 
message processed, error 401: Unauthorized

83: check_stun_auth: Cannot find credentials of user 
83: session 002003: realm  user : incoming 
packet message processed, error 401: Unauthorized

83: check_stun_auth: Cannot find credentials of user 
83: session 005002: realm  user : incoming 
packet message processed, error 401: Unauthorized



##


user nobody with PASSWORD is not found . ;-(

loging into my om room, activating my camera gives:

##

863: handle_udp_packet: New UDP endpoint: local addr MYIP:3478, remote 
addr REMOTEIP:41039
863: session 005003: realm  user <>: incoming packet 
BINDING processed, success
863: session 005003: realm  user <>: incoming packet 
message processed, error 401: Unauthorized

863: IPv4. Local relay addr: MYIP:63505
863: session 005003: new, realm=, 
username=<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>, lifetime=600
863: session 005003: realm  user 
<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet 
ALLOCATE processed, success

863: session 005003: peer MYIP lifetime updated: 300
863: session 005003: realm  user 
<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet 
CREATE_PERMISSION processed, success
863: session 005003: realm  user 
<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet 
CREATE_PERMISSION processed, error 403: Forbidden IP
863: session 005003: realm  user 
<1608132140:a8675769-9280-4ab7-ab37-d271e8e5cadb>: incoming packet 
message processed, error 403: Forbidden IP


##


gives a user name with a long number .. ?


There are two questions :

1) why do i need a user nobody:password in my config lines if the 
username generated by om is a long hash but not nobody ... ?
2) why does my trickle test fail or why does it not find the credentials 
... ?



Many thanks,

kaffeesurrogat

AW: TURN server (coturn) why?

[Rohrbach, Gerald]

That’s also understanding Maxim.

If client and OM are in the same network no coturn is needed. ( Must not be the 
same IP range, we do have in each building different IP ranges in use, 
everything is routed on the core switch.

In our case one external OM has external public IP.
Physical machine.

But clients in real live are at home, that means
a home router with NAT is between.
So coturn is needed.
I have tested a lot with this, we do have an internal
OM server and and external.
We are not using the docker KMS, but I think
that should work also.
As our sytems are pretty stable we do not touch.


Gerald










Von: Maxim Solodovnik [mailto:solomax...@gmail.com]
Gesendet: Mittwoch, 16. Dezember 2020 09:16
An: Openmeetings user-list 
Betreff: Re: TURN server (coturn) why?



On Wed, 16 Dec 2020 at 12:50, K. Kamhamea 
mailto:kamha...@googlemail.com>> wrote:
In summary two conclusions can be drawn, right?
1. There is no need to use courn if your server uses a unique public IP.

this is false assumption
According to my tests
since WebRTC is P2P
The client IP should be accessible to KMS

So TURN is not necessary as long as the server AND all client IP addresses are 
public
And there are no routers FW etc. in the middle 

2. You can run a OM Server in a private network with only one public IP using 
coturn.
--- That's cool !!!
And probably it is even necessary to use coturn if your OM server resides on a 
cloud that doesn't provide such a service.

Thank You so much for the link.
K

Am Di., 15. Dez. 2020 um 22:43 Uhr schrieb Ali Alhaidary 
mailto:ali.alhaid...@the5stars.org>>:
https://www.callstats.io/blog/2017/10/26/webrtc-product-turn-server


On 12/15/20 5:05 PM, K. Kamhamea wrote:
> I wonder why we need a coturn anyway?
>
> 1. SSL certificates can be installed without it
> 2. The server URL can be written without port number (meaning it can
> be accessed by the default 433 port) without turn server installed
> the simple iptables command does the trick
>
> iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port
> 5443
>
> and changing server.xml to the default port doesn't work anyway (with
> or without turn server)
>
> It think better avoid turn server as it may slow down the
> communication further.


--
Best regards,
Maxim

Re: TURN server (coturn) why?

[Maxim Solodovnik]

On Wed, 16 Dec 2020 at 12:50, K. Kamhamea  wrote:

> In summary two conclusions can be drawn, right?
> 1. There is no need to use courn if your server uses a unique public IP.
>

this is false assumption
According to my tests
since WebRTC is P2P
The client IP should be accessible to KMS

So TURN is not necessary as long as the server AND all client IP addresses
are public
And there are no routers FW etc. in the middle 


> 2. You can run a OM Server in a private network with only one public IP
> using coturn.
> --- That's cool !!!
> And probably it is even necessary to use coturn if your OM server resides
> on a cloud that doesn't provide such a service.
>
> Thank You so much for the link.
> K
>
> Am Di., 15. Dez. 2020 um 22:43 Uhr schrieb Ali Alhaidary <
> ali.alhaid...@the5stars.org>:
>
>> https://www.callstats.io/blog/2017/10/26/webrtc-product-turn-server
>>
>>
>> On 12/15/20 5:05 PM, K. Kamhamea wrote:
>> > I wonder why we need a coturn anyway?
>> >
>> > 1. SSL certificates can be installed without it
>> > 2. The server URL can be written without port number (meaning it can
>> > be accessed by the default 433 port) without turn server installed
>> > the simple iptables command does the trick
>> >
>> > iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port
>> > 5443
>> >
>> > and changing server.xml to the default port doesn't work anyway (with
>> > or without turn server)
>> >
>> > It think better avoid turn server as it may slow down the
>> > communication further.
>>
>

-- 
Best regards,
Maxim