I have all of the services running good on the latest version of openfire(msn, aim, etc…), but when I attempt to go to service discovery under my gmail in PSI, it cant connect to my server’'s hostname? Am I missing some settings in my openfire configuration or are there additional ports I need to open up? I have 5222 open…
Thanks,
captg
I’‘m not really sure this is the best place to be asking that. Probably the Openfire support forum would be better. It sounds like you can’‘t get a disco response at all which is beyond just the plugin. =) I have no expertise with google’'s client.
Well… I’'m not finding any other posts on this subject.
I’'m able to connect to my openfire server & use the service discovery. Just not able to use the service discovery while connected to GoogleTalk service and using my server… am i making any sense?
Anyone?
Message was edited by: captg
Are you saying that from your client, you connect to Google Talk (talk.google.com probably) and you aren’‘t able to get an answer to a service discovery request? (but it’'s all fine when you connect to your own openfire server?)
I guess it would help to ask quite bluntly… does this have anything to do with the IM Gateway plugin? =)
I’‘m not sure… I’‘m fairly new with this server application. How would I check out the IM plugin to see if it’'s the problem child?
Well I’'ll go into what the possibilities as I see them are:
(prefix to these questions, what client are you using?)
You are connected to your Openfire server with your client and trying to do a service discovery or communicate with Google’‘s service. If this is the case, you may just not have s2s turned on or haven’'t opened up port 5269.
You are connected to your Google Talk account from your client and are having issues getting a service discovery response from Google Talk. If this is the case, it really has nothing to do with Openfire at all. =/
I’‘m not sure what other scenarios there might be that I’'m not thinking of. =)
Well I’'ll go into what the possibilities as I see them are:
I don’'t have options for Google Talk in the plugin… only aim/msn/icq/irc
(prefix to these questions, what client are you using?)
I’'m using PSI to setup alt IM services with service discovery
If I’'m connected only to my Openfire server I can get the service discovery to work and I think I only have port 5222 open
Does 5269 have to be open to have google connect through service discovery?
I’‘m not sure what other scenarios there might be that I’'m not thinking of. =)
You have been a lot of help… thank you!
captg
Did you set up multiple accounts in Psi, one for your openfire server, one for google talk?
- You are connected to your Openfire server with your client and trying to do a service discovery or communicate with Google’‘s service. If this is the case, you may just not have s2s turned on or haven’'t opened up port 5269.
If I’'m connected only to my Openfire server I can get the service discovery to work and I think I only have port 5222 open
- You are connected to your Google Talk account from your client and are having issues getting a service discovery response from Google Talk. If this is the case, it really has nothing to do with Openfire at all. =/
Does 5269 have to be open to have google connect through service discovery?
Only if you are connected to your openfire server and from there trying to contact google talk. If you are connected from your client directly to google talk, then you should be good.
Daniel
captg wrote:
I’‘m not sure what other scenarios there might be that I’'m not thinking of. =)
You have been a lot of help… thank you!
captg
Well I’'ll go into what the possibilities as I see them are:
- You have a busted version of the IM Gateway plugin installed and you can see Google Talk listed under Gateways → Settings from the admin console. If this is the case, you got a busted build that wasn’'t supposed to go out and you should reinstall the plugin from the plugin downloads page on igniterealtime.org.
I don’'t have options for Google Talk in the plugin… only aim/msn/icq/irc
(prefix to these questions, what client are you using?)
I’'m using PSI to setup alt IM services with service discovery
ok, I’‘ll take you through step by step on what I’'ve done on my client side:
I have an account setup for GoogleTalk in PSI on talk.google.com: 5223 SSL
I connect to GoogleTalk and I can see all of my contacts.
“Right Click” GoogleTalk & click Service Discovery
It comes up with “gmail.com” by default and I type in my domain name (.com) *Same hostname I have programmed in the openfire configuration)
The PSI icon dances, but nothing loads.
I’'m trying to use the Service Discovery to add MSN/AIM/ICQ/IRC to my GoogleTalk. Those are the steps I take…
Anyways… does this information help? I have 5222 open
Well, I suppose the best thing to say at this point is, you can’'t add our MSN/ICQ/AIM/etc accounts from Google Talk via this plugin. The plugin does not support remote users creating accounts with it. (ie, you can only use them through an actual account on an actual Openfire server) Either way, s2s (port 5269) would need to be open to communicate between google talk and your openfire server anyway.
I think I understand what you’‘re trying to do, as I’'m having the same problem.
I have set up Openfire, installed the IM Gateway plugin, enabled some transports, and everything is working fine. I can connect the the jabber service, and see my MSN/AIM/etc. contacts.
Now I log into GTalk using Psi, go to service discovery and point it to my Openfire server, because I want to use the IM Gateway service in Openfire from Google Talk (because Google Talk doesn’'t provide this service), and I want to see my MSN contacts in Google Talk.
However, when I do this I get an error saying that the IM Gateway is only available to accounts on my Openfire server, and not external jabber servers. This is a common policy of most Jabber services (jabber80.com, jabber.dk, etc.), but in my case, I would like to make it available for me to use from GTalk.
I’‘ve searched everywhere, but I can’'t find anything explaining how to enable this remote service use?\
I hope you can help clarify this. Is it not possible (my best guess) or how to do it.
You can not do that. =) The way I orchestrated this plugin is both a blessing and a curse. To make it extremely smooth and work really well, I am using internal APIs of Openfire. As a result, I can only interact with local accounts. “period”. There’‘s no way to do what I’‘m doing and still have someone connect from a server somewhere else in the world. I plan on writing up a nice document explaining the whole thing. It’'s part of a good reason to still consider PyICQt, PyAIMt, etc etc. =) '‘cause they don’'t care.
The thing is, the standard way to deal with transports is painful. There’‘s a lot of things you can’‘t do as a transport author. (I’'m relaying my experiences with PyAIMt and PyICQt here) The use of the internal APIs dodges around the bulk of the issues you typically run into as a transport developer.
So… you might ask does this mean I’‘ll never support remote access? Unclear. To do so I’‘d have to make the whole interaction “suck again” unless … insert drum roll here … I can make use of my knowledge from both the plugin and from PyAIMt/PyICQt and work out some concepts that maybe would get accepted into the XMPP standards. That was one of my original goals here was to get to a point where I can use what I’'ve learned to improve -all- transports, not just my plugin.
See, if you were able to connect from your gmail account, I can’‘t “put things” in your roster. If you have 108 ICQ contacts, the first time you log into ICQ, you will get 108 “do you want to add me?” requests. That’'s, unfortunately, the way things are now. Roster Item exchange is a fairly cool protocol though and I -think- I may be able to make use of that somehow.
So I guess long story short … I’‘m always evaluating how this would be done, but currently, and probably for a long time now, there won’'t be support for remote use of the transports provided by the plugin.
Of course soon you’'ll be able to go the -other- direction. Have your GoogleTalk account registered with your openfire account. Not sure if that makes you happy or not. hehehe
wait… your saying that the way it works right now… you would just have to accept everyone in your ICQ/MSN/AIM Rosters? thats the only downside or? I swear it did that to me when I was using someone else’'s server.
There’‘s a lot more downsides than just that. At some point when I have time I’‘ll write out a document about what problems are dodged by using internals and try to see if I can’'t push for things to be ‘‘fixed’’ on a more global basis, so all transports can benefit from it, not just this plugin.
If the person’'s server who connected to had something other than the IM gateway plugin, then yes you would have gotten bombarded.
PyAIMt, PyICQt, PyMSNt, all require you to accept all of your contacts into your real XMPP roster unfortunately. That can lead to a lot of problems. There’‘s a lot of problems associated with the transport not knowing anything specific about your roster. Like there’‘s no way for it to know if you’‘ve deleted contacts since you last used it. It may be merrily going along thinking you have ninja@aim.whatever on your list and you really don’'t.
The plugin does -not- have this problem because it just up and puts people into your roster behind the scenes. It can also compare with your current roster and make sure things are properly synced up. Furthermore, it doesn’‘t put the contacts in your actual roster, so if you unsubscribe from your, for example, AIM transport, you won’'t end up with a bazillion leftover aim.yourserver.org contacts in your roster that are useless.
The bombardment of adds and such has been known to cause a lot of problems for end users in general though. Sure if you only have 5 or 6 it’‘s probably nothing. But some folk using PyICQt, for example, have many hundreds. I’‘m surprised some of these folk haven’‘t hit max list caps on the OSCAR servers. Anyway, the bombardment can cause a lot of shock value for the end user, lead them to sit there clicking over and over again … sometimes it even fires up enough requests to create the user’'s client. Often it brings their machine to a crawl briefly.
Anyway, like I said, there’‘s no “soon” plans of implementing anything for remote users. You might want to look into the alternative offerings if that’'s what you are after. =)