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/
