I finally did my XMPP tests with a third server to trick Bria. In short (the good news): it all worked!!
The longer version (including the bad news): When I set up a third HA server with FQDN==sip-domain with only XMPP enabled then everything works. - Online Status is updated - GroupChat works OK (drag and drop) - IM groups are transfered There is however a small showstopper: - Bria receives via XMPP the IM-enabled user group I defined (GroupChat). Unfortunately the IM contacts in the "GroupChat" group only have the "Jabber"-id filled in and not the "Softphone". As a result you can't call these contacts by right-clicking because Bria has no SIP information, only (group-)chat with them. I don't know whether the SIP/softphone information is or is not present in XMPP, but wiresharking XMPP traffic results in a long list of numbers.....is there a way to make this readable? It would be nicer if all contact information for a contact was available under Bria automagically. If the softphone information is added manually to the XMPP contact then it is kept over reboots so that makes the "problem" smaller. It would be nice however if this information was there from the start (less hassle with users). There is also no "softphone" field in the Users <Contact Information> screen. (and if I fill in for example a cell phone number then it does not show up in Bria, it does in pidgin....more testing to be done). At the start I only created the XMPP SRV records for the third server, not the SIP SRV's. To test it was not related to this I added SIP SRV's as well and enabled "Redundant SIP router", but that did not help. It did generate the following error message: Standard output In redundant configuration, SIP_REGISTRAR_NAME (th.internal.epo.org) should not equal SIP_REGISTRAR_DOMAIN_NAME ( Standard error /usr/bin/sipregistrar.sh: line 71: myRegDomain: command not found Conclusion: Bria can be tricked, but you get contacts without the SIP/softphone info. Best regards / Mit freundlichen Grüßen / Sincères salutations Paul Scheepens "JOLY, ROBERT (ROBERT)" <rj...@avaya.com> wrote on 29-04-2010 15:40:48: > > > > > I did not manage to get it working today, the third server > > got initialized, but I could not restart any services. > > Tomorrow is queens day over here (the Netherlands) and next > > week I am off, but I will give it a try, just wait. > > Keep us posted on your progress... > > > > Could you give some more details about the Bria problem.... > > Is the problem related to only 2.5 (Pro) or 3.0 as well? > > I have no indication from Counterpath that they have a fix for this > issue. All released versions of the Bria product have this bug. > > > > > Other point: when Counterpath fixes the problem is the > > provisioning of Bria then still OK? > > If I am not mistaken Sipx now delivers > > proxies:proxy1:domain="FQDN" > > and it should be > > proxies:proxy1:domain="Sipx/XMPP domain" > > > > So I think it would be nice to create a boolean in SipX in > > the Bria Pro phone group to be able to change to Sipx/XMPP domain. > > Otherwise we will still be stuck when the problem is fixed on > > their side. > > When a Bria version comes out with the XMPP bug fixed, we will > change the provisioning back to provide the XMPP domain instead of > the FQDN and we will stop supporting older 'broken' versions. > > > > > > BTW > > Maybe I was not looking in the right place or maybe > > Counterpath reacted very fast, but if you go to > > http://www.counterpath.com/upgrade-to-bria-3.0.html > > <http://www.counterpath.com/upgrade-to-bria-3.0.html> > > > > Then you can upgrade with a discount. > > As we bought most of our licenses after December 1st, 2009 we > > can actually have a free upgrade :o) > > > > Best regards / Mit freundlichen Grüßen / Sincères salutations > > > > Paul Scheepens > > > > "JOLY, ROBERT (ROBERT)" <rj...@avaya.com> wrote on 28-04-2010 > > 16:52:28: > > > > > > > Hi Bob, > > > > > > > > Thanks for the clear answer. > > > > > > > > I am not sure how dependent openfire is from SipX, would it be > > > > possible to build a third sipx server (I already have an > > HA pair), > > > > give the server a FQDN of "th.internal.epo.org" > > > > (same as the SIPX/XMPP domain) and just enable the > > [BUNDLE.IM] on it > > > > (that would solve my problem in theory for now or not?) > > > > > > If you can manage the creation of the proper SRV & A > > records for it on > > > your DNS server, that's worth a shot but it's not something > > that was > > > formally tested - let us know how it works. > > > > > > BTW, I was able to verify that using the server's FQDN when > > > configuring Bria breaks the multi-user chat feature. > > > > > > > If that would be possible do I need to enable conferencing on the > > > > same server as well. > > > > > > No need for that. > > > > > > > > > > > Hi Tony, > > > > > > > > I had to buy extra Bria licenses when 3.0 was already > > announced, but > > > > not yet available, So I asked them whether I could use > > the same (100 > > > > user-) license for 3.0, this was the answer from Bria Customer > > > > Support > > > > > > > > Hi Paul > > > > > > > > There will be some upgrade path available from Bria to Bria 3. > > > > At this time pricing has not been set for this upgrade. > > > > > > > > > > > > Regards, > > > > > > > > Customer Support > > > > CounterPath Corporation > > > > > > > > I am still waiting for "some upgrade path" other then just buying > > > > Bria 3. > > > > > > > > Best regards / Mit freundlichen Grüßen / Sincères salutations > > > > > > > > > > > > "JOLY, ROBERT (ROBERT)" <rj...@avaya.com> wrote on 28-04-2010 > > > > 15:16:25: > > > > > > > > > From: > > > > > > > > > > "JOLY, ROBERT (ROBERT)" <rj...@avaya.com> > > > > > > > > > > To: > > > > > > > > > > Paul Scheepens <pscheep...@epo.org>, "sipx- > > > > us...@list.sipfoundry.org" > > > > > <sipx-users@list.sipfoundry.org> > > > > > > > > > > Date: > > > > > > > > > > 28-04-2010 15:16 > > > > > > > > > > Subject: > > > > > > > > > > RE: [sipx-users] Fw: XMPP works for Pidgin, not for Bria > > > > > > > > > > Very good analysis of the problem. You have hit a > > limitation of > > > > > Counterpath's implementation of the XMPP protocol. We > > have made > > > > > Counterpath aware of the limitation a while back and they > > > > are working on it. > > > > > > > > > > Basically, if your XMPP domain is not the same as your > > > > FQDN, Bria will > > > > > fail to connect to the XMPP server if you configure Bria > > > > with the XMPP > > > > > domain due to a standards non-conformance in Bria. We have > > > > found that > > > > > if you configure Bria with the FQDN of the XMPP server > > > > instead of the > > > > > XMPP domain then Bria can limp along and manage to connect. > > > > I was not > > > > > aware that this work-around prevented Bria from > > > > successfully creating > > > > > an ad-hoc conference though - I will have to experiment > > with this. > > > > > > > > > > In case you are interested, here are the gory details > > we sent to > > > > > Counterpath on the subject (in this text SMC means Bria): > > > > > > > > > > Pre-conditions: > > > > > =============== > > > > > * There is an XMPP server serving XMPP domain > > 'bobjolyimtest.com' > > > > > * That XMPP server has a FQDN of 'rjolyscs3.ca.nortel.com' > > > > > * There is a DNS server configured with proper SRV records that > > > > > map the 'bobjolyimtest.com' XMPP domain to host > > > > 'rjolyscs3.ca.nortel.com' > > > > > * We have configured SMC with an XMPP account of > > > > '2...@bobjolyimtest.com'. > > > > > > > > > > Observations: > > > > > ============= > > > > > We observe that under such a scenario, the SMC properly > > > > utilizes DNS > > > > > SRV queries to ultimately find out the IP address of the > > > > XMPP server > > > > > responsible for XMPP domain 'bobjolyimtest.com' and proceeds to > > > > > authenticate itself to the server through SASL. We observe that > > > > > the mechanism chosen is DIGEST-MD5 and that the authentication > > > > attempt is > > > > > failed by the server: > > > > > [10-01-27]11:10:43.177 | Info | XMPP | "XMPP/Gloox (XML In): > > > > > <failure > > > > > > > xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><not-authorized/></failur > > > > > e> > > > > > > > > > > Looking more deeply at the problem, we see that the server > > > > rejects the > > > > > challenge response that the SMC provided because it did not > > > > > contain the proper digest-uri information. More specifically, > > > > looking at the > > > > > attached log, we can see that the challenge response > > > > provided by SMC > > > > > is: > > > > > <response xmlns='urn:ietf:params:xml:ns:xmpp- > > > > > > > > > > > sasl'>dXNlcm5hbWU9IjIwMyIscmVhbG09InJqb2x5c2NzMy5jYS5ub3J0ZWwuY29tIi > > > > xu > > > > > > > > > > > b25jZT0icnFWM21DTEFHT05LRU5NaytUNEd0YzcyMGpiTGFFL1c4L1NqaUFJWiIsY25v > > > > bm > > > > > > > > > > > NlPSIwMDAwMDAyOTAwMDA0ODIzMDAwMDE4YmUwMDAwNjc4NCIsbmM9MDAwMDAwMDEscW > > > > 9w > > > > > > > > > > > PWF1dGgsZGlnZXN0LXVyaT0ieG1wcC9ib2Jqb2x5aW10ZXN0LmNvbSIscmVzcG9uc2U9 > > > > Yz > > > > > YzYWVmNmJiZjNlZDBjZDFiMTliN2ZhYjBmNjVlOTMsY2hhcnNldD11dGYtOA==</ > > > > > response> > > > > > > > > > > If we decode that base64-encoded challenge response we get > > > > the following: > > > > > > > > > > > username="203",realm="rjolyscs3.ca.nortel.com",nonce="rqV3mCLAGONKEN > > > > Mk > > > > > +T4Gtc720jbLaE/W8/ > > > > > > > > > > > SjiAIZ",cnonce="0000002900004823000018be00006784",nc=00000001,qop=au > > > > th > > > > > ,digest- > > > > > uri="xmpp/ > > > > > > > > > > > bobjolyimtest.com",response=c63aef6bbf3ed0cd1b19b7fab0f65e93,charset > > > > =u > > > > > tf-8 > > > > > > > > > > In it we can see that the diget-uri value is "xmpp/ > > > > > bobjolyimtest.com". This particular value is causing > > > > problems because > > > > > it contains the XMPP Domain information when it should have > > > > contained > > > > > the FQDN of the XMPP server, namely > > "rjolyscs3.ca.nortel.com" as > > > > > clearly outlined in rfc2831 section 2.1.2. > > > > > > > > > > I have looked at the gloox API and I'm not convinced that > > > > there is a > > > > > way to fix this. One possible way to get around the > > problem is to > > > > > disable SASL altogether and rely on [XEP-0078 - Non-SASL > > > > > Authentication] which gloox supports. I believe that > > this can be > > > > > accomplished through the Client::setForceNonSasl(bool > > force=true). > > > > > If disabling SASL is the way to go, I would suggest that > > > > the behavior > > > > > be configurable. > > > > > > > > > > > > > > > > I forgot to mention that I saw this as well: > > > > > > > > > > http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian> > > > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian> > . > > > > > > jira.plugin.system.issuetabpanels:comment-tabpanel&focusedComm > > > > > > entId=44640#action_44640 > > > > > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian > > > > > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian> > > > > > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian > > > > > > > > <http://track.sipfoundry.org/browse/XX-6879?page=com.atlassian> > > > > > > > > > .jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCom > > > > > > mentId=44640#action_44640> > > > > > > > > > > > > What puzzles me is that Bria Pro gets the hostname instead of > > > > > > the domain name for the Jabber-id via provisioning. > > > > > > In the debug from XX-6879 it looks like SMC (Bria) uses > > > > the domain. > > > > > > Can anyone explain why Bria does not work with > > > > u...@domain, but only > > > > > > works with u...@host? > > > > > > > > > > > > I think my DNS records are OK: > > > > > > > > > > > > the ones normally needed, th.internal.epo.org is the domain: > > > > > > > > > > > > > _xmpp-client._tcp.conference.th.internal.epo.org > > > > > > Server: gdns01.internal.epo.org > > > > > > Address: 10.0.10.11 > > > > > > > > > > > > _xmpp-client._tcp.conference.th.internal.epo.org SRV > > > > > > service location: > > > > > > priority = 1 > > > > > > weight = 0 > > > > > > port = 5222 > > > > > > svr hostname = gssipx02.internal.epo.org > > > > > > > _xmpp-server._tcp.conference.th.internal.epo.org > > > > > > Server: gdns01.internal.epo.org > > > > > > Address: 10.0.10.11 > > > > > > > > > > > > _xmpp-server._tcp.conference.th.internal.epo.org SRV > > > > > > service location: > > > > > > priority = 1 > > > > > > weight = 0 > > > > > > port = 5222 > > > > > > svr hostname = gssipx02.internal.epo.org > > > > > > > > > > > > The ones added because Bria uses hostname instead of > > domain, so > > > > > > "conference.gssipx02.internal.epo.org" instead of > > > > > > "conference.th.internal.epo.org" > > > > > > > _xmpp-server._tcp.conference.gssipx02.internal.epo.org > > > > > > Server: gdns01.internal.epo.org > > > > > > Address: 10.0.10.11 > > > > > > > > > > > > _xmpp-server._tcp.conference.gssipx02.internal.epo.org > > > > SRV service > > > > > > location: > > > > > > priority = 1 > > > > > > weight = 0 > > > > > > port = 5222 > > > > > > svr hostname = gssipx02.internal.epo.org > > > > > > > _xmpp-client._tcp.conference.gssipx02.internal.epo.org > > > > > > Server: gdns01.internal.epo.org > > > > > > Address: 10.0.10.11 > > > > > > > > > > > > _xmpp-client._tcp.conference.gssipx02.internal.epo.org > > > > SRV service > > > > > > location: > > > > > > priority = 1 > > > > > > weight = 0 > > > > > > port = 5222 > > > > > > svr hostname = gssipx02.internal.epo.org > > > > > > > > > > > > > > > > > > > > > > > > > BTW: In the mean time I discovered that you can also > > dynamically > > > > > > create a conference in pidgin by selecting "Add Chat". > > > > > > > > > > > > > > > > > > > > > > > > Best regards / Mit freundlichen Grüßen / Sincères salutations > > > > > > > > > > > > Paul Scheepens > > > > > > Administrator Network Engineering | Dir. 2.7.3.2 > > European Patent > > > > > > Office Patentlaan 3-9 | 2288 EE Rijswijk | The > > > > Netherlands Tel. +31 > > > > > > (0)70 340 3331 Mobile +31 (0)642724894 pscheep...@epo.org > > > > > > http://www.epo.org <http://www.epo.org/> > > <http://www.epo.org/ > > > > > > <http://www.epo.org/> > <http://www.epo.org/ > > > > > > <http://www.epo.org/> <http://www.epo.org/ > > <http://www.epo.org/> > > > > > > > > > > > > > > > > > > > > ----- Forwarded by Paul Scheepens/EPO on 28-04-2010 > > 13:18 ----- > > > > > > > > > > > > Paul Scheepens/EPO wrote on 28-04-2010 12:09:27: > > > > > > > > > > > > > From: > > > > > > > > > > > > > > Paul Scheepens/EPO > > > > > > > > > > > > > > To: > > > > > > > > > > > > > > sipx-users@list.sipfoundry.org > > > > > > > > > > > > > > Date: > > > > > > > > > > > > > > 28-04-2010 12:09 > > > > > > > > > > > > > > Subject: > > > > > > > > > > > > > > XMPP works for Pidgin, not for Bria > > > > > > > > > > > > > > I have been trying to get XMPP working for Bria Pro 2.5 > > > > > > because some > > > > > > > users wanted a Chatroom functionality. > > > > > > > I enabled the [Bundle.IM] role on the SipX server (4.2.0) I > > > > > > created a > > > > > > > usergroup "GroupChat", enabled "IM account" and "Add user > > > > > > group as IM > > > > > > > group" > > > > > > > for the group and added 3 users that use Bria Pro. > > > > > > > > > > > > > > When restarting Bria we got a new contacts group > > > > > > "GroupChat" with the > > > > > > > users in there. > > > > > > > When you right-click a contact Bria shows the "Start > > > > Group Chat..." > > > > > > > option to start a groupchat. > > > > > > > When I select this option an invite is send to the server, > > > > > > but it is > > > > > > > not received on the other client (Bria nor Pidgin). > > > > > > > In the Bria debug of the inviter I see a <error code='404' > > > > > > > type='cancel'><remote-server-not-found > > > > > > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error> > > > > > > > > > > > > > > See attached file "Bria-Invite.txt". > > > > > > > > > > > > > > The SIP-domain is th.internal.epo.org. > > > > > > > The XMPP server is gssipx02.internal.epo.org (primary > > > > sip server). > > > > > > > > > > > > > > As the groupchat is send to > > > > "conference.gssipx02.internal.epo.org" > > > > > > > instead of "conference.th.internal.epo.org" (our > > SIP domain) I > > > > > > > have added an A record and SRV records but this did > > not help. > > > > > > > Do I need to set up a conference for this? > > > > > > > Any other suggestions? > > > > > > > > > > > > > > BTW: For info only: I got it working with Pidgin, but > > > > this works > > > > > > > completely different from Bria, with Pidgin you first > > > > > > search for Chat > > > > > > > Rooms, then join one and then you can invite users. > > > > > > > I made a conference "Mine" and left it "public" so that it > > > > > > can be found. > > > > > > > This works well, including inviting Bria users. > > > > > > > I did have to remove the password of the conference > > > > otherwise Bria > > > > > > > can't accept the invite. > > > > > > > In the Bria debug I got a > > > > > > > <error code='401' type='auth'><not-authorized > > > > > > > xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error> > > > > > > > > > > > > > > See the second file "Bria-Pidgin.txt", first the Bria debug > > > > > > with the > > > > > > > error, then the successfull join after I removed > > the password. > > > > > > > > > > > > > > Best regards / Mit freundlichen Grüßen / Sincères > > salutations > > > > > > > > > > > > > > Paul Scheepens > > > > > > > [attachment "Bria-Invite.txt" deleted by Paul > > Scheepens/EPO] > > > > > > > [attachment "Bria-Pidgin.txt" deleted by Paul Scheepens/EPO] > > > > > > > > > > > >
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
