search

ossguy / etps

0 stars 0 forks source link

Decoupling use cases #2

Open singpolyma opened 7 years ago

singpolyma commented 7 years ago

Phase 1 is about letting XMPP users send messages to SMS users. These thoughts are about letting SMS users get a JID at which to receive messages over XMPP.

Isn't that the same? Well, not quite. The former is to allow particular XMPP users access to all SMS users. The latter is to allow particular SMS users access to all of XMPP.

Forwarding

The simplest way to do this is what VOIP.ms and others call "SMS forwarding" -- messages over XMPP would be sent out from some central number over SMS. Sender information is stripped and there is no way to reply, so while this might work for basic notification cases, it's not actually particularly useful.

Bot

An extension of the above, but reformat messages to indicate sender and allow specially-formatted SMS back to the bot to send messages to any JID. This is what Cheogram "whisper" currently supports. Works, but not the best UX.

Mux

On new inbound message, check if the target JID is a customer in good standing. If so, then check if the tuple (sender JID, target JID) maps to a particular route, if so use that route, otherwise look up the pool of routes for the target JID and assign one that is not assigned to another tuple for that target to this tuple and use it.

Messages from a customer to the Mux do the reverse translation -- look up the tuple and send the message back to the original sender. If tuples are stored forever, then this becomes a permanent mapping between JIDs on either side of the Mux.

I intentionally did not mention SMS or phone numbers above because this Mux can be build XMPP-pure such that it does not even know about SMS! This is because after Phase 1 all SMS is just XMPP for particular senders, so we just have to register the Mux pool of numbers through Cheogram or similar and from there it's just XMPP. The same Mux could be used through a different set of transports to enable, say, a Kik user to receive messages from XMPP or any similar case.

This approach probably smells very similar to the current Soprani.ca codebase. That is because it is one-half of it, decoupled. Instead of doing SMS-to-SMS muxing, I propose doing XMPP-to-XMPP muxing (where one side of the Mux is probably only set up with SMS2XMPP routes for now). Getting the full functionality of SMS-to-SMS back out of this is fairly straightforward. If the Mux registers with Cheogram that the "external" side JID has a 1:1 route DID of the "internal" number, then everything will forward correctly with no additional code but we have gained additional functionality (inbound can come from XMPP pure without SMS).

A bot or similar is still needed with this approach to allow the customer to send messages to new JIDs that it has never received a message from.

Full SMS-to-SMS example

I will detail a full SMS-to-SMS example to show how this existing use case is indeed supported by this approach without really needed to explicitly coded for. Note also that in the example below if you cut off the beginning and end and messages just come from/to a non-transport JID that enables the goal use case of having an SMS user get access to messages to/from any arbitrary JID in a seamless fashion.

SMS-only sender: +15550001111 "External" sopranica number: +15553331234 "Internal" sopranica number: +155551114321 "Map table"/"Pool" sopranica number that will be used: +15557770000 Relevant XEP: https://xmpp.org/extensions/xep-0106.html

  1. User on the SMS network sends a message from +15550001111 to +15553331234 (our customer's public-facing sopranica number)
  2. VoIP-provider-specific transport (from Phase 1) is notified of the new message and relays to the registered JID for that account, which is +15551114321\5c40cheogram.com\40mux.soprani.ca@cheogram.com
  3. Cheogram, acting as in its normal function as "metagateway", relays the inbound message to the upstream JID, which is +15551114321\40cheogram.com@mux.soprani.ca -- it also rewrites the from JID to +15550001111@cheogram.com
  4. Mux checks if +15551114321@cheogram.com is a customer -- it is, so we can continue instead of returning an error
  5. Mux sees no tuple in the database for (+15550001111@cheogram.com, +15551114321@cheogram.com) so selects new route pool-sms-1 from the pool and stores it with the tuple
  6. Mux relays stanza to +15551114321@cheogram.com, rewriting the from JID to pool-sms-1@mux.soprani.ca (the JID that has previously registered as the owner of the DID from the pool)
  7. Cheogram checks if the sender has a route configured, and acting in its normal function as "metagateway" relays the message to that route, in this case relaying to +15551114321@some-gateway.soprani.ca and rewriting the from JID to pool-sms-1\40mux.soprani.ca@cheogram.com

  8. The VoiP-provider-specific transport gets this message and relays over SMS through the associated DID (+15557770000) to the target phone number (+15551114321)

  9. Customer receives this SMS and then sends a reply. That is, an SMS is sent from +15551114321 to +15557770000
  10. VoIP-provider-specific transport (from Phase 1) is notified of the new message and relays to the registered JID for that account, which is pool-sms-1\40mux.soprani.ca@cheogram.com
  11. Cheogram, acting as in its normal function as "metagateway", relays the inbound message to the upstream JID, which is pool-sms-1@mux.soprani.ca -- it also rewrites the from JID to +15551114321@cheogram.com
  12. Mux checks the tuples associated with pool-sms-1 for a target of +15551114321@cheogram.com and finds one (since it was stored in step 5 of section 1)
  13. Mux relays stanza to +15550001111@cheogram.com (since it is the other half of the tuple), rewriting the from JID to +15551114321\40cheogram.com@mux.soprani.ca
  14. Cheogram checks if the sender has a route configured, and acting in its normal function as "metagateway" relays the message to that route, in this case relaying to +15550001111@some-gateway.soprani.ca and rewriting the from JID to +15551114321\5c40cheogram.com\40mux.soprani.ca@cheogram.com
  15. The VoiP-provider-specific transport gets this message and relays over SMS through the associated DID (+15553331234) to the target phone number (+15550001111)
ossguy commented 7 years ago

So I remember when I read this again, here is a Soprani.ca parlance translation of the above: