You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@openmeetings.apache.org by Denis Noctor <de...@gmail.com> on 2020/10/15 06:29:35 UTC
General and Corporate User... (Off Topic... Sorry)
Hi there Maxim... and everyone out there,
I know this email might be considered a little off topic... but resonates an issue that may have been overlooked in the overall application of OM at a corporate level.
Let me try to explain. At present OM is browser based... thankfully Chrome and Firefox support WebRTC etc. I am aware of the Safari issues being discussed regarding audio and vid etc.
The majority of users I have are experiencing a relatively fluid experience regarding OM... however I have encountered 2 scenarios over the last few months that contradict each other... though it is not an OM issue... but maybe someone out there might be able to give some insight.
Company “A” (via it’s corporate WiFi network) was able to access a room... ... see room interactions (for example switching from whiteboard to whiteboard... typing onscreen etc) but could not share or receive audio/mic and video of other users. Clearly there were restrictions (firewall or others) on their side. However, when users used the public access network... everything was fine. Sweet. No problem now.
However, I have encountered a similar situation with Company “B”... and have asked them to use their “public” network... but they can’t experience incoming nor outgoing audio or cam.
Can you recommend a permissions checklist that they could follow to give them full access and functionality to OM?
One user from company “B” brought their computer home... logged in and they had no problem with audio/mic/cam.... so obviously there are restrictions on a corporate level.
Can anyone recommend a permissions checklist that company “B” needs to follow (grant access to)... without compromising their network or security?
Company “B” has used Zoom, Microsoft Teams without issue... but of course, these are downloaded apps (and not necessarily browser based).
@Maxim... I now this is going to cause you a headache... and I apologize in advance... but may open a few other discussions.
Any help, suggestions would be appreciated.
I know this is a huge request... but might shape future releases.
All the best,
Denis.
Sent from my iPhone
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Maxim Solodovnik <so...@gmail.com>.
On Tue, 20 Oct 2020 at 08:42, seba.wagner@gmail.com <se...@gmail.com>
wrote:
> It's all about the initial connection I think.
>
> Subsequent port negotiations are always on other ports. But that is when
> nat traversal is solved.
>
In case of corporate networks
this "other" ports should also be opened
>
> So obviously I am not 100% sure if packet filters would still act on the
> subsequent negotiated ports of the actual data communication. But I would
> guess the main thing is to get this initial communication to
> negotiate ports through. Once that is done, you should be usually fine.
>
> 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, 20 Oct 2020 at 14:37, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, 20 Oct 2020 at 02:52, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Zoom, Microsoft Teams without issue... but of course, these are
>>> downloaded apps (and not necessarily browser based).
>>> => Try with Google Talk. That is browser based. It should use the same
>>> client side technologies OpenMeetings uses.
>>>
>>> As Maxim says, in the past (with flash streaming) the solution has been
>>> HTTP Tunneling. And then moving HTTP tunneling on port 443, as usually
>>> there are no packet inspections configured for Firewalls on SSL (as they
>>> won't be able to inspect it anyway). Or use HTTPS Tunneling directly (but
>>> that was always quite resource intensive for streaming).
>>>
>>> There seem to be similar stories around Turn server (and webRTC
>>> streaming):
>>> - Move turn server to port 80 and 443
>>> - Use transport mode TCP
>>>
>>
>> Are you sure only 443 will be used by TURN this way?
>> Currently port 3478 is being used for initial communication and in
>> "discovery" mode
>> Tunneling (if used) will use more ports in min-port:max-port range
>> configured
>>
>>
>>
>> - Enable SSL certificates on Turn Server (havn't tried that one yet)
>>>
>>> It is also a good idea to inspect Turn server log files for messages (as
>>> well as enable OpenMeetings Wicket DEVELOPMENT mode) so you can see the
>>> iceCandidates (and trickleICE) process, when the browser tries through
>>> various IP and port combinations to poke a hole through the network.
>>>
>>> In order to test your Turn server you can use this trickleICE test page
>>> from the webRTC project group:
>>> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
>>> Issues around Turn server and trickleICE will be usually reported &
>>> discussed on the webRTC mailing list via this App.
>>>
>>> And finally obviously, assuming you know the target domain and
>>> transport, the easiest would obviously be to ask the company to open up
>>> their firewall!
>>>
>>> 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 Sat, 17 Oct 2020 at 04:20, Ali Alhaidary <al...@the5stars.org>
>>> wrote:
>>>
>>>>
>>>> On 10/16/20 6:14 PM, Maxim Solodovnik wrote:
>>>>
>>>> Well,
>>>>
>>>> according to my experience all corporate admins use the following
>>>> principle: "Close everything, then open all what is necessary by request"
>>>> :)))
>>>>
>>>> very much correct ;-)
>>>>
>>>>
>>>> OM now requires lots of ports :(
>>>> there was an idea of "bullet proof" network configuration (port 443
>>>> only)
>>>> but I haven't tested it yet :(
>>>> (and it was only a high level description only ... :(( )
>>>>
>>>> On Fri, 16 Oct 2020 at 22:10, Denis Noctor <de...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi there Maxim... you’ve really got my interest and attention here...
>>>>> :) Can you explain a little more why this might not be an ultimate
>>>>> solution? Thanks a lot.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> well
>>>>>
>>>>> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
>>>>> unfortunately this is not ultimate solution :(
>>>>>
>>>>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I suppose this all boils down to UDP being usually blocked by most
>>>>>> private corporate networks. Only solution I can recommend is that UDP is
>>>>>> unblocked on a public network.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>> *From:* Denis Noctor <de...@gmail.com>
>>>>>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>>>>>> *To:* user@openmeetings.apache.org
>>>>>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>>>>>
>>>>>> Hi there Maxim... and everyone out there,
>>>>>>
>>>>>> I know this email might be considered a little off topic... but
>>>>>> resonates an issue that may have been overlooked in the overall application
>>>>>> of OM at a corporate level.
>>>>>>
>>>>>> Let me try to explain. At present OM is browser based... thankfully
>>>>>> Chrome and Firefox support WebRTC etc. I am aware of the Safari issues
>>>>>> being discussed regarding audio and vid etc.
>>>>>>
>>>>>> The majority of users I have are experiencing a relatively fluid
>>>>>> experience regarding OM... however I have encountered 2 scenarios over the
>>>>>> last few months that contradict each other... though it is not an OM
>>>>>> issue... but maybe someone out there might be able to give some insight.
>>>>>>
>>>>>> Company “A” (via it’s corporate WiFi network) was able to access a
>>>>>> room... ... see room interactions (for example switching from whiteboard to
>>>>>> whiteboard... typing onscreen etc) but could not share or receive audio/mic
>>>>>> and video of other users. Clearly there were restrictions (firewall or
>>>>>> others) on their side. However, when users used the public access
>>>>>> network... everything was fine. Sweet. No problem now.
>>>>>>
>>>>>> However, I have encountered a similar situation with Company “B”...
>>>>>> and have asked them to use their “public” network... but they can’t
>>>>>> experience incoming nor outgoing audio or cam.
>>>>>>
>>>>>> Can you recommend a permissions checklist that they could follow to
>>>>>> give them full access and functionality to OM?
>>>>>>
>>>>>> One user from company “B” brought their computer home... logged in
>>>>>> and they had no problem with audio/mic/cam.... so obviously there are
>>>>>> restrictions on a corporate level.
>>>>>>
>>>>>> Can anyone recommend a permissions checklist that company “B” needs
>>>>>> to follow (grant access to)... without compromising their network or
>>>>>> security?
>>>>>>
>>>>>> Company “B” has used Zoom, Microsoft Teams without issue... but of
>>>>>> course, these are downloaded apps (and not necessarily browser based).
>>>>>>
>>>>>> @Maxim... I now this is going to cause you a headache... and I
>>>>>> apologize in advance... but may open a few other discussions.
>>>>>>
>>>>>> Any help, suggestions would be appreciated.
>>>>>>
>>>>>> I know this is a huge request... but might shape future releases.
>>>>>>
>>>>>> All the best,
>>>>>>
>>>>>> Denis.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Maxim
>>>>>
>>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Maxim
>>>>
>>>>
>>
>> --
>> Best regards,
>> Maxim
>>
>
--
Best regards,
Maxim
Re: General and Corporate User... (Off Topic... Sorry)
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
It's all about the initial connection I think.
Subsequent port negotiations are always on other ports. But that is when
nat traversal is solved.
So obviously I am not 100% sure if packet filters would still act on the
subsequent negotiated ports of the actual data communication. But I would
guess the main thing is to get this initial communication to
negotiate ports through. Once that is done, you should be usually fine.
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, 20 Oct 2020 at 14:37, Maxim Solodovnik <so...@gmail.com> wrote:
>
>
> On Tue, 20 Oct 2020 at 02:52, seba.wagner@gmail.com <se...@gmail.com>
> wrote:
>
>> Zoom, Microsoft Teams without issue... but of course, these are
>> downloaded apps (and not necessarily browser based).
>> => Try with Google Talk. That is browser based. It should use the same
>> client side technologies OpenMeetings uses.
>>
>> As Maxim says, in the past (with flash streaming) the solution has been
>> HTTP Tunneling. And then moving HTTP tunneling on port 443, as usually
>> there are no packet inspections configured for Firewalls on SSL (as they
>> won't be able to inspect it anyway). Or use HTTPS Tunneling directly (but
>> that was always quite resource intensive for streaming).
>>
>> There seem to be similar stories around Turn server (and webRTC
>> streaming):
>> - Move turn server to port 80 and 443
>> - Use transport mode TCP
>>
>
> Are you sure only 443 will be used by TURN this way?
> Currently port 3478 is being used for initial communication and in
> "discovery" mode
> Tunneling (if used) will use more ports in min-port:max-port range
> configured
>
>
>
> - Enable SSL certificates on Turn Server (havn't tried that one yet)
>>
>> It is also a good idea to inspect Turn server log files for messages (as
>> well as enable OpenMeetings Wicket DEVELOPMENT mode) so you can see the
>> iceCandidates (and trickleICE) process, when the browser tries through
>> various IP and port combinations to poke a hole through the network.
>>
>> In order to test your Turn server you can use this trickleICE test page
>> from the webRTC project group:
>> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
>> Issues around Turn server and trickleICE will be usually reported &
>> discussed on the webRTC mailing list via this App.
>>
>> And finally obviously, assuming you know the target domain and transport,
>> the easiest would obviously be to ask the company to open up their firewall!
>>
>> 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 Sat, 17 Oct 2020 at 04:20, Ali Alhaidary <al...@the5stars.org>
>> wrote:
>>
>>>
>>> On 10/16/20 6:14 PM, Maxim Solodovnik wrote:
>>>
>>> Well,
>>>
>>> according to my experience all corporate admins use the following
>>> principle: "Close everything, then open all what is necessary by request"
>>> :)))
>>>
>>> very much correct ;-)
>>>
>>>
>>> OM now requires lots of ports :(
>>> there was an idea of "bullet proof" network configuration (port 443 only)
>>> but I haven't tested it yet :(
>>> (and it was only a high level description only ... :(( )
>>>
>>> On Fri, 16 Oct 2020 at 22:10, Denis Noctor <de...@gmail.com>
>>> wrote:
>>>
>>>> Hi there Maxim... you’ve really got my interest and attention here...
>>>> :) Can you explain a little more why this might not be an ultimate
>>>> solution? Thanks a lot.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com>
>>>> wrote:
>>>>
>>>> well
>>>>
>>>> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
>>>> unfortunately this is not ultimate solution :(
>>>>
>>>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com>
>>>> wrote:
>>>>
>>>>> I suppose this all boils down to UDP being usually blocked by most
>>>>> private corporate networks. Only solution I can recommend is that UDP is
>>>>> unblocked on a public network.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> *From:* Denis Noctor <de...@gmail.com>
>>>>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>>>>> *To:* user@openmeetings.apache.org
>>>>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>>>>
>>>>> Hi there Maxim... and everyone out there,
>>>>>
>>>>> I know this email might be considered a little off topic... but
>>>>> resonates an issue that may have been overlooked in the overall application
>>>>> of OM at a corporate level.
>>>>>
>>>>> Let me try to explain. At present OM is browser based... thankfully
>>>>> Chrome and Firefox support WebRTC etc. I am aware of the Safari issues
>>>>> being discussed regarding audio and vid etc.
>>>>>
>>>>> The majority of users I have are experiencing a relatively fluid
>>>>> experience regarding OM... however I have encountered 2 scenarios over the
>>>>> last few months that contradict each other... though it is not an OM
>>>>> issue... but maybe someone out there might be able to give some insight.
>>>>>
>>>>> Company “A” (via it’s corporate WiFi network) was able to access a
>>>>> room... ... see room interactions (for example switching from whiteboard to
>>>>> whiteboard... typing onscreen etc) but could not share or receive audio/mic
>>>>> and video of other users. Clearly there were restrictions (firewall or
>>>>> others) on their side. However, when users used the public access
>>>>> network... everything was fine. Sweet. No problem now.
>>>>>
>>>>> However, I have encountered a similar situation with Company “B”...
>>>>> and have asked them to use their “public” network... but they can’t
>>>>> experience incoming nor outgoing audio or cam.
>>>>>
>>>>> Can you recommend a permissions checklist that they could follow to
>>>>> give them full access and functionality to OM?
>>>>>
>>>>> One user from company “B” brought their computer home... logged in and
>>>>> they had no problem with audio/mic/cam.... so obviously there are
>>>>> restrictions on a corporate level.
>>>>>
>>>>> Can anyone recommend a permissions checklist that company “B” needs to
>>>>> follow (grant access to)... without compromising their network or security?
>>>>>
>>>>> Company “B” has used Zoom, Microsoft Teams without issue... but of
>>>>> course, these are downloaded apps (and not necessarily browser based).
>>>>>
>>>>> @Maxim... I now this is going to cause you a headache... and I
>>>>> apologize in advance... but may open a few other discussions.
>>>>>
>>>>> Any help, suggestions would be appreciated.
>>>>>
>>>>> I know this is a huge request... but might shape future releases.
>>>>>
>>>>> All the best,
>>>>>
>>>>> Denis.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Maxim
>>>>
>>>>
>>>
>>> --
>>> Best regards,
>>> Maxim
>>>
>>>
>
> --
> Best regards,
> Maxim
>
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Maxim Solodovnik <so...@gmail.com>.
On Tue, 20 Oct 2020 at 02:52, seba.wagner@gmail.com <se...@gmail.com>
wrote:
> Zoom, Microsoft Teams without issue... but of course, these are downloaded
> apps (and not necessarily browser based).
> => Try with Google Talk. That is browser based. It should use the same
> client side technologies OpenMeetings uses.
>
> As Maxim says, in the past (with flash streaming) the solution has been
> HTTP Tunneling. And then moving HTTP tunneling on port 443, as usually
> there are no packet inspections configured for Firewalls on SSL (as they
> won't be able to inspect it anyway). Or use HTTPS Tunneling directly (but
> that was always quite resource intensive for streaming).
>
> There seem to be similar stories around Turn server (and webRTC streaming):
> - Move turn server to port 80 and 443
> - Use transport mode TCP
>
Are you sure only 443 will be used by TURN this way?
Currently port 3478 is being used for initial communication and in
"discovery" mode
Tunneling (if used) will use more ports in min-port:max-port range
configured
- Enable SSL certificates on Turn Server (havn't tried that one yet)
>
> It is also a good idea to inspect Turn server log files for messages (as
> well as enable OpenMeetings Wicket DEVELOPMENT mode) so you can see the
> iceCandidates (and trickleICE) process, when the browser tries through
> various IP and port combinations to poke a hole through the network.
>
> In order to test your Turn server you can use this trickleICE test page
> from the webRTC project group:
> https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
> Issues around Turn server and trickleICE will be usually reported &
> discussed on the webRTC mailing list via this App.
>
> And finally obviously, assuming you know the target domain and transport,
> the easiest would obviously be to ask the company to open up their firewall!
>
> 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 Sat, 17 Oct 2020 at 04:20, Ali Alhaidary <al...@the5stars.org>
> wrote:
>
>>
>> On 10/16/20 6:14 PM, Maxim Solodovnik wrote:
>>
>> Well,
>>
>> according to my experience all corporate admins use the following
>> principle: "Close everything, then open all what is necessary by request"
>> :)))
>>
>> very much correct ;-)
>>
>>
>> OM now requires lots of ports :(
>> there was an idea of "bullet proof" network configuration (port 443 only)
>> but I haven't tested it yet :(
>> (and it was only a high level description only ... :(( )
>>
>> On Fri, 16 Oct 2020 at 22:10, Denis Noctor <de...@gmail.com> wrote:
>>
>>> Hi there Maxim... you’ve really got my interest and attention here... :)
>>> Can you explain a little more why this might not be an ultimate solution?
>>> Thanks a lot.
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com>
>>> wrote:
>>>
>>> well
>>>
>>> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
>>> unfortunately this is not ultimate solution :(
>>>
>>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com>
>>> wrote:
>>>
>>>> I suppose this all boils down to UDP being usually blocked by most
>>>> private corporate networks. Only solution I can recommend is that UDP is
>>>> unblocked on a public network.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> Begin forwarded message:
>>>>
>>>> *From:* Denis Noctor <de...@gmail.com>
>>>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>>>> *To:* user@openmeetings.apache.org
>>>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>>>
>>>> Hi there Maxim... and everyone out there,
>>>>
>>>> I know this email might be considered a little off topic... but
>>>> resonates an issue that may have been overlooked in the overall application
>>>> of OM at a corporate level.
>>>>
>>>> Let me try to explain. At present OM is browser based... thankfully
>>>> Chrome and Firefox support WebRTC etc. I am aware of the Safari issues
>>>> being discussed regarding audio and vid etc.
>>>>
>>>> The majority of users I have are experiencing a relatively fluid
>>>> experience regarding OM... however I have encountered 2 scenarios over the
>>>> last few months that contradict each other... though it is not an OM
>>>> issue... but maybe someone out there might be able to give some insight.
>>>>
>>>> Company “A” (via it’s corporate WiFi network) was able to access a
>>>> room... ... see room interactions (for example switching from whiteboard to
>>>> whiteboard... typing onscreen etc) but could not share or receive audio/mic
>>>> and video of other users. Clearly there were restrictions (firewall or
>>>> others) on their side. However, when users used the public access
>>>> network... everything was fine. Sweet. No problem now.
>>>>
>>>> However, I have encountered a similar situation with Company “B”... and
>>>> have asked them to use their “public” network... but they can’t experience
>>>> incoming nor outgoing audio or cam.
>>>>
>>>> Can you recommend a permissions checklist that they could follow to
>>>> give them full access and functionality to OM?
>>>>
>>>> One user from company “B” brought their computer home... logged in and
>>>> they had no problem with audio/mic/cam.... so obviously there are
>>>> restrictions on a corporate level.
>>>>
>>>> Can anyone recommend a permissions checklist that company “B” needs to
>>>> follow (grant access to)... without compromising their network or security?
>>>>
>>>> Company “B” has used Zoom, Microsoft Teams without issue... but of
>>>> course, these are downloaded apps (and not necessarily browser based).
>>>>
>>>> @Maxim... I now this is going to cause you a headache... and I
>>>> apologize in advance... but may open a few other discussions.
>>>>
>>>> Any help, suggestions would be appreciated.
>>>>
>>>> I know this is a huge request... but might shape future releases.
>>>>
>>>> All the best,
>>>>
>>>> Denis.
>>>>
>>>> Sent from my iPhone
>>>>
>>>>
>>>
>>> --
>>> Best regards,
>>> Maxim
>>>
>>>
>>
>> --
>> Best regards,
>> Maxim
>>
>>
--
Best regards,
Maxim
Re: General and Corporate User... (Off Topic... Sorry)
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Zoom, Microsoft Teams without issue... but of course, these are downloaded
apps (and not necessarily browser based).
=> Try with Google Talk. That is browser based. It should use the same
client side technologies OpenMeetings uses.
As Maxim says, in the past (with flash streaming) the solution has been
HTTP Tunneling. And then moving HTTP tunneling on port 443, as usually
there are no packet inspections configured for Firewalls on SSL (as they
won't be able to inspect it anyway). Or use HTTPS Tunneling directly (but
that was always quite resource intensive for streaming).
There seem to be similar stories around Turn server (and webRTC streaming):
- Move turn server to port 80 and 443
- Use transport mode TCP
- Enable SSL certificates on Turn Server (havn't tried that one yet)
It is also a good idea to inspect Turn server log files for messages (as
well as enable OpenMeetings Wicket DEVELOPMENT mode) so you can see the
iceCandidates (and trickleICE) process, when the browser tries through
various IP and port combinations to poke a hole through the network.
In order to test your Turn server you can use this trickleICE test page
from the webRTC project group:
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Issues around Turn server and trickleICE will be usually reported &
discussed on the webRTC mailing list via this App.
And finally obviously, assuming you know the target domain and transport,
the easiest would obviously be to ask the company to open up their firewall!
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 Sat, 17 Oct 2020 at 04:20, Ali Alhaidary <al...@the5stars.org>
wrote:
>
> On 10/16/20 6:14 PM, Maxim Solodovnik wrote:
>
> Well,
>
> according to my experience all corporate admins use the following
> principle: "Close everything, then open all what is necessary by request"
> :)))
>
> very much correct ;-)
>
>
> OM now requires lots of ports :(
> there was an idea of "bullet proof" network configuration (port 443 only)
> but I haven't tested it yet :(
> (and it was only a high level description only ... :(( )
>
> On Fri, 16 Oct 2020 at 22:10, Denis Noctor <de...@gmail.com> wrote:
>
>> Hi there Maxim... you’ve really got my interest and attention here... :)
>> Can you explain a little more why this might not be an ultimate solution?
>> Thanks a lot.
>>
>> Sent from my iPhone
>>
>> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com>
>> wrote:
>>
>> well
>>
>> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
>> unfortunately this is not ultimate solution :(
>>
>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com> wrote:
>>
>>> I suppose this all boils down to UDP being usually blocked by most
>>> private corporate networks. Only solution I can recommend is that UDP is
>>> unblocked on a public network.
>>>
>>> Sent from my iPhone
>>>
>>> Begin forwarded message:
>>>
>>> *From:* Denis Noctor <de...@gmail.com>
>>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>>> *To:* user@openmeetings.apache.org
>>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>>
>>> Hi there Maxim... and everyone out there,
>>>
>>> I know this email might be considered a little off topic... but
>>> resonates an issue that may have been overlooked in the overall application
>>> of OM at a corporate level.
>>>
>>> Let me try to explain. At present OM is browser based... thankfully
>>> Chrome and Firefox support WebRTC etc. I am aware of the Safari issues
>>> being discussed regarding audio and vid etc.
>>>
>>> The majority of users I have are experiencing a relatively fluid
>>> experience regarding OM... however I have encountered 2 scenarios over the
>>> last few months that contradict each other... though it is not an OM
>>> issue... but maybe someone out there might be able to give some insight.
>>>
>>> Company “A” (via it’s corporate WiFi network) was able to access a
>>> room... ... see room interactions (for example switching from whiteboard to
>>> whiteboard... typing onscreen etc) but could not share or receive audio/mic
>>> and video of other users. Clearly there were restrictions (firewall or
>>> others) on their side. However, when users used the public access
>>> network... everything was fine. Sweet. No problem now.
>>>
>>> However, I have encountered a similar situation with Company “B”... and
>>> have asked them to use their “public” network... but they can’t experience
>>> incoming nor outgoing audio or cam.
>>>
>>> Can you recommend a permissions checklist that they could follow to give
>>> them full access and functionality to OM?
>>>
>>> One user from company “B” brought their computer home... logged in and
>>> they had no problem with audio/mic/cam.... so obviously there are
>>> restrictions on a corporate level.
>>>
>>> Can anyone recommend a permissions checklist that company “B” needs to
>>> follow (grant access to)... without compromising their network or security?
>>>
>>> Company “B” has used Zoom, Microsoft Teams without issue... but of
>>> course, these are downloaded apps (and not necessarily browser based).
>>>
>>> @Maxim... I now this is going to cause you a headache... and I apologize
>>> in advance... but may open a few other discussions.
>>>
>>> Any help, suggestions would be appreciated.
>>>
>>> I know this is a huge request... but might shape future releases.
>>>
>>> All the best,
>>>
>>> Denis.
>>>
>>> Sent from my iPhone
>>>
>>>
>>
>> --
>> Best regards,
>> Maxim
>>
>>
>
> --
> Best regards,
> Maxim
>
>
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Ali Alhaidary <al...@the5stars.org>.
On 10/16/20 6:14 PM, Maxim Solodovnik wrote:
> Well,
>
> according to my experience all corporate admins use the following
> principle: "Close everything, then open all what is necessary by
> request" :)))
very much correct ;-)
> OM now requires lots of ports :(
> there was an idea of "bullet proof" network configuration (port 443 only)
> but I haven't tested it yet :(
> (and it was only a high level description only ... :(( )
>
> On Fri, 16 Oct 2020 at 22:10, Denis Noctor <denisnoctor@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi there Maxim... you’ve really got my interest and attention
> here... :) Can you explain a little more why this might not be an
> ultimate solution? Thanks a lot.
>
> Sent from my iPhone
>
> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik
> <solomax666@gmail.com <ma...@gmail.com>> wrote:
>
>> well
>>
>> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
>> unfortunately this is not ultimate solution :(
>>
>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <denisnoctor@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> I suppose this all boils down to UDP being usually blocked by
>> most private corporate networks. Only solution I can
>> recommend is that UDP is unblocked on a public network.
>>
>> Sent from my iPhone
>>
>> Begin forwarded message:
>>
>>> *From:* Denis Noctor <denisnoctor@gmail.com
>>> <ma...@gmail.com>>
>>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>>> *To:* user@openmeetings.apache.org
>>> <ma...@openmeetings.apache.org>
>>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>>
>>> Hi there Maxim... and everyone out there,
>>>
>>> I know this email might be considered a little off topic...
>>> but resonates an issue that may have been overlooked in the
>>> overall application of OM at a corporate level.
>>>
>>> Let me try to explain. At present OM is browser based...
>>> thankfully Chrome and Firefox support WebRTC etc. I am aware
>>> of the Safari issues being discussed regarding audio and vid
>>> etc.
>>>
>>> The majority of users I have are experiencing a relatively
>>> fluid experience regarding OM... however I have encountered
>>> 2 scenarios over the last few months that contradict each
>>> other... though it is not an OM issue... but maybe someone
>>> out there might be able to give some insight.
>>>
>>> Company “A” (via it’s corporate WiFi network) was able to
>>> access a room... ... see room interactions (for example
>>> switching from whiteboard to whiteboard... typing onscreen
>>> etc) but could not share or receive audio/mic and video of
>>> other users. Clearly there were restrictions (firewall or
>>> others) on their side. However, when users used the public
>>> access network... everything was fine. Sweet. No problem now.
>>>
>>> However, I have encountered a similar situation with Company
>>> “B”... and have asked them to use their “public” network...
>>> but they can’t experience incoming nor outgoing audio or cam.
>>>
>>> Can you recommend a permissions checklist that they could
>>> follow to give them full access and functionality to OM?
>>>
>>> One user from company “B” brought their computer home...
>>> logged in and they had no problem with audio/mic/cam.... so
>>> obviously there are restrictions on a corporate level.
>>>
>>> Can anyone recommend a permissions checklist that company
>>> “B” needs to follow (grant access to)... without
>>> compromising their network or security?
>>>
>>> Company “B” has used Zoom, Microsoft Teams without issue...
>>> but of course, these are downloaded apps (and not
>>> necessarily browser based).
>>>
>>> @Maxim... I now this is going to cause you a headache... and
>>> I apologize in advance... but may open a few other discussions.
>>>
>>> Any help, suggestions would be appreciated.
>>>
>>> I know this is a huge request... but might shape future
>>> releases.
>>>
>>> All the best,
>>>
>>> Denis.
>>>
>>> Sent from my iPhone
>>
>>
>>
>> --
>> Best regards,
>> Maxim
>
>
>
> --
> Best regards,
> Maxim
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Maxim Solodovnik <so...@gmail.com>.
Well,
according to my experience all corporate admins use the following
principle: "Close everything, then open all what is necessary by request"
:)))
OM now requires lots of ports :(
there was an idea of "bullet proof" network configuration (port 443 only)
but I haven't tested it yet :(
(and it was only a high level description only ... :(( )
On Fri, 16 Oct 2020 at 22:10, Denis Noctor <de...@gmail.com> wrote:
> Hi there Maxim... you’ve really got my interest and attention here... :)
> Can you explain a little more why this might not be an ultimate solution?
> Thanks a lot.
>
> Sent from my iPhone
>
> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
> well
>
> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
> unfortunately this is not ultimate solution :(
>
> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com> wrote:
>
>> I suppose this all boils down to UDP being usually blocked by most
>> private corporate networks. Only solution I can recommend is that UDP is
>> unblocked on a public network.
>>
>> Sent from my iPhone
>>
>> Begin forwarded message:
>>
>> *From:* Denis Noctor <de...@gmail.com>
>> *Date:* October 15, 2020 at 1:29:35 AM CDT
>> *To:* user@openmeetings.apache.org
>> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>>
>> Hi there Maxim... and everyone out there,
>>
>> I know this email might be considered a little off topic... but resonates
>> an issue that may have been overlooked in the overall application of OM at
>> a corporate level.
>>
>> Let me try to explain. At present OM is browser based... thankfully
>> Chrome and Firefox support WebRTC etc. I am aware of the Safari issues
>> being discussed regarding audio and vid etc.
>>
>> The majority of users I have are experiencing a relatively fluid
>> experience regarding OM... however I have encountered 2 scenarios over the
>> last few months that contradict each other... though it is not an OM
>> issue... but maybe someone out there might be able to give some insight.
>>
>> Company “A” (via it’s corporate WiFi network) was able to access a
>> room... ... see room interactions (for example switching from whiteboard to
>> whiteboard... typing onscreen etc) but could not share or receive audio/mic
>> and video of other users. Clearly there were restrictions (firewall or
>> others) on their side. However, when users used the public access
>> network... everything was fine. Sweet. No problem now.
>>
>> However, I have encountered a similar situation with Company “B”... and
>> have asked them to use their “public” network... but they can’t experience
>> incoming nor outgoing audio or cam.
>>
>> Can you recommend a permissions checklist that they could follow to give
>> them full access and functionality to OM?
>>
>> One user from company “B” brought their computer home... logged in and
>> they had no problem with audio/mic/cam.... so obviously there are
>> restrictions on a corporate level.
>>
>> Can anyone recommend a permissions checklist that company “B” needs to
>> follow (grant access to)... without compromising their network or security?
>>
>> Company “B” has used Zoom, Microsoft Teams without issue... but of
>> course, these are downloaded apps (and not necessarily browser based).
>>
>> @Maxim... I now this is going to cause you a headache... and I apologize
>> in advance... but may open a few other discussions.
>>
>> Any help, suggestions would be appreciated.
>>
>> I know this is a huge request... but might shape future releases.
>>
>> All the best,
>>
>> Denis.
>>
>> Sent from my iPhone
>>
>>
>
> --
> Best regards,
> Maxim
>
>
--
Best regards,
Maxim
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Denis Noctor <de...@gmail.com>.
Hi there Maxim... you’ve really got my interest and attention here... :) Can you explain a little more why this might not be an ultimate solution? Thanks a lot.
Sent from my iPhone
> On Oct 16, 2020, at 9:17 AM, Maxim Solodovnik <so...@gmail.com> wrote:
>
> well
>
> you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
> unfortunately this is not ultimate solution :(
>
>> On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com> wrote:
>> I suppose this all boils down to UDP being usually blocked by most private corporate networks. Only solution I can recommend is that UDP is unblocked on a public network.
>>
>> Sent from my iPhone
>>
>> Begin forwarded message:
>>
>>> From: Denis Noctor <de...@gmail.com>
>>> Date: October 15, 2020 at 1:29:35 AM CDT
>>> To: user@openmeetings.apache.org
>>> Subject: General and Corporate User... (Off Topic... Sorry)
>>>
>>> Hi there Maxim... and everyone out there,
>>>
>>> I know this email might be considered a little off topic... but resonates an issue that may have been overlooked in the overall application of OM at a corporate level.
>>>
>>> Let me try to explain. At present OM is browser based... thankfully Chrome and Firefox support WebRTC etc. I am aware of the Safari issues being discussed regarding audio and vid etc.
>>>
>>> The majority of users I have are experiencing a relatively fluid experience regarding OM... however I have encountered 2 scenarios over the last few months that contradict each other... though it is not an OM issue... but maybe someone out there might be able to give some insight.
>>>
>>> Company “A” (via it’s corporate WiFi network) was able to access a room... ... see room interactions (for example switching from whiteboard to whiteboard... typing onscreen etc) but could not share or receive audio/mic and video of other users. Clearly there were restrictions (firewall or others) on their side. However, when users used the public access network... everything was fine. Sweet. No problem now.
>>>
>>> However, I have encountered a similar situation with Company “B”... and have asked them to use their “public” network... but they can’t experience incoming nor outgoing audio or cam.
>>>
>>> Can you recommend a permissions checklist that they could follow to give them full access and functionality to OM?
>>>
>>> One user from company “B” brought their computer home... logged in and they had no problem with audio/mic/cam.... so obviously there are restrictions on a corporate level.
>>>
>>> Can anyone recommend a permissions checklist that company “B” needs to follow (grant access to)... without compromising their network or security?
>>>
>>> Company “B” has used Zoom, Microsoft Teams without issue... but of course, these are downloaded apps (and not necessarily browser based).
>>>
>>> @Maxim... I now this is going to cause you a headache... and I apologize in advance... but may open a few other discussions.
>>>
>>> Any help, suggestions would be appreciated.
>>>
>>> I know this is a huge request... but might shape future releases.
>>>
>>> All the best,
>>>
>>> Denis.
>>>
>>> Sent from my iPhone
>
>
> --
> Best regards,
> Maxim
Re: General and Corporate User... (Off Topic... Sorry)
Posted by Maxim Solodovnik <so...@gmail.com>.
well
you can set TURN to use TCP (just add `?transport=tcp` to TURN URL)
unfortunately this is not ultimate solution :(
On Thu, 15 Oct 2020 at 23:48, Denis Noctor <de...@gmail.com> wrote:
> I suppose this all boils down to UDP being usually blocked by most private
> corporate networks. Only solution I can recommend is that UDP is unblocked
> on a public network.
>
> Sent from my iPhone
>
> Begin forwarded message:
>
> *From:* Denis Noctor <de...@gmail.com>
> *Date:* October 15, 2020 at 1:29:35 AM CDT
> *To:* user@openmeetings.apache.org
> *Subject:* *General and Corporate User... (Off Topic... Sorry)*
>
> Hi there Maxim... and everyone out there,
>
> I know this email might be considered a little off topic... but resonates
> an issue that may have been overlooked in the overall application of OM at
> a corporate level.
>
> Let me try to explain. At present OM is browser based... thankfully Chrome
> and Firefox support WebRTC etc. I am aware of the Safari issues being
> discussed regarding audio and vid etc.
>
> The majority of users I have are experiencing a relatively fluid
> experience regarding OM... however I have encountered 2 scenarios over the
> last few months that contradict each other... though it is not an OM
> issue... but maybe someone out there might be able to give some insight.
>
> Company “A” (via it’s corporate WiFi network) was able to access a room...
> ... see room interactions (for example switching from whiteboard to
> whiteboard... typing onscreen etc) but could not share or receive audio/mic
> and video of other users. Clearly there were restrictions (firewall or
> others) on their side. However, when users used the public access
> network... everything was fine. Sweet. No problem now.
>
> However, I have encountered a similar situation with Company “B”... and
> have asked them to use their “public” network... but they can’t experience
> incoming nor outgoing audio or cam.
>
> Can you recommend a permissions checklist that they could follow to give
> them full access and functionality to OM?
>
> One user from company “B” brought their computer home... logged in and
> they had no problem with audio/mic/cam.... so obviously there are
> restrictions on a corporate level.
>
> Can anyone recommend a permissions checklist that company “B” needs to
> follow (grant access to)... without compromising their network or security?
>
> Company “B” has used Zoom, Microsoft Teams without issue... but of course,
> these are downloaded apps (and not necessarily browser based).
>
> @Maxim... I now this is going to cause you a headache... and I apologize
> in advance... but may open a few other discussions.
>
> Any help, suggestions would be appreciated.
>
> I know this is a huge request... but might shape future releases.
>
> All the best,
>
> Denis.
>
> Sent from my iPhone
>
>
--
Best regards,
Maxim
Fwd: General and Corporate User... (Off Topic... Sorry)
Posted by Denis Noctor <de...@gmail.com>.
I suppose this all boils down to UDP being usually blocked by most private corporate networks. Only solution I can recommend is that UDP is unblocked on a public network.
Sent from my iPhone
Begin forwarded message:
> From: Denis Noctor <de...@gmail.com>
> Date: October 15, 2020 at 1:29:35 AM CDT
> To: user@openmeetings.apache.org
> Subject: General and Corporate User... (Off Topic... Sorry)
>
> Hi there Maxim... and everyone out there,
>
> I know this email might be considered a little off topic... but resonates an issue that may have been overlooked in the overall application of OM at a corporate level.
>
> Let me try to explain. At present OM is browser based... thankfully Chrome and Firefox support WebRTC etc. I am aware of the Safari issues being discussed regarding audio and vid etc.
>
> The majority of users I have are experiencing a relatively fluid experience regarding OM... however I have encountered 2 scenarios over the last few months that contradict each other... though it is not an OM issue... but maybe someone out there might be able to give some insight.
>
> Company “A” (via it’s corporate WiFi network) was able to access a room... ... see room interactions (for example switching from whiteboard to whiteboard... typing onscreen etc) but could not share or receive audio/mic and video of other users. Clearly there were restrictions (firewall or others) on their side. However, when users used the public access network... everything was fine. Sweet. No problem now.
>
> However, I have encountered a similar situation with Company “B”... and have asked them to use their “public” network... but they can’t experience incoming nor outgoing audio or cam.
>
> Can you recommend a permissions checklist that they could follow to give them full access and functionality to OM?
>
> One user from company “B” brought their computer home... logged in and they had no problem with audio/mic/cam.... so obviously there are restrictions on a corporate level.
>
> Can anyone recommend a permissions checklist that company “B” needs to follow (grant access to)... without compromising their network or security?
>
> Company “B” has used Zoom, Microsoft Teams without issue... but of course, these are downloaded apps (and not necessarily browser based).
>
> @Maxim... I now this is going to cause you a headache... and I apologize in advance... but may open a few other discussions.
>
> Any help, suggestions would be appreciated.
>
> I know this is a huge request... but might shape future releases.
>
> All the best,
>
> Denis.
>
> Sent from my iPhone