Thanks Paul... It takes a while with these folks. What I discovered is that they don't much care about their retail operation (folks like us that just go buy the product off the web site). They seem to be more focused on their OEM partners... That's the way it seems to me anyway.
I've had to resort to giving them access to my corporate phone system for them to test their XMPP features. I have a beta build that doesn't replicate contacts finally. Regarding XMPP groups. These do work in sipXecs if you create a user group and enable IM settings in the group. The group will appear in your XMPP client with all the members of the group and you don't have to request / authenticate each one. Mike On Tue, Nov 23, 2010 at 12:33 PM, Paul Scheepens <[email protected]> wrote: > Actually they themselves know it at different times....I only got > this file because the right guy saw my request after my question > whether web tabs were provisionable was first answered with a "No". > So lucky me/us/world. > > XMPP groups are sort of working for me. I have to find some time to retest. > First I have to do a DNS/DHCP upgrade and other stuff. I promised > Counterpath to have some info for them by the end of the week. > I extend that promise to you now as well :o) > > Regards, Paul > > > While I'm picking on them, I noticed the 3.0 to 3.1 doc you attached > > doesn't have a revision date on it. However it looks like on this > > version there might be nothing that fails to configure the phone > > properly and keep it form working! I have an urge to know "when" > > they knew about these changes, but that's just me. > > > > Thanks for sharing! > > > On Tue, Nov 23, 2010 at 11:58 AM, Tony Graziano < > [email protected] > > > wrote: > > Is anything you are talking to them about addressing proper storage > > of xmpp contacts on the server? > > > > Ex: in an AD environment running oepnfire (no sipx) it is possible > > for all users to see other users without having to authorize it and > > store contacts centrally (using an xml script and plugin on openfire). > > > > In latest snapshot i attempted to do this and it appeared to work > > but not on bria client (without AD, just using the authorization > > plugin). Spark would load the contacts and show their presence > > without having to manually ask and authorize them for the local > > domain. Bria XMPP would not even load them, which i assumed to be an > > issue where they don't like the webdav method at all.. > > > > I know I had had a fight with their support. Ok, not a fight, but a > > literal wearing down of me for their lack of understanding I felt > > like every byte of information they actually understood took an > > enormous amount of effort on my part, and at the end I didn't feel > > victorious either. It was all about webdav or centralized storage of > > contacts. I know I opened a JIRA too. > > > > So have you addressed centralized contact storage with them? > > > On Tue, Nov 23, 2010 at 11:32 AM, Paul Scheepens <[email protected]> > wrote: > > Small update on my Bria experiences. > > > > - Stability/too "heavy": > > I think/hope I got the message across to Counterpath....they will > > try not to gain more weight > > -Support: > > Counterpath is still listening to me, but it takes time to change/ > > patch/modify.......... > > - Deskphone mode with video on Bria: > > Apparently Bria for Broadsoft supports this as we speak. I don't > > know how this works however. > > Is there a BroadSoft user here that could make a trace? > > Maybe we could make this work in SipX :o) > > - .NET troubles: > > I fixed this issue by uninstalling .NET and reinstalling it with > > http://www.sereby.org/site/AiO > > - Codec negotiation: > > I think you opened a different thread on this one. > > - Web Tabs: > > They can be set through central provisioning, maybe the settings can > > be incorporated into SipX's Bria provisioning. > > See the attached file. > > > > > > > > BTW: I have 14 points outstanding with Counterpath at the moment, > > some simple, some difficult, but I think I will get at least half of > > them fixed within decent time. > > BTW2: If you want to use a Polycom CX300 with Bria then don't, use a > > Plantronics Calisto P540. it's the same thing, its cheaper and it > > performs echo cancellation > > when using the speakerphone (because it has a newer firmware on it, > > and Polycom is relying on the software). > > Apparently Plantronics is also interested to improve the > > interoperability with Bria, Polycom is not. > > > > Paul > > > > > > I've come to the same solution, that counterpath could do a better > > > > job before releasing in making sure things work as expected. I won't > > > > go down that road here... > > > > > > Valid point, the application is too heavy as well IMHO. > > > Softphones should be agile, not elephants. > > > > > > > I have noticed that the support has been "lackluster", I spend 20-30 > > > > hours troubleshooting their prouduct, which I paid 60.00 for, yet > > > > spend an inordinate amount of time trying to document the issues and > > > > getting them to listen. As a result, I'm a big hardphone fan (still). > > > > Hardphones are the better bet. Softphones (and expensive Tandberg/ > > > Cisco/Polycom kit) do video. > > > I would like to see the Deskphone mode of Bria extended so that it > > > supports video on PC, voice on HP. > > > > On Thu, Nov 4, 2010 at 11:54 AM, Kyle Haefner < > [email protected] > > > > > wrote: > > > >> Hi Paul, > > > >> > > > >> I think the most frustrating part is that everything worked in Bria > > > >> 2.5 and now several things do not. The things I like the least: > > > >> > > > >> 1. It requires a new C++ runtime to be installed, with windows XP > > > >> computers and certain hot fixes Bria would always crash on startup, > > > >> the workaround is to uninstall several hot fixes making installation > > > >> a lot more difficult for end users. Even with this done, several of > > > >> my end users complain it locks up the XP machines. > > > > > > > > I ran into the same issue, spending several hours to get it > > > > installed on a particular machine. BUT if your developer is on the > > > > dotnet path, there is no avoiding it (get a mac?). > > > > > > Bria is at the moment too resource intensive and sluggish to be > > goodsoftware, > > > but I can't find a better product. I have only recently stumbled > > upon my first > > > "unknown software exception" error. If you have more details about > > > what in C++ is causing this > > > then I am all ears, I am getting the PC of the affected user today > > > or tomorrow to fix the problem. > > > > > > >> 2. 3.x does not handle codec negotiation when a called person has a > > > >> cell phone sim-ringed through our mediant 2000 gateway, according to > > > >> the trace it Bria 3.x grabs g711 and then I get one-way audio with a > > > >> polycom talking g722. I've tried both checking and unchecking > > > >> "Accept first codec offered" setting to no avail. 2.5 and several > > > >> other softphones work fine, including CSIPsipmple on android. > > > > I have not tried with 3.1.2, but previous 3.1's I never had a > > > > problem with G722 negotiating (polycom hd <>bria). I don;t think 3.0 > > > > had g722. So saying 3.x is a little bit of a gray statement (to me > > > > at least). Do you have a call trace for this to see where the > > > > negotiation is set up and what UA is ignoring the proper facts? > > > > > > I had a problem with Bria and Polycom once, the problem disappeared > > > after a reboot and > > > before I started troubleshooting. Bria was indeed using G.711 > > > instead of G.722. > > > If you have this consistently then a trace would be good indeed. The > > > sim-ringing > > > should not affect codec negotiation AFAIK (I am sim-ringing my cell > > > phone as well). > > > > > > >> 3. The XMPP part was nice helps to bring a unified application that > > > >> offers similar features to OCS/Lync. > > > >> > > > >> Other gripes: > > > >> > > > >> LDAP, is not a dynamic query, it is a onetime query at program > > > >> launch, not based on what you've just typed. > > > > > > You can also use the "search on demand" function, it's less fancy, > > > but it works. > > > I can't use the "Type to filter list" because the list is not > > > completely loaded from the LDAP. > > > We probably have too many users in the LDAP (7000+). > > > > > > >> The new web modules are kinda cool and could have neat possibilities > > > >> regarding sipxecs REST APIs, but they are not set through the > > > >> central provision. Why? > > > > > > Someone has to make it. I will try to find out whether it is > provisionable > > > according to Counterpath. > > > > > > >> I guess in the end 3.x feels much more like a financial upgrade for > > > >> counterpath rather than a feature upgrade for customers. > > > > > > Yes and no, it was a complete .NET rebuild and it did not bring a > > > lot for the end-user. > > > If they get some agility into the product, support XMPP in a decent > > > way and fix some annoying bugs then > > > it could be a top product IMHO. The workgroup feature can be useful > > > as well in some deployments. > > > > > > > There were changes from bria 2.5, to 3.0, to 3.1 (syntax, options, > > > > etc.). It takes a while to get caught up to make sure the phone gets > > > > provisioned properly. I wish webdav would work or that your > > > > directory were centrally stored properly for xmpp too. I have not > > > > tried 3.1,2 yet though. I have to meditate before touching a new > > > > version of bria, and that takes time. > > > > > > I think Webdav works well with Bria, webdav was not working OK on SipX. > > > > I have used a separate Webdav server and Bria works flawless in that > case. > > > I think most webdav issues should be sorted in 4.3.2 (like the > > > possibility to write > > > presence requests back to the server). > > > > > > >> Paul I agree it is the best out there, but to me what that really > > > >> says is the state of soft-phones in general is really awful. > > > > > > > AGreed. > > > > > > Have to agree as well. > > > > > > >> What I really wish is that sipcommunicator worked well. > > > > > > > Me too. > > > > > > It already came a long way, but it's still in alpha state. > > > Here are a few others that were OK-ish in the past but at that time > > > lost from Bria, > > > I don't have the time at the moment to retest, but maybe there is > > > something nice out there: > > > http://www.globaliptel.com/eng/content/Content/Ninja/comparison.html > > > http://www.portsip.com/softphone.htm > > > http://www.sr-l.com/deutsch/index_grau.htm?page=main_homepage.htm > > > http://www.nch.com.au/talk/index.html > > > > > > Voice only: > > > http://www.phonerlite.de/features_de.htm > > > > _______________________________________________ > > sipx-users mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > > > > -- > > ====================== > > Tony Graziano, Manager > > Telephone: 434.984.8430 > > sip: [email protected] > > Fax: 434.326.5325 > > > > Email: [email protected] > > > > LAN/Telephony/Security and Control Systems Helpdesk: > > Telephone: 434.984.8426 > > sip: [email protected] > > > > Helpdesk Contract Customers: > > http://support.myitdepartment.net > > > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > > > > > > > > > -- > > ====================== > > Tony Graziano, Manager > > Telephone: 434.984.8430 > > sip: [email protected] > > Fax: 434.326.5325 > > > > Email: [email protected] > > > > LAN/Telephony/Security and Control Systems Helpdesk: > > Telephone: 434.984.8426 > > sip: [email protected] > > > > Helpdesk Contract Customers: > > http://support.myitdepartment.net > > > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > _______________________________________________ > > 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/ > -- There are 10 kinds of people in this world, those who understand binary and those who don't. [email protected] blog: http://www.sipxecs.info call: sip:[email protected] <sip%[email protected]>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
