Software Fixes, Enhancements and Adjustments:
Problem uploading materials to the ACC with IWMaterials (CRs #21103, #24996):
End users upload files to events, portals, and overview pages on the ACC using the IWMaterials applications. Sometimes, IWMaterials did not read the proxy settings, and as a result it failed to upload the files to the ACC. The problem is now resolved.
Enhanced support for HTTP error code 401 (CRs #25276, #25093, #24939) Enhanced support for HTTP error code 407 (CR #25078):
The Participant application and myAT&T now offer complete support for HTTP error code 401. Error code 401 is typically returned from a proxy server that requires authentication. The Participant application and myAT&T did not support this request in some scenarios. They now respond to code 402 by displaying a dialog that prompts the user for network credentials, and submit them to the remote server. Similarly, HTTP error code is now fully supported in all scenarios.
ISS failure with proxies that require user authentication (CR #25076):
During event entry, the ISS determines the best available ICS for an end user based on their network connection and location. When the connection to an ICS crossed a proxy that required authentication, the ISS would “hang up” and had to be stopped by the user. The problem is now resolved and the ISS runs its routines quickly.
New EULA in Participant install (CRs #25079, #25080):
The Participant application now displays a new EULA (End User License Agreement). The EULA is always displayed and the user must accept it before install/upgrade continues.
Participant reconnects during Application Sharing (CR #25104):
The Participant application used to reconnect in the following scenario:
1. User A starts application sharing of his/her Participant application
2. User A gives remote control to user B over the shared Participant application
3. User B selects to minimize the Participant application or close one of its dialog windows (i.e. Audio devices).
4. The Participant application of User A disconnects and reconnects to the event.
The problem is now resolved.
Problem giving remote control on a shared application (CR #25105):
If the presenter tried to give control of a shared application to another user immediately after initiating the application sharing session, control did not pass to the remote user. The scenario was very rare, and the problem is now resolved.
“Caps Lock” status change in Application Sharing (CR #25269):
The status of the Caps Lock in Windows could have been changed unintentionally during application sharing in live events. The problem is now resolved.
ICS failure during Application Sharing (CR #25320) Application Sharing performance enhancement (CR #25321):
An improvement was made in the ICS mechanism that handles users with poor network connections during Application Sharing. The connection status of all users is now reset for each new application sharing session. Users with temporarily poor connection (i.e. because the user was downloading large files in the background) will enjoy improved performance once their network status has improved and a new Application Sharing session has started.
Enhancement in MS Word document insertion (CR #25322):
Users can insert MS Word documents from their desktop during a live event. Previously, users could have received an error message if they tried to display the document while the Participant application was still inserting it into the event. The scenario was rare and was not reported from the field but rather detected in our labs. The problem is now resolved.
Failure of Materials Editor in the presence of a Proxy server (CR #25550):
The Materials Editor displayed an error message to users when uploading files to the ACC through a Proxy Server. The error message was displayed in a very specific scenario. The problem is now resolved.
Application Sharing performance improvement (CR #25585):
The Participant application includes a mechanism that controls the Application Sharing session so it will not overload PC and network connections. The Participant application was previously configured to consume not more than 50% of the CPU time when sharing an application. The default has changed now to allow up to 70% of the CPU time. Users can change this value from the Options dialog in the Participant application.
We advise users to set the relevant „Output Bandwidth Control under the Application Sharing tab in the Options dialog based on their need and usage.