Interferences with '#' key usage and PBX call transfer command

#1

Hi,

in our virtual PBX, to transfer a call, we need to dial:
#1234# (where ‘1234’ is the destination extension number).

Trouble is: when using the remote PIN to open door, the PBX will go into transfer mode after dialing ‘#’ (this behavior cannot be changed on the PBX side, unfortunately).
Sometimes the door opens, sometimes it does not…and sometimes the GDS becomes unresponsive, unable to hangup or even reboot (through the web interface), so now we have guests waiting in front of a blocked door: not great.

Is there any solution/workaround for this problem ?

#2

Your hardware set up is not present, nor is your network configuration so for any of us here as customers of grandstream is very difficult to guess your set up to assist you.
Id suggest to go direct to Grandstream support - helpdesk.grandstream.com

#3

image
in your pin do not put a # and you do not have to confirm the code if you put 0 seconds, the door opens instantly, I simply put 0 as pin.

#4

you can solve this problem only on the PBX Server side, or you can try playing on dial plans,
GDS side is it not possible to change #?

#5

The GDS does not need the # to operate, you enter the pin, if you set Door Delay before Unlock to 0 seconds, the relay works instantly at the end of the pin, I put a 1 digit pin, the door opener is protected by white list.

#6

Thanks for an interesting tip !
I just did a test (my “Delay before Unlocks” was already set to 0), and it doesn’t seem to work with my 4 digit remote PIN.

Which device / firmware are you using ?IMG_20230926_091440

#7

1.0.11.23, but it always worked for me, even with previous versions, is the test station in the white list?

#8

The # is embedded into the system to transmit the digits inputted as entered.

#9

Did some more testing, and it works indeed as you say!

I just needed to wait about 4 seconds, not sure which setting this depends on (tried changing “No key input timeout(s)” without success).

Thanks again for a nice workaround!

#10

If you cannot use “#” to tell this is end of keypad input (like enter in computer, GDS is an embedded minicomputer), then you have to configure “No Key Input Timeout(s)” so the system can send PIN out once it think there is no more key input. The default value is 4 seconds. You can reduce it to 2 seconds or even 1 second, but the timer setting too short will have risk that if someone input the PIN digits too slow and over the configured timer (say one slower input four digits PIN but after input 2 forgot the 3rd digit and start thinking, then over the time configured say 1 second, then 2 digits PIN will send out automatically which is wrong and door will not open). You can test and try in your real environment to decide how many seconds is best (instead of default 4 seconds).

Hope this helps. Thank you for using Grandstream Access Control Products.

#11

If you set ‘‘Delay before Unlock’’ to 0 seconds, the relay is activated upon receipt of the code, so for you it takes 4 seconds for the code to be received by the GDS. You need to find out why this code is received by the GDS after this delay
I think it’s in the configuration of the phones that you have to look for, you certainly have a ‘‘no key input timer’’ in the phones, or you have to look for how to send one or more DTMF once you are in communication with the GDS.
‘‘No Key Input Timer’’ is a parameter that you must use for dialing numbers or codes from the GDS keyboard, it replaces the # which is for short ‘‘send’’ but I believe that the # dialed on the GDS keypad will not interfere with your system because the GDS does “in bloc” dialing, it takes the line once it has confirmation that you have dialed a number, it’s either if you dialed #, either after the ‘‘no key input timer’’.

#12

Indeed, “No Key Input Timeout(s)” is only relevant when directly using the keypad of the GDS3710.

I have tried with Linphone, a hardware IP phone and over my mobile line (PBX’s sip trunk): always the same delay (actually closer to 5 seconds) So the delay probably comes from the PBX. That’s another issue that I will investigate, but worse case scenario I will accept the 5 sec delay.

#13

Therefore, you are describing a dialing table misconfiguration or it is non existent.

I would suggest you have a look at that to match all of the digits dialed to ensure immediate sending of the digits.