SHOFARSUITE
Shofar Suite réunit Shofar ePDG, Shofar Packet Core et Shofar IMS : de l’accès Wi-Fi sécurisé à la voix, au messaging et aux services, avec des interfaces 3GPP visibles et des fonctions déployables séparément.
VoLTE · VoWiFi · MMTel · policy · charging · messaging · observabilité
Chaque produit répond à une frontière réseau précise et peut être déployé seul. Ensemble, ils forment un chemin mobile cohérent, observable et fondé sur des interfaces standards.
P/I/S-CSCF, policy, MMTel, interconnexion et IP-SM-GW dans des rôles séparés. Le produit porte la signalisation, la QoS, les services d’appel et l’exploitation.
PGW IPv6 spécialisé IMS, commun aux accès cellulaires et Wi-Fi : S5/S8, S2b, GTP-U, policy Gx et SGi. La bascule inter-accès conserve le préfixe /64 et la session de policy, avec migration du bearer voix vers le chemin actif.
Passerelle SWu en Go : IKEv2, EAP-AKA′, relais SWm et ESP userspace. Son plan utilisateur fonctionne en mode autonome ou en S2b natif vers Shofar Packet Core.
La suite isole les responsabilités et rend chaque frontière vérifiable. Vous pouvez ouvrir un accès VoWiFi, déployer un cœur IMS ou faire évoluer l’ancrage paquet sans migration « big bang ».
Chaque produit fonctionne seul ou dans la chaîne complète, face aux fonctions réseau existantes.
Un processus par fonction : le breakout, le SMS ou l’observabilité évoluent sans emporter le registrar.
Interfaces, responsabilités, dépendances et critères de service sont définis avant chaque mise en production.
Les protocoles standards restent visibles : chaque lien indique son point de référence et son statut produit.
Sélectionnez un parcours pour suivre la signalisation et le point où Shofar apporte sa décision.
Le tunnel SWu protège l’accès Wi-Fi. Shofar ePDG peut relayer le trafic directement vers l’IMS ou établir un bearer S2b natif vers Shofar Packet Core. Avec S5/S8 et S2b sur la même ancre, le handover VoLTE↔VoWiFi conserve le préfixe IPv6 et la session de policy.
Le jeton ISC authentifie la reprise de service, y compris lors d’une ré-origination B2BUA sur un nouveau Call-ID.
L’IP-SM-GW convertit SIP MESSAGE, RP et TPDU vers SMPP. Le profil de déploiement définit séparément les politiques MO, MT, OTA, DLR, fenêtres et reprise du bind.
Composez le périmètre selon le besoin : accès, contrôle de session, services voix, policy, charging, messaging et exploitation.
REGISTER, IMS-AKA, IPsec ESP, routage SIP stateful, registrar partagé et sélection Cx des S-CSCF.
Appels MO/MT, early media, 100rel/PRACK, renvois, barring, conférence, breakout BGCF et média ancré.
PCRF, règles QoS, RAR/RAA, état Redis et charging INITIAL/UPDATE/TERMINATION en mode observation.
IP-SM-GW SIP↔SMPP, reg-event, XCAP/simservs, Sh et bootstrap GBA.
KPI MO/MT, PDD, answer-time, codes SIP, santé Diameter, registrations, dialogues, SMS/SMPP, IPsec et capture HEP SIP et messaging multi-collecteurs isolée — sans identifiants abonnés dans les labels.
Les rôles stateless, l’état Redis, les identités d’instance, la stickiness SIP et le fencing des rôles actifs composent une architecture HA à qualifier selon le RTO/RPO contractuel.
Validation du candidat avant swap, secrets hors YAML et rollback groupé.
La topologie, le fencing, les dépendances et les scénarios N-1 sont qualifiés selon le RTO/RPO retenu pour le projet.
AMD64 et ARM64, systemd aujourd’hui ; packaging OCI/Helm dans la trajectoire d’industrialisation.
Chaque fonction est présentée selon son statut produit et ses prérequis de déploiement, sans confondre disponibilité logicielle et niveau de service contractuel.
Cœur IMS, accès VoWiFi, policy, messaging ou ancrage paquet : définissons les fonctions, interfaces, dépendances et objectifs de service.
Merci de nous avoir contactés — nous revenons vers vous rapidement.