Ajouter les appels navigateur avec le Webphone SDK

Utilisez le SDK actuel, gardez les identifiants permanents sur le serveur et testez les appels navigateur en sécurité.

Commencer par le paquet et la référence pris en charge

Ouvrez Documentation API → Webphone SDK. Téléchargez le paquet web ou les ressources documentées et suivez les exemples de la même version. Lisez tout avis de sécurité lié avant d’intégrer une ancienne copie. Ce SDK web ne remplace pas une intégration d’appels mobile native.

Le développeur doit préparer une application HTTPS authentifiée, une identité SIP autorisée, les permissions microphone et les ressources du SDK actuel. Le SDK Playground aide à vérifier compte et navigateur, mais ses appels sont réels et peuvent être facturés.

Garder les secrets permanents côté serveur

1. Utilisez normalement l’exemple de jeton géré comme point de départ en production.
2. Le backend authentifie l’utilisateur et vérifie quelle identité IllyVoIP il peut utiliser.
3. Avec la clé API du compte, il demande l’autorisation navigateur courte durée documentée. Ne retournez que les données nécessaires au SDK, jamais la clé permanente.
4. Initialisez le SDK avec ces données et l’exemple actuel correspondant. Gérez expiration, déconnexion et erreurs au lieu de créer continuellement des sessions.

N’acceptez pas une identité arbitraire d’un navigateur non authentifié et ne laissez pas créer de jetons pour d’autres comptes. Gardez clés et mots de passe SIP hors du JavaScript public, dépôts, URL et captures. Le mode SIP brut est une option avancée, pas une raison de mettre des secrets permanents dans le frontend.

Rendre la préparation visible

Affichez connexion en cours, prêt, entrant, actif, terminé et échec via les événements documentés. Demandez le microphone après une action claire, proposez le choix audio si supporté et affichez les refus. Un clavier affiché ne prouve pas l’enregistrement, ni celui-ci l’audio bidirectionnel.

Ne supposez pas que le SDK fournit toute la politique multiappareil. Respectez connexion et déconnexion et affichez les conflits de session. Une session déconnectée ou terminée ne doit plus se présenter active. Effacez l’état téléphonique du compte à la déconnexion et initialisez l’identité autorisée du nouvel utilisateur, pas celle du précédent en cache.

Effectuer une petite recette

Avec autorisation, testez un appel sortant et entrant, réponse/fin, microphone/haut-parleur et commandes d’attente, clavier ou transfert exposées. Testez refus de permission, perte réseau, déconnexion/changement de compte et comportement multiappareil voulu. Suivez diagnostics et régions actuels ; le repli régional ne garantit pas la survie d’un appel interrompu.

Utilisez des destinations de test autorisées, vérifiez les tarifs et ne considérez pas les appels répétés comme gratuits. Ne collectez ni transmettez d’enregistrements sans informations et autorisations requises.

Diagnostiquer par étape

Si l’autorisation échoue, examinez réponse backend et droits d’identité sans journaliser de secrets. Si la signalisation échoue, vérifiez région et compatibilité réseau/navigateur. Si l’audio manque, vérifiez appareils, permission et accès réseau aux médias. Conservez versions SDK/navigateur, erreur nettoyée, heure/fuseau et référence publique pour le support.

La référence API fait autorité pour méthodes, données et durées des jetons. Consultez Démarrage rapide API pour l’accès au compte et les requêtes sûres.