when I send a packet formatted as
<message id="JN_19"
to="chanks@v-ldap-test.infoassure.local"
type="chat"
from="btroxell@v-ldap-test.infoassure.local/NtwoK">
<thread>bc5e9512-cfb9-40bc-a168-c34e5ca3bb7e</thread>
<body>hello
</body>
</message>The packet is not getting delivered to
chanks@v-ldap-test.infoassure.local
does anyone have any suggestions as to how to trouble shoot this issue.
Thanks,
Casey
It should work I guess
I tried and it works for me: ejabberd 2.0.2, using the domain "localhost", users test1 and test2:
I send from test1@localhost/Tka:
<message id="JN_19"to="test2@localhost"
type="chat"
from="test1@localhost/Tka">
<thread>bc5e9512-cfb9-40bc-a168-c34e5ca3bb7e</thread>
<body>hello
</body>
</message>
test2 receives:
<message from='test1@localhost/Tka'id='JN_19'
xml:lang='es'
type='chat'
to='test2@localhost'>
<thread>bc5e9512-cfb9-40bc-a168-c34e5ca3bb7e</thread>
<body>hello
</body>
</message>
clarification.
I am using the Jabber-net library to build an IM client that connects to the eJabberd server.
The problems that I am encountering is that
<message>packers are not getting delivered to my client if they are addressed to the bare JID.For example if I have three clients
1) IM custom (logged in as source@server/custom)
2) IM custom (logged in as destination@server/custom)
3) IM Spark (logged in as destination@server/Spark)
if #1 sends the following message
<message id="JN_17" to="destination@server/custom" type="chat" from="source@server/custom"><thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 1</body>
</message>
The message is delivered to #2 only as it should be.
But if #1 sends the following message
<message id="JN_17" to="destination@server" type="chat" from="source@server"><thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 2</body>
</message>
The message is delivered ONLY to the Spark client (#3) when it should be delivered to both (#2) and (#3).
I suspect that the issue could be cuase by how I am connecting to eJabberd from client #2? Could this be the case? Does anyone have any ideas as to what could cuase a message sent to the server not to be routed to a specific resource?
One difference that I have noticed is that the Spark client is using PLAIN
authentication and the Jabber-Net library is using
<auth mechanism="DIGEST-MD5"xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
A second difference that I noticed is that
Spark is establishing a session using:
<iq id="J74ma-1" type="set"><session xmlns="urn:ietf:params:xml:ns:xmpp-session"/>
</iq>
and Jabber-Net is using:
<iq id="JN_2" type="set" to="v-doc-imchat.infoassure.local"><session xmlns="urn:ietf:params:xml:ns:xmpp-session" />
</iq>
I don't know if including the 'to' attribute matters or not.
Thanks,
Casey
a test to clarrify the issue
I thought the issue might have something to do with
so I did the following experiment:
Using just 2 clients
1) IM custom (logged in as source@server/custom)
2) IM custom (logged in as destination@server/custom)
if #1 sends the following message
<message id="JN_17" to="destination@server/custom" type="chat"from="source@server/custom">
<thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 1</body>
</message>
The message is delivered to #2
But if #1 sends the following message
<message id="JN_17" to="destination@server" type="chat"from="source@server">
<thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 2</body>
</message>
The message is NOT delivered to (#2) when it should be
This leads me to believe that the issue is not that the message is only being sent to the highest priority user - because there is ONLY one recieving user logged on.
Thanks,
Casey
related behavior
Once I determined that the issue was related to the routing of the Message packets in general I started experimenting with Direct Invitation to a room as defined in:
When I did this I got the following unexpected result:
Using just 2 clients
1) IM custom (logged in as source@server\custom)
2) IM Spark (logged in as destination@server\spark)
When I send the message:
<message id="JN_23" from="source@server\custom" to="destination@server\spark"><x jid="room1@server" xmlns="jabber:x:conference" /></message>The response I get is:
<message from='destination@server\spark' to='source@server/custom' type='error' id='JN_23'><x jid='room1@server' xmlns='jabber:x:conference'/><error code='404' type='cancel'><remote-server-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></message>Using the same two clients when I send the message:
<message id="JN_23" from="source@server\custom" to="destination@server"><x jid="room1@server" xmlns="jabber:x:conference" /></message>the message is delivered just fine
This surprised be a little. So something is going on that is resulting in:
1) messages are delivered to the Spark client only if the to attribute excludes the Resource
2) messages are delivered to my custom client that uses the Jabber-net libary ONLY if the to attribute includes the Resource
resource separator is /, not \
When I send the message:
<message id="JN_23" from="source@server\custom" to="destination@server\spark"><x jid="room1@server" xmlns="jabber:x:conference" /></message>You already posted that topic in another post. Why did you repeat here?
resource separator is not the issue
Thanks for the comments.
Some of samples I posted did have the "/" the wrong way.
This mistake does not occur in my code and occured only becuase I mistyped the sample during my post.
I did not know about the affect of the priority on the delivery of messages and I will investigate that.
Thanks for the suggestions.
Casey
priority not the issue
My application was using a priority of zero
I changed it to a priority of 100 and the behavior remains the same.
When I use Spark to generate an invite packet of :
<message id="byy4q-40" to="room1@conference.v-doc-imchat.infoassure.local"><x xmlns="http://jabber.org/protocol/muc#user">
<invite to="btroxell@v-doc-imchat.infoassure.local">
<reason>Please join me in a conference.</reason>
</invite>
</x>
</message>
it never arrives at my client
Still puzzled.
Any suggestions would be welcomed
Casey
Problem Solved
It turns out that my problems was being cuased by the fact that the Resource was getting changed to -1 in a part of my code. Once I figured out that then the problems went away.
Thanks again for the hints.
Casey
Destination will receive if priority is not negative
But if #1 sends the following message
<message id="JN_17" to="destination@server" type="chat"from="source@server">
<thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 2</body>
</message>
The message is NOT delivered to (#2) when it should be
This leads me to believe that the issue is not that the message is only being sent to the highest priority user - because there is ONLY one recieving user logged on.
I tried and the message is delivered if destination@server/custom has a positive priority (zero or higher).
If priority of destination is negative, the message is not delivered.
This is explained in XMPP-IM:
However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below).
In any case, you can try with regular desktop Jabber clients like Psi, Tkabber or Gajim.
Message to bare JID is sent to highest priority session
But if #1 sends the following message
<message id="JN_17" to="destination@server" type="chat" from="source@server"><thread>da19059b-dbdb-48bd-8b2b-8deac4ce58c0</thread>
<body>Test Message 2</body>
</message>
The message is delivered ONLY to the Spark client (#3) when it should be delivered to both (#2) and (#3).
Where did you read that a message stanza with bare JID destination SHOULD be delivered to all sessions of destination JID? Or did you simply imagine that?
The message is delivered to the resource with the highest priority, as explained in
11.1. Inbound Stanzas
...
4. Else if the JID is of the form <user@domain> and there is at least one available resource available for the user, the recipient's server MUST follow these rules:
1. For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource [...]. If two or more available resources have the same priority, the server MAY use some other rule [...]