Our Knowledge Base has changed location, the new website is https://knowledge.star2star.com

Community

StarScope 2 does not display the correct line status i.e. Stuck conference room calls, someone on the phone when they are not etc.

Possible Cause I
Excessive Latency, Packet Loss, or Congestion (Jitter) on Data Network
Because Line state updates from the server to the client get sent by using UDP packets, excessive latency, packet Loss, or congestion on data network may prevent the client PC from receiving them.
The User Datagram Protocol (UDP) is suitable for purposes where error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the
network interface level. Time-sensitive applications, such a StarScope 2, use UDP because dropping packets is preferable to waiting for delayed packets, which is not an option in a real-time system.

Corrective Action I
If you are utilizing a laptop and 'wireless' connection, move to a traditional 'hard-wire' connection and determine if the problem persists.
Check your network cables and ensure they are securely patched in. Run a ping test to check for latency, packet loss or jitter. The following
web site offers an easy Web-GUI interface to perform this: http://www.pingtest.net/   After running the test you will receive the results, if your
test passed with an acceptable grade, close/reopen the Sta2Star Application Framework (StarScope 2), and determine if the correct line status is
displayed with no stuck calls. If the line status is still not updating or there are stuck calls move to the next section.

Possible Cause II
If a NAT device or a firewall separates the client and server, the client most likely does not receive line state updates from the server.

Corrective Action II
I. Windows Firewall Exception
Step 1 Choose Start > Settings > Control Panel > Windows Firewall.
Step 2 Choose the Allow a program through Windows Firewall link
Step 3 Click the Allow another program button > The Allow a program dialog box displays.
Step 4 Click Browse. Navigate to C:\Program Files\Star2Star\Star2Star.exe file and click Open.
Step 5 To Allow an Existing Exception
        a) On the left side, check the program exception Name box to allow through Windows Firewall.
        b) If you allowed the program exception, then check (allow) the box for each Private or Public
        network location you want the program to have access to through Windows Firewall.

After adding the Windows Firewall Exception close/reopen the Sta2Star Application Framework (StarScope 2), and determine if the correct
line status is displayed with no stuck calls. If the line status is still not updating or there are stuck calls move to the next section.

Possible Cause III
Applicable ONLY for locations utilizing the  the StarBox Redundant Failover Interface (Dual WAN).
Line state updates from the server to the client get sent by using UDP packets via a proxy connection to the server.
When the primary circuit goes down and the secondary interface engages, the 'firstcontact' proxy also connects automatically.
If the secondary WAN interface is NAT'd  the client most likely does not receive line state updates from the server. * refer to
Possible Cause II.

Corrective Action III
If your running data 'behind' the StarBox (LAN2 populated) as recommended, to take advantage of the StarBox QOS, please determine
which WAN connection is being utilized by navigating to  http://www.whatsmyip.org/ which will return your public IP address.  The secondary WAN
interface may be NAT'd however, the address assigned to the StarBox must be DMZ'd (all ports available) for the Sta2Star Application Framework
(StarScope 2), to send/receive line state updates to/from the server. Please work with your IT staff and Star2Star Reseller if further assistance is required.

Possible Cause IV
Applicable ONLY for locations utilizing the  the StarBox Redundant Failover Interface (Dual WAN).
The primary WAN connection is 'flapping' up/down, causing the StarBox to switch back/forth between the primary/secondary WAN interfaces.
When the primary circuit goes down and the secondary interface engages, the 'firstcontact' proxy also connects automatically. If the circuit is
'flapping' up/down, causing the StarBox to switch back/forth between the primary/secondary WAN interfaces, multiple 'firstcontact' proxy connections
are established, and the server does not know which IP address to send/receive line state updates to/from.

Corrective Action IV
If your running data 'behind' the StarBox (LAN2 populated), as recommended, to take advantage of the Starbox QOS, please determine
which WAN connection is being utilized by navigating to  http://www.whatsmyip.org/ which will return your public IP address. If the primary
WAN connection is 'flapping' up/down, please pull the patch cable from LAN1 of the Starbox forcing it to utilize the secondary WAN connection
until repairs have been completed by your primary ISP. Please work with your IT staff and Star2Star Reseller if further assistance is required.

Possible Cause V
There is an actual "stuck" call on the StarBox, which is being displayed in the the Sta2Star Application Framework (StarScope 2).

Corrective Action V
Submit a request for support, and advise that you have already performed the previous troubleshooting steps.
A Star2Star Technical Support Representative will be able to assist you further.

0 Comments

Article is closed for comments.
Powered by Zendesk