nope, i just wanted to let the community know that when running the wildfire server and the spark client on the same machine, you will have login problems, now that i’'ve splitted them, all works fine, with the patched asterisk-im and also the 1.2.0 beta,
i wanted to share my experience with the community, even if that may be OT.
talking about asterisk-im 1.2.0 beta, there may be a bug:
as already noted by other testers, if you are using the embedded database, you will not be able to save the asterisk manager info.
using an external database, in my case mysql, works.
so, resuming, i confirm that with 1.2.0 beta:
-
embedded db has problems
-
‘‘on phone’’ status works fine
-
placing a call from contacts works fine
-
placing a call with ‘‘Dial number’’ works fine
-
receiving a call makes ‘‘on phone’’ status change accordingly.
now, i’‘m headbunging on wildfire + asterisk-im + spark, because i didn’'t want to write an asterisk cti from scratch.
what i found in wildfire, after only 2 days, is far more than i could desire, almost 90% of the features i was hunting for.
so here is my wishlist, i’‘m going to accomplish it because i have to do it for job: i’'m payed for it.
of course the results will be licensed under gpl and, i hope, integrated into the main asterisk-im and spark trunk.
of course, any help from the depelopment team, and the authors of asterisk-im and spark will be greatly appreciated!
so here comes the roadmap:
-
clicking on spark, in Spark->Preferences, i think that sould be added an icon on the navigation on the left, something like ‘‘Dialing’’ or ‘‘CTI’’ with the ability to setup some of the features below
-
like ADM ( http://adm.hamnett.org ), when the spark client, connected as an user mapped to a phone, receives a phone call, a popup could be created, containing info about the caller.
-
like ADM, the action of receiving a call, should be optionally mapped to an action, configured in the CTI Preferences described before. the action could be, for example, to open the browser with an url like http://someurl/printCallerIdInfo.php?id=�llerid% . you know, for crm integration
-
it would be nice if, also in the Preferences options, the user would optionally let his other contacts to let them know with which caller id they are on phone
-
like the Coccinella client, it will be helpful to have an address book. The way is done in Coccinella is approssimative: only the name and the telephone number … it would be better to centralize the user base on the jabber server side. not sure about that.
about that point, maybe the “User Properties” on the wildfire server could be extended.
in fact i don’‘t understand why if you edit your properties on Spark, with “Edit my Profile”, they could be viewed from another client, even Coccinella, even the avatar works well, but on the wildfire server side, you don’‘t get those info; you can’‘t edit them and you can’'t create them.
Simply extending those fields, would accomplish the ‘‘commercial’’ user base problem.
i mean, you could create on the server a group named something like ‘‘Customers’’ or ‘‘Customers - $BrandName’’ and its contacts would be searchable from the ‘‘back-end’’ users, and used from the caller popup feature.
this includes on the other hand, the ability for the ‘‘Customers’’ to login your wildfire jabber server, but, hey, this is a feature
what do you think ? every cent will be appreciated