Yes, as you do not have any FW or multiple NATs, but in real life, things are different :-)

Ali

On 12/17/20 3:52 PM, K. Kamhamea wrote:
Of course. We had a mutual exchange through camera (we both used even I hight resolution) and microphone ( the sound was nearly "brilliant" ).
We also watched videos and other slides.
This test was limited though as two users participated only.
Best K

Am Do., 17. Dez. 2020 um 13:24 Uhr schrieb Ali Alhaidary <ali.alhaid...@the5stars.org <mailto:ali.alhaid...@the5stars.org>>:

    kindly define 'worked' please

    Ali

    On 12/17/20 12:47 PM, K. Kamhamea wrote:
    I tested the following configuration and it worked without TURN
    Server. Maybe the reason ist the new Kurento version available
    since November 2020.
    (https://www.kurento.org/blog/kurento-6150-november-2020)

    WebRTC.png

    Am Mi., 16. Dez. 2020 um 10:13 Uhr schrieb Rohrbach, Gerald
    <g.rohrb...@funkegruppe.de <mailto:g.rohrb...@funkegruppe.de>>:

        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
        <mailto:solomax...@gmail.com>]
        *Gesendet:* Mittwoch, 16. Dezember 2020 09:16
        *An:* Openmeetings user-list <user@openmeetings.apache.org
        <mailto:user@openmeetings.apache.org>>
        *Betreff:* Re: TURN server (coturn) why?

        On Wed, 16 Dec 2020 at 12:50, K. Kamhamea
        <kamha...@googlemail.com <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
            <ali.alhaid...@the5stars.org
            <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

Reply via email to