powered by Jive Software

AIM transport issue

I am running into this issue while using the latest GA gateway release:

with the AIM transport I am connecting OK and my AIM contacts come in and show up online, however when I then try to send a message to an AIM contact I get an error back from the gateway saying that I am not logged into the AIM transport. If I then disconnect and reconnect to the transport (without logging my XMPP account off) everything works fine.

Has anyone seen this, or knows what the issue may be? I am using a custom client so maybe I am missing sending some stanza. Yahoo/MSN/ICQ seem to work fine in this regard however.


Hrm. Can you see anything indicating that you failed to log in to AIM in the debug logs?

Does this happen every time?

(btw what’‘s ‘‘GA’’ release? ;D I don’'t know what the GA means)


oh oh generally available, my bad.

Message was edited by: jadestorm

No, thats whats wierd. It doesn’‘t say the connection failed, it acutally mentions the OSCAR connection being made, and it does pull in the AIM contacts and show their status’'s properly - so it does connect OK. I only get this message when I try to send a message to a AIM contact (the contact never gets the message either).

When I log in I am sending an iq:register to login to the transport and this behavior occurs. Is there something in the codebase that would make the AIM transport “think” I am not registered?

Also for more information, if I then send a:

and then send a iq:register again to log in it all works fine, which means that the AIM message is received OK on the other end.


Message was edited by: sphillips

Why are you using jabber:iq:register to log in instead of registering once and just sending an available presence to it anytime afterwards? You are causing the transport ‘‘extra work’’ to remove and recreate your registration every time.

I vaguely recall seeing the behavior you describe before, and I thought I recalled there being a fix for it.

It’‘s probably getting confused along the way because it -sounds- like you are sending an available presence to the transport, it goes to log you in, but then you send it a registration stanza that’‘s effectively telling it to change how you are registered, so what’‘s probably happening is it’‘s attempting to disconnect you after it receives that register stanza but it hasn’'t completed logging in yet so it gets into a bit of a confused state as to where it should be.

Yes, I am using iq:register every time I log in because I find that sometimes servers “lose” registrations and it confuses users when their contacts dont show up with the correct presence.

I think your analysis is correct, because I believe I am sending an ‘‘available’’ stanza to the XMPP server and then sending iq:register to every transport every time I log in.

I was assuming that I could call iq:register as many times as possible, and if the login credentials matched with the ones already stored on the server then nothing would happen and only if the credentials were different there would be a clean up and a transport re-registration.

I want to make it as smooth as possible for the end user, so for those cases where the registration to a transport was “lost” or the login credentials have changed, the user doesnt need to perform a manual regisrtation with each transport. In the latter case where the login credentials have changed, I cannot think of a way for the client to “know” what login credentials the server has and if they are correct or not. Therefore I just send the login credentials each time on server login.

I also wanted to make it simple on the client side so the client didnt need to know if the user had previously registered with a servers transport or not


Message was edited by: sphillips