On Tue, 20 Oct 2020 at 08:42, [email protected] <[email protected]> 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 <[email protected]> > wrote: > >> >> >> On Tue, 20 Oct 2020 at 02:52, [email protected] < >> [email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> *Date:* October 15, 2020 at 1:29:35 AM CDT >>>>>> *To:* [email protected] >>>>>> *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
