I went back and inspected/corrected a bunch of stuff in the SipXecs configuration, specifically the .ini files for Bria for provisioning. I think pretty much everything is working like it should, minus the contacts being +1'ed every time you shut down and restart Bria, and the Webdav storage issue, which I've switch to local in all the Bria provisioning .ini files.
On Fri, Dec 17, 2010 at 4:53 PM, Tony Graziano <[email protected] > wrote: > On Fri, Dec 17, 2010 at 5:40 PM, Victor Williams > <[email protected]> wrote: > > List still isn't sending to my Yahoo address, so hopefully this one will > > work... > > > > I have successfully gotten this working...to an extent, however, a few > > things stand out that appear to be incorrect, and I don't know where to > fix > > them (I can't tell whether it's "feature functionality" or if it's an > error > > somewhere...in either Bria or SipXecs): > > > > 1. Every time logging into Bria via the provisioning route, I keep > getting > > contacts showing up that I don't believe should. In the group "Ungrouped > > Contacts", I keep getting the same one added to that group every time I > log > > in. So if contactA is there when I log off, contactA is there twice when > I > > log back in. If I then log off, contactA is there three times when I got > in > > again. Etc, etc. It can be re-created 100% of the time. > > Known bug, the last bria lab release fixes that. There is a JIRA on it. > > > > 2. When Bria user A and Bria user B initially log in and add each other > as > > contacts, neither of them will get a permission request or appear as > online > > in each other's contacts unless the Jabber: field is filled in with > > [email protected], and then hit 'Ok'. Question for Counterpath > > ultimately, and I will raise it with them, but shouldn't that field just > > assume it's the same domain unless otherwise stated? > > No, because the correct format should not assume one's own domain, > since it can talk to many. Unless you are using the Spark client which > known how to search and dig your own domain for contacts, you would > have to enter it. Even Spark populates the <user>@<domain> when adding > from their search function. > > > > 3. The "Work" contact group is automatically populated with contacts > from > > the SipXecs install, regardless if they are enabled for IM...even the > > superadmin user is listed. If I remove the group, then come back, it's > > magically back again. I don't want any users automatically populated. > The > > ultimate goal is to pick users out of a directory (which one is > unimportant > > now), be able to add their softphone or sip address, and save it in > Contacts > > and have it be persistent across restarts. > > This is correct if there is a group speeddial I believe. > > > > 4. To get presence and everything working correctly on each login, for > each > > user one has to edit each profile and then put [email protected] in > the > > Jabber field and re-check the box to see presence information for that > > user. Otherwise, you can't see presence information. Why isn't this > kept > > across restarts of Bria? > Your XMPP profile is not storing the contacts locally. It should be, > as there is a known bug with storing via the webdav method. > > > > > > There are other nagging issues, but those are the 4 that are getting most > on > > my nerves right now, and I don't know where the problem truly resides. > For > > what its worth, logging into Spark or Pidgin with no changes on the > SipXecs > > side just works. Only looking at the Bria log file was I able to figure > out > > that it was sending u...@ipaddressofxmppserver instead of > > [email protected]. That is the only reason I tried filling (and > > re-filling) the Jabber: field with [email protected], and > everything > > magically started working. However, those changes aren't kept across > > restarts, and I have no idea why. > > > I think there is a HUGE number of comments on this, and some progress > being made with Counterpath. I'm not pointing fingers at anyone, but > this is something they have been slowly fixing one issue at a time, > like the whole VCARD cache stuff too. > > I would encourage you to look in the tracker and see the outstanding > issues, what's been done, and comment/assist as you feel prudent. > > > > > ----------------------------------------------------------------------------------------------------- > > > > Also, you need to setup bria to communicate with sipxopenfire. It is > better > > to use the bria provisioning service in sipconfig to do this. You should > > have a sip ONLY account and an IM account (both pointed to sipx). 2 > > accounts, not both services in one. > > See the wiki on counterpath provisioning. > > ----- Original Message ----- > > From: sipx-users-boun...@xxxxxxxxxxxxxxxxxxx > > <sipx-users-boun...@xxxxxxxxxxxxxxxxxxx> > > To: sipx-us...@xxxxxxxxxxxxxxxxxxx <sipx-us...@xxxxxxxxxxxxxxxxxxx> > > Sent: Thu Dec 16 11:01:08 2010 > > Subject: [sipx-users] Clarification on IM (XMPP vs SIP) > > I have the Bria 3 client working with our install of SipXecs, but I'm > > confused on the instant messenger aspect. If I just fire up Bria with a > SIP > > profile and check both the SIP and IM boxes, people can IM each other. > How > > is that working? Is that going through the SipXecs server, or is that a > > straight peer-to-peer IM? I don't see any log file containing > conversation > > history on the SipXecs server. > > I also set up an XMPP profile in Bria 3, and that is working. But again, > I > > don't understand the difference between the SIP IM vs the XMPP IM when it > > just comes to simple instant messaging. What is gained/lost by using one > or > > the other? > > What I'm trying to accomplish: I don't want users to send/receive files > or > > anything, I just want users to be able to IM each other and have the > > conversation logged on the server. > > Our install doesn't need any of the advanced functionality that Openfire > or > > any other solution offers. At this time, we only want people to IM each > > other and have the conversations logged. What is the most > straightforward > > way to allow that to happen with the SipXecs install? > > > > _______________________________________________ > > sipx-users mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > Tony > _______________________________________________ > 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/
