As for XMPP documentation (Example 10) this kind of stanza should be valid:
<presence from="support#im.server.com" />
However ejabberd replies with 400 response. The reason here is a missing "to" field. I wonder why it happens.
Based on a XML schema of a XEP-0114 analysis I guess the reason is in a fact that support#im.server.com is an external component.
Could someone confirm that I am right/wrong, or give a suggestion how to overcome the situation?
XMPP Server: ejabberd 2.1.5.
example 10 which you refer to sends out a user presence to a client and includes a resource. So this is server => client.
If I understand you correct you send this presence from your component to the server (component=>server). Without a to address the server is not able to route this presence to another entity.
Related
I wrote an external component for Ejabberd, but when trying to send presence stanzas on behalf of a user i get a 400 error.
The component's name is bot.domain.com and the host name in Ejabberd is domain.com and I have set the "check_from" flag to false for my component.
Below is an example of a presence stanza I am trying to send from the component on behalf of a user:
<presence from="user#domain.com">
<status>Test status</status>
<show>dnd</show>
</presence>
And this is the error message that is returned by Ejabberd:
<presence type="error" to="user#domain.com">
<status>Test status</status>
<show>dnd</show>
<error code="400" type="modify">
<bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
</error>
</presence>
If I add to="user2#domain.com" in the package I'm sending, the destination user actually receives the package.
If I add to="domain.com", I don't get the 400 error anymore, but the presence is not broadcast to anyone in the user's roster.
The actual problem seems to be that Ejabberd is not broadcasting the presence packet to everyone in the user's roster.
Any ideas what I might be missing or why I get the 400 error when not specifying the "to" field?
You cannot broadcast roster presence on behalf of a user from a component. Component service does not load the user roster. Only the ejabberd_c2s is taking care of loading roster to broadcast presence. It also takes care of checking privacy list and many important features of XMPP.
As a side note, I do not know what you expect to do with that approach, but you can split presence from user session in XMPP. A user is online first because he has a session open on XMPP and only secondarily because he sent a presence. By faking presence sending from component for a users, you are not guaranteed that that user will have a session opened. In that case, the overall behaviour will certainly not the one you expect.
I'm creating a web XMPP client to connect to an XMPP ejabberd server and I have the following problem:
My client can send messages just alright.
The problem is when I try to receive messages. I only receive stanzas directed to my full JID, that is including the resource I am using, so I don't receive stanzas directed to my user#domain but I do receive stanzas sent to my user#domain/resource.
This is not an ideal situation since the other clients I need to communicate with work with bare JIDs.
I have little experience with Strophe so maybe someone with more experience can illustrate what I'm doing wrong. Thanks in advance!
Have you checked if your xmpp server offers a setting to route messages to all resources?
OpenFire offers a property named route.all-resources which will forward messages to all resources for a person.
Also, you may want to adjust the priority of your resource, as only the resource with the highest priority will have the message sent to it (if the message does not specify a resource).
Here is an example of setting your resource priority to 10 with Strophe.js
connection.send($pres().c("priority").t("10"));
This article describes the intended behaviour, and also this answer from a related question may help you understand what's happening.
How to know that message is deliver to other user using XMPP framework and ejabberd, we are using XEP-0184 class for Message Delivery Receipts , we send the receipts request while sending with the message but didn’t get any response.
My Query is should i need to configure anything on server (or any changes in ejabberd.cfg file) for that or any client side code we need to do.
No, XEP-0184 is a purely client protocol, so there's nothing to set up on the server.
Among the reasons you're not receiving any acknowledges there might be:
Your clients just do not have XEP-0184 enabled.
Depending on the XMPP libraries you're using (on both clients — the sender and the receiver), the sender might decide to not even request receipts if it discovers (by querying the peer's capabilities) that it has XEP-0184 turned off.
To be may be more clear: XEPs usually suggest the implementations to check if the feature defined by the XEP is supported, and to not attempt to use it if it isn't. Not all libraries and client do this, but some do. This means that some implementations might go like this: OK, I was requested to send delivery receipt requests, so
Do service discovery on the peer I'm about to contact.
Check to see if it has XEP-0184 enabled.
If not, I'll just silently not attach any receipt requests.
Whether a particular XMPP library does this by itself depends on how "smart" is was made.
If by XMPP Framework you mean this library, please try to read its source code to see if it's "smart" and asks the peer for its caps and then checks to see if XEP-0184 is enabled.
Also check to see if you can enable logging of XML streams exchanged by your client. Inspecting them is the best way to debug XMPP-related issues.
You can use XEP-0022 Message events extension to achieve this:
Here your message stanza formate:
<message to='username#domain.com' id='msgId-21102012,12:12:11'>
<body>How are you doing?</body>
<x xmlns='jabber:x:event'>
<offline/>
<delivered/>
<composing/>
</x>
</message>
Based on receipnt status, open fire will respone with message event status. Once look into XEP-022 extension.
We were using openfire 3.7.1 as our XMPP server, and we wanted to extend the Presence stanza to include some extra information like:
<presence from="you#MyServer.com">
<body>...</body>
<custom_element>
<custom_data/>
</custom_element>
</presence>
Could you please show me some pointers as what would be a better approach to do so? E.g., should I modify or extend some XMPP schema so that openfire will process the above presence packet as usual (currently if I send message like above, openfire seems not taking it as a Presence packet)? And should I create a plugin to intercept all packets so as to process our custom elements?
Thanks in Advance!
This is how it is normally done:
<presence from="you#MyServer.com">
<x xmlms="http://mycompany.com/mycustomnamespace1>
<custom_data/>
</x>
</presence>
Openfire will route such a packet without any problems.
You only need a server plugin when the server has to process any action on this custom elements. When the server should route the presence only to your contacts then nothing is required on the server.
I'm trying to understand the differences between AMQP and XMPP and among other things I don't really understand if XMPP works like it had Queues.
When you send a message to various clients what happen if one of them is down? The server enqueues the message up to the client is up again or how does it work?
Thanks
It depends on the XMPP server implementation how messages and iq's are handeld when the JID is offline. Section 11.1 of RFC 3921:
Else if the JID is of the form and there are no
available resources associated with the user, how the stanza is
handled depends on the stanza type:
...
For message stanzas, the server MAY choose to store the stanza on
behalf of the user and deliver it when the user next becomes
available, or forward the message to the user via some other means
(e.g., to the user's email account). However, if offline message
storage or message forwarding is not enabled, the server MUST return
to the sender a stanza error. (Note: Offline
message storage and message forwarding are not defined in XMPP, since
they are strictly a matter of implementation and service
provisioning.)
For IQ stanzas, the server itself MUST reply on behalf of the user
with either an IQ result or an IQ error. Specifically, if the
semantics of the qualifying namespace define a reply that the server
can provide, the server MUST reply to the stanza on behalf of the
user; if not, the server MUST reply with a
stanza error.