Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Incoming Call Bar not working SE 10.0.0.3 1

Status
Not open for further replies.

scudworth

Technical User
Oct 19, 2012
37
CA
I have a Server Edition with 9608's registered to it. I have an extension setup that has the Incoming Call Bar setting ticked under Telephony > Supervisor settings. When I call in to the AA from outside and dial the extension, the call comes through to the extension. It looks like either the Incoming call bar isn't being applied, or something is overriding it. Anyone have any ideas? Thanks!
 
What type of action in the Voicemail Pro callflow is doing the transfer?

Stuck in a never ending cycle of file copying.
 
Under Telephony Actions > Transfer, and it's going to $KEY.

I just tried with a DID and it looks like it's being blocked when going directly to the phone, and not from voicemail. So does it treat a transfer from voicemail as an internal call?
 
If this is by design, you're going to have to parse out the blocked extension(s) and target a disconnect rather than a transfer, in the VM Pro.

That could be painful, LOL.

and of course, because this is Avaya, even if it is a bug, it will be "by design".

GB
 
Looks like it (which I would say is a bug).

You could add a workaround to the AA by saving $KEY as a $CP value using a Generic action*, testing the value of that $CP using a Test Variable action to see if it matches the user, send matching calls back to the AA via some "That number is not valid" announcement, and non-matching calls to the Transfer action which will now need to use $CP.

And having said all that if its just one user you may be able to just put there number in the Menu action directly and send matches round the loop that way but would need to see the full autoattendant and know the pattern of extension numbers you might want this for.

[*The need to save $KEY as a $CP value is because a Test Variable action behaves very differently if you use it to test the value of $KEY directly - basically it waits to collect a new set of dialing digits from the caller]

Stuck in a never ending cycle of file copying.
 
The problem with doing anything like you mentioned sizbut, is that the incoming call bar will vary. This is for a hospital that will turn it on/off depending if the person has paid for phone use. So the staff will just toggle with barring, I don't want them to have to do extensive modifications in Voicemail Pro.

On their old CS1K, they had a button they would press to disable or enable a phone. Is there something like that I could do that wouldn't use call baring?
 
again, assuming this is for just one phone? And making a stab of a guess at the control of this would be on some OTHER phone.

Use a VM pro module (Module A) to test the Status of a control HG (generic action, generic command, change user or group config, operation = get, parameter = service mode ->(0,1 or 2) and a variable routing test to test for 0, 1 2). Put control to set this HG into OOS. FWIW, 0 = OOS, 1 = in service, 2 = night service, for the control HG.

Make a VM pro module for the DID/DDI (Module B)... start point to the module A above (test HG status)... In service (1) goes to a transfer to the phone, OOS (0) goes to a message saying the phone is OOS, then disconnect. In the incoming call route, route to VM:Module B

on the AA, create a unique entry on the menu for this one extension, tie to Module B.

Whatever phone (nursing station?) has the set control HG to OOS button on it will control the incoming call bar.

GB
 
I guess the hunt group solution - even if it is a good solution - will be a problem caused by the maximum number of hunt groups in the system.

If you have to use an AA I would set DND or a call back number (like it is often done for meet me conferencing. Then you could check the value of the user against the $KEY variable for the target user.

That way the user can be called internally but not through AA and you can have another module to get and to set the status.
 
Is the VM doing a Blind to assisted transfer?

An assisted transfer would probably look like an internal call & so would not get blocked
A blind transfer should be seen as an external call (if not then this is a bug).


Do things on the cheap & it will cost you dear
 
Probably still want internal calls to work. Could use the exception list though I guess.

APSS/ACIS/ACSS-SME
not arrogant, just succinct.
 
in general I find this a strange request anyway

1) Hospitals near me would physically remote the bedside phone if the patient was not paying for it.
2) I don't see the problem with inbound calls anyway , after all the do not cost the Hospital anything (however having seen the size of the markup Hospitals generally put on their calls I would not be surprised @ then charging for inbound as well)

I would also suggest investigating some of the Hotel/Motel packages that are available as they seem to be able to perform this functionality as req (I know that Tiger actually makes programming changes to the IPO as required for this type of functionality, it makes the Audit trail almost useless :-( )



Do things on the cheap & it will cost you dear
 
Physically removing the phone is what I suggested as well, but since they had the ability to enable/disable the phones from their main reception console on the CS1k, they want that on the IPO as well.

The transfer is just a regular transfer action in VMPro. I tried the other one to route by Internal/External and it routes based on External correctly, but still doesn't follow the incoming call bar.

I could turn on the DND and just allow reception calls to come through, but they seem happy with Outgoing bar working, since that's more important.
 
Going out on a limb here.
You could use the same control that the conference bridge from Kyle H. uses.
The source number callback entry P1234 for example.

Then you could make a setup for reception to dial into the VM and change it and all transfers look at that and only transfer if the number matches and if not they send calls to reception instead (or better disconnect immediately)

every time a room clears out they change the callback entry to anything but 1234 and transferring is not possible any more and ass soon as the room gets occupied again they change it back.

To make it easy create 2 shortcodes
1. they dial the shortcode enter the extension - in the voicemail it will take that information and sets the P1234
2. they dial the other shortcode enter the extension - the voicemail sets the information to P4321

that would however not check the outgoing calls :)
except if you send their outgoing calls through the voicemail and check if the entry is P1234 and then allow the calls to go through.

Lots of heavy lifting until it is set up but then you are good to go and have a happy customer.



Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter
 
Westi, could this be done dynamically for the user extensions so there's only an "Enable" module and "Disable" module, or would you have to do both for each extension you'd want to modify?
 
Yes
basically use what is dialed as extension information

Shortcode
*22
Voicemail Collect
TurnOff

in the VM module called TurnOff you will then simply ask for the extension number (maybe password protected) and that is all the information the voicemail needs and the call flow will then change the P entry in the source numbers.

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top