Bridged Appearance Behaviour, internal vs external call via embedded A

[Greybeard191]

Scenario:

IPO 500V2 6.0.18 1416 phones firmware version 4.00
4 line analog overline group, call go to AA, routed via options 1-3 to three different receptionists. All three receptionists have "can intrude" checked, and 'cannot be intruded" unchecked

Each of these receptionists has bridged appearances for the other two receptionist's 1st two call appearances (3rd call appearance is reserved).

Behaviour:

1) for internal calls (extension --> extension), call alerts on the dialed receptionist's first available call appearance. The associated bridge appearance for that call appearance alerts on the other two receptionist sets (both green and red leds flash), and the call can be answered by pressing that button. Call answered by pressing that bridge appearance "stays" on that bridge appearance (the receptionist who pressed the bridge appearance does not see the call on their call appearances, but on the bridge appearance button that they pressed.

2) For external calls, things are rather different. And behaviour also changes based on whether the autoattendent is using a blind or normal transfer to send the call to the appropriate extension.

Calls comes in, is routed to desired receptionist, appears on first available call appearance. Call also alerts on the associated bridge appearance on other two receptionist phones, but in the following manner:

A) if call was routed via a blind transfer from AA, bridge appearance has only a flashing green led. Bridge appearance cannot be pressed (beeps). Call also alerts on the first available call appearance on the phones on the two receptionists and this call appearance must be pressed to pick up the call. The incoming caller hears ringing while waiting for either the desired receptionist or the bridge recpetionists to pickup (post-autoattedant).

B) if call was routed via a normal transfer from AA, bridge appearance has a flashing red and green led (bridge appearance looks just like an internal extension to extension call). Bridge appearance can be pressed, but when you press it, the call immediately transfers to the first availabel call appearance on that phone. The incoming caller hears MOH while waiting for either the desired receptionist or the bridge recpetionists to pickup (post-autoattedant).

I suspect that this has to do with the fact that the embedded AA is doing transfers, not dials, although from the documentation a "blind transfer. Neither I, or the customer, like the behaviour being 'different' depending on whether the call is internal or external.

Is there to make the external calls behave like interal calls on these bridge appearances?

Not in front of IP Office right now, would transfering to a phantom user who is forward unconditional to a SC with a dial "receptionist extension" create the appropriate bridge appearance behaviour on the other phones?

GB

 

[tlpeter]

What happens when you use coverage appearances ?

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[Greybeard191]

There is a phone which also has coverage appearances for these three recptionists, and it works fine:

Call alerts on desired receptionist, and brdige appearances for other two receptionists. After 15 seconds, coverage appearance for desired receptionist alerts (red and green leds), and call can be answered by pressing that coverage button, and call stays on that button.

GB

 

[Greybeard191]

and FWIW, I actually thought about using coverage appearances rather than bridge appearances, but IPO only allows a single coverage appearance for a given user (UserA can only have a single coverage appearance of ReceptionB), so there's no way to cover multiple calls coming in using coverage appearances (if a second call comes in to RecpB while userA is answering the first call, the second call doesn't alert or appear on UserB's set).

GB

 

[tlpeter]

Why don't you use a group?
Much easier in my eyes.

Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[Greybeard191]

So will a blind or normal transfer from a AA ringing a hunt group act any different?

In this scenario, the embedded AA is a requirement of the customer.

Or are you talking about a pickup group?

GB

 

[Greybeard191]

I looked at using call pickup, call pickup member or group, or directed call pickup... you can have multiples of these, but the problem is that they don't give options for alerting, which is also a requirement of the customer.

Ultimately, if there's not fix, I'll leave it as bridged appearances and normal transfer, as this is the closest behaviour I can get to what I want.

But I don't get why it works differently, internal vs. external.

GB

 

[amriddle01]

You are using bridged appearences where groups are the best solution so it isn't necessary, put them in groups that either alerts all at once or steps around or overflows from one to the others and/or you can even give them a group button or pick up mambers button to achieve what you want. These will all work better than bridging keys

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[tlpeter]

mean a normal group.
Put the receptonist in it and make another group for the other two users.
Put this second group in the overflow.
If needed then you can add the receptionist in the second group too.
No need for bridge appearances.


Homo sapiens non urinat in ventum

honey, i fried the IP Office !!!

Sarcasm, it's only one of the services I offer.

 

[Greybeard191]

hmmm... I dunno. This gets complicated, at least in my mind. I don't know that HG fucntionality gives what the customer wants, exactly.

I've got a AA directing calls to three separate receptionists, via three different options. The recptionists cover for each other (via bridge appearances). A 4th person covers for all three via coverage appearances.

So HG1 (recA) overflows to HG2 (recb, recC)

HG3 (recB) overflows to HG4 (reca, recC)

HG5 (recC) overflows to HG6 (recA, recB)

and HG2, 4, and 6 overflow to HG7 (4th user)?

Like that? Hopefully the displays on the 1416's (receptionists) and 1408 (4th person) show enough info so they can answer the call correctly. Bridged appearances do, via the button at least.

The customer also doesn't want the phones to ring on the first overflow (easy to do with the bridged appearances), yet ring on the second overflow (again easy to do with coverage appearances).

Bridged appearances gives the customer EXACTLY what they want, they just act different with depending on whether it's internal or external call.

 

[amriddle01]

You can give them a group button that will indicate a call queueing on the first overflow group so it doesn't ring but they can pickup from it and then have it ring as normal on the second overflow

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[amriddle01]

In fact the group button can be used to display and answer calls on the first group, no need for waiting fot it to overflow

ACSS (SME)
APSS (SME)

http://www.ipoffice.tel

"I'm just off to Hartlepool to buy some exploding trousers

 

[mattKnight]

What happens if you direct an external call to the receptionist phone without using the AA?



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Greybeard191]

MattKnight:

I just tried this (directing external directly to receptionist).

Bridged appearances in this case work exactly the same as an internal call. The Bridged appearance button alerts (red and green), the call can be answered by pushing that button, and the call stays on that button 9does not move to a call appearance).

Soooo... it's the AA which is mucking things up. I tried making a SC (dial extn tel#=recptionist extension#), creating a phantom user with forward unconditional to the SC, and then changing the AA to do a normal or blind transfer to the phantom user. The effect on the bridge appearances from doing this doesn't change (see first post for differences between blind and normal transfers).... I was half hoping that the SC/dial extn would somehow strip off the effects of the AA, but no go.

GB

 

[Greybeard191]

Update:

This issue (weird bridged appearance behaviour behind an embedded AA) appears to be completely fixed by upgrading to 6.1.5. In tech bulletin 127 (6.1.5 release) it makes references to "CQ40507 Bridged Appearance Button does not work correctly", and I guess this might have been it.

Anyway, there is a way to fix this... upgrade.

GB