Two Phones Ring Simultaneously

[optionsleft]

We have hotel client with each room having 1 IP(9620) and 1 analog extension, and total of 500 IP & analog (1xxx - IP, 2xxx - analog). Is there a way for these two extensions to ring simultaneously when incoming call is received? With IP the analog can be bridged into it but with analog cannot do that. Terminating-extension group is also not possible since there are only 32 groups available in the system.

Any workaround on this?

Running CM 4.0.1.

Many thanks,

 

[Ronster]

Why not always send calls to the analog extension?
Hide the IP extension from the directory by putting a non-display character at the start of the name field.


Ronster
"I always arrive late at the office, but I make up for it by leaving early."

 

[optionsleft]

Thanks for the reply but what I am looking at is that any incoming call on either IP or analog extension it should ring to both simultaneously.

Thanks,

 

[Ronster]

Yes OL,

I understand that you always want both phones to ring. I repeat, why can you not have all the calls always go to the analog phones and have the IP phones ring too on their bridged appearances.

There would never be a need to dial the other number. Do not even tell people what the IP extension numbers are.

Ronster
"I always arrive late at the office, but I make up for it by leaving early."

 

[Ronster]

Or... put a call-fwd on the IP phones to send the calls to the analog extension which will then also ring at the IP bridged appearance.

Ronster
"I always arrive late at the office, but I make up for it by leaving early."

 

[matthartt]

This would really use up a lot of ext's but could you make a bunch of "X" port stations with each ext on it. If you called it wouldn't it call both?

 

[ClovistheCat]

how about a cover path with a cover answer group so both both extensions will ring?

 

[optionsleft]

Coverage answer-group is up to 200 groups only. I'm just doing some workarounds together with your tips. Still trying to find the best one.

 

[Mitch672]

Ronsters method IS the best method for this, there is no waste, and you will absolutley need 2 RTU per hotel room to do this.

mitch

AVAYA Certified Specialist

 

[optionsleft]

Yeah I agree.

Thanks a lot guys.

 

[Ronster]

"medal, medal, medal!"

Ronster
"I always arrive late at the office, but I make up for it by leaving early."

 

[dialtonebone]

Agreed -- I would go with Ronsters first option.

Bridge the rooms primary extension to one phone, and make the other phone the primary extension. 2 RTU's gone, but that is just how it is.

Just curious, why does this hotel have two phones of different types in each room? Not trying to sound like a poop, but simply out of curiosity.

 

[optionsleft]

Hotel suites have up to 5 phone locations - bedside, hall, bathroom, reception, etc..Having 1 analog ext. port for all the locations will work but in the long run and based on experience the PBX analog card get damaged. That's why they came up with this solution although i was not involved in the design process i just have to implement the project.

What I did and agreed upon by the hotel management is that analog ext. is bridged to IP, there is no additional call-appr on the IP phone since they wanted to send only one calling number per guest room.

It might not be a good solution because RTU's were doubled at the same time IP extensions & sets were not being maximize. But we need to satisfy the customer that's why we are here.


Cheers! Thanks to all

 

[dialtonebone]

Of course, I just wanted to see the reasoning/history.

I would definitely do this:

Lets pretend room numbers are 200 to 500.

The extensions are 7200 to 7500. This means 7+Room number

Analog lines should be used for the rooms existing wiring. This will be the primary line. Room 200 will be using ext 7200 for the whole rooms wiring.
Create an extension for the IP phone, of 8200. I only saying this simply for ease of use. Take all the call appearances off this phone, and do a "abrdg-appr" or Analog Bridge of 7200 onto this phone.

Tuh-duh. Someone else may have already covered this.