Been asked to speak to you today to tell you about the facilities and services offered by JVCS, as the schools videoconferencing gateway piloting activity will take place using equipment that is provided for this service. Important for UKERNA to understand more about your videoconferencing activities Unique issues you face Challenges that you have encountered Requirements that are central to a successful videoconferencing infrastructure and service However, there is a tension here, as the operation of the service must not be put at risk or compromised
Role of JVCS – to support and facilitate videoconferencing for the community and their guests Standards based H.323 (IP) & H.320 (ISDN) videoconferencing only – and gatewaying between them If a conference does not start when it is scheduled to, the operators will proactively provide assistance It is often apparent on monitoring console that there is a problem – may manage to resolve without the conference participants being aware a change was made If an IP endpoint does not connect – they will redial it etc If a conference does not start as expected, a participant should phone the Management Centre to alert the operations staff. If there is a serious technical issue that cannot be resolved at the time – the operations staff will attempt to identify where the problem is Which part of the network Endpoint configuration issue Etc They will not be able to provide significant technical assistance to resolve the difficulty – as this is outside their current remit Elements of the service to support videoconferencing are…
Closely managed by UKERNA – I have daily interaction with John & other staff Variation in number of conferences supported – mainly due to variation in teaching use Typically support between 40 – 60 conferences a day these can be short, with 2 venues or complex with many venues, using IP & ISDN, requiring continual operator support Usually expect to have the phone answered by a person who can assist with the resolution of a problem during hours of operation – on the rare occasions when an operator is not available there is an answer phone
All conferences should be booked in the booking service – so everyone knows what is going on & endpoints/ venues don’t get double booked Feb 2004 – launched a new, improved user interface for the booking service – much easier to use Registration procedure – to gather all information, agree to security policy due to PDA – only open to academic users & those involved in this pilot others can be invited to conferences as ‘guests’ Username/password login – to track what users are doing Configurable “Favourites” list – to make frequent booking of conferences with people/endpoints easier Produces scheduling information - for the operators to schedule the conferences on the MCUs Auto-email of conference details – so everyone who needs to knows what is going on Statistics gathering tool – for reporting & ensure there is enough staff & MCU resource
Undertaking, and passing, a QA test is a prerequisite for use of JVCS During testing we have had experience of non-compliant H.323 endpoints severely adversely affecting conferences Eg audio interference In my personal experience - the worse case this can require rebooting on the whole MCU – meaning all conferences running at that time on that MCU are impacted. It obviously takes time to identify this type of fault – endpoint or MCU (which on the occasion I am referring to resulted two MCUs needing to be rebooted before we worked out what was going on) The purpose of the QA test is to provide advise on the quality of the set up of the facility It could be an endpoint is on a poorly provisioned network or in an unfortunate location – its better that is picked up in a test environment than in a situation where the technology is ‘mission critical’ Its very easy to blame the service if things go wrong – this is not necessarily the case I feel its important that the experience of the use of videoconferencing is good and the perception of JVCS is positive In my previous example it took us a while to realise it was the endpoint and not the MCU/service that was at fault. Compatibility tests for non-registered endpoints.
Reading MGC - max 24 endpoints at 2Mb/s IP Ditto for Leeds & Edinburgh Reading & Edinburgh can support 24 ISDN endpoints each at 384k/ISDN6 Leeds can support 8 ISDN endpoints each at 384k/ISDN6 (upgrade for this project) Total number of endpoints per MCU 48 at 384k or greater Not including the test MCU – not generally used as part of the service – for backup / resilience/ and testing
Other new documentation and more interop testing on the way VTAS is available for limited technical consultancy work - this is not funded as part of the project - So there would be an additional cost associated with this