Des systèmes téléphoniques de différents fabricants ont besoin d'un moyen commun pour établir un appel.
SIP ne transporte pas le média, et cette frontière explique pourquoi un appel connecté peut n'avoir aucun son.
Que fait concrètement SIP ?
Il amène deux parties à convenir qu'une session doit avoir lieu, et à quelles conditions.
La RFC 3261, la spécification de juin 2002 qui le définit, décrit SIP comme "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". Les cinq tâches sont : trouver l'extrémité distante, déterminer si elle accepte l'appel, convenir du média, sonner, puis raccrocher ou transférer. La spécification les énumère ainsi :
User location: determination of the end system to be used for
communication;
User availability: determination of the willingness of the called
party to engage in communications;
User capabilities: determination of the media and media parameters
to be used;
Session setup: "ringing", establishment of session parameters at
both called and calling party;
Session management: including transfer and termination of
sessions, modifying session parameters, and invoking
services.Aucune de ces cinq tâches ne consiste à transporter l'audio. C'est toute l'étendue du rôle.
Pourquoi mon appel est-il connecté sans audio ?
Parce que l'audio n'a jamais été du ressort de SIP, et les deux chemins peuvent échouer indépendamment.
La spécification est explicite sur sa propre portée :
SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.
Le média circule via RTP, négocié pendant l'établissement puis acheminé de façon autonome, souvent entre des terminaux que la signalisation n'a jamais touchés. La signalisation peut aboutir et les deux côtés peuvent s'accorder sur le fait qu'une session est active. L'audio peut malgré tout ne pas arriver parce qu'un pare-feu, un traducteur d'adresses réseau ou une règle de routage entre les terminaux média l'a bloqué tout en laissant la signalisation intacte.
C'est pourquoi l'audio unidirectionnel et l'absence d'audio constituent leur propre catégorie de diagnostic plutôt qu'une variante de défaillance d'appel. Le journal d'appels affichera un appel connecté, car un appel connecté est exactement ce que la signalisation a réalisé. Dépannage vocal détaille les symptômes. L'outil d'appel test de Bird affiche un résumé du pic audio pour chaque direction, où un zéro d'un côté est le symptôme d'audio unidirectionnel exprimé sous forme de nombre.
Cette même séparation permet à d'autres éléments de s'intégrer naturellement. La RFC 3261 le formule ainsi : "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." La messagerie vocale, les groupes d'appels, l'enregistrement des appels et un agent IA reposent tous sur ces primitives plutôt que d'être définis par le protocole.
Dois-je enregistrer un client avant qu'il puisse appeler ?
Non. Les trunks Bird authentifient les appels sans enregistrement du client.
SIP définit bien une fonction d'enregistrement, qui permet à un agent utilisateur d'indiquer au réseau où il peut être joint à un instant donné. C'est ce qui rend un téléphone de bureau joignable lorsque quelqu'un compose un poste. Mais s'enregistrer et passer un appel sont deux actes distincts, et un système qui ne fait qu'émettre des appels n'a jamais besoin d'être joignable.
Un SIP INVITE est la méthode qui demande un appel. Bird authentifie chacun d'eux par rapport à la liste d'adresses IP autorisées du trunk ou par un challenge d'authentification. Les clients ne s'enregistrent pas auprès du trunk. Configurez Bird comme trunk plutôt que comme compte enregistré : pas de section type=registration dans Asterisk, register=false sur une passerelle FreeSWITCH, registration réglé sur none dans FreePBX ou 3CX. Lorsqu'un softphone ne permet pas de désactiver l'enregistrement, la tentative d'enregistrement échouée est cosmétique et la numérotation fonctionne quand même, car la plateforme agit sur l'invitation plutôt que sur l'enregistrement. Configuration client SIP contient les configurations détaillées.
Le corollaire concerne l'emplacement des identifiants. Votre client envoie deux identités distinctes. L'identifiant de l'appelant va dans l'en-tête From et doit être un numéro que vous avez vérifié. Le nom d'utilisateur digest est bird sur chaque trunk. Placer l'identifiant de l'appelant dans le champ d'authentification provoque une erreur d'authentification plutôt qu'une erreur mentionnant l'identifiant de l'appelant.
Pourquoi les réponses ressemblent-elles à celles de HTTP ?
Parce que le protocole a été conçu ainsi, jusqu'aux plages de numéros.
SIP est un protocole textuel de requête et réponse avec des méthodes et des en-têtes. Ses réponses utilisent les mêmes six classes avec les mêmes numéros familiers : un 404 pour une destination inexistante et un 486 pour un système terminal occupé. Cette structure commune vous permet de lire une trace SIP quasiment comme vous liriez une trace HTTP.
Il y a deux exceptions. Une sixième classe, 6xx, n'a pas d'équivalent HTTP et signifie qu'aucun serveur nulle part ne peut traiter la requête, pas seulement celui-ci. Un code courant porte aussi une signification en Bird que le standard ne décrit pas. Que signifient les codes de réponse SIP couvre les deux cas, y compris pourquoi un 503 de Bird est généralement un refus qu'il décline d'expliquer sur le réseau plutôt qu'une surcharge.
Où rencontre-t-on SIP sur Bird ?
Au niveau du trunk, qui est l'adresse vers laquelle votre équipement envoie.
Chaque trunk possède un domaine SIP fixe et accepte UDP ou TCP sur 5060, ou TLS sur 5061 si vous souhaitez chiffrer la signalisation en transit. Ce qui peut lui envoyer du trafic est à votre discrétion, et un nouveau trunk n'accepte rien tant que vous ne l'avez pas autorisé. Qu'est-ce qu'un trunk SIP couvre cette décision et les trois mécanismes qui la sous-tendent. Qu'est-ce qu'un API vocal explique comment la partie SIP et la partie HTTP se répartissent le travail.
En bref
SIP met en place les sessions mais ne les transporte pas.
Sa propre spécification le décrit comme un composant plutôt qu'un système complet. L'audio passe par un protocole distinct et souvent par un chemin distinct.
Cette séparation explique pourquoi un appel peut se connecter sans son.
La signalisation et le média peuvent échouer indépendamment : un appel peut se connecter normalement sans transmettre de son, et aucun des deux côtés n'a tort sur ce qu'il a constaté.
S'enregistrer et appeler sont deux actes distincts.
Un client s'enregistre pour indiquer où il peut être joint. Passer un appel ne l'exige pas, et Bird authentifie chaque invitation plutôt qu'un enregistrement.
Les réponses ressemblent à celles de HTTP parce qu'elles ont été conçues ainsi.
Six classes de réponses avec des numéros familiers, plus une classe sans équivalent en HTTP, qui signifie qu'aucun serveur nulle part ne peut traiter la requête.