> 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/></failure> > > > > 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'>dXNlcm5hbWU9IjIwMyIscmVhbG09InJqb2x5c2NzMy5jYS5ub3J0ZWwuY29tIixu > > > b25jZT0icnFWM21DTEFHT05LRU5NaytUNEd0YzcyMGpiTGFFL1c4L1NqaUFJWiIsY25vbm > > > NlPSIwMDAwMDAyOTAwMDA0ODIzMDAwMDE4YmUwMDAwNjc4NCIsbmM9MDAwMDAwMDEscW9w > > > PWF1dGgsZGlnZXN0LXVyaT0ieG1wcC9ib2Jqb2x5aW10ZXN0LmNvbSIscmVzcG9uc2U9Yz > > YzYWVmNmJiZjNlZDBjZDFiMTliN2ZhYjBmNjVlOTMsY2hhcnNldD11dGYtOA==</ > > response> > > > > If we decode that base64-encoded challenge response we get > the following: > > > username="203",realm="rjolyscs3.ca.nortel.com",nonce="rqV3mCLAGONKENMk > > +T4Gtc720jbLaE/W8/ > > > SjiAIZ",cnonce="0000002900004823000018be00006784",nc=00000001,qop=auth > > ,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> . > > > 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> > > > .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/> > > > > > > > ----- 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/
