GSC3570 Lagging



We have ordered a few GSC3570 last year and we keep hearing complaints from our clients.
Every a few days, the GSC3570 starts lagging and the following have been noticed:

  1. Door ringing is in silent, you cannot hear the incoming call.
  2. In call screen takes about 10s to change the status from ringing to in call.
  3. Door release not reliable.

Rebooting the GSC3570 fixes the problem for another few days.
Currently using the latest firmware .
We have reported this problem 3 months ago “case ID is 20200904132005” and still no update from Grandstream.

The isssue is occuring on 3 systems:
Audio serverless solution: 2 x GSC3570 (Call between the two GSC3570)
Video Serveless solution: 1 x 3rd party video door station calls the two GSC3570 in serverless mode.
Video solution with UCM6202: 1 x 3rd party video door station calls the two GSC3570.

Anyone experiencing similar issues?
@supportteam can we have a fix for this issue ASAP.


Do you have SYSLOG or Coredump available for analyze? How’s your network setup? What 3rd party video door station used?

For the case 1, when that lagging happens, will the IP Peering call (meaning one GSC3570 call another GSC3570 via the Direct IP Call mode) also has same lagging? Just want to identify whether whether the issue is caused by SIP Server (lost registration but record still there), or Network environment, or GSC3570 itself.

If SIP server used, what is the “NAT” setting and “Register Expiration” time? If you reduce the “Registration Expiration” from default 60 min to 1 or 2 minutes, what your will get? Also, poking around the “NAT” setting, use “NO” or “AUTO” or else, what will happen? Is the SIP Server or UCM in the SAME location as the Video Door Bell or GSC3570, or the UCM is remotely located and GSC3570 and Video Door Bell registered as remote SIP extension?

Please help to advise. Seems to me this might be network or NAT related issue.

Thank you for using Grandstream Access Control products.



Please find below the configuration backup and wireshark with device log . We always run the latest firmware.

  • The three systems have the GSC3570 installed on a private network.
    Audio serverless solution: 2 x GSC3570 (Call between the two GSC3570)
    installed on my desk with a flat TPlink switch. IP peering call.

  • Video Serverless solution: 1 x 3rd party video door station calls the two GSC3570 in serverless mode.
    installed on client private network with a flat TPLink switch. IP peering call between Akuvox EV21V door station and the two GSC3570s.

  • Video solution with UCM6202: 1 x 3rd party video door station calls the two GSC3570.
    installed on client network with TPLink switch, switch connected to the UCM LAN port and UCM WAN port to the router. SIP registered call from the Akuvox EV21V door station to the two GSC3570s.
    Registration doesn’t drop. Call received but in silent, video and screen lag. As soon as the GSC3570 is restarted, it works again.

Hope this help.


Have you tried direct IP call from one GSC3570 to another GSC3570? Will the lagging happen in the direct IP call? I seems cannot duplicate the issue.

I also guessing this is setup or network environment related. Here is some suggestion for you to try:

  1. For current network topology, change in the SIP setting “Registration Expiration” from default “60” to “10”, reduce the time window, to avoid “False” registration, basically GSC still shows registration but in UCM side already expired. You can do this to the 3rd party door phone as well.
  2. poking around “NAT Traversal” setting, see which choice better suited your environment (there are quite a few choices).
  3. Leave the UCM LAN port empty and connected that TP-Link switch uplink same as the WAN port of UCM, both to the LAN ports of the router. Reconfigure the topology and see whether helps.

Because you mentioned reboot GSC3570 works again but idle for a while problem happened, this is very likely a hint the network configuration or topology might be the culprit.

Please test around and advise whether this helps. Thanks!



As I mentioned previously, yes my demo on my desk have 2 x GSC3570 only and it does lag too.
What is important to know, it might take 2-4 days or a week to start lagging. Definetely not before 2 days.

I will start playing with the NAT settings but I am using IP call on a flat and standalone switch.



OK, I will try to duplicate that. I have two GSC3570 in my desk also under same PoE switch, and up and running for two days already, will see what happens after another two or three days.

Also, do you have switch from other vendor instead of TP-Link? I don’t have good experience with TP-Link switch therefore always using Netgear or Linksys unmanaged small PoE switch.

Will update you my testing result. Thanks.



Thanks, yes I have a Netgear switch too.
I will try on both and see if there is any difference.



The logs I sent you, can you see anything strange that affects it?
In this picture which I noticed when it fails, it show " LoopRoster registerhandler: 38 failed!!!\n "
What does this mean?

Also please the screenshot in this link where you can see errors and warning which it doesnt when it works fine. hope this helps.


@Grandpart: The " LoopRoster registerhandler: 38 failed!!!\n " is just routine info log (not error) for the AVS running inside. Will ask engineering to take a look of the files you provided. And will also try to duplicate your issue in lab. Once having any news will update you. Thanks.


Hi, we also have a two GSC3570 set up (+ one GDS3710 gate station) as per my earlier posts in another thread. All connected through a small Edimax GS-3005P PoE+ ‘smart managed’ network switch.

I don’t know about lag* but we have several times lost ringing sound for calls from the kitchen unit to the office unit. Re-boot fixes the issue. When person calling from kitchen has had no reply and comes down to the office to see why, I notice that the GDS3710 [Correction: Oops, that should have been GSC3570] is flashing a red light, presumably indicating that the call has come through but without sound so I have been unaware of the call (unit is behind me). *re the lag, No way I would know as the calling unit is remote from my office. Hence do not know if there is a lag between the person calling and the call coming through…

Son has done all the configuration but fairly certain calls between the two GSC3570 units are direct IP dialing [Confirmed: Yes, IP dialling. Also confirmed there is lag]. We do have a separate SIP server on a RPi but that is used sequentially to fwd calls to mobile phones (& I currently no longer use that as I do not like having the sip phone app running all the time on my phone). Did initially try GSwave but that was more problematic, or at least more limited (do not recall the details). Would be great if there was a GS app that did not need to be constantly active to receive calls; eg like email and message apps on a phone.


Hi David,

Thanks for your feedback.
So you are still experiencing the same issue?
Have you tried to replace the TP Link switch?



@GS_Guy Why not getting same log info when it is working fine. So I guess the log info is related to the issue. hope so.


Last time was a week or so ago but it will often go that long or more before the problem re-occurs.

I haven’t tried a different switch as I don’t have another one that is PoE. But I just remembered, the TPLink I was going to get was not available and turned out to be an end of life product so I ended up getting a similarly spec’d Edimax GS-3005P model. It is ~2 months old. Sorry about putting people wrong on that. Have corrected it in my original post.


@David_NZ Have you reported this issue before?
I find it strange that @GS_Guy and Grandstream team never faced this issue when we have been suffering for 4-5 months now on 3 different systems!


I have a similar problem on mine. Connected to a cloud Netsapiens. It just hangs totally and cannot make calls. It just hangs on the spinning calling screen, I have to reboot everytime.

I will try to get syslog and capture but it seems to do that every single time, even after a reboot.


No, sorry hadn’t bothered reporting it. It can be a pain in the butt but so far has only occurred perhaps 4 times in 2 months. Simpler to reboot and forget than undertake a prolonged discussion with GS that may or may not get me anywhere.

Seem to recall that GS are working on updated firmware that will include auto-reboot which hopefully will at least alleviate the issue to some extent. Better of course if the issue can be fixed properly.

It would be interesting to know how far off the firmware update is.

[Made a ‘small’ correction to my original post: it is the GSC3570 unit in the office that is flashing a red light (missed call), not the GDS3710! The latter is outside ~80m away at a gate]


@Grandpart: It is not that GS not facing the issue, it is that we are not able to duplicate this in our labs. The syslog you provided does not help to locate the cause of the issue. There are quite a lot elements could cause this if went wrong: SIP stack, touch UI resource allocation or waking from sleeping or exit from screensaver, RTSP processing, Network NIC energy saving, thread priority, memory redistribution, etc., just name a few.

We can only fix issue if duplicable and can sure locate the root cause, otherwise might fix one and broken another, for an embedded system like this.

That said, next firmware we have implemented user configurable auto-reboot to help avoiding the problem. The firmware is under QA now and will be released once passed QA.

Thank you very much.


@David_NZ: If the GSC3570 configured as serial hunting, then if the first one w/o pick up but answered in 2nd, then first will display “Missing Call” in the “Call histroy” icon and the LED will flash “RED” at back (if turned on) and home button to remind that there are missed calls (because the GSC3570 LCD could turn OFF/BLACK to energy saving mode). If parallel hunting, you pick up at one GSC3570 then another GSC3570 will have a missed call and turn on red LED as reminder (this is for IP call mode). Just press the “Call history” to check then exit the LED reminding will be turned OFF.

Also if configured correctly, the GSC3570 will “Preview” during ringing stage (meaning you can SEE the person at GDS3710 when GSC3570 ringing before you answer the call, you can press the soft button to open door directly w/o answer the call; of course you can pick up call and talk to the gate then open door).

Hope this helps. Thank you for using Grandstream products.


@GS_Guy is there a setting for preview?
You said if it is configured correctly, what is required? does the door station need to support anything special?



Hi. Thanks for the reply.

The problem I was describing (no ringing sound on the GSC3570 in my office) was solely in relation to a GSC3570 (in kitchen) -> GSC3570 (in office) call. That is 1:1 direct IP dialing. If there is no answer that is the end of it - there is no forwarding of the call if it is not picked up in the office. The gate station (GDS3710) is not involved at all.

As far as I know we have never made an office -> kitchen call so I do not know if there are any ringing problems with the kitchen GSC3570.

Note that the GSC3570 -> GSC3570 calling was not the reason for installing the devices (that is more an afterthought when a certain other realised it provided a convenient means of contacting me!). Ironically, it has turned out to be the most common (if not almost only) usage so far - albeit only 2 months since the system was installed.

The primary reason for installing the system was of course to be able to respond to the gate station at either the office GSC3570 or kitchen GSC3570 (if the call from the gate is not answered on the office unit). Dialling from the gate station is sequential - first to the office GSC3570, then to the kitchen GSC3570, then to the sip server on the RPi (which then dials out to mobile phones). Only reason we are using the RPi sip server is because the GDS3710 dial group is limited to 4 numbers and we need more than that (8 would be great but even 6 would suffice … please … :slight_smile:). But as I noted above, all of that has nothing to do with the GSC3570 (in kitchen) -> GSC3570 (in office) call issue.

I do not know if there is a problem with GDS3710 (gate station) -> GSC3570 calls as that has barely been used so far! Just initial testing. So far we have left the gate open when expecting visitors.