You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2020/09/21 05:21:50 UTC

Coturn intermittent issues

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

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.

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 ?

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>

Re: Coturn intermittent issues

Posted by Maxim Solodovnik <so...@gmail.com>.
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.wagner@gmail.com <se...@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 <so...@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.wagner@gmail.com <
>> seba.wagner@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 <so...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, 21 Sep 2020 at 12:22, seba.wagner@gmail.com <
>>>> seba.wagner@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

Re: Coturn intermittent issues

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@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.wagner@gmail.com <se...@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 <so...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 Sep 2020 at 12:22, seba.wagner@gmail.com <
>>> seba.wagner@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
>

Re: Coturn intermittent issues

Posted by Maxim Solodovnik <so...@gmail.com>.
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.wagner@gmail.com <se...@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 <so...@gmail.com>
> wrote:
>
>>
>>
>> On Mon, 21 Sep 2020 at 12:22, seba.wagner@gmail.com <
>> seba.wagner@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

Re: Coturn intermittent issues

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com> wrote:

>
>
> On Mon, 21 Sep 2020 at 12:22, seba.wagner@gmail.com <se...@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
>

Re: Coturn intermittent issues

Posted by Maxim Solodovnik <so...@gmail.com>.
On Mon, 21 Sep 2020 at 12:22, seba.wagner@gmail.com <se...@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

Re: Coturn intermittent issues

Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
I was able to fix some of:
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
By calculating the hmac correctly and passing it in.

Although there are still 401 errors in CoTurn log, trickle-ice finishes
successfully.

But I'm not sure if that will fix the Kurento errors.

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 17:21, seba.wagner@gmail.com <se...@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
>
> 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.
>
> 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 ?
>
> 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>
>