Was on holiday and had a lot of mails to catch up........
Here my answers to the original questions:
Paul
P.S. I am not in the rest of the week, so if you have questions dont
expect a reply before monday.
Victor Williams <[email protected]> wrote on 17-12-2010 23:40:30:
> 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.
As Tony said, this should be fixed in 3.1.2.1 (build 58992).
What build are you running?
> 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?
It works for me without the domain name, again build 58992.
> 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 happens because webdav is enabled for the Line (this is different
from webdav for the Phone).
Go to <Devices>, <Phones>, select a Line (not a Phone), go to <Resources>
and put "Resource list method" to "Local". Push it, delete the group in
Bria and restart Bria.
> 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?
You are probably doing this in the "Work" group that Bria gets from SipX.
The webdav from SipX is read-only, so you lose any changes you make after
a reboot.
If you create entries manually it should be OK. I believe work is done to
make the SipX list writeable as well.
Tony opened some issues in relation to this.
Disable "Webdav" on the "Line by changing the "Resource list method" to
"Local" and test again.
(If I read your other mail correctly you changed this by editing the ini
file. By changing the "Resource list method"
you will keep the change for ever).
> 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.
Again, disable webdav on the "Line".
Hope this helps/clears things up.
Regards, Paul
>
-----------------------------------------------------------------------------------------------------
>
> 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.
> ============================
> Tony Graziano, Manager
> Telephone: 434.984.8430
> Fax: 434.984.8431
> Email: tgrazi...@xxxxxxxxxxxxxxxxxx
> LAN/Telephony/Security and Control Systems Helpdesk:
> Telephone: 434.984.8426
> Fax: 434.984.8427
> Helpdesk Contract Customers:
> http://www.myitdepartment.net/gethelp/
> ----- 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/
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
