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.
Could you give some more details about the Bria problem....
Is the problem related to only 2.5 (Pro) or 3.0 as well?
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.
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
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/></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/
