I am trying to implement a xmpp/SMS forking service and have successfully setup for incoming sms where the SMS is forked to both the users regular mobile and their XMPP client with no issue, however for outbound SMS when originated by the XMPP client I observe two issues -
XMPP originated message
a) Openfire is addressing the SMS to the mobile with the same TO: & FROM: fields, thus the mobile user receives a sms addressed to themselves from themself - desired behaviour is for the mobile user that the SMS should show the original originator as opposed to the xmpp users’ own identity - how/where is this configurable ?
b) Today the Openfire behaviour changes if the user’s xmpp client is logged in or not, as in if the xmpp client IS logged in and another xmpp user messages them they receive the mesagge as only xmpp but not SMS on mobile (as in xmpp is not sent to the SMSC). If the xmpp target user is NOT logged in to xmpp on their client, the message is delivered to SMS as desired (except the TO and FROM issue as above.) Desired behaviour is to deliver to both SMS and XMPP irrespective of logged in state.
Using Openfire 4.6.3, standard setup - route to SMSC is via xmpp.
Please can I ask for thoughts/tips on what configuration I might be missing or how to correctly setup this quite useful function ?
(Apologies if this is not the correct channel to ask - if the case please can a moderator help relocate )
Hi Magnus - I think we need a bit more background on the solution that you have built. It has been a while since I last touched SMPP, but lets see…
Although there is an SMS service in Openfire, I do not recall that it is used to route XMPP messages (rather, it is something used to alert administrators). Have you built your own solution? In any case, that implementation does not explicitly set a source address for the SMS (which I guess would translate to the ‘from’ address’ of an XMPP stanza), but you can probably set one through configuration. That will then be used for all SMS messages though. There is not a ‘per message’ API that I am aware of.
The more I re-read your message, the less likely it is that you’re using Openfire’s SMS service implementation.
I think that the key bit that I’d like to see clarified is around this line of your message:
route to SMSC is via xmpp
How exactly does that work? In XMPP, things are addressable by JID. Does the SMSC have its own JID? If so, what generates the stanzas sent to it (and how does that encapsulate the message to be transferred)?
If you do depend on an implementation that is not in the Openfire code base, then the matter of translating the ‘to’ and ‘from’ JIDs in each stanza to corresponding phone numbers needs to be somewhere in that solution. Assuming that the addressing in the stanza is correct (which it appears to be, given that your XMPP client correctly receives the message) then something is off in that mapping.
The title of this post includes the word ‘carbon’ - does that mean that somehow, the SMSC establishes some kind of dummy XMPP client connection for each user, and the solution dependends on XEP-0280: Message Carbons to intercept relevant messages?
We’re neck-deep in assumptions here, so it might be best to first get a better picture of the setup.
Good evening and thankyou for the reply, I should be more clear, with help i have enabled a ss7 smsc to support xmpp forking, so that an incoming sms is forked to mobilenumber@domain.com and this works well - all users are addressed by use of e.164 based jid. The smsc itself is originating and can be addressed from its own domain.
Its the route of xmpp into sms (smsc) where I think you are correct that i might need to adjust the openfire configuration - to achieve the desired forking of a xmpp message to go to both the xmpp user and be forked to same user id but at the smsc domain. Does this help clarify ? Thanks
Also worth clarifying I added the “Carbon” in the title as I think the answer might be to configure Carbon within Openfire to fork the msg to the SMS xmpp jid as well as delivering to the xmpp native domain user ? Hence perhaps its a question on how to substitute the domain in the Carbon process to the smsc domain in the users jid ? Appreciate any tips as I think(hope) very close to eureka moment.
Thanks
Magnus
How does a message that is composed on an XMPP client currently end up at the SMSC?
Assuming that your (XMPP) users have all JIDs in the form of mobilenumber@domain.com, then an XMPP message sent by one user to another user would have a ‘from’ address that is sender.e164@domain.com and a ‘to’ address that is recipient.e164@domain.com.
This would mean that the message is routed between the devices of the end-users, but not to the SMSC. Yet, you mentioned that in this scenario an SMS message was also received (although the ‘from’ addressing in the SMS is wrong).
Hello again, good question and its taken me a while to arrive at that I think its working at inward sms by the smsc delivering a xmpp msg to the user correctly addressed as in mobilenumber@domain.com which is fine, however my analysis is that out bound is working as openfire only has one server2server xmpp link setup, and when the local domain xmpp client is off line perhaps openfire as a last resort is sending it to the only connected server (smsc). Hence I arrive at the conclusion that I perhaps missing a function that might be possible to achieve either if I use a xmpp connected bot client to echo messages while transforming the jid domain or I might need have something written to interact with the “org.jivesoftware.openfire.interceptor” function? Not sure if this was the intended use case ? All knowledge welcome, thanks
Magnus
In every reply, you’re giving new bits of information that seems to be crucial for an understanding of your setup. It might be good to first step back a bit, and have a complete picture of the solution, including the exact addressing scheme that’s in use, and how the SMSC fits into all that.
If you’re not comfortable sharing details about a proprietary solution publicly, you might want to consider engaging one of our professional support partners, which are listed at Ignite Realtime: Support - Professional Partners
It might be good to first step back a bit, and have a complete picture of the solution, including the exact addressing scheme that’s in use, and how the SMSC fits into all that.