my 1 cent, I think if the IVR had a way to allow you to program forwarding numbers via a script and allow the user to change the forwarding location via the script:
Location: Mobile Location: Tampa Office Location: Home and the number could be stored via dtmf, then in user options you can turn on forwarding (or off), and set "1 for - "(in your voice) Mobile", etc. at the same time, i think a smartphone app would be much more widely used... but that's how I see the user pattern going. maybe the smartphone app has an xmpp command capability built in too... like a little forward my calls wizard... On Thu, Sep 22, 2011 at 6:02 PM, Niek Vlessert <[email protected]>wrote: > On Thu, Sep 22, 2011 at 11:46 PM, Todd Hodgen <[email protected]> > wrote: > > Personally, I find that the call forwarding is pretty robust compared to > > many systems out there. And creativity goes a long way. For example, > if > > you assign two extensions to one phone, one for internal, and one for > their > > external DID, you will have routing for internal calls via forwarding, > and > > routing for external calls via forwarding, just as one small example. > > > > Thank you for this tip, didn't know that, will look into it. What is > you opinion about the pattern idea? > > > If curious what is being developed, you want to log into the dev area of > > Sipfoundry. There are a lot of initiatives proposed, I would recommend > > looking there first to see what discussions have already gone on. Look > > under developers/Issues Tracker. > > > > I know about the tracker, I my post I mentioned my own ticket from > that area.. Lots of tickets about call forwards are retired and also a > lot are bugfixes. Bugfixes are VERY important, but I'm talking about > features here. > > > You are referencing Spark, and I believe a few people use Spark, but if I > > recall correctly, the xmpp use has been designed around and tested with > > Pidgin. You might want to try it and see if you get different results. > > > I was mentioning Spark as an example because I know the colors there. > I guess it doesn't make much of a difference which XMPP client I'm > using. The thing is that when a user doesn't have an XMPP client the > hardphone status from that user is not visible to other XMPP users. I > guess this is not a bug, but something which is not implemented. > That's why I suggested to give people online with a hardphone and > offline with XMPP some new XMPP status. > > Regards, > > Niek > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Niek Vlessert > > Sent: Thursday, September 22, 2011 2:34 PM > > To: sipXecs developer discussions > > Subject: [sipx-dev] Call Forwarding & User States > > > > Hello, > > > > I would like to start a new development discussion about call forwarding > & > > states a user can be in. > > > > Call forwarding in SipX IMHO is limited. It's better than Lync, but worse > > then a Siemens PBX costing 500 box. A philosophy would be that the user > is > > responsible for his/her own reachability, but I don't think that's always > an > > answer. > > > > I probably don't know all the ins and outs of this or if some of these > > things are already being developed, so please tell me if I'm missing > > anything. > > > > Hereby a list of things which could be improved with some directions how > > this might be possible. > > > > - setting Call Forwarding from a phone is not working very well, because > the > > forwarding is done by the phone which causes weird effects. Being able to > > set CFWD by a * code on the phone itself is useful, I wrote a ticket why > & > > about a solution: > > http://track.sipfoundry.org/browse/XX-9863 Another solution would be to > > create a button on a phone which will start a script which will change > the > > forwards through restinterface. But that's more like a workaround and if > > other * codes are available, why not this one? > > - unconditional forward is not possible in the GUI. Ring for 0 seconds > would > > be that. Also in http://track.sipfoundry.org/browse/XX-9863 > > - setting DND is not possible from the phone. Yes you can, but that's a > > phone setting. It would be better to do this in the PBX and also inform > > OpenFire that the user is on DND, which now is not known in OpenFire. > Once > > again, could be done by rest, but through an invite would be nicer. :) > > - Another thing about Openfire; if half the people have a softphone with > > XMPP, and the other half has hardphones, the status of the hardphones is > not > > visible in OpenFire. Why not make a user semi-offline when the user is > > offline with XMPP and online with a hardphone? (red in Spark instead of > > gray), so the hard phone status of the user can also be shared through > XMPP > > - It would be useful to make other routing decisions for external calls > > (from customers) then for internal ones. Company policy can be that a > > customer always gets a person on the phone. So if a customer calls you > and > > you are not there, the call gets routed to reception which can then > answer > > the call. But if your colleague calls and you're not there, the call > should > > just give busy, because it's not useful for the caller to get the > > receptionist in this case. > > - Even better; if reception calls you, it can be useful to make different > > routing decisions. Or if the office manager calls you. Stuff like that. > > - A way to go is to allow patterns per extension and per pattern call > > forwards. I will think about this some more before I will propose > something > > - We're almost finished with the hot desking thing. So we have a bunch of > > states, which a user can be in: regular online, offline/logged out, DND, > > busy. A user calling cannot hear the status, he/she will only hear busy. > So > > a message if a user is logged out and if they're on DND can be useful, > > instead of just the busy sound. > > > > That's it for now, maybe I'll add more things. > > > > Regards, > > > > Niek Vlessert > > Telecats B.V. > > _______________________________________________ > > sipx-dev mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > > _______________________________________________ > > sipx-dev mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.465.6833 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Contract Customers: http://support.myitdepartment.net <http://support.myitdepartment.net>Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices!
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
