Progress on the GSM network at FreeCalypso HQ

[Mychaela Falconia]

Hi Denver,

> If one is concerned about group texting, for example,
> then BulkVS probably won't suffice.

What "they" (my philosophical enemies) call "group texting", I call
SMS abuse.  AFAIK there is no straightforward way to block it outright
- after all, a GSM User Equipment implementation may offer the option
of defining a group list in the UI and then sending a message to
everyone on that list - but unless I am badly mistaken somewhere, to
the GSM network this operation would look indistinguishable from a
very fast user manually sending the same message text to multiple
recipients, with each SMS-PP being a separate transaction.  However,
if my Themyscira Wireless operation ever expands to providing services
to untrusted general public (as opposed to family members only) - and
that's a very very big *if* - in that case, if I catch someone
engaging in such SMS abuse, I will promptly terminate their service
for cause.

> 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?

> 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?

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

> 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?

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.

> (not to mention likely inappropriate if you're not a business sending
> transactional messages).

This is my main point, more than the cost - my ThemWi GSM subscribers
(initially only family members, then *maybe* much much later general
public in my very limited local area) are human end users, not
businesses doing transactional SMS, and they need to be classified
correctly.

> 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.

2) In our own FreeCalypso GSM handset implementation, i.e., FC
Tourmaline firmware, there will also be MMS "blocking" in the sense of
not having MMS functionality included in the fw.  Pirelli's firmware
behaves so badly upon receiving MMS because it _does_ include an MMS
functional component, with no way for the user to disable it - thus
having it disabled at firmware build time will be a major improvement.

> 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.

M~