I’‘ve been researching this problem (which I posted as a much broader question some time ago) and I’'ve come to this:
If I send a presence packet with no type from my component to the msn gateway it does not get there at all, but presence packets with type (like subscribe or subscribed) and iq packets do get to the gateway quite fine. I’‘ve come to the point that I can register my component to the msn but I have no way to tell the gateway that I’'m online.
Is there any design reason for that behavior or is it that no one tried that before?
If there is no design or protocol barrier I’'d like a hint about which classes should I look in order to change that behavior to the one I need
How are you able to verify that the presence packet isn’‘t delivered to the component? Also, is this a gateway that’'s acting as an external component?
Easy, I just sniff the packets in the local tcp connection between the component and jive. The msn gateway is PyMSN-t so it’'s is external, my component is a plugin so it is internal.
By the way, is there an internal msn connector that I’'m not aware of?
Hmm, I don’‘t see any obvious reasons why your presence packets should fail. I can only assume that the routing logic in the server itself has some issues. Perhaps it doesn’'t correctly account for inter-component communication.
This is Gato’‘s area of expertise and he’'s on vacation this week. So, I filed JM-375 and we should get an answer from Gato on it next week.
Why is the gateway saying its unavailable? That would be the answer as to why the server is not forwarding packets to it. Also I see msn subscirbing to your presence but not you subscribing to msn. In other words i dont see the subscribed back from msn.
I also thought that, but I also sniffed a correct registration to the gateway by a client, and it always sends those unavailable packets until it sees the presence from the other side. This is also confirmed by the msn gateway’'s log:
08/17/05 - 13:43:30 - PyTransport: Sending unavailable presence to non-logged in user "test@colas.devel.pbxip.net"
then my quesiton would be is this directed presence of unavailable then affecting Messenger’'s forwarding of presence packets. Id have to go in and check the messenger code but if anyone is familiar with it offhand: Does Messenger think then that the gateway is unavailable? And is that why it is not forwarding the presence packets?
I’‘ve been working on a gateway framework to take care of the details of registration, presence management, etc. I’'ve seen the behavior that when an “unavailable” packet is sent, Messenger will stop forwarding any packets until a login comes around from that entity.
For example, the gateway (my implementation) is required to send an unavailable if the user unregisters (along with an unsubscribed and unsubscribe). In my testing, unavailable never makes it and if I send it first, than the unsubscribe(d) won’'t make it easier.
So, the user unregisters. Then the gateway sends a directed unavailable to the user? If that is the case and other presences aren’'t getting through that would seem it would be the same case then as is be experienced with the msn gateway.