SIP - Guide rapide

Le protocole SIP (Session Initiation Protocol) est l'un des protocoles les plus couramment utilisés dans la technologie VoIP. Il s'agit d'un protocole de couche application qui fonctionne en conjonction avec d'autres protocoles de couche application pour contrôler les sessions de communication multimédia sur Internet.

Technologie VoIP

Avant d'aller plus loin, commençons par comprendre quelques points sur la VoIP.

• VOIP est une technologie qui vous permet de diffuser du contenu vocal et multimédia (vidéos, images) sur Internet. C'est l'un des moyens les moins chers de communiquer à tout moment, n'importe où avec la disponibilité d'Internet.

• Certains avantages de VOIP incluent -

  • À bas prix

  • Portability

  • Pas de câbles supplémentaires

  • Flexibility

  • Vidéo conférence

• Pour un appel VOIP, tout ce dont vous avez besoin est un ordinateur / ordinateur portable / mobile avec une connexion Internet. La figure suivante montre comment un appel VoIP a lieu.

Avec ce bien fondamental, revenons au SIP.

SIP - Aperçu

Vous trouverez ci-dessous quelques points à noter sur SIP -

• SIP est un protocole de signalisation utilisé pour créer, modifier et terminer une session multimédia via le protocole Internet. Une session n'est rien d'autre qu'un simple appel entre deux points de terminaison. Un point de terminaison peut être un smartphone, un ordinateur portable ou tout appareil capable de recevoir et d'envoyer du contenu multimédia sur Internet.

• SIP est un protocole de couche application défini par la norme IETF (Internet Engineering Task Force). Il est défini dansRFC 3261.

• SIP incarne l'architecture client-serveur et l'utilisation d'URL et d'URI à partir de HTTP et un schéma de codage de texte et un style d'en-tête de SMTP.

• SIP prend l'aide de SDP (Session Description Protocol) qui décrit une session et RTP (Real Time Transport Protocol) utilisé pour fournir la voix et la vidéo sur le réseau IP.

• SIP peut être utilisé pour des sessions à deux parties (unicast) ou multiparties (multicast).

• D'autres applications SIP incluent le transfert de fichiers, la messagerie instantanée, la vidéoconférence, les jeux en ligne et la distribution multimédia à la vapeur.

Où se situe le SIP?

Fondamentalement, SIP est un protocole de couche application. Il s'agit d'un protocole de signalisation réseau simple permettant de créer et de terminer des sessions avec un ou plusieurs participants. Le protocole SIP est conçu pour être indépendant du protocole de transport sous-jacent, de sorte que les applications SIP peuvent s'exécuter sur TCP, UDP ou d'autres protocoles réseau de couche inférieure.

L'illustration suivante montre la place de SIP dans le schéma général des choses -

En règle générale, le protocole SIP est utilisé pour la téléphonie Internet et la distribution multimédia entre deux ou plusieurs terminaux. Par exemple, une personne peut lancer un appel téléphonique avec une autre personne en utilisant SIP, ou quelqu'un peut créer une conférence téléphonique avec de nombreux participants.

Le protocole SIP a été conçu pour être très simple, avec un ensemble limité de commandes. Il est également basé sur du texte, de sorte que n'importe qui peut lire un message SIP passé entre les points de terminaison dans une session SIP.

Certaines entités aident SIP à créer son réseau. Dans SIP, chaque élément du réseau est identifié par unSIP URI(Uniform Resource Identifier) ​​qui est comme une adresse. Voici les éléments du réseau -

• Agent utilisateur
• Serveur proxy
• Serveur registraire
• Rediriger le serveur
• Serveur de localisation

Agent utilisateur

C'est le point final et l'un des éléments de réseau les plus importants d'un réseau SIP. Un point de terminaison peut lancer, modifier ou mettre fin à une session. Les agents utilisateurs sont le périphérique ou l'élément de réseau le plus intelligent d'un réseau SIP. Cela peut être un softphone, un mobile ou un ordinateur portable.

Les agents utilisateurs sont logiquement divisés en deux parties -

• User Agent Client (UAC) - L'entité qui envoie une demande et reçoit une réponse.

• User Agent Server (UAS) - L'entité qui reçoit une demande et envoie une réponse.

Le SIP est basé sur une architecture client-serveur où le téléphone de l'appelant agit comme un client qui initie un appel et le téléphone de l'appelé agit comme un serveur qui répond à l'appel.

Serveur proxy

C'est l'élément de réseau qui prend une requête d'un agent utilisateur et la transmet à un autre utilisateur.

• Fondamentalement, le rôle d'un serveur proxy ressemble beaucoup à un routeur.

• Il a une certaine intelligence pour comprendre une demande SIP et l'envoyer avec l'aide de l'URI.

• Un serveur proxy se situe entre deux agents utilisateurs.

• Il peut y avoir un maximum de 70 serveurs proxy entre une source et une destination.

Il existe deux types de serveurs proxy -

• Stateless Proxy Server- Il transmet simplement le message reçu. Ce type de serveur ne stocke aucune information sur un appel ou une transaction.

• Stateful Proxy Server- Ce type de serveur proxy garde une trace de chaque demande et réponse reçue et peut l'utiliser à l'avenir si nécessaire. Il peut retransmettre la demande, s'il n'y a pas de réponse de l'autre côté à temps.

Serveur registraire

Le serveur d'enregistrement accepte les demandes d'enregistrement des agents utilisateurs. Il aide les utilisateurs à s'authentifier au sein du réseau. Il stocke l'URI et l'emplacement des utilisateurs dans une base de données pour aider d'autres serveurs SIP dans le même domaine.

Jetez un œil à l'exemple suivant qui montre le processus d'enregistrement SIP.

Ici, l'appelant souhaite s'inscrire auprès du domaine TMC. Il envoie donc une demande REGISTER au serveur Registrar du TMC et le serveur renvoie une réponse 200 OK lorsqu'il a autorisé le client.

Rediriger le serveur

Le serveur de redirection reçoit les demandes et recherche le destinataire prévu de la demande dans la base de données de localisation créée par le registraire.

Le serveur de redirection utilise la base de données pour obtenir des informations de localisation et répond avec 3xx (réponse de redirection) à l'utilisateur. Nous aborderons les codes de réponse plus loin dans ce didacticiel.

Serveur de localisation

Le serveur de localisation fournit des informations sur les emplacements possibles d'un appelant aux serveurs de redirection et proxy.

Seul un serveur proxy ou un serveur de redirection peut contacter un serveur de localisation.

La figure suivante illustre les rôles joués par chacun des éléments du réseau lors de l'établissement d'une session.

SIP - Architecture système

SIP est structuré comme un protocole en couches, ce qui signifie que son comportement est décrit en termes d'un ensemble d'étapes de traitement assez indépendantes avec seulement un couplage lâche entre chaque étape.

• La couche la plus basse de SIP est sa syntax and encoding. Son encodage est spécifié à l'aide d'unBackus-Naur Form grammar (BNF).

• Au deuxième niveau se trouve le transport layer. Il définit comment un client envoie des demandes et reçoit des réponses et comment un serveur reçoit des demandes et envoie des réponses sur le réseau. Tous les éléments SIP contiennent une couche de transport.

• Vient ensuite le transaction layer. Une transaction est une demande envoyée par une transaction client (en utilisant la couche de transport) à une transaction serveur, avec toutes les réponses à cette demande envoyées depuis la transaction serveur vers le client. Toute tâche accomplie par un client agent utilisateur (UAC) s'effectue à l'aide d'une série de transactions.Stateless proxies ne contiennent pas de couche de transaction.

• La couche au-dessus du transaction layerest appelé l'utilisateur de la transaction. Chacune des entités SIP, à l'exception deStateless proxies, est un utilisateur de transaction.

L'image suivante montre le flux d'appels de base d'une session SIP.

Vous trouverez ci-dessous une explication étape par étape du flux d'appels ci-dessus -

• Une demande INVITE qui est envoyée à un serveur proxy est responsable du lancement d'une session.

• Le serveur proxy envoie un 100 Trying réponse immédiate à l'appelant (Alice) pour arrêter les retransmissions de la demande INVITE.

• Le serveur proxy recherche l'adresse de Bob dans le serveur de localisation. Après avoir obtenu l'adresse, il transmet la demande INVITE plus loin.

• Après, 180 Ringing (Réponses provisoires) générées par Bob est renvoyée à Alice.

• UNE 200 OK La réponse est générée peu de temps après que Bob décroche le téléphone.

• Bob reçoit un ACK de l'Alice, une fois qu'il obtient 200 OK.

• En même temps, la session est établie et les paquets RTP (conversations) commencent à circuler des deux côtés.

• Après la conversation, n'importe quel participant (Alice ou Bob) peut envoyer un BYE demande de mettre fin à la session.

• BYE atteint directement d'Alice à Bob en contournant le serveur proxy.

• Enfin, Bob envoie un 200 OK réponse pour confirmer le BYE et la session est terminée.

• Dans le flux d'appels de base ci-dessus, trois transactions sont (marqués comme 1, 2, 3) disponibles.

L'appel complet (de INVITE à 200 OK) est appelé Dialog.

Trapèze SIP

Comment un proxy aide-t-il à connecter un utilisateur à un autre? Découvrons-le à l'aide du schéma suivant.

La topologie indiquée dans le diagramme est connue sous le nom de trapèze SIP. Le processus se déroule comme suit -

• Lorsqu'un appelant lance un appel, un message INVITE est envoyé au serveur proxy. À la réception de l'INVITE, le serveur proxy tente de résoudre l'adresse de l'appelé à l'aide du serveur DNS.

• Après avoir obtenu la route suivante, le serveur proxy de l'appelant (Proxy 1, également connu sous le nom de serveur proxy sortant) transmet la demande INVITE au serveur proxy de l'appelé qui agit comme un serveur proxy entrant (Proxy 2) pour l'appelé.

• Le serveur proxy entrant contacte le serveur de localisation pour obtenir des informations sur l'adresse de l'appelé à laquelle l'utilisateur s'est enregistré.

• Après avoir obtenu des informations du serveur de localisation, il transfère l'appel vers sa destination.

• Une fois que les agents utilisateurs connaissent leur adresse, ils peuvent contourner l'appel, c'est-à-dire que les conversations passent directement.

Les messages SIP sont de deux types - requests et responses.

• La ligne d'ouverture d'une demande contient une méthode qui définit la demande et un Request-URI qui définit où la demande doit être envoyée.

• De même, la première ligne d'une réponse contient un code de réponse.

Méthodes de demande

SIP requestssont les codes utilisés pour établir une communication. Pour les compléter, il y aSIP responses qui indiquent généralement si une demande a réussi ou échoué.

Ces demandes SIP, connues sous le nom de METHODES, rendent le message SIP exploitable.

• Les MÉTHODES peuvent être considérées comme des requêtes SIP, car elles demandent qu'une action spécifique soit entreprise par un autre agent utilisateur ou serveur.

• Les MÉTHODES se distinguent en deux types -

  • Méthodes de base

  • Méthodes d'extension

Méthodes de base

Il existe six méthodes principales décrites ci-dessous.

INVITER

INVITE est utilisé pour lancer une session avec un agent utilisateur. En d'autres termes, une méthode INVITE est utilisée pour établir une session média entre les agents utilisateurs.

• INVITE peut contenir les informations multimédias de l'appelant dans le corps du message.

• Une session est considérée comme établie si un INVITE a reçu une réponse de succès (2xx) ou un ACK a été envoyé.



• Une demande INVITE réussie établit un dialog entre les deux agents utilisateurs qui continue jusqu'à ce qu'un BYE soit envoyé pour terminer la session.

• Une INVITE envoyée dans une boîte de dialogue établie est connue sous le nom de re-INVITE.

• Re-INVITE permet de modifier les caractéristiques de session ou d'actualiser l'état d'une boîte de dialogue.

Exemple INVITE

Le code suivant montre comment INVITE est utilisé.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected].168.2.1  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

AU REVOIR

BYE est la méthode utilisée pour mettre fin à une session établie. Il s'agit d'une demande SIP qui peut être envoyée par l'appelant ou l'appelé pour mettre fin à une session.

• Il ne peut pas être envoyé par un serveur proxy.

• La demande BYE achemine normalement de bout en bout, en contournant le serveur proxy.

• BYE ne peut pas être envoyé à une session INVITE en attente ou non établie.

S'INSCRIRE

La demande REGISTER effectue l'enregistrement d'un agent utilisateur. Cette demande est envoyée par un agent utilisateur à un serveur d'enregistrement.

• La demande REGISTER peut être transmise ou envoyée par mandataire jusqu'à ce qu'elle atteigne un bureau d'enregistrement faisant autorité du domaine spécifié.

• Il porte l'AOR (Address of Record) dans le To en-tête de l'utilisateur en cours d'enregistrement.

• La requête REGISTER contient la période (3600sec).

• Un agent utilisateur peut envoyer une demande REGISTER au nom d'un autre agent utilisateur. Ceci est connu commethird-party registration. Ici leFrom La balise contient l'URI de la partie soumettant l'enregistrement au nom de la partie identifiée dans le To entête.

ANNULER

CANCEL est utilisé pour terminer une session qui n'est pas établie. Les agents utilisateurs utilisent cette demande pour annuler une tentative d'appel en attente lancée plus tôt.

• Il peut être envoyé soit par un agent utilisateur, soit par un serveur proxy.

• CANCEL est un hop by hop request, c'est-à-dire qu'il parcourt les éléments entre l'agent utilisateur et reçoit la réponse générée par l'élément avec état suivant.

ACK

ACK est utilisé pour accuser réception des réponses finales à une méthode INVITE. Un ACK va toujours dans le sens de INVITE.ACK peut contenir un corps SDP (caractéristiques du média), s'il n'est pas disponible dans INVITE.

• ACK ne peut pas être utilisé pour modifier la description de média qui a déjà été envoyée dans l'invitation initiale.

• Un proxy avec état recevant un ACK doit déterminer si le ACK doit être transmis en aval à un autre proxy ou agent utilisateur.

• Pour les réponses 2xx, ACK est de bout en bout, mais pour toutes les autres réponses finales, il fonctionne bond par bond lorsque des proxys avec état sont impliqués.

OPTIONS

La méthode OPTIONS est utilisée pour interroger un agent utilisateur ou un serveur proxy sur ses capacités et découvrir sa disponibilité actuelle. La réponse à une demande répertorie les capacités de l'agent utilisateur ou du serveur. Un proxy ne génère jamais de requête OPTIONS.

Méthodes d'extension

Souscrire

SUBSCRIBE est utilisé par les agents utilisateurs pour établir un abonnement dans le but d'obtenir une notification sur un événement particulier.

• Il contient un Expires champ d'en-tête qui indique la durée d'un abonnement.

• Une fois la période écoulée, l'abonnement se terminera automatiquement.

• L'abonnement établit un dialogue entre les agents utilisateurs.

• Vous pouvez vous réinscrire à nouveau en envoyant un autre SOUSCRIPTION dans la boîte de dialogue avant l'heure d'expiration.

• Un 200 OK sera reçu pour un abonnement de l'utilisateur.

• Les utilisateurs peuvent se désabonner en envoyant une autre méthode SUBSCRIBE avec la valeur Expires 0 (zéro).

NOTIFIER

NOTIFY est utilisé par les agents utilisateurs pour obtenir l'occurrence d'un événement particulier. Habituellement, un NOTIFY se déclenchera dans une boîte de dialogue lorsqu'un abonnement existe entre l'abonné et le notifiant.

• Chaque NOTIFY recevra 200 réponses OK s'il est reçu par le notificateur.

• NOTIFY contient un Event champ d'en-tête indiquant l'événement et un subscriptionstate champ d'en-tête indiquant l'état actuel de l'abonnement.

• Un NOTIFY est toujours envoyé au début et à la fin d'un abonnement.

PUBLIER

PUBLISH est utilisé par un agent utilisateur pour envoyer des informations sur l'état des événements à un serveur.

• PUBLISH est surtout utile lorsqu'il existe plusieurs sources d'informations sur les événements.

• Une demande PUBLISH est similaire à un NOTIFY, sauf qu'elle n'est pas envoyée dans une boîte de dialogue.

• Une demande PUBLISH doit contenir un Expires champ d'en-tête et un Min-Expires champ d'en-tête.

RÉFÉRER

REFER est utilisé par un agent utilisateur pour désigner un autre agent utilisateur afin d'accéder à un URI pour la boîte de dialogue.

• REFER doit contenir un Refer-Toentête. Il s'agit d'un en-tête obligatoire pour REFER.

• REFER peut être envoyé à l'intérieur ou à l'extérieur d'une boîte de dialogue.

• UNE 202 Accepted déclenchera une demande REFER qui indique qu'un autre agent utilisateur a accepté la référence.

INFO

INFO est utilisé par un agent utilisateur pour envoyer des informations de signalisation d'appel à un autre agent utilisateur avec lequel il a établi une session multimédia.

• Il s'agit d'une demande de bout en bout.

• Un proxy transmettra toujours une demande INFO.

METTRE À JOUR

UPDATE est utilisé pour modifier l'état d'une session si une session n'est pas établie. L'utilisateur peut changer le codec avec UPDATE.

SI une session est établie, une réinvitation est utilisée pour modifier / mettre à jour la session.

PRACK

PRACK est utilisé pour accuser réception d'un transfert fiable de réponse provisoire (1XX).

• Généralement, PRACK est généré par un client lorsqu'il reçoit une réponse provisoire contenant un RSeq numéro de séquence fiable et un supported:100rel entête.

• PRACK contient la valeur (RSeq + CSeq) dans le rack entête.

• La méthode PRACK s'applique à toutes les réponses provisoires à l'exception de la réponse 100 Trying, qui n'est jamais transportée de manière fiable.

• Un PRACK peut contenir un corps de message; il peut être utilisé pour l'échange d'offres / réponses.

MESSAGE

Il est utilisé pour envoyer un message instantané en utilisant SIP. Un MI se compose généralement de messages courts échangés en temps réel par des participants engagés dans une conversation textuelle.

• Le MESSAGE peut être envoyé dans une boîte de dialogue ou en dehors d'une boîte de dialogue.

• Le contenu d'un MESSAGE est transporté dans le corps du message en tant que MIME attachement.

• UNE 200 OK une réponse est normalement reçue pour indiquer que le message a été remis à sa destination.

Une réponse SIP est un message généré par un serveur d'agent utilisateur (UAS) ou un serveur SIP pour répondre à une demande générée par un client. Il peut s'agir d'un accusé de réception formel pour empêcher la retransmission des demandes par un UAC.

• Une réponse peut contenir des champs d'en-tête supplémentaires d'informations nécessaires à un UAC.

• SIP a six réponses.

• 1xx à 5xx a été emprunté à HTTP et 6xx est introduit dans SIP.

• 1xx est considéré comme un provisional réponse et le reste sont final réponses.

S.No.	Description de la fonction
1	1xx: réponses provisoires / informatives Des réponses informatives sont utilisées pour indiquer call progress. Normalement, les réponses sont de bout en bout (sauf 100 essais).
2	2xx: Réponses de succès Cette classe de réponses est destinée à indiquer qu'une demande a été acceptée.
3	3xx: rediriger les réponses En général, ces réponses de classe sont envoyées par des serveurs de redirection en réponse à INVITE. Ils sont également connus sous le nom de réponses de classe de redirection.
4	4xx: Réponses aux échecs du client Les réponses d'erreur du client indiquent que la demande ne peut pas être satisfaite car certaines erreurs sont identifiées du côté UAC.
5	5xx: Réponse en cas d'échec du serveur Cette réponse de classe est utilisée pour indiquer que la demande ne peut pas être traitée en raison d'une erreur avec le serveur.
6	6xx: réponse globale en cas de panne Cette classe de réponse indique que le serveur sait que la demande échouera partout où elle sera essayée. Par conséquent, la demande ne doit pas être envoyée à d'autres emplacements.

Un en-tête est un composant d'un message SIP qui transmet des informations sur le message. Il est structuré comme une séquence de champs d'en-tête.

Les champs d'en-tête SIP suivent dans la plupart des cas les mêmes règles que les champs d'en-tête HTTP. Les champs d'en-tête sont définis commeHeader: field, où Header est utilisé pour représenter le nom du champ d'en-tête, et field est l'ensemble de jetons contenant les informations. Chaque champ se compose d'un nom de champ suivi de deux points (":") et de la valeur du champ (c'est-à-dire,field-name: field-value).

En-têtes SIP - Forme compacte

De nombreux champs d'en-tête SIP courants ont une forme compacte où le nom du champ d'en-tête est indiqué par un seul caractère minuscule. Quelques exemples sont donnés ci-dessous -

Entête	Forme compacte
À	T
Via	V
ID d'appel	je
Contact	M
De	F
Matière	S
Content-Length	je

Format d'en-tête SIP

L'image suivante montre la structure d'un en-tête SIP typique.

Les en-têtes sont classés comme suit en fonction de leur utilisation dans SIP -

• Demande et réponse
• Demande seulement
• Réponse uniquement
• Corps du message

SDP signifie Session Description Protocol. Il est utilisé pour décrire des sessions multimédia dans un format compris par les participants sur un réseau. En fonction de cette description, un participant décide s'il veut rejoindre une conférence ou quand ou comment rejoindre une conférence.

• Le propriétaire d'une conférence en fait la publicité sur le réseau en envoyant des messages multicast qui contiennent une description de la session, par exemple le nom du propriétaire, le nom de la session, le codage, le timing etc. En fonction de ces informations, les destinataires de l'annonce prendre une décision sur la participation à la session.

• SDP est généralement contenu dans la partie du corps du protocole d'ouverture de session communément appelé SIP.

• SDP est défini dans la RFC 2327. Un message SDP est composé d'une série de lignes, appelées champs, dont les noms sont abrégés par une seule lettre minuscule, et sont dans un ordre requis pour simplifier l'analyse.

Objectif du SDP

Le but de SDP est de transmettre des informations sur les flux multimédias dans les sessions multimédias pour aider les participants à rejoindre ou à recueillir des informations sur une session particulière.

• SDP est une courte description textuelle structurée.

• Il transmet le nom et le but de la session, les supports, les protocoles, les formats de codec, les informations de synchronisation et de transport.

• Un participant provisoire vérifie ces informations et décide s'il souhaite rejoindre une session et comment et quand rejoindre une session s'il décide de le faire.

• Le format a des entrées sous la forme <type> = <valeur>, où <type> définit un paramètre de session unique et la <value> fournit une valeur spécifique pour ce paramètre.

• La forme générale d'un message SDP est -

  x = parameter1 parameter2 ... parameterN

• La ligne commence par une seule lettre minuscule, par exemple x. Il n'y a jamais d'espace entre la lettre et le =, et il y a exactement un espace entre chaque paramètre. Chaque champ a un nombre défini de paramètres.

Paramètres de description de session

Description de la session (* indique facultatif)

• v = (version du protocole)
• o = (propriétaire / créateur et identifiant de session)
• s = (nom de la session)
• i = * (informations de session)
• u = * (URI de la description)
• e = * (adresse e-mail)
• p = * (numéro de téléphone)
• c = * (informations de connexion - non requises si incluses dans tous les supports)
• b = * (informations de bande passante)
• z = * (ajustements du fuseau horaire)
• k = * (clé de cryptage)
• a = * (zéro ou plusieurs lignes d'attribut de session)

Version du protocole

Le champ v = contient le numéro de version SDP. Étant donné que la version actuelle de SDP est 0, un message SDP valide commencera toujours par v = 0.

Origine

Le champ o = contient des informations sur l'expéditeur de la session et les identificateurs de session. Ce champ est utilisé pour identifier de manière unique la session.

• Le champ contient -

  o = <username> <session-id> <version> <network-type> <address-type>

• le username Le paramètre contient le login ou l'hôte de l'expéditeur.

• le session-id est un horodatage NTP (Network Time Protocol) ou un nombre aléatoire utilisé pour garantir l'unicité.

• le version est un champ numérique qui est augmenté pour chaque modification de la session, également recommandé comme horodatage NTP.

• le network-typeest toujours IN pour Internet. Le paramètre de type d'adresse est IP4 ou IP6 pour l'adresse IPv4 ou IPv6, soit sous forme décimale en pointillés, soit sous un nom d'hôte qualifié complet.

Nom et informations de la session

Le champ s = contient un nom pour la session. Il peut contenir n'importe quel nombre de caractères différent de zéro. Le champ optionnel i = contient des informations sur la session. Il peut contenir n'importe quel nombre de caractères.

URI

Le champ facultatif u = contient un indicateur de ressource uniforme (URI) avec plus d'informations sur la session

Adresse e-mail et numéro de téléphone

Le champ optionnel e = contient une adresse e-mail de l'hôte de la session. Le champ optionnel p = contient un numéro de téléphone.

Données de connexion

Le champ c = contient des informations sur la connexion multimédia.

• Le champ contient -

  c = <network-type> <address-type> <connexion-address>

• le network-type Le paramètre est défini comme IN pour Internet.

• le address-type est défini comme IP4 pour les adresses IPv4 et IP6 pour les adresses IPv6.

• le connection-address est l'adresse IP ou l'hôte qui enverra les paquets multimédias, qui peuvent être en multidiffusion ou en monodiffusion.

• En cas de multidiffusion, le champ d'adresse de connexion contient -

  adresse-de-connexion = adresse-multicast de base / ttl / nombre-d'adresses

où ttl est la valeur de durée de vie et le nombre d'adresses indique le nombre d'adresses multicast contiguës incluses en commençant par l'adresse multicast de base.

Bande passante

Le champ facultatif b = contient des informations sur la bande passante requise. C'est de la forme -

b = modificateur: bande passante - valeur

Heure, heures de répétition et fuseaux horaires

Le champ t = contient l'heure de début et l'heure de fin de la session.

t = heure de début heure de fin

Le champ facultatif r = contient des informations sur les temps de répétition qui peuvent être spécifiés soit en NTP, soit en jours ( j ), heures ( h ) ou minutes ( m ).

Le champ optionnel z = contient des informations sur les décalages de fuseau horaire. Ce champ est utilisé si la session en cours couvre un passage de l'heure d'été à l'heure d'hiver, ou vice versa.

Annonces aux médias

Le champ facultatif m = contient des informations sur le type de session multimédia. Le champ contient -

m = liste de formats de transport de port multimédia

• Le paramètre multimédia est soit audio, vidéo, texte, application, message, image ou contrôle. Le paramètre de port contient le numéro de port.

• Le paramètre de transport contient le protocole de transport ou le profil RTP utilisé.

• La liste des formats contient plus d'informations sur les médias. Habituellement, il contient des types de charge utile multimédia définis dans les profils audio vidéo RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

L'un de ces trois codecs peut être utilisé pour la session multimédia audio. Si l'intention est d'établir trois canaux audio, trois champs multimédias distincts seraient utilisés.

Les attributs

Le champ facultatif a = contient les attributs de la session multimédia précédente. Ce champ peut être utilisé pourextend SDP to provide more information about the media. S'il n'est pas entièrement compris par un utilisateur SDP, le champ d'attribut peut être ignoré. Il peut y avoir un ou plusieurs champs d'attribut pour chaque type de charge utile de média répertorié dans le champ de média.

Les attributs dans SDP peuvent être soit

• niveau session, ou
• niveau des médias.

Le niveau de session signifie que l'attribut est répertorié avant la première ligne multimédia dans le SDP. Si tel est le cas, l'attribut s'applique à toutes les lignes média en dessous.

Le niveau de média signifie qu'il est répertorié après une ligne de média. Dans ce cas, l'attribut s'applique uniquement à ce flux multimédia particulier.

SDP peut inclure des attributs de niveau session et de niveau média. Si le même attribut apparaît dans les deux, l'attribut de niveau de média remplace l'attribut de niveau de session pour ce flux de média particulier. Notez que le champ de données de connexion peut également être au niveau de la session ou au niveau du support.

Un exemple SDP

Vous trouverez ci-dessous un exemple de description de session, tiré de la RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

L'utilisation de SDP avec SIP est donnée dans la réponse d'offre SDP RFC 3264. Le type de corps de message par défaut dans SIP est application/sdp.

• L'appelant répertorie les capacités multimédias qu'il est prêt à recevoir dans SDP, généralement dans un INVITE ou dans un ACK.

• La partie appelée répertorie ses capacités multimédias dans la réponse 200 OK à l'INVITE.

Une utilisation SIP typique de SDP comprend les champs suivants: version, origine, sujet, heure, connexion et un ou plusieurs médias et attributs.

• Les champs d'objet et d'heure ne sont pas utilisés par SIP mais sont inclus pour des raisons de compatibilité.

• Dans la norme SDP, le champ sujet est un champ obligatoire et doit contenir au moins un caractère, suggéré comme s = - s'il n'y a pas de sujet.

• Le champ d'heure est généralement défini sur t = 00. SIP utilise les champs de connexion, de média et d'attribut pour configurer des sessions entre UA.

• Le champ d'origine a une utilisation limitée avec SIP.

• L'identifiant de session est généralement maintenu constant tout au long d'une session SIP.

• La version est incrémentée chaque fois que le SDP est modifié. Si le SDP envoyé est inchangé par rapport à celui envoyé précédemment, la version est conservée.

• Comme le type de session multimédia et le codec à utiliser font partie de la négociation de connexion, SIP peut utiliser SDP pour spécifier plusieurs types de supports alternatifs et pour accepter ou refuser sélectivement ces types de supports.

La spécification offre / réponse, RFC 3264, recommande qu'un attribut contenant a = rtpmap: soit utilisé pour chaque champ de média. Un flux multimédia est refusé en définissant le numéro de port sur zéro pour le champ multimédia correspondant dans la réponse SDP.

Exemple

Dans l'exemple suivant, l'appelant Tesla veut mettre en place un appel audio et vidéo avec deux codecs audio possibles et un codec vidéo dans le SDP transporté dans l'invitation initiale -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Les codecs sont référencés par les numéros de profil RTP / AVP 97, 98.

La partie appelée Marry répond à l'appel, choisit le deuxième codec pour le premier champ média et refuse le deuxième champ média, ne voulant que la session AMR.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Si cet appel audio uniquement n'est pas acceptable, Tom enverra un ACK puis un BYE pour annuler l'appel. Sinon, la session audio serait établie et les paquets RTP échangés.

Comme cet exemple l'illustre, à moins que le nombre et l'ordre des champs multimédias ne soient conservés, l'appelant ne saurait avec certitude quelles sessions multimédias ont été acceptées et refusées par l'appelé.

Les règles d'offre / réponse sont résumées dans les sections suivantes.

Règles de génération d'une offre

Une offre SDP doit inclure tous les champs SDP obligatoires (cela inclut v =, o =, s =, c = et t =). Ce sont des champs obligatoires dans SDP.

Il comprend généralement un champ média ( m = ) mais ce n'est pas obligatoire. Les lignes multimédias contiennent tous les codecs répertoriés par ordre de préférence. La seule exception à cela est que si le point de terminaison prend en charge un grand nombre de codecs, les plus susceptibles d'être acceptés ou les plus préférés doivent être répertoriés. Différents types de médias incluent l'audio, la vidéo, le texte, le MSRP, le BFCP, etc.

Règles de génération d'une réponse

Une réponse SDP à une offre doit être construite selon les règles suivantes -

• La réponse doit avoir le même nombre de m = lignes dans le même ordre que la réponse.

• Les flux multimédias individuels peuvent être refusés en définissant le numéro de port sur 0.

• Les flux sont acceptés en envoyant un numéro de port différent de zéro.

• Les charges utiles répertoriées pour chaque type de support doivent être un sous-ensemble des charges utiles répertoriées dans l'offre.

• Pour les charges utiles dynamiques, le même numéro de charge utile dynamique n'a pas besoin d'être utilisé dans chaque direction. En général, une seule charge utile est sélectionnée.

Règles de modification d'une session

Chaque partie peut lancer un autre échange d'offre / réponse pour modifier une session. Lorsqu'une session est modifiée, les règles suivantes doivent être suivies -

• Le numéro de version de la ligne d' origine ( o = ) doit être soit le même que le dernier envoyé, ce qui indique que ce SDP est identique à l'échange précédent, ou il peut être incrémenté de un, ce qui indique un nouveau SDP qui doit être analysé.

• L'offre doit inclure toutes les lignes médias existantes et elles doivent être envoyées dans le même ordre.

• Des flux multimédias supplémentaires peuvent être ajoutés à la fin de la liste m = line.

• Un flux multimédia existant peut être supprimé en définissant le numéro de port sur 0. Cette ligne multimédia doit rester dans le SDP et dans tous les futurs échanges offre / réponse pour cette session.

Appel en attente

Un interlocuteur lors d'un appel peut temporairement mettre l'autre en attente. Cela se fait en envoyant un INVITE avec un SDP identique à celui de l'INVITE d'origine mais aveca = sendonly attribut présent.

L'appel est à nouveau activé en envoyant une autre INVITE avec le a = sendrecvattribut présent. L'illustration suivante montre le déroulement des appels d'un appel en attente.

Personal mobilityest la possibilité d'avoir un identifiant constant sur un certain nombre d'appareils. SIP prend en charge la mobilité personnelle de base à l'aide de la méthode REGISTER, qui permet à un appareil mobile de modifier son adresse IP et son point de connexion à Internet tout en continuant à recevoir des appels entrants.

SIP peut également prendre en charge service mobility - la capacité d'un utilisateur à conserver les mêmes services lorsqu'il est mobile

Mobilité SIP pendant le transfert (pré-appel)

Un appareil associe son URI de contact à l'adresse d'enregistrement par un simple enregistrement sip. Selon l'adresse IP de l'appareil, l'enregistrement autorise la mise à jour automatique de ces informations dans le réseau sip.

Pendant le transfert, l'agent utilisateur achemine entre différents opérateurs, où il doit s'enregistrer à nouveau auprès d'un contact en tant qu'AOR auprès d'un autre fournisseur de services.

Par exemple, prenons l'exemple du flux d'appels suivant. UA qui a temporairement reçu un nouvel URI SIP avec un nouveau fournisseur de services. L'UA effectue alors un double enregistrement -

• Le premier enregistrement s'effectue auprès du nouvel opérateur de service, qui lie l'URI de contact de l'appareil à l'URI AOR du nouveau fournisseur de services.

• La deuxième demande REGISTER est renvoyée vers le fournisseur de services d'origine et fournit l'AOR du nouveau fournisseur de services en tant qu'URI de contact.

Comme montré plus loin dans le flux d'appels, lorsqu'une demande arrive sur le réseau du fournisseur de services d'origine, l'INVITE est redirigé vers le nouveau fournisseur de services qui achemine ensuite l'appel vers l'utilisateur.

Pour le premier enregistrement, le message contenant l'URI de l'appareil serait -

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

Le deuxième message d'enregistrement avec l'URI itinérant serait -

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

Le premier INVITE représenté dans la figure ci-dessus sera envoyé à sip: registrar2.in; le deuxième INVITE serait envoyé à sip: sip: [email protected], qui serait transmis àsip:[email protected]. Il atteint Tom et permet d'établir la session. Périodiquement, les deux enregistrements doivent être actualisés.

Mobilité pendant un appel (réinviter)

L'agent utilisateur peut changer son adresse IP au cours de la session lorsqu'il passe d'un réseau à un autre. Le SIP de base prend en charge ce scénario, car une re-INVITE dans une boîte de dialogue peut être utilisée pour mettre à jour l'URI du contact et modifier les informations sur le média dans le SDP.

Jetez un œil au flux d'appels mentionné dans la figure ci-dessous.

• Ici, Tom détecte un nouveau réseau,

• Utilise DHCP pour acquérir une nouvelle adresse IP, et

• Effectue une re-INVITE pour permettre la signalisation et le flux multimédia vers la nouvelle adresse IP.

Si l'UA peut recevoir des médias des deux réseaux, l'interruption est négligeable. Si ce n'est pas le cas, quelques paquets multimédias peuvent être perdus, entraînant une légère interruption de l'appel.

Le re-INVITE apparaîtrait comme suit -

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

Le re-INVITE contient la nouvelle adresse IP de Bowditch dans les champs d'en-tête Via et Contact et des informations sur les médias SDP.

Mobilité en milieu d'appel (avec remplacer l'en-tête)

Dans la mobilité de mi-appel, l'ensemble de routes réel (ensemble de proxys SIP que les messages SIP doivent traverser) doit changer. Nous ne pouvons pas utiliser un re-INVITE en mobilité midcall

Par exemple, si un proxy est nécessaire pour la traversée NAT, l'URI du contact doit être modifié - une nouvelle boîte de dialogue doit être créée. Par conséquent, il doit envoyer un nouveau INVITE avec un en-tête Replaces, qui identifie la session existante.

Note - Supposons que A et B sont tous les deux dans un appel et si A obtient un autre INVITE (disons de C) avec un en-tête de remplacement (doit correspondre au dialogue existant), alors A doit accepter l'INVITE et terminer la session avec B et transférer toutes les ressources vers dialogue nouvellement formé.

Le flux d'appels est illustré dans la figure suivante. Il est similaire au flux d'appels précédent utilisant re-INVITE, sauf qu'un BYE est automatiquement généré pour mettre fin au dialogue existant lorsque l'invitation avec les remplacements est acceptée.

Voici les points à noter dans ce scénario -

• Le dialogue existant entre Tom et Jerry inclut l'ancien serveur proxy visité.

• La nouvelle boîte de dialogue utilisant le nouveau réseau sans fil nécessite l'inclusion du nouveau serveur proxy visité.

• En conséquence, une INVITE avec des remplacements est envoyée par Tom, qui crée une nouvelle boîte de dialogue qui inclut le nouveau serveur proxy visité mais pas l'ancien serveur proxy visité.

• Lorsque Jerry accepte l'invitation, un BYE est automatiquement envoyé pour mettre fin à l'ancienne boîte de dialogue qui achemine via l'ancien serveur proxy visité qui n'est plus impliqué dans la session.

• La session multimédia résultante est établie à l'aide de la nouvelle adresse IP de Tom du SDP dans INVITE.

Mobilité de service

Les services dans SIP peuvent être fournis dans des proxies ou dans des UA. Fournir une mobilité de service avec une mobilité personnelle peut être difficile à moins que les appareils de l'utilisateur ne soient configurés de manière identique avec les mêmes services.

SIP peut facilement prendre en charge la mobilité des services sur Internet. Lorsqu'il est connecté à Internet, un UA configuré pour utiliser un ensemble de proxies en Inde peut toujours utiliser ces proxies en itinérance en Europe. Cela n'a aucun impact sur la qualité de la session média car le média circule toujours directement entre les deux UA et ne traverse pas les serveurs proxy SIP.

Les services résidents du point de terminaison sont disponibles uniquement lorsque le point de terminaison est connecté à Internet. Un service de terminaison tel qu'un service de transfert d'appel implémenté dans un point d'extrémité échouera si le point d'extrémité a temporairement perdu sa connexion Internet. Par conséquent, certains services sont mis en œuvre dans le réseau à l'aide de serveurs proxy SIP.

Parfois, un serveur proxy transfère un seul appel SIP à plusieurs points de terminaison SIP. Ce processus est connu sous le nom de fourche. Ici, un seul appel peut faire sonner plusieurs terminaux en même temps.

Avec la fonction SIP forking, vous pouvez faire sonner votre téléphone de bureau en même temps que votre softphone ou un téléphone SIP sur votre mobile, ce qui vous permet de prendre facilement l'appel de l'un ou l'autre appareil.

Généralement, dans un bureau, supposons que le patron soit incapable de prendre l'appel ou absent, la fourche SIP permet au secrétaire de répondre aux appels de son poste.

Le fork sera possible s'il y a un proxy avec état disponible car il doit fonctionner et répondre parmi les nombreux qu'il reçoit.

Nous avons deux types de fourches -

• Fourche parallèle
• Fourche séquentielle

Fourche parallèle

Dans ce scénario, le serveur proxy va bifurquer l'INVITE vers, disons, deux périphériques (UA2, UA3) à la fois. Les deux appareils généreront 180 Ringing et quiconque recevra l'appel générera un 200 OK. La réponse (supposons UA2) qui atteint en premier l'expéditeur établira une session avec UA2. Pour l'autre réponse, un CANCEL sera déclenché.

Si l'expéditeur reçoit les deux réponses simultanément, alors basé sur la valeur q, il transmettra la réponse.

Fourche séquentielle

Dans ce scénario, le serveur proxy va bifurquer l'INVITE vers un périphérique (UA2). Si UA2 est indisponible ou occupé à ce moment-là, le proxy le redirigera vers un autre périphérique (UA3).

Branche - ID et étiquette

Les ID de branche aident les proxys à faire correspondre les réponses aux requêtes fourchues. Sans les ID de branche, un serveur proxy ne serait pas en mesure de comprendre la réponse fourchue. L'identifiant de branche sera disponible dans l'en-tête Via.

Les balises sont utilisées par l'UAC pour distinguer plusieurs réponses finales de différents UAS. Un UAS ne peut pas résoudre si la demande a été fourchue ou non. Par conséquent, il doit ajouter une balise.

Les mandataires peuvent également ajouter des balises si cela génère une réponse finale, ils n'insèrent jamais de balises dans les demandes ou les réponses qu'ils transmettent.

Il est possible qu'une seule demande puisse également être acheminée par plusieurs serveurs proxy. Ainsi, le proxy qui ferait une fourchette ajoutera ses propres identifiants uniques aux branches qu'il a créées.

Jambe d'appel et ID d'appel

Une étape d'appel fait référence à une relation de signalisation un à un entre deux agents utilisateurs. L'ID d'appel est un identifiant unique transporté dans le message SIP qui fait référence à l'appel. Un appel est une collection de segments d'appel.

Un UAC commence par envoyer une INVITE. En raison de la fourche, il peut recevoir plusieurs 200 OK de différents UA. Chacun correspond à une étape d'appel différente dans le même appel.

Un appel est donc un groupe de segments d'appel. Un tronçon d'appel fait référence à une connexion de bout en bout entre les UA.

Les espaces CSeq dans les deux directions d'un tronçon d'appel sont indépendants. Dans une seule direction, le numéro de séquence est incrémenté pour chaque transaction.

Messagerie vocale

La messagerie vocale est très courante de nos jours pour les utilisateurs d'entreprise. C'est une application téléphonique. Il vient à l'image lorsque l'appelé est indisponible ou incapable de recevoir l'appel, le PBX annoncera à l'appelant de laisser un message vocal.

L'agent utilisateur recevra une réponse 3xx ou sera redirigé vers le serveur de messagerie vocale si le numéro de l'appelé est inaccessible. Cependant, une sorte d'extension SIP est nécessaire pour indiquer au système de messagerie vocale la boîte vocale à utiliser, c'est-à-dire le message d'accueil à lire et l'emplacement de stockage du message enregistré. Il y a deux façons d'y parvenir -

• En utilisant une extension de champ d'en-tête SIP

• En utilisant Request-URI pour signaler ces informations

Supposons pour l'utilisateur sip:[email protected] a un système de messagerie vocale à sip: voicemail.tutorialspoint.com qui fournit la messagerie vocale, l'URI de demande de l'INVITE lorsqu'il est transmis au serveur de messagerie vocale pourrait ressembler à -

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

L'illustration suivante montre comment Request-URI porte l'identifiant de la boîte aux lettres et la raison (ici 486).

Comme nous le savons, un serveur proxy peut être sans état ou avec état. Ici, dans ce chapitre, nous aborderons plus en détail les serveurs proxy et le routage SIP.

Serveur proxy sans état

Un serveur proxy sans état transfère simplement le message qu'il reçoit. Ce type de serveur ne stocke aucune information sur l'appel ou la transaction.

• Les mandataires sans état oublient la requête SIP une fois qu'elle a été transmise.
• La transaction sera rapide via des proxys sans état.

Serveur proxy avec état

Un serveur proxy avec état assure le suivi de chaque demande et réponse qu'il reçoit. Il peut utiliser les informations stockées à l'avenir, si nécessaire. Il peut retransmettre la demande s'il ne reçoit pas de réponse de l'autre côté.

• Les proxys avec état se souviennent de la demande une fois qu'elle a été transmise, afin qu'ils puissent l'utiliser pour le routage avancé. Les proxys avec état maintiennent l' état de la transaction . La transaction implique l'état de la transaction,notétat de l'appel .

• La transaction n'est pas aussi rapide avec les proxys avec état que sans état.

• Les mandataires avec état peuvent bifurquer et retransmettre si nécessaire (par exemple: renvoi d'appel occupé, par exemple).

Via et Record-route

Record-Route

L'en-tête Record-Route est inséré dans les demandes par des mandataires qui voulaient être dans le chemin des demandes suivantes pour le même identifiant d'appel. Il est ensuite utilisé par l'agent utilisateur pour acheminer les demandes suivantes.

Via

Les en-têtes Via sont insérés par les serveurs dans les requêtes pour détecter les boucles et pour aider les réponses à retrouver leur chemin vers le client. Ceci est utile pour que seules les réponses atteignent leur destination.

• Un UA lui-même génère et ajoute sa propre adresse dans un champ d'en-tête Via lors de l'envoi de la demande.

• Un mandataire qui transmet la demande ajoute un champ d'en-tête Via contenant sa propre adresse en haut de la liste des champs d'en-tête Via.

• Un mandataire ou UA générant une réponse à une demande copie tous les champs d'en-tête Via de la demande dans l'ordre dans la réponse, puis envoie la réponse à l'adresse spécifiée dans le champ d'en-tête Via supérieur.

• Un mandataire recevant une réponse vérifie le champ d'en-tête Via supérieur et correspond à sa propre adresse. S'il ne correspond pas, la réponse a été rejetée.

• Le champ d'en-tête Via supérieur est alors supprimé et la réponse transmise à l'adresse spécifiée dans le champ d'en-tête Via suivant.

Les champs d'en-tête contiennent le nom de protocole, le numéro de version et le transport (SIP / 2.0 / UDP, SIP / 2.0 / TCP, etc.) et contiennent des numéros de port et des paramètres tels que reçu, rport, branch.

• Une étiquette reçue est ajoutée à un champ d'en-tête Via si un UA ou un mandataire reçoit la demande d'une adresse différente de celle spécifiée dans le champ d'en-tête Via supérieur.

• Un paramètre de branche est ajouté aux champs d'en-tête Via par les UA et les mandataires, qui est calculé comme une fonction de hachage du Request-URI, et du numéro To, From, Call-ID et CSeq.

SIP (Softphone) et PSTN (Old phone) sont tous deux des réseaux différents et parlent des langues différentes. Nous avons donc besoin d'un traducteur (Gateway ici) pour communiquer entre ces deux réseaux.

Prenons un exemple pour montrer comment un téléphone SIP passe un appel téléphonique vers un PSTN via une passerelle PSTN.

Dans cet exemple, Tom (sip:[email protected]) est un téléphone SIP et Jerry utilise un numéro de téléphone mondial +91401234567.

SIP vers PSTN via des passerelles

L'illustration suivante montre un flux d'appels de SIP vers PSTN via des passerelles.

Vous trouverez ci-dessous une explication étape par étape de tout le processus qui se déroule lors du passage d'un appel d'un téléphone SIP vers le RTPC.

• Tout d'abord, (Tom) SIP phone compose le numéro global +91401234567 pour joindre Jerry. L'agent utilisateur SIP le comprend comme un numéro global et le convertit en request-uri à l'aide de DNS et déclenche la demande.

• Le téléphone SIP envoie l'INVITE directement à la passerelle.

• La passerelle initie l'appel dans le RTPC en sélectionnant une jonction SS7 ISUP vers le commutateur téléphonique suivant dans le RTPC.

• Les chiffres composés à partir de l'INVITE sont mappés dans l'IAM ISUP. Le message d'adresse complète ISUP (ACM) est renvoyé par le RTPC pour indiquer que la jonction a été créée.

• Le téléphone génère une sonnerie et passe au commutateur téléphonique. La passerelle mappe l'ACM à la réponse 183 Progression de session contenant un SDP indiquant le port RTP que la passerelle utilisera pour relier l'audio du PSTN.

• A la réception du 183, l'UAC de l'appelant commence à recevoir les paquets RTP envoyés depuis la passerelle et présente l'audio à l'appelant afin qu'il sache que l'appelé progresse dans le PSTN.

• L'appel se termine lorsque l'appelé répond au téléphone, ce qui amène le commutateur téléphonique à envoyer un message de réponse (ANM) à la passerelle.

• La passerelle coupe alors la connexion audio PSTN dans les deux sens et envoie une réponse 200 OK à l'appelant. Comme le chemin du média RTP est déjà établi, la passerelle répond au SDP dans le 183 mais n'entraîne aucune modification de la connexion RTP.

• L'UAC envoie un ACK pour terminer l'échange de signalisation SIP. Comme il n'y a pas de message équivalent dans ISUP, la passerelle absorbe l'ACK.

• L'appelant envoie BYE à la passerelle pour terminer. La passerelle mappe le BYE dans le message de libération ISUP (REL).

• La passerelle envoie le 200OK au BYE et reçoit un RLC du PSTN.

Un codec, abréviation de codeur-décodeur, effectue deux opérations de base -

• Premièrement, il convertit un signal vocal analogique en sa forme numérique équivalente afin qu'il puisse être facilement transmis.

• Ensuite, il reconvertit le signal numérique compressé en sa forme analogique d'origine afin qu'il puisse être rejoué.

Il existe de nombreux codecs disponibles sur le marché - certains sont gratuits tandis que d'autres nécessitent une licence. Les codecs varient en termes de qualité sonore et de bande passante en conséquence.

Les périphériques matériels tels que les téléphones et les passerelles prennent en charge plusieurs codecs différents. Tout en se parlant, ils négocient le codec qu'ils utiliseront.

Ici, dans ce chapitre, nous allons discuter de quelques codecs audio SIP populaires qui sont largement utilisés.

G.711

G.711 est un codec qui a été introduit par l'UIT en 1972 pour une utilisation dans la téléphonie numérique. Le codec a deux variantes:A-Law est utilisé en Europe et dans les liaisons téléphoniques internationales, uLaw est utilisé aux États-Unis et au Japon.

• G.711 utilise une compression logarithmique. Il réduit chaque échantillon 16 bits à 8 bits, ce qui lui permet d'atteindre un taux de compression de 1: 2.

• Le débit est de 64 kbit / s pour une direction, donc un appel consomme 128 kbit / s.

• G.711 est le même codec utilisé par le réseau PSTN, il offre donc la meilleure qualité vocale. Cependant, il consomme plus de bande passante que les autres codecs.

• Cela fonctionne mieux dans les réseaux locaux où nous avons beaucoup de bande passante disponible.

G.729

G.729 est un codec avec des exigences de faible bande passante; il offre une bonne qualité audio.

• Le codec encode l'audio par trames de 10 ms. Étant donné une fréquence d'échantillonnage de 8 kHz, une trame de 10 ms contient 80 échantillons audio.

• L'algorithme de codec code chaque trame sur 10 octets, de sorte que le débit binaire résultant est de 8 kbit / s dans une direction.

• G.729 est un codec sous licence. Les utilisateurs finaux qui souhaitent utiliser ce codec doivent acheter un matériel qui l'implémente (que ce soit un téléphone ou une passerelle VoIP).

• Une variante fréquemment utilisée de G.729 est G.729a. Il est compatible avec le codec d'origine, mais a des exigences de processeur inférieures.

G.723.1

G.723.1 est le résultat d'un concours que l'UIT a annoncé dans le but de concevoir un codec qui permettrait des appels sur des liaisons modem à 28,8 et 33 kbit / s.

• Nous avons deux variantes de G.723.1. Ils fonctionnent tous deux sur des trames audio de 30 ms (soit 240 échantillons), mais les algorithmes diffèrent.

• Le débit de la première variante est de 6,4 kbit / s, tandis que pour la deuxième variante, il est de 5,3 kbit / s.

• Les trames codées pour les deux variantes sont respectivement de 24 et 20 octets.

GSM 06.10

GSM 06.10 est un codec conçu pour les réseaux mobiles GSM. Il est également connu sous le nom de GSM Full Rate.

• Cette variante du codec GSM peut être librement utilisée, vous la trouverez donc souvent dans les applications VoIP open source.

• Le codec fonctionne sur des trames audio de 20 ms (soit 160 échantillons) et il compresse chaque trame à 33 octets, de sorte que le débit binaire résultant est de 13 kbit /.

Un agent d'utilisateur dos à dos (B2BUA) est un élément de réseau logique dans les applications SIP. C'est un type d'UA SIP qui reçoit une demande SIP, puis reformule la demande et l'envoie en tant que nouvelle demande.

Contrairement à un serveur proxy, il maintient l'état des dialogues et doit participer à toutes les requêtes envoyées sur les dialogues qu'il a établis. Un B2BUA brise la nature de bout en bout du SIP.

B2BUA - Comment ça marche?

Un agent B2BUA fonctionne entre deux points de terminaison d'un appel téléphonique et divise le canal de communication en deux call legs. B2BUA est une concaténation d'UAC et d'UAS. Il participe à toute la signalisation SIP entre les deux extrémités de l'appel, il a établi. Comme B2BUA disponible dans un fournisseur de services de dialogue peut implémenter certaines fonctionnalités à valeur ajoutée.

Dans le tronçon d'appel d'origine, le B2BUA agit en tant que serveur d'agent d'utilisateur (UAS) et traite la demande en tant que client d'agent d'utilisateur (UAC) vers l'extrémité de destination, gérant la signalisation entre les points d'extrémité dos à dos.

Un B2BUA conserve l'état complet des appels qu'il gère. Chaque côté d'un B2BUA fonctionne comme un élément de réseau SIP standard comme spécifié dans la RFC 3261.

Fonctions de B2BUA

Un B2BUA fournit les fonctions suivantes -

• Gestion des appels (facturation, déconnexion automatique des appels, transfert d'appel, etc.)

• Interfonctionnement de réseau (peut-être avec adaptation de protocole)

• Masquage des internes du réseau (adresses privées, topologie du réseau, etc.)

Souvent, les B2BUA sont également implémentés dans les passerelles multimédias pour relier les flux multimédias pour un contrôle total sur la session.

Exemple de B2BUA

De nombreux systèmes téléphoniques d'entreprise PBX (PBX) intègrent une logique B2BUA.

Certains pare-feu ont intégré la fonctionnalité ALG (Application Layer Gateway), qui permet à un pare-feu d'autoriser le trafic SIP et multimédia tout en maintenant un haut niveau de sécurité.

Un autre type commun de B2BUA est connu sous le nom de contrôleur de frontière de session (SBC).