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 '[email protected]'. 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'>dXNlcm5hbWU9IjIwMyIscmVhbG09InJqb2x5c2NzMy5jYS5ub3J0ZWwuY29tIixub25jZT0icnFWM21DTEFHT05LRU5NaytUNEd0YzcyMGpiTGFFL1c4L1NqaUFJWiIsY25vbmNlPSIwMDAwMDAyOTAwMDA0ODIzMDAwMDE4YmUwMDAwNjc4NCIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LXVyaT0ieG1wcC9ib2Jqb2x5aW10ZXN0LmNvbSIscmVzcG9uc2U9YzYzYWVmNmJiZjNlZDBjZDFiMTliN2ZhYjBmNjVlOTMsY2hhcnNldD11dGYtOA==</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=utf-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. > jira.plugin.system.issuetabpanels:comment-tabpanel&focusedComm > entId=44640#action_44640 > <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 > [email protected] 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: > > > > [email protected] > > > > 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 [email protected] 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/
