Un échec de liaison SIP est un statut, pas un appel délivré

Un échec de liaison SIP est un statut, pas un appel délivré.

Distinguer les échecs de liaison SIP des sessions actives

Dans l'architecture IOSOR, un échec de liaison SIP se produit pendant la phase de signalisation, avant même qu'une session multimédia ne soit établie. Lorsqu'une requête E.164 est initiée, le système tente de lier l'appel à un point de terminaison de destination. Si cette liaison échoue en raison d'un délai d'attente, d'une erreur d'authentification ou de l'indisponibilité du point de terminaison, elle est enregistrée comme un événement de statut.

Logique du grand livre et seuil prépayé de 20 USD

La plateforme fonctionne sur un modèle prépayé strict avec un seuil de 20 USD requis pour maintenir les capacités de routage actives. Lorsqu'une tentative d'appel est effectuée, le système vérifie le solde disponible et place une 'retenue prépayée' temporaire sur le compte pour cette transaction spécifique. Si la liaison SIP échoue, cette retenue est immédiatement libérée. Aucun débit n'est effectué pour la durée de la tentative infructueuse.

Attribution de numéros JIT et états de connexion

Les numéros au sein de l'écosystème IOSOR sont gérés via l'attribution JIT (Just-In-Time). Lorsqu'un utilisateur demande un numéro, il est attribué et provisionné pour une utilisation immédiate sans avoir besoin d'un stock physique ou d'un inventaire pré-alloué. Si un échec de liaison SIP survient sur un numéro attribué en JIT, le système traite cela comme un non-événement pour le calcul de la charge récurrente mensuelle (MRC) liée à la durée de l'appel.

Notifications Webhook pour le trafic non délivré

Pour maintenir une visibilité maximale, chaque échec de liaison SIP déclenche une notification webhook. Cela permet aux développeurs de distinguer un 'DLR' (accusé de réception) pour une session réussie d'un simple statut d'échec. Ces webhooks fournissent des codes d'erreur granulaires expliquant pourquoi la liaison n'a pas pu être complétée. Qu'il s'agisse d'une commande 'STOP' de la destination ou d'un délai d'attente du réseau, les données sont disponibles pour une observabilité en temps réel.

Ressources techniques et logique de basculement

Pour une compréhension approfondie de la gestion des calculs financiers et des basculements de routage, veuillez consulter la documentation suivante :

• Arrondi de la durée des appels vocaux : audit des débits 6/6 vs 60/60
• Langage de statut partagé pour le produit et la finance
• chemin de secours ordonné sans double débit

Commencez avec IOSOR

Ouvrez la console IOSOR et accédez à vos paramètres de routage SIP pour auditer vos webhooks de signalisation. Assurez-vous que les échecs de liaison et de requête déclenchent des libérations immédiates de retenue au lieu d'inscrire des enregistrements de minutes connectées dans votre grand livre de comptes. Configurez une surveillance automatisée de l'état pour capturer des codes d'erreur précis lors de la négociation initiale du point de terminaison.

À retenir — IOSOR

Cet article a démontré qu'un échec de liaison ou de requête SIP relève strictement de la phase de signalisation et ne doit jamais être enregistré en tant que session d'appel active. En isolant la négociation de signalisation des chemins médias établis, le moteur de facturation garantit qu'aucune durée connectée n'est facturée lorsqu'une session ne parvient pas à aboutir.

Veuillez vérifier que vos journaux d'événements capturent des codes d'erreur de signalisation granulaires et libèrent instantanément toute retenue de grand livre réservée pour du trafic non acheminé.