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~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community