A couple things here... To clarify one point... With a hunt group it doesn't strictly go to the VM of the last person in the list. If you uncheck the VM check box you can fwd to any other extension.
OK, so for what Scott is trying to do... if you are trying to reproduce key system functionality I would either use a hunt group or a call routing phantom as Todd suggested. I prefer the phantom because then you can use time of day routing on the phantom to route to an AA at night. If you don't care about key system functionality you can have a single inbound user exist on multiple phones and then on those phones in Lines -> Registrations set the number of line appearances you want and calls per line key (I usually set this to 1 to not confuse receptionists). On this one user you can also control ringing for time of day with call forwarding. Mike On Jan 13, 2012 3:08 AM, "Todd Hodgen" <[email protected]> wrote: > In the hunt group, it will be forwarded to the voicemail of the last > extension. However, you can create a phantom extension, that forwards all > calls to an express route to any voicemail you would like. > > The scenario you have on your current PBX is very workable. Forward > incoming calls to a phantom extension, which forwards to two other > extensions as the same time. Either Operator can answer the call. > > I like the Voice Operator Panel for this. And, they have a method of > deployment using VOP server, so messaging can be passed between the two > consoles, or you can use the integrated xmpp for that. > > Unless you will be passing calls from one reception phone to the other, I > don't see a benefit to shared line appearance. You can put one extenson > on > the phones, have it register several buttons for the line so they multiple > line appearances for the line, on each position. > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Scott Howell > Sent: Thursday, January 12, 2012 10:56 PM > To: [email protected] > Subject: [sipx-users] Understanding Call Handling Option > > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <65428> > Message-ID: <[email protected]> > > > > I have a strong background in telecom on a variety of pbx vendors, but am > having some difficulty in understanding some "basics" with a pure SIP > solution. > > I am looking to replace an existing PBX for a customer with sipX and have > been doing some testing, but here is what I'd like to get my head around. > I > am sure there is something obvious that I am missing, but need some > direction. > > The current scenario is a company with 2 operators. In the current system > we utilize a virtual extension which appears on both phones. Incoming > calls > point to the virtual and both phones ring. Either receptionist can answer > the call and it "snaps" to a "call key". They both have multiple call keys > and can place several calls on hold as new calls arrive and handle them in > any order they see fit. > > So, in sipX the obvious thing that comes to mind is to use ACD as a simple > clean solution. However, I don't think this customer likes the idea of > them > "having" to deal with the call before they get another. > > The other option (Which I believe is the feedback I expect) is to put a > series of shared lines on both phones and put them in a simple hunt group / > and or CF between them. How does this impact VM? ie Lines 250 - 255 > appear > on both phones, calls point to 250, 250 hunts to 255 - If a call hunts to > 253 and CF-NA goes to VM does it go to box 250 or 253? > > Or, is there another way to set this up? > > Thanks for all the help I have received in this forum!! > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
