Progress on the GSM network at FreeCalypso HQ

[Denver Gingerich]

On Tue, May 10, 2022 at 04:26:43PM -0800, Mychaela Falconia wrote:
> > Having tested a lot of different VoIP providers claiming to support SMS, I
> > would just caution anyone using a new service to test for the full set of
> < ASCII characters and ideally some non-ASCII UTF-8 if you care about such
> > things, since many providers will silently ignore and/or convert to spaces
> > any characters that aren't in the GSM 7-bit default alphabet (per
> > https://en.wikipedia.org/wiki/GSM_03.38 ) rather than upgrading to UCS-2.
> 
> Can one get "raw" access to SMS PDUs, without any "user-friendly"
> transcoding?  Consider, for example, the case of an AT&T subscriber
> exchanging SMS with a T-Mobile subscriber - surely the two carriers'
> SMSCs exchange raw SMS PDUs between each other?  If Alice on AT&T
> sends SMS to Bob on T-Mobile, doesn't it pass through transparently?
> Transparently meaning that if Bob sent GSM 03.38, then Alice will
> receive GSM 03.38, if Bob sent UCS-2, then Alice will receive UCS-2,
> and if Bob sent a badly malformed SMS, then Alice would receive all
> that badness as-is - or does it not work that way?

There are some carriers that will let you send SMS PDUs, if I understand what you mean.  Normally this is done via SMPP.  The carrier that we at JMP use (Bandwidth) has given us SMPP access, and we could setup a test environment for you if you're interested in seeing if it does what you want.

I believe most carriers offering SMPP expected a certain minimum spend (my understanding is that Bandwidth's minimum spend is currently $1,000/month).  However, I did find one reseller that has more reasonable rates who claims SMPP support, and even mentions how PDUs should be written in its help page:

  https://wiki.voip.ms/article/SMPP

Now I don't know for sure if VoIP.ms will transmit your SMS PDU unadulterated to the next hop carrier(s) - this may require some testing.  I know that Bandwidth makes at least one edit to passed-on messages, but the one I'm aware of is for MM4 (used for MMS) not for SMPP (SMS).  So it may be that you get the behavior you want with Bandwidth.  But testing would be required.

> > And be especially careful about whether the provider supports P2P routes
> > or only A2P
> 
> Here is what BulkVS says on this matter:
> 
> https://www.bulkvs.com/faqs/messaging-P2P_A2P.html
> 
> For my use case, what I really need is P2P: if I take one of the
> numbers I got from the bulk provider and assign that number to an
> individual subscriber on my Themyscira Wireless service, that
> subscriber is a human end user, not a business application, and they
> need to have the same SMS-PP experience as they would on AT&T or
> T-Mobile etc.  That's P2P, right?

Yes, that is P2P.

> If BulkVS only offers A2P and not P2P SMS, then their service won't
> work for my use case - or am I missing something?

No, you are correct.  And if you need to send raw SMS PDUs I don't think they would work either.  There is another carrier/reseller I know that does do P2P (aside from Bandwidth), but I don't believe they support SMPP.  Let me know if they are still of interest and I can try to find it for you.

> > it is hard to find the former,
> 
> Are you saying that your JMP service is the only viable SMS P2P
> provider in the world?  Or are there any others who don't require
> getting into Jabber and who would be easier to interface with a GSM
> SMSC such as the one built into OsmoMSC?

Well I don't know off-hand of any other carriers aside from the one we use that support P2P SMS over SMPP.  My guess is that most will have a high minimum spend.  If that's no object, you may want to inquire at Level 3 or other carriers similar to Bandwidth.

> Cost is not really an issue, I would be willing to pay fair prices, I
> just need a service that is friendly to interfacing _my own server_ to
> it, rather than something that is targeted to end consumers only.

Yes, anyone offering P2P SMS over SMPP is going to let you do the interfacing you want, and is not targeted toward end consumers.

> > Sadly, I don't think "blocking" is possible.
> > Rather, senders' MMS will just silently fail to get to you.
> 
> The latter counts as blocking for me - having MMS silently fail to
> hit the intended victim^H^H^H^H^H^Hrecipient will be infinitely better
> than inflicting catastrophic damage on the receiving phone - and the
> latter is what happens currently with the combination of extant
> T-Mobile GSM service and Pirelli DP-L10 handset firmware.  When I
> speak of "blocking" MMS, I speak of blocking _that_ damage scenario.
> I am going to block it on two levels:
> 
> 1) In my Themyscira Wireless GSM network implementation, not provide
> and not implement any MMS functionality at all.  There will be no MMS
> server on ThemWi (thus hopefully no way for any ThemWi subscriber to
> originate MMS, if I ever open the service to untrusted users), there
> won't be any network entity sending SMS-encapsulated WAP push messages
> (the part that inflicts damage on phones) to ThemWi subscribers, and
> whatever gateway processes I implement for interfacing to the outside
> world (PSTN), those gateway processes will only handle calls and SMS -
> no MMS.

My understanding is that this is relatively easy to achieve - you simply run an SMPP server and no MM4 server and you won't get any MMS then.

> > I suppose you could write a bot that replies to MMS with an SMS that says
> > "this number does not support MMS"
> 
> A bot like this would be nice, but I would need to put some upper bound
> on the effort to implement one.  If implementing such a bot would
> require implementing full MMS Rx functionality first, then it will
> probably be a no-go.

Yeah, it depends on how you end up configuring things.  You could theoretically set your MMS to be delivered via simple XML/JSON to an HTTP endpoint of yours, and reply with a simple XML/JSON response that indicates the SMS to be delivered back (while having incoming SMS go to your SMPP server).  I don't know for sure if this works as I expect with Bandwidth, but the control panel suggests it might.

Denver
https://jmp.chat/