ensuite, très étonnant d'avoir un cas de facturation de sms, sur frnog ils martèlent qu'un opérateur ne peut pas facturer de sms reçu (pas mms, mais bien sms) à l'abonné, car contrairement au MMS en désactivant les données cellulaires, et au téléphone où il suffit de ne pas décrocher, le SMS, l'abonné n'a pas le choix que de le recevoir.

le problème du RCS, c'est qu'il demande une intégration applicative partout, alors qu'il y avait déjà un standard : xmpp pour les messages (et gère aussi la voix/visio), et sip pour la téléphonie (socle du volte/vowifi)

Frnog c'est pas vraiment pertinent en téléphonie mobile (y'a genre un message/an qui n'est pas de l'enfonçage de porte ouverte concernant la téléphonie mobile), après le 3gpp c'est un écosystème qui a beaucoup évolué en vase clos et qui reste assez isolé vis à vis du reste des télécoms et d'autre standard. Concernant Frnog je me permets d'ajouter que c'est quand même devenu très léger techniquement. Et donc au sujet du billing de messages entrants c'est n'importe quoi ce constat comme quoi ça serait pas supporté, c'est supporté depuis toujours, je vous déterre la PR d'Ericsson de 1999 sur la dispo de la feature en temps réel https://news.cision.com/ericsson/r/ericsson-first-with-real-time-charging-for-text-messages-for-pre-paid-users,c14827 :

By allowing GSM pre-paid subscribers' accounts to be debited in real-time - as they send, or receive, text messages on their mobile phones -

Après je le concède le SA5 (System Architecture workgroup 5 "Management, Orchestration and Charging" https://www.3gpp.org/3gpp-groups/service-system-aspects-sa/sa-wg5) c'est le summum de la chiantitude au 3GPP, mais bon les affirmations du genre la réception des SMS ne peut pas être facturée c'est juste une méconnaissance de la facturation dans le monde 3GPP, TS 32.274 clause 5.1.3 :

The following service level events shall, based on operator configuration, trigger the generation of charging
information:
- Simple submission, except for device triggering – based on reception at the SMS node.
- Enhanced submission – based on completion of the transaction handling at the SMS node.
- Origination retry – based on the enhanced submission where the initial handling fails and a redelivery attempt is
initiated.
- Delivery, except for device triggering – based on delivery from the SMS node.
- Delivery report – reports based on the delivery to Person.
- Termination – Application to Person scenario only.
- Termination retry – Application to Person scenario only – reattempt delivery of an SM to a terminating entity;
- SM Service request.
- SMS via T4 related events specified in clause 5.1.4

Du coup n'importe quel solution de billing qui supporte le 3gpp peut facturer des sms entrants.

Après concernant la non utilisation du standard XMPP, je suis d'accord que ca aurait été une bonne idée de l'adopter, tout en gardant en tête que le RCS est essentiellement basé sur des specs de l'OMA, donc ils n'ont pas non plus réinventé un nouveau truc from scratch. Après de toute façon si ça n'a pas été adopté c'est que c'etait trop loin de l'approche 3gpp et beaucoup trop porté sur les couches applicatives, si ça avait décollé je suis certain que les implémentations aurait finies dans la baseband et downstream des messages via le RIL par le même datapath que les SMS et donc le fait d'avoir un protocole ouvert n'aurait pas changé grand chose, on se serait probablement retrouvé exactement dans le cas de RoHC avec un truc "issu des standards" mais complètement noyé dans la stack 3gpp. Donc au final selon moi c'est vraiment une considération accessoire la non utilisation de XMPP, on est plus dans la feature qui avait peu d'intérêt, trop à la marge du 3gpp et qui tombait au mauvais moment.