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.
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. 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. -----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/
