Bla

SOCIETE NATIONALE DES TELECOMMUNICATIONS

(TUNISIE TELECOM)

---------°°°°°°-----------

CONSULTATION N°…

POUR

LA FOURNITURE, L’INSTALLATION, LE TEST ET LA MISE EN

PLACE D’UNE PLATE-FORME RING BACK TONE

POUR LES ABONNES AU RESEAU MOBILE

DE TUNISIE TELECOM

CAHIER DES CLAUSES TECHNIQUES

SOMMAIRE

CHAPITRE I : Généralités ............................................................................................................. 5
1. Objet .......................................................................................................................................................................... 5
2. Portée de la commande ............................................................................................................................ 5
3. Conditions générales ................................................................................................................................................ 5

CHAPITRE II : MODELE DE PAIEMENT, ETATS D’ABONNES RBT, ETATS TONALITE RBT.....8

1. Modèle de paiement ......................................................................................................................................................... 8
2. Etats d’une tonalité RBT................................................................................................................................................. 8
2.1 Tonalité en instance .................................................................................................................................................. 8
2.2 Tonalité rejetées ........................................................................................................................................................ 8
2.3 Tonalités approuvées ................................................................................................................................................ 8
3. Périodes de validité d’une tonalité RBT ........................................................................................................................ 8
3.1 Période de validité absolue (date limite de droit d’utilisation d’une tonalité RBT) ........................................... 8
3.2 Période de validité relative d’une tonalité RBT ..................................................................................................... 8
4.Etats d'un abonné RBT…………………………………………………………………………………………………11
4.1 Abonné RBT actif ..................................................................................................................................................... 9
4.2 Abonné RBT suspendu............................................................................................................................................. 9
4.3 Abonné RBT désactivé ............................................................................................................................................. 9
4.4 Abonné RBT désinscrit du service .......................................................................................................................... 9

CHAPITRE III : FONCTIONNALITES DU SERVICE RBT ..................................................................... 11
I. Fonctionnalités dédiées aux abonnés résidentiels ................................................................................................ 11
II. Fonctionnalités dédiées aux administrateurs RBT de l’entreprise (RBT corporate) ....................................... 15
III. Fonctionnalités dédiées à l’administrateur de la plate-forme RBT ................................................................... 16
IV. Fonctionnalités réservées au fournisseur de contenu .......................................................................................... 18
V. Fonctionnalités réservées au service Customer Care .......................................................................................... 19

CHAPITRE IV : INTERFACES UTILISATEURS ...................................................................................... 21
1. Interface Web ........................................................................................................................................................... 21
2. Interface WAP .......................................................................................................................................................... 22
3. Interface SMS ........................................................................................................................................................... 22
4. Interfaces USSD ....................................................................................................................................................... 23
5. Interface IVR ............................................................................................................................................................ 23

CHAPITRE V : TAXATION ET FACTURATION DU SERVICE RBT ................................................... 26
1. Conditions générales ................................................................................................................................................ 26
2. Taxation/facturation des abonnés RBT résidentiels mobiles................................................................................ 26
2.1 Cas des abonnés prépayés........................................................................................................................................ 27
2.2 Cas des abonnés post-payés ..................................................................................................................................... 27
3. Facturation des abonnés Corporate mobiles ......................................................................................................... 27

CHAPITRE VI : ARCHITECTURE ET INTERFACES DE LA PLATE-FORME RBT ......................... 29
1. Composants de la plate-forme RBT ........................................................................................................................ 29
2. Architecture d’intégration, Interfaces et Interfonctionnement ............................................................................ 31
2.1 Architecture ............................................................................................................................................................. 31
2.2 Interfaces avec les différents nœuds du réseau de Tunisie Télécom ................................................................... 31
3. Logique d’un appel RBT .......................................................................................................................................... 32
3.1 Cas d’un appel entrant vers un abonné ON-NET mobile ................................................................................... 32
3.2 Cas où l’appelé B active le service de transfert d’appel ...................................................................................... 33
3.3 Cas où l’appelé B active le service double appel (ou appel en attente) .............................................................. 33
4. Dimensionnement ...................................................................................................................................................... 33
5. Redondance ............................................................................................................................................................... 34
6. Capacité sur les interfaces ........................................................................................................................................ 34

7. Interfaces TCP/IP ..................................................................................................................................................... 35
8. Sécurité du Système .................................................................................................................................................. 35

CHAPITRE VII : EXPLOITATION, ADMINISTRATION ET MAINTENANCE .................................. 36
1. Gestion et maintenance de la plate-forme RBT ...................................................................................................... 36
2. Fonction de Gestion .................................................................................................................................................. 36
3. Equipements de gestion et de maintenance............................................................................................................. 39
4. Fiabilité ...................................................................................................................................................................... 40
5. Disponibilité générale ............................................................................................................................................... 41

CHAPITRE VIII : PRESTATIONS .............................................................................................................. 42
1. Prestations d’installation et de mise en service....................................................................................................... 42
2. Documentation .......................................................................................................................................................... 42
3. Formation .................................................................................................................................................................. 43
4. Assistance technique……………………………………………………………………………………………….. 47
5. Assistance commerciale ............................................................................................................................................ 46
6. Maintenance et pièces de rechanges ........................................................................................................................ 46
7. Planning de mise en service ...................................................................................................................................... 47
8. Climatisation ............................................................................................................................................................. 47
9. Tableau de conformité .............................................................................................................................................. 47

LISTE DES ABBRÉVIATIONS
Abonné A L’Abonné qui émet l’appel, ou qui initie un acte
Abonné B L’Abonné destinataire de l’appel ou récepteur de l’acte
ASN.1 Abstract Syntax Notation One
ATM Asynchronous Transfert Mode
CDR Call Detail Record
Diameter Diameter est un protocole de base destiné à fournir une plate-forme AAA
EMM Ericsson Multi Mediation
ETSI European Telecommunications Standards Institute
GIF Graphic Interchange Format
GSM Global System for Mobile communications
JPEG Joint Photographic Experts Group
HLR Home Location Register
INAP Intelligent Network Application Part
INS Intelligent system
IMSI International Mobile Subscriber Identity
IP Internet Protocol
ISUP ISDN User Part
IVR Interactive Voice Response
MAP Mobile Application Part
MIB Management Information Base
MSISDN Mobile Subscriber Integrated Services Digital Network Number
MSS Mobile Soft Switch
MPEG Moving Picture Experts Group,
NGN Next Generation Network
OSS Operation Sub System
PGS Personalized Greeting Service
RI Réseau Intelligent
RBT Ring Back Tone
SMPP Short Message Peer to Peer Protocol
SMSC Short Message Service Center
TCP/IP Transmission Control Protocol over Internet Protocol
USSD Unstructured Supplementary Service Data
VAS Value Added Services
VXML Voice XML
WAP Wireless Application Protocol

CHAPITRE I : GENERALITES

1. Objet
La présente consultation a pour objet la fourniture, l’installation, le test et la mise en place d’une plateforme
Ring Back Tone (RBT) pour les abonnés prépayés, post payés au réseau mobile ainsi qu’aux abonnés
en roaming de Tunisie Télécom.
Le présent cahier des spécifications techniques définit les exigences d’ordre technique et fonctionnel de
Tunisie Télécom quant aux fournitures et prestations attendues du soumissionnaire.
2. Portée de la commande
Tunisie Télécom se propose d’acquérir une plate-forme RBT permettant aux abonnés prépayés, post-payés,
résidentiels et Corporate au réseau mobile de Tunisie Télécom ainsi qu’aux abonnés mobiles en roaming de
bénéficier du service Ring Back Tone (RBT).
La solution proposée doit être capable de s’intégrer au réseau de Tunisie Télécom dans ses différentes
phases à savoir, TDM, phase transitoire TDM-NGN et 100% NGN.
La plateforme RBT doit être capable de s’interfacer au réseau Mobile actuel de Tunisie Télécom via SS7 et
avec le réseau NGN mobile de Tunisie Télécom via SIGTRAN.
A cet effet, le soumissionnaire doit proposer une offre financière et technique complète (architecture, listes
de matériels, licences de services, licences logicielles, prestations, délai de réalisation, etc.) tels que définis
dans le présent cahier des charges et ce, conformément à la méthode d’implémentation « IN-Based sans
tromboning ».
Le programme d’équipements et prestations, objet du présent marché, porte notamment sur:
 La fourniture du matériel et des logiciels,
 La fourniture des licences de service RBT et Multimédia RBT,
 L’installation et la configuration du système,
 L’installation et le paramétrage des logiciels,
 L’installation et l’activation des fonctionnalités,
 La gestion et la maintenance des services,
 Le support technique,
 L’intégration et l’adaptation avec le réseau existant de TUNISIE TÉLÉCOM,
 La cohabitation des solutions RBT proposées à la fois dans un environnement TDM et NGN
 La Migration de la solution du TDM vers NGN
 La formation du personnel de TUNISIE TÉLÉCOM,
 Les prestations d’installation, de test, de réception et de mise en service ainsi que toutes les
sujétions nécessaires au bon fonctionnement du réseau.
 Les prestations d’assistance technique et commerciale.
 La maintenance des équipements de la plateforme fournie.

3. Conditions générales
3.1 Généralités
1. Tunisie Télécom entend acquérir des systèmes complets, suffisamment dimensionnés et en service.
2. Le système attendu doit être une solution complète et clé en main.
3. Le système proposé doit être, à la date limite de remise de l’offre, disponible, testé et commercialisé.
4. Toute fonctionnalité ou caractéristique demandée dans ce document doit être offerte et supportée par le
système proposé tel qu’ils seront fourni en cas d’adjudication indépendamment du fait que cette
fonctionnalité ou cette caractéristique soit « de base » ou « optionnelle » vis-à-vis du soumissionnaire.
Consultation N°… pour l’installation, le test et la mise en place d’une plateforme RBT 5

5. Le soumissionnaire donnera toutes les spécifications, marques, caractéristiques techniques et
mécaniques ainsi que la documentation complète de tous les équipements, matériels ou logiciels proposés
dans son offre.
6. Le système proposé doit être modulaire. A cet effet, le soumissionnaire est tenu à indiquer la position,
le rôle et la réalisation des entités physiques (architecture matérielle de la solution) ainsi qu’à identifier les
différents modules logiciels composant le système proposé.
7. Tout oubli d’un élément quelconque nécessaire au bon fonctionnement du système sera pris en charge
par le soumissionnaire.
8. Tout équipement, matériel ou logiciel nécessaire au fonctionnement, à l’exploitation, à la surveillance,
à la maintenance et à la gestion des systèmes proposés dans les meilleures conditions doit être inclus dans
l’offre.
9. Tunisie Télécom ne fournira, dans le cadre de ce projet, que les liens de transmission, les lignes Frame
Relay, les lignes téléphoniques ou lignes spécialisées, l’accès VPN et la connectivité IP, au cas où ils sont
disponibles, l’énergie primaire sous la forme de la basse tension triphasée 220/380V 50 Hz plus ou moins
10% et 5% respectivement ainsi que la climatisation de la salle qui abritera la plate-forme RBT.
10. L’installation, le fonctionnement, le test et la mise en service des systèmes proposés ne doivent en
aucun cas perturber le fonctionnement des équipements du réseau de Tunisie Télécom en service.
11. Dans le cas d’extensions éventuelles, correction et/ou des changements de configuration seraient
bénéfiques à Tunisie Télécom, le soumissionnaire est dans l’obligation d’en informer Tunisie Télécom tout
en précisant les effets de ces changements sur la qualité et la continuité du service. Avant chaque extension
ou correction et/ou changement, une documentation complète doit être fournie à Tunisie Télécom pour
convenir au travail à effectuer.
12. La modification des fonctionnalités existantes et l’introduction de nouvelles fonctionnalités doivent être
possibles sans aucun changement dans l’architecture et la structure du système et sans perturbation majeure
du service.
13. Le soumissionnaire doit indiquer clairement la politique de sécurité réseau adoptée pour assurer la
protection du réseau de son système contre les attaques et les intrusions extérieures. Il doit fournir à Tunisie
Télécom l’architecture détaillée du réseau de son système. Toute modification ultérieure du réseau doit
s’accompagner d’une modification du document.
14. Le soumissionnaire doit détailler pour chaque entité du système les paramètres décrivant les conditions
d’environnement (température, humidité, pression, résistance aux vibrations).
15. La plate-forme proposée doit supporter au moins la langue arabe, la langue française et la langue
anglaise dans les caractères des messages courts de notification.
16. La solution RBT proposée doit être implémentée selon la méthode « IN- Based sans tromboning » se
basant sur
 le composant PGS/INS d’Ericsson intégrable sur le réseau intelligent mobile de Tunisie Télécom
 une plate-forme de gestion de contenu RBT.
Toute la documentation relative à la solution proposée doit être présentée à l’appui.
17. Il appartient au soumissionnaire de prendre toutes les dispositions nécessaires (techniques et
financières) à la connexion des équipements proposés au réseau mobile de Tunisie Télécom en cours
d’exploitation. Ces dispositions incluent bien entendu le fait de se procurer, d’étudier, de s’adapter aux
spécifications techniques des équipements en cours d’exploitation.
18. Le système proposé doit être capable de s’interconnecter à un réseau 3G ou à un réseau conforme 3GPP
R4 et ce, sans changement de matériels. Le soumissionnaire doit indiquer clairement les actions à
entreprendre afin d’assurer cette interconnexion.
19. La plate-forme RBT proposée doit être capable de fonctionner sur un environnement hybride TDM et
NGN et ce, pendant la phase de migration du réseau mobile de Tunisie Télécom vers NGNs. Durant cette

phase aucune dégradation de la performance du service et des fonctionnalités existantes n’est tolérée.
L’architecture d’intégration de la solution proposée dans le réseau de Tunisie Télécom pendant la phase de
migration vers NGN doit être conforme à l’Annexe 3.
20. Le soumissionnaire s’engage à fournir les dernières versions opérationnelles à la date de livraison pour
les logiciels indépendamment des versions mentionnées dans l’annexe technique de sa soumission et ce, sur
la base des prix contractuels. Le soumissionnaire prendra à sa charge toutes les modifications résultant du
changement de la version logicielle.
21. Le système proposé doit être extensible vers des capacités plus importantes et ce, sans rajout de
matériel (uniquement augmentation en droit d’usage).
22. Le soumissionnaire doit détailler clairement les possibilités d’extension de la plate-forme proposée
ainsi que les modifications qu’il serait appelé à effectuer sur le système proposé, et ce, sur la base d’une
documentation complète fournie à TUNISIE TELECOM décrivant clairement les principes et les
procédures à appliquer pour convenir au travail à effectuer.
23. Le soumissionnaire doit présenter le roadmap de développement des nouvelles fonctionnalités de son
système ainsi que celles relatives aux évolutions matérielles, logicielles ou d’architecture, ou encore aux
évolutions des interfaces.
24. Dans le cas particulier où le soumissionnaire prévoit une modification matérielle, logicielle, de
prestation ou d’architecture intervenant dans les deux premières années d’exploitation de la plate-forme, il
fournira dans son offre une documentation spécifique à cette évolution, tout en précisant son impact sur
l’ancienne génération et les modifications à apporter pour sa mise à niveau.
3.2 Références aux normes internationales et protocoles supportés
1. La solution proposée doit être conforme à toutes les spécifications techniques de l’ETSI qui lui sont
applicables et les recommandations de l’UIT relatives à la signalisation SS7 (livre bleu 1989 et blanc
1993). Dans ce document, les références à des recommandations, des avis, des prescriptions ou des
spécifications concernent toujours les dernières versions en vigueur.
2. La solution proposée doit être conforme à toutes les recommandations de l’IETF (RFC 2719) relative au
transport de la signalisation au dessus de l’IP (SIGTRAN).
3. La solution proposée doit supporter l’intégration à un réseau conforme 3GPP R99 et 3GPP R4 relatives
à la spécification de la norme UMTS 3G.
Et ce, sans changement de matériel. Le soumissionnaire doit indiquer clairement les actions à entreprendre
pour assurer cette intégration.
4. La plateforme proposée doit supporter au moins les codecs audio suivants : G711, G722, G723, G726,
G729, AMR, Alaw, μlaw.
5. La plateforme proposée doit supporter au moins les formats image suivants : JPEG, GIF
6. La plateforme proposée doit supporter au moins les codecs vidéo suivants : MPEG4, H.263 et H.264


CHAPITRE II : MODELE DE PAIEMENT, ETATS D’ABONNES
RBT, ETATS TONALITE RBT

1. Modèle de paiement
1.1. La plate-forme RBT doit permettre à l’administrateur du système de configurer d’une manière flexible
le modèle de paiement à adopter (service RBT avec ou sans frais fixes d’activation du service, frais de
téléchargement de tonalité RBT avec ou sans période de validité, etc.).
1.2. La plate-forme de gestion de contenu RBT doit permettre à l’administrateur du système de définir
différents modèles de paiement et ce, selon le type des abonnés mobiles cibles (résidentiels TT, ou
corporate TT, abonnés en roaming.), et en fonction de leurs modes de paiement (prépayés ou post-payés).
1.3. A cet effet, le soumissionnaire doit fournir toute la documentation possible relative à la définition des
différents modèles de paiement ainsi que le cycle de vie des abonnés RBT associé à chaque modèle de
paiement.

2. Etats d’une tonalité RBT
Toutes les tonalités chargées sur le système doivent être soumises à un processus d’approbation dont le
principe est explicité en détail dans le chapitre III, paragraphe III.4 du présent cahier des charges. Le
processus d’approbation fait ressortir les 3 états de tonalités suivants :
2.1 Tonalité en instance
2.1.1 Une tonalité en instance est une tonalité qui a été téléchargée par le fournisseur de contenu sur le
système (upload) et devra être approuvée ou désapprouvée par l’administrateur de la plate-forme.
2.1.2 Pendant cette phase de suspension, le fournisseur de contenu n’a pas le droit d’accéder à ces tonalités.
A cet état, l’administrateur peut approuver ou rejeter la tonalité. Le fournisseur de contenu est alors notifié
par é-mail, ou par SMS de la décision de l’administrateur.
2.2 Tonalité rejetées
Une tonalité rejetée est une tonalité non approuvée par l’administrateur et par la suite, elle ne sera pas
publiée sur la plate-forme.
2.3 Tonalités approuvées
Une tonalité approuvée est une tonalité acceptée par l’administrateur et prête à être publiée sur le système
et par la suite utilisée.
3. Périodes de validité d’une tonalité RBT
Le système proposé doit définir deux types de périodes de validité des tonalités RBT :
4.1 Période de validité absolue (date limite de droit d’utilisation d’une tonalité RBT)
i. Chaque tonalité RBT publiée sur le système doit avoir une date de fin des droits d’utilisation.
ii. La date de fin des droits d’utilisation fait l’objet d’un accord entre l’administrateur de la plate-forme
et le fournisseur de contenu.
iii. A l’issu de cette date, le contenu ne sera plus disponible sur les canaux d'accès au service exigé par
le présent cahier des charges et qui sont : Web, WAP, IVR, SMS et USSD.
iv. La plateforme RBT doit notifier l’administrateur par é-mail ou par SMS X jours (X paramétrable
par l’administrateur) avant l’expiration de la période de validité absolue des tonalités RBT.
4.2 Période de validité relative d’une tonalité RBT
i. C’est la période pendant laquelle une tonalité RBT peut être utilisée après son téléchargement par
l’abonné dans sa propre librairie RBT.

ii. Une fois la période de validité relative d’une tonalité RBT arrive à sa fin, la plate-forme RBT doit
être capable de notifier l’abonné (par SMS, par email) de cet évènement et que la tonalité serait
renouvelée automatiquement par le système à moins que l’abonné renonce à cette action (arrêt du
renouvellement) et ce, par l’appel d’un numéro court pour les abonnés ON-NET en local ou d’un
numéro long pour les abonnés ON-NET en roaming.
iii. Le renouvellement de sa tonalité RBT devrait être possible par les différents canaux d’accès à la
plate-forme RBT (Web, WAP, SMS, IVR et USSD)
iv. La valeur de cette durée de validité relative doit être fixée par l’administrateur de la plate-forme une
fois la tonalité est approuvée sur le système.
v. Le système ne doit rendre visible que les tonalités RBT qui puisse être utilisées pendant au moins la
période de validité relative et avant la date limite de droit d’utilisation.

4. Etats d’un abonné RBT
La plateforme proposée doit permettre à l’administrateur du système de définir le cycle de vie d’un
abonné RBT dont les états doivent être comme suit :
4.1 Abonné RBT actif
Un abonné RBT à l’état « actif » est un abonné qui peut bénéficier des fonctionnalités proposées par
la plateforme RBT (achat, offre de tonalité RBT, copie de tonalité RBT, etc.). En l’appelant, ses
contacts entendent la tonalité RBT qu’i leur a réservée.
La période pendant laquelle un abonné RBT est à l’état « actif » (période de validité du service RBT)
doit être configurable par l’administrateur du système.
La plateforme RBT doit allouer une licence d’utilisation du service RBT à chaque abonné RBT à
l’état « actif ».
4.2 Abonné RBT suspendu
Un abonné RBT « suspendu » est abonné dont la date de validité de son compte RBT a expiré et qui
n’a pas encore renouvelé le service RBT ce, durant une période de grâce (ou période de suspension)
dont la durée est configurable par l’administrateur du système.
Durant la période de grâce, l’abonné sera dépourvu de toutes les fonctionnalités RBT. En l’appelant
ses contacts entendent la tonalité traditionnelle de l’IUT.
Le profile d’un abonné RBT à l’état « suspendu » reste intacte au niveau de la plateforme RBT, et ce,
en vue de le recharger suite au renouvellement du service par l’abonné en question.
4.3 Abonné RBT désactivé
Un abonné RBT à l’état « désactivé » est un abonné actif qui a initié la suspension de fonctionnalité
de jeu de la tonalité de retour RBT pour ses appelants et ce, pendant la période de validité de son
service.
Le profile d’un abonné RBT à l’état « désactivé » reste intact au niveau de la plateforme RBT et ce,
en vue de le recharger suite à une requête de réactivation du service.
La durée maximale de sauvegarde des données d’un abonné à l’état « désactivé » doit être
configurable par l’administrateur de la plateforme RBT.
Un abonné désactivé a tout les droits de personnaliser son compte RBT et d’exécuter les
fonctionnalités RBT qui lui sont dédiées.
4.4 Abonné RBT désinscrit du service
Un abonné RBT est à l’état « désinscrit » du service RBT soit à sa demande ou soit s’il garde son état


« suspendu » jusqu’à l’expiration de sa période de grâce.
Dans ce cas, il sera désapprovisionné du système et perdra par la suite son profil ainsi tout son
historique d’usage.
Par conséquent, une licence d’utilisation du service RBT devra être libérée. Cette licence peut être
réutilisée par un autre utilisateur.


CHAPITRE III : FONCTIONNALITES DU SERVICE RBT
1. La plate-forme RBT doit fournir une panoplie de fonctionnalités de base dédiées à la fois aux
abonnés au réseau mobiles de Tunisie Télécom (résidentiels et corporate, en local et en roaming), à
l’administrateur de la plate-forme, aux fournisseurs de contenu et aux agents du service à la clientèle.
2. Toute les fonctionnalités précisées dans le présent cahier des charges doivent être fournies par la
plate-forme RBT et ce, en environnement TDM, environnement hybride (TDM et NGN) et en
environnement tout NGN.
3. Les fonctionnalités exigées par le présent cahier des charges doivent inclure au moins :
I. Fonctionnalités dédiées aux abonnés résidentiels
I.1 Souscription /désinscription au/du service
i. La plate-forme RBT doit permettre aux abonnés résidentiels au réseau mobile de Tunisie Télécom
de se souscrire au service /se désinscrire du service et ce, à travers les interfaces suivantes : l’IVR,
SMS, USSD, Web, WAP.
ii. Une fois l’abonné s’est inscrit au service RBT, la plate-forme RBT doit lui envoyer un SMS de
notification l’informant de la réussite de l’opération d’inscription.
iii. La plate-forme doit de même attribuer au nouvel inscrit au service RBT un mot de passe relatif à
son nouveau compte RBT. Ce mot de passe lui sera envoyé par SMS ou par e-mail ou lui sera
délivré par le Customer Care. Par conséquent, à chaque accès aux interfaces du service, l’abonné
RBT doit s’authentifier par la saisie de son login (son MSISDN) et son mot de passe.
iv. La plateforme doit permettre à l’abonné RBT de changer son mot de passe à tout moment et selon
ses préférences.
v. La plateforme RBT doit offrir une tonalité par défaut au nouvel abonné RBT. Initialement cette
tonalité sera attribuée à tous les appelants de cet abonné.
vi. La plate-forme RBT doit permettre à l’administrateur d’envoyer des demandes de souscription aux
abonnés via SMS. Il doit avoir la possibilité de définir la date/ l’heure, le segment d’abonnés auquel est
destinée cette demande d’inscription.
I.2 Souscription au service RBT lors du premier achat de tonalité
i. La plateforme RBT doit permettre à un abonné non encore inscrits au service RBT et qui lance une
requête d’achat de tonalité RBT via SMS/USSD/WAP/Web/IVR de s’inscrire systématiquement au
service.
ii. Dans le cas où l’abonné choisit le menu IVR comme interface d’accès au service RBT, l’abonné
payera dans ce cas, les minutes de connexion au serveur IVR de la plate-forme RBT, les frais de
souscription au service RBT ainsi que les frais d’achat de(s) tonalité(s).
I.3 Activation/désactivation du service
i. La plate-forme doit permettre à l’abonné RBT d’activer/désactiver le service RBT et ce, à travers le
menu IVR, l’interface SMS, l’interface USSD ou le portail Web, le portail WAP
ii. Les appelants d’un abonné RBT désactivé entendent la tonalité de retour classique et ce, pendant la
période de validité du service du dit abonné.
iii. Un abonné désactivé a tous les droits de personnaliser son compte RBT et d’exécuter les
fonctionnalités RBT offertes par la plate-forme RBT.
iv. Le profile d’un abonné RBT désactivé doit rester intacte au niveau de la plate-forme RBT et ce, en
vue de le recharger suite à une requête de réactivation du service.


v. La durée de sauvegarde des données d’un abonné désactivé doit être configurable par
l’administrateur du système à travers une interface WUI.
I.4 Récupération de son mot de passe
i. La plate-forme RBT doit permettre à un abonné RBT mobile ayant oublié son mot de passe de le
récupérer et ce, à la base de la fourniture de son MSISDN et de son code PIN. Pour ce faire, il peut
appeler le serveur IVR ou visiter le portail Web de Tunisie Télécom, portail WAP ou encore
contacter le service Customer Care.
ii. La plateforme RBT doit permettre à l’administrateur de configurer le nombre de tentatives de
récupération de mots de passe par jour par abonné et ce, afin d’optimiser les ressources et améliorer
l’aspect sécurité du service.
I.5 Personnalisation de sa boîte RBT
i. La plateforme RBT doit permettre à un abonné RBT mobile, à travers une interface Web de
personnaliser son compte (groupe des appelants, configuration des listes de lecture, gestion du
temps de lecture des tonalités, etc.).
ii. Chaque abonné RBT doit avoir son propre album personnel dans lequel il stocke les tonalités RBT
achetées, reçues comme cadeau ou celles attribuées automatiquement par l’opérateur.
iii. Les tonalités doivent être classées, au niveau de l’album personnel en deux catégories :
 Tonalités attribuées : la (les) tonalité(s) qui a (ont) été attribuée(s) à un appelant, à un groupe
d’appelant ou à tous les appelants.
 Tonalités non attribuées : les tonalités qui ont été achetées, reçues comme cadeau, copiées etc. et
qui n’ont pas été attribuées.

I.6 Consultation de l’historique d’usage
i. La plate-forme RBT doit permettre à un abonné RBT mobile de consulter son historique d’usage
relatif aux transactions initiées (date de souscription, titre de la tonalité RBT, numéro du
bénéficiaire du cadeau, heure de début et de fin de la transaction, durée d’exécution de
téléchargement/offre de tonalité, prix de la tonalité téléchargée, date d’expiration de la tonalité
téléchargée, etc.) et ce, à travers l’interface Web.
I.7 Exploration et achat de RBT
i. La plateforme RBT doit permettre à un abonné RBT mobile de passer en revue, faire la recherche
des tonalités RBT (par artiste, par titre, par catégorie, Top 10, etc.), pré-écouter les morceaux de
musique, etc. à travers les interfaces utilisateurs disponibles (Web/IVR) et ce, avant de lancer
l’opération d’achat de la tonalité RBT désirée.
ii. Un SMS ou un email de notification du succès ou d’échec de l’opération d’achat doit être envoyé à
l’abonné RBT mobile à la fin de la transaction.
iii. La plate-forme RBT doit informer ses abonnés mobiles des mises à jour du contenu RBT par SMS,
par e-mail ou par out call (au décrochage de l’abonné RBT, il doit entendre un message
personnalisé configuré par l’opérateur lui informant de la liste des tonalités (intitulé tonalité et nom
de l’artiste) récemment publiées sur le système) et ce, à chaque période de temps définie par
l’opérateur.

I.8 Liste de lecture des tonalités RBT
i. Les abonnés RBT mobiles doivent avoir la possibilité de créer une liste de lecture RBT qui sera
jouée d’une manière aléatoire ou séquentielle en fonction de l’appelant et/ou en fonction de la date
(semaine, mois, année) et/ou en fonction de la plage horaire de la journée.
ii. L’abonné RBT doit être capable de configurer d’une manière simple et flexible, à travers
l’interface Web, une parmi les possibilités de programmation des listes de lecture suivantes :

a. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle,
en fonction du numéro de l’appelant et en fonction de la plage horaire et ce, à une date fixée ou
encore pendant une durée bien déterminée.
b. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle
en fonction du groupe auquel appartient l’appelant et en fonction de la plage horaire et ce, à
une date fixée ou encore pendant une durée bien déterminée.
c. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle
en fonction de (s) la plage(s) horaire(s) bien déterminée(s) et ce, à une date fixée ou encore
pendant une durée bien déterminée.
d. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle
pour un appelant bien déterminé à une date fixée ou pendant une durée bien déterminée.
e. Une tonalité RBT ou un groupe de tonalités sera joué d’une manière aléatoire ou séquentielle
pour un groupe d’appelants bien déterminé à une date fixée ou pendant une durée bien
déterminée.
f. Tonalité RBT par Défaut.
I.9 Offre de tonalités RBT
i. La plate-forme RBT doit permettre à un abonné RBT mobile (A) d’offrir une tonalité RBT à un
utilisateur (B). Dans ce cas, l’abonné A doit fournir le numéro du bénéficiaire de la tonalité RBT,
l’identifiant/nom de la tonalité à offrir ainsi que la date et l’heure de l’opération de l’offre et ce, à
travers les interfaces WEB, IVR, SMS, USSD et WAP.
ii. Dans le cas où les paramètres date et heure de l’offre n’ont pas été entrées par l’abonné RBT, le
système devrait enregistrer l’acte de l’offre à la date et l’heure de sa réalisation.
iii. L’opération d’offre de tonalité RBT n’est réalisée par la plate-forme RBT que dans le cas où
l’abonné RBT A possède une balance suffisante (cas où il est prépayé) pour pouvoir offrir la
tonalité à l’abonné B.
iv. Dans le cas où l’abonné RBT A est un abonné post-payé, la plate-forme RBT doit générer à la fin
de l’opération d’offre un CDR propre à cette opération.
v. Les champs d’un CDR généré par la plateforme RBT sont précisés dans le paragraphe 2 du
chapitre V Taxation.
vi. L’acte de l’offre de tonalité RBT consiste en le payement par l’offreur (A) des frais d’achat de la
tonalité RBT à offrir pour l’abonné B ainsi que les frais fixes de souscription de l’abonné B au
service RBT (au cas où ce dernier n’est pas encore inscrit au service).
vii. La logique de l’offre de tonalité RBT doit être comme suit :
i. Si l’abonné B accepte la tonalité offerte par A, la plate-forme RBT doit tester si l’abonné B est déjà
inscrit au service ou non.
 Si l’abonné B est non encore souscrit au service RBT, la plate-forme RBT doit être capable de
l’approvisionner automatiquement sur le système.
 La plate-forme teste de même si l’offreur (A) possède le solde suffisant pour pouvoir payer à
la fois les frais d’achat de la tonalité RBT pour l’abonné B ainsi que les frais de souscription
de ce dernier au service RBT et ce, pendant la première période de l’abonnement au service.
 A la fin de la transaction d’offre de tonalité RBT avec succès, la plate-forme RBT doit
envoyer un message de notification de succès de l’opération de l’offre et de déduction du
solde à l’abonné A et un message de notification à l’abonné B lui informant du succès de la
réception du cadeau et qu’il payera les frais d’activation du service RBT dès la prochaine
période.
 L’abonné B a la possibilité de désactiver à tout moment son inscription du service RBT.


 Si l’abonné B est déjà souscrit au service RBT, la plate-forme RBT doit envoyer un message de
notification à l’abonné B lui indiquant que l’abonné A lui offre une tonalité RBT.
A la fin de la transaction d’offre de tonalité avec succès, la plate-forme RBT doit envoyer un
message de notification de succès de réception du cadeau et de déduction du solde à l’abonné A.
ii. Si l’abonné B refuse le cadeau, la plate-forme RBT doit envoyer un message de notification de
refus à l’abonné A.
viii.Les frais d’offre de tonalité RBT et éventuellement ceux d’inscription du récepteur du cadeau au
service RBT seront imputés sur la facture de l’abonné A au cas où il est post-payé. A cet effet, la
plate-forme RBT doit être capable de générer des CDRs de facturation relatifs à chaque acte initié.
I.10 Offre de service RBT
La plate-forme RBT doit permettre à un abonné RBT mobile (A) d’envoyer une invitation d’inscription au
service RBT à un utilisateur (B) qui n’est pas encore souscrit à ce service et ce, via
WEB/SMS/USSD/IVR/WAP
i. Dans le cas où l’abonné A possède une balance suffisante (A prépayé) pour pouvoir payer les frais de
souscription de l’abonné B au service RBT et ce, pendant la première période de l’abonnement au
service, la plate-forme RBT doit être capable d’approvisionner automatiquement l’abonné B sur le
système.
 A la fin de la transaction d’offre de service RBT avec succès, la plate-forme RBT doit envoyer
un message de notification de succès de réception du cadeau et de déduction du solde à
l’abonné A.
 La plate-forme RBT doit envoyer de même un message de notification à l’abonné B (message
de bienvenue au système et de nécessité de payer les frais du service dès la prochaine période).
 L’abonné B a la possibilité à tout moment de désactiver son inscription du service RBT.

ii. Dans le cas où l’abonné A est un abonné post-payé et à la fin de l’opération d’invitation au service, la
plate-forme RBT doit générer un CDR relatif à cet acte initié et l’envoyer au système de facturation
BSCS IX R2 de Tunisie Télécom.
iii. Les champs d’un CDR généré par la plateforme RBT sont précisés dans le paragraphe 2 du chapitre
V Taxation.
I.11 Copie de tonalité RBT
La plate-forme RBT doit permettre aux abonnés mobiles résidentiels de copier des tonalités RBT et ce,
conformément aux deux procédures de copie suivantes :
I.11.1 Copie lors de l’établissement d’un appel RBT
i. La plate-forme RBT doit permettre aux abonnés RBT mobiles de copier des tonalités RBT pendant la
phase d’établissement d’appel.
ii. Le principe de cette fonctionnalité doit être comme suit : Quand un abonné RBT A appelle un abonné
B RBT et avant le décroché de B, l’abonné A peut appuyer sur une touche DTMF de son téléphone et
copier par la suite la tonalité RBT assignée par l’abonné B et ce, dans son album personnel. A la fin de
la transaction de copie, la plate-forme RBT doit envoyer un SMS de notification de copie de tonalité
RBT à l’abonné A.
iii. La fonctionnalité de copie de tonalité RBT consiste en le téléchargement d’une tonalité RBT à partir
de la librairie (album RBT) de l’appelé (B) vers la librairie de l’appelant (A).
I.11.2 Copie à travers l’IVR-RBT
i. Le principe de cette fonctionnalité doit être comme suit : un abonné RBT mobile (A) peut appeler le
module IVR de la plate-forme RBT moyennant un numéro court (abonné ON-NET en local) ou un
numéro long (abonné ON-NET en roaming) et ce, pour copier une tonalité RBT à partir de la
bibliothèque d’un abonné RBT B. Pour ce faire, l’abonné (A) doit entrer le MSISDN de l’abonné (B).


Par respect de confidentialité des informations personnelles, l’abonné A ne devrait en aucun cas accéder
à la bibliothèque de tonalités de l’abonné RBT B.

II. Fonctionnalités dédiées aux administrateurs RBT de l’entreprise (RBT corporate)
i. Le service RBT corporate permet à l’entreprise d’activer et d’attribuer une tonalité spécifique à son
activité sur les lignes corporate mobiles de ses employés et ce, pendant les horaires de travail.
ii. En dehors des horaires de travail, l’abonné RBT corporate est considéré par la plate-forme dans le cas
où est provisionné sur le système RBT, comme étant un abonné RBT résidentiel mobile. Il jouit de ce
fait de toutes les fonctionnalités réservées à ce segment d’abonnés spécifiées dans le paragraphe I du
présent chapitre.
iii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise et ce, à travers un outil
d’administration disponible sur le portail Web de Tunisie Télécom de configurer plusieurs types de
tonalités RBT :

o Musical,
o Publicitaire : Mini spot Publicitaire, diffusion musicale du slogan de la société, etc.
o Infos : Flash d'infos (horaires d’ouverture, changement d’adresse, changement de numéro de
téléphone, etc.), annonce d’offres spéciales, promotions, etc.
o Messages de dédicace et de félicitations :
iv. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de charger via le Web le
contenu audio enregistré par ses soins ou par Tunisie Télécom, et l’utiliser en tant que tonalité de
retour propre à son entreprise.
v. A cet effet, la plate-forme RBT doit être capable de recevoir cet enregistrement, de le stocker
temporairement, et ce, en vue de son approbation par l’administrateur de la plateforme RBT.
vi. La plateforme RBT doit notifier l’administrateur de la plateforme RBT (par e-mail, SMS) des
nouveaux enregistrements chargés sur le système par l’administrateur de l’entreprise. A cet effet,
l’administrateur de la plateforme RBT doit être capable d’accéder à son compte et ce, en vue de les
approuver. Une fois l’enregistrement est approuvé, il sera automatiquement attribué au compte
corporate de l’administrateur de l’entreprise.

vii. L’accès à l’interface d’administration RBT doit être authentifiable via un nom d’utilisateur et un mot
de passe attribués par le système dès l’inscription au service.
viii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de changer à tout moment
via une interface WUI ses paramètres d’accès à son compte corporate.
ix. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de télécharger et de
contrôler les tonalités (musique, spot publicitaires, infos) sur les lignes téléphoniques mobiles des
employés de son entreprise par l’intermédiaire d’une interface graphique d’administration accessible à
travers le portail Web de Tunisie Télécom.
x. L’administrateur RBT de l’entreprise doit pouvoir utiliser l’outil d’administration RBT au moins
pour :
- approvisionner les abonnés RBT corporate
- approvisionner les tonalités RBT
- charger sur le système les tonalités DIY enregistrées par ses soins.
- Gérer (ajouter, supprimer, etc.) des lignes / des groupes de lignes du compte RBT.
- assigner les tonalités RBT à différents groupes d'employés différentes tonalités RBT selon
l’évènement ou la plage horaire de son choix.
- grouper certains numéros de lignes mobiles et leurs assigner les mêmes tonalités pendant des
horaires de travail bien particuliers.

xi. Le nombre maximal de tonalités RBT corporate téléchargeables par l’administrateur RBT de
l’entreprise doit être configurable par l’administrateur de la plateforme RBT.
xii. La plate-forme RBT doit permettre à l’administrateur RBT de l’entreprise de notifier par SMS ou par
e-mail ses employés des changements effectués sur leurs profils de tonalités RBT.


xiii. Un abonné RBT corporate n’a aucun accès à son compte corporate durant les plages horaires de
travail. Par conséquent, il n’a aucun droit d’attribution de tonalités ni de personnalisation de sa boîte
RBT par soi-même.
III. Fonctionnalités dédiées à l’administrateur de la plate-forme RBT
La plate-forme RBT doit fournir à l’administrateur un outil de gestion orienté Web et facile à s’interfacer
lui permettant au moins de :
- Administrer, contrôler et gérer le service RBT,
- gérer les différents intervenants sur la plate-forme (fournisseur de contenu, agent de service à la
clientèle, abonnés RBT et administrateurs RBT corporate)
- gérer les différentes tonalités publiées sur le système.
- Gérer les performances du système
Les tâches réservées à l’administrateur de la plate-forme RBT doivent être comme suit:
III.1 Gestion des comptes RBT
III.1.1 Gestion des droits
La plate-forme RBT doit être capable de créer un compte à l’administrateur du système lui allouant tous les
privilèges de gestion. Tous les comptes autres que le compte de l’administrateur du système ne peuvent
utiliser que des fonctions limitées d’administration du service.
III.1.2 Gestion des comptes des abonnés RBT
L’administrateur du système doit pouvoir créer et gérer un compte pour chaque abonné RBT mobile, et ce,
afin de lui attribuer les droits d’accès à sa propre boite RBT.
L’administrateur doit au moins pouvoir :
 Inscrire un abonné ON-NET au service RBT et ce, en lui allouant une boîte RBT personnelle.
 Désinscrire un abonné ON-NET RBT et ce, par la libération de sa boîte RBT personnelle.
 réactiver un abonné RBT
 Désactiver un abonné RBT
 Modifier les informations personnelles des abonnés RBT, etc.
III.1.3 Gestion des comptes administrateur RBT corporate
La plate-forme RBT doit permettre à l’administrateur du système de créer et de gérer les comptes des
administrateurs RBT corporate et ce, afin de leur permettre la gestion, l’administration et la configuration
des comptes des abonnés RBT corporate mobiles.
III.1.4 Gestion des comptes des fournisseurs de contenu
L’administrateur du système doit pouvoir créer et gérer un compte pour chaque fournisseur de contenu et
ce, afin de lui attribuer les droits et les restrictions d’accès au système de gestion des contenus RBT.
A chaque chargement de tonalité ou de groupe de tonalités RBT sur le système, l’administrateur doit être
informé par mail ou par SMS et ce, en vue d’approuver/refuser le contenu chargé.
III.1.5 Gestion des comptes des agents du service Customer Care
L’administrateur du système doit pouvoir créer et gérer les comptes des agents du service Customer Care
afin de leur permettre la connexion à la plate-forme RBT et ce, en vue de fournir le support client aux
abonnés du service RBT.
III.2 Gestion des fournisseurs de Contenu


La plate-forme proposée doit supporter la gestion de plusieurs fournisseurs de contenu à la fois. A cet effet,
le soumissionnaire doit indiquer le nombre maximal de fournisseurs de contenu gérables par la plate-forme
et le nombre maximal de contenus édités par Fournisseur.
III.3 Gestion des tonalités RBT
L’administrateur du système doit être capable de supprimer et modifier les tonalités et les catégories des
contenus et ce, indépendamment des fournisseurs de contenu auxquels appartiennent ces tonalités. Il a de
même le droit de fixer la période de validité relative des tonalités publiées sur le système (chansons,
enregistrement personnel (DIY), etc.)
III.4 Approbation des tonalités RBT
III.4.1 L’administrateur de la plate-forme RBT doit pouvoir :
 Approuver/refuser les tonalités RBT téléchargées par les fournisseurs de contenu
 Approuver/refuser les tonalités RBT corporate chargées par l’administrateur RBT corporate
III.4.2 Les critères d’approbation ou de rejet des tonalités RBT se basent sur la qualité de
l’enregistrement, son contenu, le débit de lecture, l’intitulé de la tonalité, l'identification de tonalité,
l'artiste, le genre musical, la taille, le format, la catégorie, la période de validité, la date limite des
droits d’utilisation, le nom du fournisseur de contenu, etc.
III.4.3 Le processus d’approbation doit ressortir 3 types de tonalités : tonalité en instance, tonalité
acceptée et tonalité rejetée comme défini dans le Chapitre II du présent cahier des charges.
III.4.4 L’administrateur du système a le droit de rejeter les tonalités jugées non conformes aux exigences
spécifiées et fournir par conséquent les justificatifs nécessaires aux fournisseurs de contenus
correspondant et ce, à la base de la fourniture d’un rapport précisant les causes de rejet des tonalités.
III.4.5 Le système doit pouvoir vérifier automatiquement, les tonalités insérées et bloquer celles jugées
non conformes aux exigences spécifiées par l’administrateur de la plate-forme.
III.5 Gestion des capacités de stockage de la plate-forme de gestion de contenu
 Cas des abonnés RBT résidentiels
La plate-forme RBT doit permettre à l’administrateur de configurer le nombre maximum de :
 tonalités RBT par album personnel.
 listes de lecture RBT par appelant
 tonalités par liste de lecture
 groupes d’appelants par abonné RBT.
 numéros d'appels par groupe d’appelants.
 Cas des abonnés RBT corporate mobile
La plate-forme RBT doit permettre à l’administrateur de configurer le nombre maximum de :
 compte RBT corporate par entreprise
 abonnés RBT corporate par compte corporate
 tonalités RBT par album corporate
 liste de lecture RBT par compte RBT corporate
 tonalités RBT par liste de lecture
 maximum de tonalités personnalisées « Do It Yourself » par compte corporate

III.6 Gestion des donnés d’usage sur la plateforme
i. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée
minimale de stockage des détails d’usage d’un abonné RBT dont notamment :
 La date et l’heure d’inscription/désinscription au/du service RBT
 La date et l’heure de l’activation/désactivation du service RBT
 La date et l’heure de passage d’un état à un autre (actif/suspendu/désactvé/désinscrit)

 Toutes les informations relatives aux transactions d’achat de tonalité RBT initiées
 Toutes les informations relatives aux transactions d’offre de tonalité RBT ou d’invitation
au service RBT.
 Toutes les informations relatives aux transactions de copie de tonalité RBT
 Les périodes de validité relative des tonalités RBT téléchargées

.
ii. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée
minimale de stockage des détails d’usage d’un administrateur RBT corporate dont notamment :
 La taille de flotte gérable
 Les tonalités téléchargées
 Les plages horaires de lecture des RBT corporate
 La date et l’heure d’achat/upload de tonalité sur le système

iii. La plate-forme RBT doit permettre à l’administrateur de la plateforme de configurer la durée
minimale de stockage des tonalités sur le système dont notamment :
 Les tonalités chargées sur le système : la date limite de droit d’utilisation des tonalités
RBT.
 Les tonalités en instance
 approuvées
 Les tonalités rejetées

IV. Fonctionnalités réservées au fournisseur de contenu
i. La plate-forme RBT doit fournir aux fournisseurs de contenu une interface WUI, leur permettant de
gérer par eux mêmes leur contenu RBT et ce, dans la limite des privilèges qui leurs seront accordés.
ii. Chaque fournisseur de contenu aura un accès sécurisé au système de gestion de contenu par le biais
d’un nom d’utilisateur et d’un mot de passe fournis par l’administrateur de la plate-forme.
IV.1 Publication des tonalités RBT
i. La plate-forme RBT doit permettre aux fournisseurs de contenu la publication des tonalités RBT à
travers des connexions sécurisées (FTPS).
ii. En accédant à l’interface de gestion de contenu WUI, le fournisseur de contenu doit entrer des
informations concernant la (les) tonalité(s) à publier à savoir : l’identifiant de la tonalité, l’intitulé de la
tonalité, le nom de l’artiste, le genre musical, la taille, le format, la date limite des droits d’utilisation,
etc.
iii. Le fournisseur de contenu doit être capable de publier son contenu sur le système par lot de tonalités.
IV.2 Suppression d’une tonalité RBT
i. La plate-forme RBT doit permettre au fournisseur de contenu de ne supprimer que les tonalités publiées
par ses soins et ce, seulement suite à l'approbation de l'administrateur de la plate-forme.
IV.3 Modification d'une tonalité RBT
i. La plate-forme RBT doit permettre au fournisseur de contenu de ne modifier que les tonalités publiées
par ses soins et ce, seulement suite à l'approbation de l'administrateur de la plate-forme.
ii. La modification d’une tonalité implique le rechargement de cette tonalité sur le système et ce, en vue
d’être approuvée par l’administrateur et par la suite être publiée.
iii. Le fournisseur de contenu peut, sans avoir l’approbation de l’administrateur de la plate-forme, modifier
seulement les tonalités qui sont en attente d’approbation ou rejetées par l’administrateur du système.
IV.4 Cacher une tonalité RBT
i. La plateforme RBT doit permettre à l’administrateur du système de rendre invisible sur le portail
Web/WAP (cas de l’IVR : supprimer l’annonce vocale correspondante) une tonalité ou un groupe de

tonalités et ce, indépendamment du fournisseur de contenu.
ii. Un fournisseur de contenu ne peut cacher que les tonalités publiées par ses soins.
iii. La tonalité dont le statu sets désormais « caché » ne peut plus être consultée ni achetée.
iv. Les abonnés qui ont déjà une tonalité à l’état « caché » dans leur album doivent pouvoir continuer à
l’utiliser jusqu’à l’expiration de sa date de validité relative.
IV.5 Restitution d’une tonalité RT
i. La plateforme RBT doit permettre à l’administrateur du système de remettre à la disposition des abonnés
une tonalité ou un groupe de tonalité dont le statut était « caché ».
ii. Le fournisseur de contenu ne peut remettre au statut « caché » que les tonalités publiées par ses soins.
V. Fonctionnalités réservées au service Customer Care
V.1 La plate-forme RBT doit offrir un outil de gestion orienté Web permettant au Customer Care
d’assister les abonnés au service RBT qui manifestent des réclamations ou des problèmes lors de leurs
utilisation du service RBT.
V.2 A chaque réclamation sur le service RBT, parvenue au système, la plate-forme RBT doit générer
un feedback indiquant la date, l’heure de la réclamation ainsi que l’identifiant de l’agent ayant résolu la
réclamation.
V.3 L’interface de service d’aide à la clientèle doit supporter les fonctionnalités suivantes :

i. La connexion authentifiée à la page Web de gestion du compte RBT de l’utilisateur final moyennant le
numéro d’appel de l’utilisateur et un numéro de session attribué automatiquement à chaque réclamation.
ii. L’accès à l’historique d’usage des abonnés incluant les détails de chaque action d’inscription, d’achat,
etc. tels que la date/heure de début et de fin de la transaction, le nom de la tonalité téléchargée, sa date
d’expiration, l’état de l’action effectuée (succès ou échec), etc.
iii. L’accès à la liste des contacts, aux tonalités assignées, à l’album personnel de l’abonné.
iv. L’approvisionnement/le désapprovisionnement des utilisateurs au/du service RBT : Cette action
consiste à l’envoi d’un message de souscription/désinscription au système d’approvisionnement de la
plate-forme.
v. La programmation d’une tonalité par défaut,
vi. L’attribution/la suppression d’une tonalité à un contact ou à un groupe de contact, suppression de
tonalité de sa librairie, etc. et ce, suite à une demande de la part de l’abonné RBT.
vii. L’offre de tonalité RBT à un autre abonné et ce, suite à une demande de la part de l’abonné RBT.
viii. L’invitation d’un abonné non RBT à s’inscrire au service. et ce, suite à une demande de la part d’un
abonné RBT.
ix. Toutes les opérations d’aide et d’assistance aux abonnés au service RBT (récupération du mot de passe
oublié, etc.)
V.4 Toutes les modifications faites par l’agent du service Customer Care sur un compte d’utilisateur
devront être enregistrées parmi l’historique d’usage de l’abonné et seront marquées par la mention
« modifiées par le service Customer Care ».

4. En plus des fonctionnalités de base du service RBT, la plate-forme RBT doit offrir d’autres
fonctionnalités dont au moins :

4.1 Tonalité hybride
i La solution proposée doit supporter en plus du jeu de la tonalité RBT, le jeu hybride de tonalité
classique (ITU Tone) et de tonalités Ring Back Tone.

ii La plateforme proposée doit permettre à l’administrateur de sélectionner le mode simple (tonalité RBT
seulement) ou hybride de jeu de la tonalité de retour.

4.2 Offre massive de tonalité RBT
i. La plate-forme RBT doit permettre l’offre massive, à titre gratuit, d’une ou de plusieurs tonalités RBT
aux abonnés RBT mobiles.
ii. La plate-forme RBT doit permettre à l’administrateur de sélectionner le segment d’abonnés cible.

4.3 Promotions
i. La plate-forme RBT doit permettre à l’administrateur de lancer des promotions sur les tonalités RBT
(exemple : premier mois d’abonnement au service offert, deux sonneries offertes pour chaque abonnement,
deux sonneries au prix d’une, etc.). Par conséquent, la plateforme doit permettre à l’administrateur de
configurer les tonalités à promouvoir, configurer les périodes de promotion, le prix des tonalités durant ces
promotions, la durée de validité promotionnelle des tonalités RBT, etc.).
ii. Le soumissionnaire doit fournir une liste de promotions susceptible à être promulguer.
iii. Les promotions doivent être disponibles sur toutes les interfaces d’accès (WEB, SMS, IVR, WAP et
USSD).

4.4 Classe de service des abonnés RBT
i. La plateforme RBT doit permettre à l’administrateur de la plateforme d’offrir des
fonctionnalités/configurations propres à chaque classe d’abonnés mobile.
ii. La classification des abonnés RBT doit être conforme à celle (classes de service) au niveau de l’IN
mobile de Tunisie Télécom. La synchronisation de ces classes de service doit être via le protocole Diameter
SCAP. Le soumissionnaire se chargera d’assurer le développement nécessaire pour convenir à ce besoin.
5. Outre les fonctionnalités ci-dessus mentionnées, la plate-forme proposée doit être capable de fournir le
Multimédia RBT (vidéo-RBT, picture-RBT).
6. La plate-forme Multimédia RBT doit supporter la fonctionnalité « Vidéo RBT » ainsi que toutes les
exigences qui en découlent telles que le support des codecs Vidéo, le support des interfaces
d’interconnexion aux différents nœuds de Tunisie télécom.
7. Le soumissionnaire est tenu à préciser la liste des fonctionnalités offertes pour le service Multimédia
Ring Back Tone. Un document détaillé renfermant la liste des fonctionnalités propres au service
Multimédia RBT doit être fourni.


CHAPITRE IV : INTERFACES UTILISATEURS
La plate-forme RBT doit prévoir plusieurs canaux de communication. Les différents types d’interface qui
doivent être supportées et proposées dans la soumission sont les suivantes :
1. Interface Web
2. Interface WAP
3. Interface SMS
4. Menu IVR
5. Interface USSD
1. Interface Web
1.1 La plate-forme RBT doit permettre aux abonnés RBT mobile de Tunisie Télécom (résidentiels et
corporate) de personnaliser leur comptes RBT et ce, à travers une interface accessible à partir du portail
Web de Tunisie Télécom.
1.2 L’interface Web du service RBT doit permettre à un abonné RBT mobile résidentiels au moins de :
i. s’authentifier à chaque tentative d’accès à son compte. L’opération d’authentification doit se faire par
l’introduction du numéro MSISDN et d’un mot de passe.
ii. récupérer son mot de passe : cette facilité doit permettre à un abonné RBT mobile ayant oublié son
mot de passe de le récupérer à travers l’interface Web et ce, moyennant la fourniture de son login. Un
SMS renfermant le mot de passe oublié sera ainsi envoyé au MSISDN entré.
iii. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,
programmer les méthodes de lecture des tonalités (aléatoire, par segment de temps, par appelant ou
groupe d’appelant, etc.), supprimer des tonalités RBT de son album, supprimer des contacts de son
compte, etc.).
iv. explorer le contenu RBT (navigation et consultation des tonalités RBT disponibles dans son album
personnel ainsi que celles publiées sur le système)
v. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.
vi. Acheter des tonalités RBT
vii. Copier des tonalités RBT
viii. Offrir des tonalités RBT
ix. Inviter un abonné non RBT à se souscrire au service RBT.
1.3 Les contenus RBT doivent être présentés aux abonnés RBT résidentiels Mobile de Tunisie Télécom
accédants au portail Web de Tunisie Télécom des albums classés au moins par :
i. catégories de la tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,
fêtes spécifiques, sport, enfants, etc.).
ii. Titre de la tonalité (chanson)
iii. Les TOP 10 de la semaine
iv. Nom d’artiste
v. Les dernières tonalités publiées
vi. Les tonalités les plus souvent téléchargées
1.4 Ces types de classement doivent être disponibles à tout moment aux abonnés RBT.
1.5 L’interface de service RBT hébergée sur le site Web de Tunisie Télécom doit supporter les langues


arabe, français et anglais.
1.6 La plate-forme RBT doit permettre aux administrateurs RBT de l’entreprise de gérer, configurer les
comptes de leurs employées corporate et ce, pendant les horaires de travail à travers une interface web
(WUI) accessible via le portail WEB de Tunisie Télécom.
2. Interface WAP
2.1 La plate-forme RBT doit permettre aux abonnés RBT résidentiels au réseau mobile de Tunisie
Télécom de personnaliser leur comptes RBT et ce, à travers une interface de service consultée à
partir du portail WAP de Tunisie Télécom.
2.2 L’interface WAP du service RBT doit permettre à un abonné RBT mobile au moins de :
i. s’authentifier à chaque tentative d’accès à son compte. L’opération d’authentification doit se faire
par l’introduction d’un login (son MSISDN) et d’un mot de passe.
ii. récupérer son mot de passe : cette facilité doit permettre à un abonné RBT mobile ayant oublié son
mot de passe de le récupérer à travers l’interface WAP et ce, moyennant la fourniture de son login. Un
SMS renfermant le mot de passe oublié sera ainsi envoyé au MSISDN entré.
iii. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,
programmer les méthodes de lecture des tonalités (aléatoire, par segment de temps, par appelant ou
groupe d’appelant, etc.), supprimer des tonalités RBT de son album, supprimer des contacts de son
compte, etc.).
iv. explorer le contenu RBT (navigation et consultation des tonalités RBT disponibles dans son album
personnel ainsi que celles publiées sur le système)
v. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.
vi. Acheter des tonalités RBT
vii. Copier des tonalités RBT
viii. Offrir des tonalités RBT
ix. Inviter un abonné non RBT à se souscrire au service RBT.
2.3 Les contenus RBT doivent être présentés aux abonnés RBT accédants au portail WAP de Tunisie
Télécom en des albums classés au moins par :
i. catégories de la tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,
ii. Titre de la tonalité (chanson)
iv. Nom d’artiste
vi. Les tonalités les plus souvent téléchargées
2.4 Ces types de classement doivent être disponibles à tout moment aux abonnés RBT.
2.5 L’interface de service RBT hébergée sur le site WAP de Tunisie Télécom doit supporter les langues
arabe, français et anglais.
3. Interface SMS
3.1 La plate-forme RBT doit fournir une interface SMS permettant aux abonnés RBT mobiles
résidentiels de Tunisie Télécom au moins de :
i. S’inscrire au service RBT, avec ou sans achat de tonalité : Cette facilité inclut la demande de
confirmation envoyée à l’utilisateur via SMS. Le service ne doit pas être activé que si l’utilisateur

confirme par SMS sa demande d’inscription.
ii. Se désinscrire du service RBT : Cette facilité inclut la demande de confirmation envoyée à
l’utilisateur via SMS. Le service ne doit pas être désactivé que si l’utilisateur confirme par SMS sa
demande de désinscription.
iii. Acheter une tonalité ou plusieurs tonalités RBT : cette transaction consiste en l’envoi d’un SMS
contenant le(s) code(s) de(s) la tonalité(s) RBT à télécharger à un numéro court configurable par
l’administrateur du système pour le cas des abonnés mobiles en local. Pour le cas des abonnés en
roaming, ce message sera envoyé à un numéro long défini par l’administrateur du système.
iv. Attribuer une tonalité par défaut à tous les contacts
v. Attribuer des tonalités spécifiques à un contact ou à un groupe de contacts
vi. Offrir une tonalité RBT à un autre abonné comme cadeau
vii. Offrir le service RBT à un abonné non encore inscrit au service,
3.2 Le contenu des SMS envoyés par les abonnés à la plateforme RBT doit être configurable par
l’administrateur de la plate-forme.
3.3 Les dialogues SMS consistent en l’échange de SMS de notification de la plateforme RBT à
l’abonné RBT et des SMS de confirmation envoyés par l’abonné RBT à la plate-forme. Les messages de
notification doivent inclure au moins :
i. Les SMS de notification indiquant le mot de passe attribué par le système à l’abonné mobile et ce,
lors la création de son compte RBT.
ii. Les SMS de récupération du mot de passe oublié
iii. Les SMS de notification du risque d’expiration de la date de validité des tonalités RBT et de la
nécessité de les renouveler et ce, avant x jours (x configurable par l’administrateur) de la date
d’expiration de la période de validité relative de la tonalité en question. Ce message doit inclure des
informations sur la tonalité (date d’expiration, prix de renouvellement, méthodes de renouvellement,
etc.).
iv. Les SMS de notification de l’expiration prochaine de la validité du compte RBT. (la durée de validité
du compte RBT doit être configurable par l’administrateur de la plateforme)
v. Les SMS de notification de la réception de tonalité RBT/du service RBT comme cadeau.
4. Interfaces USSD
4.1 La plate-forme RBT devrait à travers une interface SOAP avec l’USSDC de Tunisie Télécom
permettre à un abonné RBT mobile au moins de :
i. S’inscrire au service RBT, avec ou sans achat d’une tonalité
ii. Se désinscrire du service RBT
iii. Acheter une tonalité ou plusieurs tonalités RBT
iv. Attribuer une tonalité par défaut à tous les contacts
v. Attribuer des tonalités spécifiques à un contact ou à un groupe de contacts
vi. Offrir une tonalité RBT à un autre abonné mobile.
vii. Inviter un abonné non RBT mobile à s’inscrire au service RBT.
5. Interface IVR
5.1 La plate-forme RBT doit fournir une interface IVR permettant aux abonnés RBT résidentiels
mobiles de Tunisie Télécom au moins de :
i. s’authentifier à chaque tentative d’accès à son compte par l’introduction de son login (MSISDN) et

son mot de passe.
ii. s’inscrire au service RBT, avec ou sans achat d’une tonalité
iii. se désinscrire du service RBT
iv. pré-écouter des morceaux des tonalités publiées sur le système et ce, avant confirmation d’achat.
v. acheter des tonalités RBT
vi. explorer le contenu RBT (navigation et écoute des tonalités RBT disponibles dans son album
personnel)
vii. copier des tonalités RBT
viii. offrir des tonalités RBT
ix. inviter un abonné non RBT à se souscrire au service RBT
x. explorer les tonalités disponibles sur le système
xi. personnaliser son propre compte (changer son mot de passe, choisir une tonalité par défaut,
attribuer une tonalité particulière à un contact ou à un groupe de contact, supprimer des tonalités
RBT de son album, etc.).
5.2 L’accès à l’IVR de la plate-forme RBT (IVR-RBT) doit être possible moyennant l’appel d’un
numéro court et ce, pour le cas des abonnés mobiles de Tunisie Télécom en local et moyennant l’appel
d’un numéro long pour le cas des abonnés ON-NET en roaming.
5.3 En accédant au serveur IVR- RBT, un message d’accueil au service RBT doit être joué à
l’abonné. Cette fonctionnalité peut être activée ou désactivée par l’administrateur du système.
5.4 Les contenus RBT doivent être présentés aux abonnés RBT résidentiels mobiles de Tunisie
Télécom accédants au serveur vocal de la plate-forme en des albums classés au moins par :
i. catégories de tonalité (chanson orientale, chanson occidentale, film, divertissements ; Religions,
ii. Titre de la tonalité
iv. Nom d’artiste
vi. Les tonalités les plus souvent téléchargées.
5.5 Ces types de classement doivent être disponibles à tout moment à l’abonné RBT.
5.6 Le module IVR-RBT proposé dans la solution doit être fourni avec au moins 3 langues (arabe,
français, Anglais) incluant l’ensemble des annonces statiques et dynamiques permettant d’assurer le
bon fonctionnement de l’ensemble du service RBT.
5.7 Le soumissionnaire doit s’engager à fournir le matériel et les logiciels nécessaires afin que
Tunisie Télécom puisse publier les enregistrements des nouvelles annonces statiques ainsi que
modifier celles existantes. Le soumissionnaire doit spécifier les formats des fichiers pour lesquels la
publication serait possible.
5.8 L’ensemble des ressources vocales du module IVR-RBT de la plate-forme proposée doit être
administrable. A cet effet, ce module IVR - RBT doit offrir depuis un unique centre de contrôle une
interface permettant de modifier d’une manière simple et flexible son flow : ajouter, modifier et
supprimer les annonces, afficher les alarmes, générer des fichiers logs, etc.
5.9 Le soumissionnaire est tenu à fournir toute la documentation se rapportant aux procédures de
configuration du module IVR RBT.

5.10 Toute modification introduite sur le contenu du serveur de gestion de contenu doit entrainer la
mise à jour de la librairie média (lecteur de tonalité RBT) du système ainsi que la mise à jour du
module IVR RBT. A cet effet, le soumissionnaire doit indiquer la fréquence avec laquelle les mises à
jour sont effectuées et doit fournir toute la documentation relative à la procédure de mise à jour.
5.11 Le module IVR-RBT devra supporter l’ensemble des fonctions nécessaires au bon déroulement
du service RBT. Les principales fonctions requises sont :
i. Enregistrement et lecture des annonces vocales (statiques ; dynamiques afin de jouer les chiffres
ou les dates),
ii. Demande et collecte des interactions utilisateurs (Recommandation Q23 de l’UIT relative aux
caractéristiques techniques des appareils téléphoniques à clavier),
iii. Possibilité d’interpréter des scripts VXML,
5.12 La durée moyenne d’un appel vers l’IVR-RBT ne doit pas dépasser les 100 secondes à l’heure
chargée.

Le soumissionnaire doit détailler les spécifications de l’interface permettant de s’interconnecter avec les
nœuds du réseau de Tunisie Télécom suivants : l’USSDC, le CRM et le site Web, et ce, afin d’assurer les
fonctionnalités relatives aux interfaces des nœuds ci-dessus mentionnés.
Le soumissionnaire doit fournir une XML API afin de s’interconnecter avec l’USSDC, le CRM et le site
Web de Tunisie Télécom.


CHAPITRE V : TAXATION ET FACTURATION DU SERVICE RBT
1. Conditions générales
1.1 La plate-forme RBT doit être en mesure de supporter les protocoles de taxation actuellement utilisés dans
le réseau de Tunisie Télécom et spécifiés ultérieurement.
1.2 La plateforme RBT doit envoyer Y fois /jour (Y configurable par l’administrateur du système) des SMS de
notifications aux abonnés RBT actifs pendant les X jours (X étant configurable par l’administrateur) qui
précèdent la fin de chaque période de paiement des frais (mensuel, trimestriels, semestriel, etc.) d’activation du
service RBT, informant l’abonné prépayé mobile du renouvellement automatique de son service RBT.
1.3 Si l’abonné mobile prépayé manque à l’action de renouvellement de son service à la fin de ces X jours, il
sera automatiquement suspendu et entrera par la suite dans une période de grâce dont la durée est configurable
par l’administrateur du système.
1.4 Si aucune alimentation de la balance de l’abonné n’a été constatée au bout de N vérifications/jour pendant
la période de grâce (N configurable par l’administrateur du système), l’abonné sera automatiquement
désapprovisionné de la plate-forme et perdra, dans ce cas, son profil ainsi que son historique d’usage. Un
message de notification de désinscription du service lui sera ainsi envoyé par la plateforme RBT.
1.5 La taxation et la facturation du service RBT doit être possible à l’acte initié (souscription au
service/désinscription, activation/désactivation du service, offre de tonalité RBT, etc.) et/ou à la durée de
connexion au module IVR –RBT
1.6 A cet effet, la plate-forme RBT doit :
 s’interfacer avec le RI mobile via le protocole Diameter SCAP et ce, afin de d’envoyer les paramètres
de taxation relatifs à chaque acte initié par l’abonné mobiles prépayé
 générer des CDRs relatifs à l’initiation d’un acte en format ASN.1.et les envoyer au système de
facturation BSCS IX R2 via FTP et ce, pour le cas des abonnés mobiles post-payés.
1.7 . La taxation à la durée des appels établis par les abonnés mobiles prépayés vers le module IVR –RBT via
le protocole INAP CS1+ est à la charge des MSC de Tunisie Télécom dans un environnement TDM et à la
charge des MSC-S dans le cas de la migration du réseau mobile de Tunisie Télécom vers NGN.
1.8 La facturation des appels établis par les abonnés mobiles post-payés vers le module IVR –RBT est à la
charge des MSC de Tunisie Télécom dans un environnement TDM et à la charge des MSC-S dans le cas de la
migration du réseau mobile de Tunisie Télécom vers NGN.
1.9 . La fréquence d’envoie des fichiers CDR par la plate-forme RBT doit être configurable par
l’administrateur.
1.10 La plate-forme RBT doit permettre la compression des fichiers CDRs dans un format standard (.zip ou
.rar)
1.11 La plateforme RBT proposée doit permettre le stockage des fichiers CDRs pendant au moins 3 mois.
1.12 Le nombre maximum de CDR pouvant être inclus dans un même fichier doit être configurable par
l’administrateur du système.
1.13 La plate-forme proposée doit générer des alarmes dans le cas de détection de problème dans la génération
ou lors du transfert des fichiers CDRs.
2. Taxation/facturation des abonnés RBT résidentiels mobiles
Afin de déterminer le type du compte de l’abonné RBT (abonné prépayé ou post-payé) et ce, pour des raisons
de taxation/éventuellement génération de CDR de facturation des actes initiés, la plateforme RBT doit être
capable, moyennant le protocole Diameter SCAP d’interroger le réseau Intelligent mobile sur le type de

compte de l’abonné en question. Dans le cas d’une réponse favorable du côté de l’IN mobile (ie. abonné
prépayé), la plateforme doit envoyer les paramètres de taxation précisés dans le paragrpahe 2.1 du présent
chapitre. Sinon, la plateforme doit générer des CDRs dont le contenu est précisé dans le paragrpahe 2.2 du
présent chapitre.
2.1 Cas des abonnés prépayés
i. A l’initiation d’un acte, les paramètres de taxation envoyés par la plate-forme RBT au RI mobile de
Tunisie Télécom via Diameter SCAP doivent inclure au moins :
 Le numéro de l’abonné A (MSISDN (A))
 Le numéro de l’abonné B (MSISDN (B))
 Le type de l’acte (inscription, désinscription, activation, désactivation, achat, offre de tonalité
RBT, invitation au service RBT, copie, consultation des tonalités sur le système, etc.)
 L’identifiant du contenu RBT.
 La date et l’heure (heure : minute : seconde) de l’acte

ii. La liste exhaustive des actes possibles sera arrêtée lors de la mise en place de la plateforme RBT.

2.2 Cas des abonnés post-payés
i. Les CDR générés par la plate-forme RBT suite à l’accomplissement d’un acte initié par un abonné
RBT mobile post- payé doivent contenir au moins les informations suivantes :
 Le numéro de l’abonné A (MSISDN (A))
 Le numéro de l’abonné B (MSISDN (B))
 L’IMSI de l’abonné A
 Le type de l’acte (inscription, désinscription, activation, désactivation, achat, offre de tonalité
RBT, invitation au service RBT, copie, consultation des tonalités sur le système, etc.)
 L’identifiant de la tonalité RBT
 L’interface d’accès utilisée (Web/IVR/SMS/WAP/USSD)

ii. A la fin de l’acte, la plateforme RBT doit inclure un champ dans les CDR générés relatifs à l’état de la
transaction (succès, échec.) et ce, pour des raisons de statistiques de performance du système.
iii. La liste exhaustive des actes possibles sera arrêtée lors de la mise en place de la plateforme RBT.
iv. Le soumissionnaire doit expliciter la méthode d’extraction de l’IMSI et les procédures de son
inclusion dans les CDRs générés par la plateforme RBT. Un document décrivant ces procédures doit
être fourni à l’appui.
v. Le soumissionnaire doit prévoir la possibilité d’ajout d’autres champs au niveau des CDR générés et
ce, au besoin futur consenti par Tunisie Télécom.
vi. Les CDR des appels initiés par les abonnés post-payés au module IVR – RBT seront générés par les
MSC de Tunisie Télécom dans un environnement TDM et par les MSC-S dans le cas de la migration
du réseau mobile vers NGN.
3. Facturation des abonnés Corporate mobiles
3.1 Le service RBT pour les employés corporate mobiles d’une entreprise n’est valable que pendant les
horaires de travail. Hors horaires de travail un employé d’une entreprise est considéré comme étant un
abonné mobile résidentiel ; il jouit à cet effet de toutes les fonctionnalités RBT précisées dans le
paragraphe I. du chapitre III du présent cahier des charges.
3.2 A cet effet, la plate-forme RBT proposée doit être capable de tenir en compte de ces changements de
classe d’abonnés et des modifications qui leur sont afférentes.
3.3 Les administrateurs RBT corporate (clients entreprises) doivent être facturés périodiquement (dont la
durée est configurable par l’administrateur du système : mensuellement, trimestriellement, etc.) sur les

frais de souscription/activation au service RBT par ligne corporate affiliés et ce, en fonction de la taille de
la flotte de l’entreprise.
3.4 La mise à jour du contenu RBT Corporate (achat de tonalité RBT, chargement de tonalité DIY sur le
système) sera facturée périodiquement selon les critères suivants :
 L’identifiant de la tonalité RBT achetée
 le nombre de lignes configuré par l’administrateur RBT de l’entreprise : L’administrateur RBT de
l’entreprise peut ne pas généraliser la mise à jour pour toutes les lignes de la flotte.
 la fréquence de(s) la mise (s) à jour effectuées pendant la durée de la validité du compte RBT
corporate.

3.5 Cas des abonnés Corporate mobiles post-payés
i. La plate-forme RBT doit être capable de générer des CDRs et de les envoyer au système de Facturation
BSCS IX R2 de Tunisie Télécom incluant au moins les paramètres suivants :
 L’identifiant de l’administrateur de l’entreprise (MSISDN)
 L’IMSI de l’administrateur de l’entreprise
 L’identifiant de la tonalité RBT
 La fréquence de la mise à jour de contenu effectuée pendant la période de validité du compte
RBT corporate
 Le nombre de lignes d’abonnés corporate mobiles impliqués dans l’acte,
 Le type de l’acte initié (inscription, désinscription, activation, désactivation, mise à jour de
contenu (achat, DIY))

ii. Le soumissionnaire est tenu à préciser tous les champs à insérer dans les CDRs nécessaires pour la
facturation des abonnés Corporate mobiles.


CHAPITRE VI : ARCHITECTURE ET INTERFACES DE LA PLATE-
FORME RBT
1. Composants de la plate-forme RBT

La plate-forme RBT, objet de la présente consultation, indépendamment qu’elle soit en environnement TDM
ou en environnement NGN, doit prévoir les principaux modules suivants :
1.1. Le module PGS/INS
Conformément à la logique d’implémentation « IN-Based sans trombonning », ce module doit permettre
principalement :
i Le contrôle de l’établissement d’un appel vers un abonné RBT
ii La gestion de multi-legs
iii L’extraction de l’identifiant de la tonalité RBT attribuée par l’abonné RBT à son (ses) appelant(s)
Ce module doit être intégrable au réseau intelligent mobile de Tunisie Télécom. A cet effet, le soumissionnaire
doit préciser les méthodes et les procédures d’intégration de ce module dans le système existant. Un document
détaillé décrivant ces procédures d’intégration doit être présenté à l’appui.
1.2 La plate-forme de gestion de contenu RBT
1.2.1 Le module d’inscription et de désinscription
i. Ce module doit permettre :
 L’inscription (provisioning) des abonnés au service RBT et ce, via SMS, IVR, WEB, WAP, USSD ou
par l’intermédiaire du service Customer Care.
 La désinscription du service RBT et ce, suite à une demande de la part de l’abonné via SMS, IVR,
WEB, WAP, USSD ou par l’intermédiaire du service Customer Care.
 Le provisioning automatique : La plateforme RBT doit permettre à un abonné non encore inscrit au
service RBT et qui lance une opération d’achat de tonalité RBT de s’inscrire automatiquement au service. Le
soumissionnaire est tenu à communiquer un document détaillant le work flow de cette opération ainsi que les
nœuds et interfaces impliqués.
 Le provisioning en masse : La plateforme RBT doit prévoir la possibilité d’approvisionner en masse un
ou plusieurs segments d’abonnés non encore inscrits au service RBT. Un document décrivant ce processus
doit être fourni à l’appui.
 La désinscription du service RBT par le système et ce, suite à l’expiration de la période de grâce relative
à un abonné suspendu et qui n’a pas encore payé les redevances de prolongation de son abonnement au
service RBT.
ii. Toute demande d’inscription ou de désinscription parvenue à la plate-forme RBT proposée via les
interfaces d’accès possibles, ci-dessus mentionnées, doit mettre à jour la marque TICK au niveau HLR ainsi
que mettre à jour la base de données utilisateurs de la plate-forme RBT.
iii. A cet effet, le soumissionnaire doit fournir un document complet et détaillé décrivant la procédure de
provisioning des abonnés RBT sur le système ainsi que les différentes interactions et pré-requis sur les nœuds
de réseau de Tunisie Télécom impliqués dans ce processus.
iv. Toute de demande d’inscription ou de désinscription du service RBT doit tenir en compte la classe de
service de l’abonné prépayé ou post-payé résidentiel et corporate en question. A cet effet, la plateforme
proposée doit prévoir toute les interconnexions possibles avec les nœuds du réseau de Tunisie Télécom
nécessaires pour convenir à ce travail.

1.2.2 La Base de données utilisateurs
i. La base de données utilisateur doit permettre le stockage des profiles des abonnés RBT mobiles.
ii. Le profil d’un abonné RBT doit inclure au moins :
 L’identifiant de l’abonné
 Le nom de l’abonné
 Le prénom de l’abonné
 La date d’inscription/d’activation au service RBT
 La date d’activation du service RBT
 L’identifiant ou la liste des identifiants de tonalités RBT attribuées
 Les numéros d’appel (MSISDN) ou identifiant des groupe d’appel auxquels est attribuée les
tonalités,
 Le type du compte (prépayé, post-payé),
 La classe de service de l’abonné
iii. La base de données proposée doit être gérée par le système de gestion de Base de donnée « ORACLE
10g » ou une version ultérieure. Le soumissionnaire doit tenir à sa charge la fourniture des licences
Oracles acquise sur son système ainsi que toute les dispositions qui en découlent et ce, afin de fournir à
Tunisie Télécom une solution complète et clé en main.

1.2.3 Le serveur de gestion du contenu RBT
i Le serveur de gestion du contenu RBT doit permettre :
 au fournisseur de contenu d’uploader, stocker et gérer le contenu RBT qu’ils chargent sur le système
via HTTPS/FTPS. Toutes les fonctionnalités dédiées aux fournisseurs de contenu sont détaillées dans
le paragraphe IVdu chapitre III du présent cahier des charges.

 à l’administrateur de la plateforme RBT d’administrer, gérer les comptes des fournisseurs de
contenu RBT ainsi que le contenu RBT et ce, à travers une interface graphique d’administration
WUI.
ii Le serveur de gestion du contenu RBT doit être capable de mettre à jour régulièrement le module IVR-
RBT de la plateforme et ce, pour rendre visible aux abonnés RBT le nouveau contenu sur la
plateforme.
1.2.4 Lecteur de tonalité RBT
i. Ce module doit servir essentiellement pour :
 La mise en mémoire cash des tonalités RBT
 La sélection et la lecture des tonalités RBT.
ii. Tout changement sur le profil de l’abonné RBT (ie : changement des tonalités RBT attribuées) doit
obligatoirement mettre à jour le lecteur de tonalité RBT.
iii. Le lecteur de tonalité RBT doit supporter la lecture et l’affichage des picture/vidéo RBT.


Bla

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Bla

Similar a Bla (20)

Bla