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 that would be possible do I need to enable conferencing on the same
server as well.
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'>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
> > pscheep...@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/
