This Question is Possibly Answered

1 "correct" answer available (10 pts) 2 "helpful" answers available (5 pts)
6 Replies Last post: Jan 26, 2008 10:54 PM by Daniel Henninger  
Jonathon Taylor Bronze 9 posts since
Apr 2, 2007
Currently Being Moderated

Dec 10, 2007 12:03 PM

IRC Transport Breaks XMPP MUC?

 

My question is how to configure OpenFire to force clients to use XMPP MUC over IRC when the IRC transport is enabled.  When I enable IRC for my clients they all get the error "No Response From Server" when they try to create an ad-hock conference.  I turned debug logging on and the issue appears to happen when clients are not registered with IRC.  Disabling IRC solved the issue.  Is this behavior by design?

 

 

I am using OpenFire 3.4.2 and Spark 2.5.8.  I confirmed this behavior with OpenFire 3.4.1 as well. 

 

 

Here are the relavent logs:

 

 

2007.12.10 09:15:23 Received iq packet: &lt;iq id="NQ71J-98" to="jtaylor_a1a@conference.irc.chat.xxxxx.edu" type="get" from="jtaylor@chat.xxxxx.edu/spark"&gt;&lt;query xmlns="http://jabber.org/protocol/disco#info"/></iq>

 

2007.12.10 09:15:23 irc: Sending packet: &lt;iq type="error" id="NQ71J-98" from="jtaylor_a1a@conference.irc.chat.xxxxx.edu" to="jtaylor@chat.xxxxx.edu/spark"&gt;&lt;error code="403" type="auth"&gt;&lt;forbidden xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/&gt;&lt;/error&gt;&lt;/iq&gt;

 

2007.12.10 09:15:23 Received presence packet: &lt;presence id="NQ71J-99" to="jtaylor_a1a@conference.irc.chat.xxxxx.edu/Jonathon Taylor" from="jtaylor@chat.xxxxx.edu/spark"&gt;&lt;x xmlns="http://jabber.org/protocol/muc"/></presence>

 

2007.12.10 09:15:23 Unable to find session.

 

2007.12.10 09:15:23 irc: Sending packet: &lt;message type="error" to="jtaylor@chat.xxxxx.edu/spark" from="conference.irc.chat.xxxxx.edu"&gt;&lt;error code="503" type="cancel"&gt;&lt;service-unavailable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/&gt;&lt;/error&gt;&lt;body&gt;You are not currently logged into the IRC transport.&lt;/body&gt;&lt;/message&gt;

 

 

Daniel Henninger Jiver 2,933 posts since
Aug 10, 2005
Currently Being Moderated
Dec 10, 2007 12:11 PM in response to: Jonathon Taylor
Re: IRC Transport Breaks XMPP MUC?

I'm not following exactly, but XMPP MUC shouldn't be affected by IRC's MUC implementation.  But yes, you are required to be registered with the IRC transport to use IRC's MUC implementation.  Otherwise there's no attachment of your account to an IRC account, which is necessary for it to function correctly.

Daniel Henninger Jiver 2,933 posts since
Aug 10, 2005
Currently Being Moderated
Dec 10, 2007 12:29 PM in response to: Jonathon Taylor
Re: IRC Transport Breaks XMPP MUC?

It -ought- to be using the main XMPP conference service.  That's rather bizarre that it's not.  =(  I can't duplicate it at the moment.  Anyone else running into this?  Is it only invite to conference?

Rasul Shishehbor Bronze 1 posts since
Jan 25, 2008
Currently Being Moderated
Jan 25, 2008 6:53 PM in response to: Jonathon Taylor
Re: IRC Transport Breaks XMPP MUC?

 

I'm also having this problem, I'm wondering if it's only on Spark clients.  The problem is, instead of just having conference.server.domain.name in the Conferences tab of Spark, I've also got a conference.irc.server.domain.name and unfortunately Spark chooses to search the conference.irc service first (which doesn't exist I don't have an IRC gateway registered?) So it errors out with "Unable to connect to service" or something along that lines.  Again this happened with Openfire 3.4.4 server, and Spark 2.5.8  server is on Solaris 10 U4.   I can reproduce it 100% with the spark client, and having all the non-beta plugins enabled (I think the big thing is have the IRC gateway enabled).

 

 

Daniel Henninger Jiver 2,933 posts since
Aug 10, 2005
Currently Being Moderated
Jan 26, 2008 10:54 PM in response to: Rasul Shishehbor
Re: IRC Transport Breaks XMPP MUC?

Yeah, it is definitely a Spark bug.  Sigh.  Being the lead developer of Spark now though, I'll see what I can do.  hehhehe

 

SPARK-962

More Like This

  • Retrieving data ...