Xest Support

-

This is most likely a firewall issue.

Please configure your firewall to allow network traffic to and from the Xest applications.

if you are using the windows firewall or are not sure what firewall you are using please try the steps below:

Navigate to your control panel and find the windows firewall application.

click allow a program through windows firewall and add the Xest application to the allow list.

If this does not fix your issue or if windows firewall is not active, please contact your network administrator to get the Xest application added to the allowed list of programs.

Should this not fix the issue please contact us so we may further trouble shoot the issue.

-

-

There are 3 potential things we have seen that can cause lag.

1 - the CPU of the machine is over working and the incoming information is being buffered

2 - An issue with the way your Network is currently configured.

3 - An out of date Video Card Driver.

In our experience this is usually caused be the specs of the machine not meeting minimum requirements or there is some other process running that is using the process power the CPU to a point that Xest cannot perform the needed processes. An up to date Video Card Driver has helps for some.

A good way to test this is to have the Teacher application running on a pc that has not experienced lag while running the application and a Student application running on a pc that has also not experienced lag. Then have the pc that is experiencing the lag run the Student application. From the Teacher app, bring the student screen that is not lagging to you and send to all. If one pc receiving that student is slower than the other (lagging) then that is the pc and not the network as multicast would not cause that issue. If more than one of the PC's are experiencing lag, then the network is the likely cause of the problem.

-

-

The share my screen, shares it to all computers. The Bring it to me allows me to share another screen onto mine and allows me to share between other students. But I cannot see how to share the teacher screen with only one or two screens?.

This is by design. We are able to do that but this would introduce another few steps for the teacher to follow and increase the complexity of the application. Our success to date has been around the fact that it’s very simple for a teacher to use and adopt with 1 button press to share and 2 presses to bring a student.

-

-

Real-time Transport Protocol (RTP)

RTP (version 2) is a real-time transport protocol that provides end-to-end delivery services to support applications transmitting real-time data, e.g., interactive audio and video, over unicast and multicast network services. RTP is defined in IETF RFC 1889, along with a profile for carrying audio and video over RTP in RFC 1890. Both are IETF Proposed Standards, and are expected to be finalized in early 1997. RTP is used on the MBONE by vat, the video/audio tool. In addition commercial implementations of RTP and applications that use RTP are currently available for a number of platforms.

RTP services include payload type identification, sequence numbering, and time stamping. Delivery is monitored by means of a closely integrated control protocol called RTCP (see next section).

RTP provides end-to-end delivery services, but it does not provide all of the functionality that is typically provided by a transport protocol. In fact, RTP typically runs on top of UDP to utilize its multiplexing and checksum services. Other transport protocols besides UDP can carry RTP as well.

The RTP header provides the timing information necessary to synchronize and display audio and video data and to determine whether packets have been lost or have arrived out of order. In addition, the header specifies the payload type, thus allowing multiple data and compression types. RTP is tailored to a specific application via auxiliary profile and payload format specifications. As an example, a payload format might specify what type of audio or video encoding is carried in the RTP packet. Encoded data can be compressed before delivery.

To set up an RTP session, the application defines a particular pair of destination transport addresses (one network address plus a pair of ports for RTP and RTCP). In a multimedia session, each medium is carried in a separate RTP session, with its own RTCP packets reporting the reception quality for that session. For example, audio and video would travel on separate RTP sessions, enabling a recipient to select whether or not to receive a particular medium.

An audio-conferencing scenario presented in RFC 1889 illustrates the use of RTP. Suppose each participant sends audio data in segments of 20 ms duration. Each segment of audio data is preceded by an RTP header, and then the resulting RTP message is placed in a UDP packet. The RTP header indicates the type of audio encoding that is used, e.g., PCM. Users can opt to change the encoding during a conference in reaction to network congestion or, for example, to accommodate low-bandwidth requirements of a new conference participant. Timing information and a sequence number in the RTP header are used by the receivers to reconstruct the timing produced by the source, so that in this example, audio segments are contiguously played out at the receiver every 20 ms.

RTP does not provide any mechanisms to ensure timely delivery or provide quality-of-service guarantees. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the underlying network is reliable. Some adaptive applications do not require such guarantees, but for those that do, RTP must be accompanied by other mechanisms to support resource reservation and to provide reliable service.

Real-time Control Protocol (RTCP)

RTCP is the control protocol that works in conjunction with RTP. RTCP control packets are periodically transmitted by each participant in an RTP session to all other participants. Feedback of information to the application can be used to control performance and for diagnostic purposes.

RTCP performs the following four functions.

1) Provide information to application:

The primary function is to provide information to an application regarding the quality of data distribution. Experiments with IP multicasting have established the importance of user feedback from RTCP to diagnose distribution faults. Each RTCP packet contains sender and/or receiver reports that report statistics useful to the application. These statistics include number of packets sent, number of packets lost, interarrival jitter, etc. This reception quality feedback will be useful for the sender, receivers, and third-party monitors. For example, the sender may modify its transmissions based on the feedback; receivers can determine whether problems are local, regional or global; network managers may use information in the RTCP packets to evaluate the performance of their networks for multicast distribution

2) Identify RTP source:

RTCP carries a transport-level identifier for an RTP source, called the canonical name (CNAME). This CNAME is used to keep track of the participants in an RTP session. Receivers use the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, e.g., to synchronize audio and video.

3) Control RTCP transmission interval:

To prevent control traffic from overwhelming network resources and to allow RTP to scale up to a large number of session participants, control traffic is limited to at most 5 percent of the overall session traffic. This limit is enforced by adjusting the rate at which RTCP packets are transmitted as a function of the number of participants. Since each participant sends control packets to everyone else, each can keep track of the total number of participants and use this number to calculate the rate at which to send RTCP packets.

4) Convey minimal session control information:

As an optional function, RTCP can be used as a convenient method for conveying a minimal amount of information to all session participants. For example, RTCP might carry a personal name to identify a participant on the user's display. This function might be useful in loosely controlled sessions where participants informally enter and leave the session.

Reference: https://www.csie.ntu.edu.tw/~course/u1580/Download/Multicast/highprot.html

-

-

Xest works with the Computer Names in the XestConfigs.db file found in the Configs folder along with the executable file.

If you are using the Demo version, please email support with the correct Computer Name for us to update or add to the XestConfigs.db file.

If you are using the Full version, you can update or add the Computer Name to your XestConfigs.db file via the Xest Configuration Manager.

Another tip: It could be a spelling error or perhaps a text case difference. If you are still receiving this error, please email support so we can sort this out.

-