Using callback to open gate?

[Alistair.Campbell]

Quadro 4x:
I'd like to configure callback so a 'free' 2-ring call from an authorised phone will then call 'back' to an FXS but with a DTMF string once the gate panel answers to operate the gate relay.

The only way to insert DTMF (AFAICS) is to use the second-stage call feature in call routing, but if callback is sent to such a configured virtual extension, it doesn't progress, I guess because callback is waiting for DTMF <from> the FXS...

Anyone have any workarounds?

Thanks,
Alistair

[davrays]

You are giving interesting questions, Alistair, this one made me think a little bit . Thats a nice way to use callback

When you are using the callback capability of authorised phones database, the system call to the destination you specified (PBX phone in this case), and plays the messages of the Autoattendant, which you called to.

So I would try to do this the following way:

1. Create a special AA (as probably you would not like to change the message of your main AA). Let is be attendant extension 10.
2. Record a WAV file containing the digits used to open the door (i.e. WAV file containing the "123" DTMF digit sequence). You can record that as a voicemail or reminder in your voicemailbox, then download to PC. Call it dooropener.wav.
3. Modify the "Welcome Message" or "Recurring Attendant Prompt" (whetever you like) of attendant 10 - upload the newly recorded dooropener.wav.
4. Modify the settings as needed so your people will call to that attendant 10 to open the door. One of the ways would be for them to call regular AA, then dial 10, the same way as they do when calling an extension. Other, maybe better way, is to route the incoming calls to an extension, which will forward them either to regular AA or to AA 10, based on the Caller ID.

Thats it - as soon as your authorized people will call to AA 10 and hangup, the AA will call to FXS phone (as you configured that in "Authorized Phone database"), and play the digits 1+2+3. The door will open...

Best regards,
David

[davrays]

Thinking more about this - forget about my previous post

There is much easier way to do that - using the two-stage dialing on FXS (as you mentioned). This should work without problems... You need to callback to "Auto->OpenTheDoor", add have the rule like "pattern=OpenTheDoor, NDS=11, prefix=<door extension>,,,<digits to open the door>", inbound filter=PBX".

This should do the trick - if you call to any AA, then hangup, the system will call to FXS extension and inject digits.

****************************************

UPDATE after some testing: Just make sure the "Login Extension" in the Authorized phones database is not the same extension you are calling to open the door!!!

[KSComs]

http://www.2n.cz/products/door-lift-...unication.html

Actually this is a better solution to be honest....




Kev

[Alistair.Campbell]

Thanks, davrays.
There is a complication with callback - am using a incoming SIP trunk to provide the 'secret' number for gate opening purposes. However, the callback function only seems to work on incoming PSTN calls.

Is there any way to enable callback for SIP calls?

Thanks.

[davrays]

Yep, sure you can enable callbaack for the SIP calls starting from 5.1.x software.

If you have older version, you'll need to upgrade to the latest 5.1.x...

[Alistair.Campbell]

Thanks, David,

However, there is not specifically a setting equivalent to the 'Route incoming FXO Call to' for FXO incoming calls, so I use the 'Caller ID based services' and unconditionally forward to the AA, which it seems to work, but the AA then instantly answers the call - not really allowing any time for the caller to hang up - in fact it's not clear if the unconditionally route rule actually answers the incoming call before forwarding it - it happens so quickly.

So, ideally, the unconditionally forwarding rule should not answer the incoming call (maybe this happens, but I haven't been able to verify it) and then the AA could (a) ideally hang up the incoming call itself or either (b) not answer at all or (c) at least not for 10-15 seconds or so. Then, ideally, at that time the AA could place the 'callback' so that someone driving up to the gate can see that it's operated and can safely hang up while the AA is still ringing if the auto hangup is really not possible.

Really, for auto callback, the autohangup IS a desireable feature in any case as it prevents a user from accidentally activating the AA IVR.

Apologies for barking on about this slightly unorthodox usage here - but ppl I have set up with this remote opening from their mobiles are still getting potentially getting hit with a mobile call charge because the delay is so short - any workarounds?

Thanks, Alistair

[Alistair.Campbell]

Thanks, David,

However, there is not specifically a SIP setting equivalent to the 'Route incoming FXO Call to' (for FXO incoming calls), so I use the 'Caller ID based services' and unconditionally forward to the AA, which it seems to work, but the AA then instantly answers the call - not really allowing any time for the caller to hang up - in fact it's not clear if the unconditionally route rule actually answers the incoming call before forwarding it - it happens so quickly.

So, ideally, the unconditionally forwarding rule should not answer the incoming call (maybe this happens, but I haven't been able to verify it) and then the AA could (a) ideally hang up the incoming call itself or either (b) not answer at all or (c) at least not for 10-15 seconds or so. Also, ideally, at that time the AA could place the 'callback' so that someone driving up to the gate can see that it's operated and can safely hang up while the AA is still ringing if the auto hangup is really not possible.

But then, for auto callback, the autohangup IS a desireable feature in any case as it prevents a user from accidentally activating the AA IVR when they are calling to get the callback.

Apologies for barking on about this slightly unorthodox usage here - but ppl I have set up with this remote opening from their mobiles are still getting potentially getting hit with a mobile call charge because the delay is so short - any workarounds?

Thanks, Alistair

[Alistair.Campbell]

Apologies for double post. the later one has a few corrections...

[davrays]

Hi Alistair

I am testing this scenario (with call coming from SIP to some virtual extension, being forwarded to the 00, with SIP caller added to the "Authorized Phones Database"), and it works perfectly. It waits at least about 15 seconds before activating the AA, and if I hangup before that, calls back to some FXS extension, injects digits.
So the option (c) is working correctly.

Now, to understand whay it is not working on your device, I would need to look at the logs. You can send me a PM, so I'll give you the mail address to send the logs. You would need to enable developer logging, then make incoming call to your AA, see the erroneous behaviour, then download the logs and send them to me.

What refers to the autohangup, it is actually possible to implement that, but we don't do that intentionally, as we want to leave callers a possibility to connect to AA, if they want that by some reason, even if they activated callback in "Authorized Phones Database". Of course, we could add an option in the "Authorized Phones Database" GUI, which will allow to hangup automatically, and lose the capability to connect to AA... If you think it is important, you can try to push Epygi through your distrubutor
I can add this feature to out tasks list too, but it will have really low priority, unless you can increase that through your disti

Best regards,
David