SchoolCloud Parents Evening & SmoothWall

[smarties11]

Hi All,

 

There is an existing thread on this in the SmoothWall Direct Support forum, however it won't let me reply to it. Has this forum closed?

 

I wondered if any other SmoothWall users here have been able to get SchoolCloud Parents Evening system working using TCP only?

 

Their guide at https://support.parentseveningsystem.co.uk/article/825-video-appointments-network-requirements states that UDP is required for best quality. Responses on the previous post quoting SchoolCloud state that TCP only is fine. I have whitelisted and disabled HTTPS inspection for twilio.com, parentseveningsystem.co.uk, schoolcloud.co.uk, pendo.io and bugsnag.com PLUS the almost 4,000 IP addresses listed in their guide.

 

The Twilio tests all pass perfectly (except UDP of course), every single time.

 

On a live parents evening (and a trial one I have created) the calls only connect properly around 50% of the time. The parents name appears in the window, but there is only a black screen where the video would be. Same on parents end, they see the teacher name but no video. Sometimes the video kicks in after a few seconds, sometimes after a few minutes, sometimes not at all.

 

Those teachers working at home don't have this issue, just our on-site users. Thankfully not many of those at the moment!

 

SchoolCloud are recommending we allow UDP as per their technical document (though they say their tests indicate TCP only works - not sure how in-depth these tests were) however this concerns me as it's a total of 50,001 UDP ports over almost 4,000 worldwide Amazon AWS IP addresses, and this seems a bit like building a motorway to ride a pushbike down to me. We are a Lincs School so firewalling is done upstream on the emPSN network at KCOM, so the request would need to go via them.

 

Obviously if UDP is necessary then we'll have to evaluate the risk, however I just wondered whether other Schools have had success with TCP only as per the guide?

 

Thanks!

[pete]

We're also in Lincolnshire and found that in-school video connectivity required UDP enabled if the ISP was emPSN. The video link would never establish if one person was in-school (test parent or test teacher).

 

Most of our staff are happy to conduct parent's evenings on the sofa in their slippers, but a few staff with excessively noisy children at home have opted to stay in-school.

[smarties11]

We're also in Lincolnshire and found that in-school video connectivity required UDP enabled if the ISP was emPSN. The video link would never establish if one person was in-school (test parent or test teacher).

 

Most of our staff are happy to conduct parent's evenings on the sofa in their slippers, but a few staff with excessively noisy children at home have opted to stay in-school.

 

Hi Pete,

 

Thanks for this confirmation. Very frustrating when the message from SchoolCloud is that TCP only is OK, UDP for best quality.

 

Out of interest, to get it working, did you request just port 3478 to be open on UDP? Or the full 10,000-60,000 plus 3478? Again, mixed messages from SchoolCloud. Docs say the full shebang, support are asking for 3478 only.

 

If you did the full range, was this met with any challenge from KCOM/emPSN? It seems like a LOT of ports to open up over a LOT of IPs! I've looked up some of the IPs and they are all over the world! Twilio's docs suggest it's possible to force in their API that only a subset of data centres are used (rather than relying on latency tests) but I'm awaiting a response from SchoolCloud on this. It seems shoddy to me to open up IP ranges in China, Japan etc that will never be used unless our Teachers are in those countries...

 

Thanks!

[pete]

Schoolcloud may have changed their implementation since October 2020, but at the time it definitely didn't work via SW on an emPSN network. We verified using the various WebRTC test tools - https://networktest.twilio.com/

 

UDP 3478 wasn't mentioned in the documentation back then either and the note about UDP generally only appeared 2 weeks into our trial, so we made the bulk port changes (outbound only + related inbound).

 

We asked KCOM to sanity check the Schoolcloud instructions, but they were OK to make the change.

 

It's on the "revisit once we're back in" list, but at the time we discovered the UDP problem ~5 days before the first live parent's evening so....

[smarties11]

Schoolcloud may have changed their implementation since October 2020, but at the time it definitely didn't work via SW on an emPSN network. We verified using the various WebRTC test tools - https://networktest.twilio.com/

 

UDP 3478 wasn't mentioned in the documentation back then either and the note about UDP generally only appeared 2 weeks into our trial, so we made the bulk port changes (outbound only + related inbound).

 

We asked KCOM to sanity check the Schoolcloud instructions, but they were OK to make the change.

 

It's on the "revisit once we're back in" list, but at the time we discovered the UDP problem ~5 days before the first live parent's evening so....

 

Many thanks for your input Pete. I'll await confirmation from SchoolCloud over port 3478 or 10,000-60,000 and then get onto KCOM.

[toffee_paul]

Looking into using School Cloud for our next remote parents evenings, anyone know of issues with ISPs that aren't emPSN?

[smarties11]

Looking into using School Cloud for our next remote parents evenings, anyone know of issues with ISPs that aren't emPSN?

 

Hi,

 

The best thing to do at this stage is to run the Twilio Network Test (https://networktest.twilio.com/) - and make sure your clients pass ALL the tests. You'll need to run it from a PC with a mic and camera, and grant permissions when requested, in order to get a pass on these tests.

 

We were told by SchoolCloud technical support that only the TCP connectivity was required, and that UDP was required only 'for optimal call quality'. However, this was not the case for us. We found that with TCP connectivity we were hitting issues in around 50% of our calls where the connection wouldn't be made. Once we had our ISP put the UDP firewall rules in place, it worked perfectly.

 

Therefore, based on our experiences, if you don't get a green pass for all tests then you will need the relevant firewall rules in place - so the test is a good yardstick!

 

Hope this helps!

[jtotheb]

Hi,

 

The best thing to do at this stage is to run the Twilio Network Test (https://networktest.twilio.com/) - and make sure your clients pass ALL the tests. You'll need to run it from a PC with a mic and camera, and grant permissions when requested, in order to get a pass on these tests.

 

Just as an addendum to this, devices might pass the Twilio test with flying colours but you might still hit issues when using it in anger. UDP Flood prevention caused us issues in a weird way.

 

We ran the Twilio tests and performed individual dummy calls without issue, but once we had multiple live calls going it fell apart.

 

Schoolcloud do "strongly recommend" UDP Flooding protection is disabled in their requirements section, but it might not be triggered and reveal itself in testing - only once you've got multiple live calls going on.

 

When we saw it triggering on connections to clients we put in exceptions for the clients to/from Twilio, but this just shifted the flood to the ISP interface which didn't manifest until the next session so it may need a fairly broad to/from Twilio exception to work reliably depending on how your firewall's IPS works.

[smarties11]

Just as an addendum to this, devices might pass the Twilio test with flying colours but you might still hit issues when using it in anger. UDP Flood prevention caused us issues in a weird way.

 

We ran the Twilio tests and performed individual dummy calls without issue, but once we had multiple live calls going it fell apart.

 

Schoolcloud do "strongly recommend" UDP Flooding protection is disabled in their requirements section, but it might not be triggered and reveal itself in testing - only once you've got multiple live calls going on.

 

When we saw it triggering on connections to clients we put in exceptions for the clients to/from Twilio, but this just shifted the flood to the ISP interface which didn't manifest until the next session so it may need a fairly broad to/from Twilio exception to work reliably depending on how your firewall's IPS works.

 

This is interesting! Currently most teachers do their appointments from home, and we only have 6 or 7 on-site. We have had evenings in the past though where all teachers have been on-site without issue.

 

I'm thinking it might be worth putting an exception in now, as a pre-emptive measure for the future. Appreciate your feedback!

[jtotheb]

Currently most teachers do their appointments from home, and we only have 6 or 7 on-site. We have had evenings in the past though where all teachers have been on-site without issue.

 

I'm thinking it might be worth putting an exception in now, as a pre-emptive measure for the future. Appreciate your feedback!

 

It sounds like you're fine. We found 3+ simultaneous calls would kill it for us on a Sophos UTM.

[2097]

We just did one last night . Worked fine with Smoothwall.

 

But then again i have the exceptions in place and a large range of UDP ports unblocked on our separate firewall on demand when its required , Turned off again once finished.