Précédent Sommaire Suivant
Lorsqu’un utilisateur utilise une application dont le but est de le faire communiquer avec d’autres utilisateurs (s’il n’y en a qu’un, on parle d’unicast -téléphonie sur IP- et s’il y en a plusieurs, on parle de multicast –visioconférence ou forum-), cette application fait appel au protocole SIP en lui précisant la nature des échanges. SIP choisit ensuite, parmi les 5 protocoles détaillés dans l'architecture en couche, les mieux adaptés à ces échanges et détermine le nombre de sessions à ouvrir. Pour véhiculer de la vidéo, par exemple, 2 sessions doivent être ouvertes : l’une pour l’image et l’autre pour le son. Et pour un échange en unicast, 4 sessions seront ouvertes : 2 pour la communication vidéo montante et 2 pour la descendante.
Pour établir la communication entre l'UAC du terminal appelant et l'UAS du terminal appelé, ceux-ci doivent être identifiés. Ainsi, chaque utilisateur et sa machine est identifié par une adresse appelée URL SIP qui se présente comme une URL Mailto ou Telnet :
Dans la plupart des cas, une adresse SIP est obtenue à partir de l’adresse email. La partie utilisateur est composée d’un nom ou d’un numéro de téléphone alors que la partie machine est un nom de domaine ou une adresse numérique de réseau.
Pour localiser un serveur SIP, le client envoie une requête URI au serveur proxy le plus proche. L’adresse IP du destinataire n’est alors pas précisée. Si le client souhaite communiquer avec son destinataire, il envoie une requête URI directement vers le port d’entrée de l'UAS du destinataire de la requête. Le protocole utilisé (TCP ou UDP), l’adresse IP et le port d’entrée du serveur du destinataire doivent donc être précisés, lors de l’émission d’une requête URI, par le client. Si le port d’entrée du serveur n’est pas précisé, alors c’est le numéro 5060 par défaut. Lorsque le serveur destinataire reçoit une requête, celui-ci la redirige vers la couche transport TCP ou UDP de son architecture. Si la requête URI ne précise aucun protocole, UDP est utilisé par défaut, puis TCP en cas d’échec. Si le serveur n’est pas joignable, un message ICMP est envoyé au client pour l’en informer. Rappelons que dans le cas d’applications nécessitant un transport en temps-réel, UDP est indispensable. Par contre, pour un transport fiable de données, TCP sera utilisé. En cas d’échec de localisation du serveur SIP distant, le client utilise D.N.S.(Domain Name Server) pour obtenir l’URL SIP d’un autre serveur SIP.
Une fois le client connecté à un serveur SIP distant, il peut lui adresser une ou plusieurs requêtes SIP et recevoir une ou plusieurs réponses de ce serveur. Les réponses contiennent certains champs identiquement remplis à ceux des requêtes : ce sont les champs Call-ID, Cseq, To et From que nous étudierons plus en détails au paragraphe II.7.6 qui présente les en-têtes des messages SIP. Dans le cas d’un transport TCP et d’une transaction simple(requête + réponse), requête et réponse SIP sont transportées par la même connexion TCP. Si plusieurs requêtes émanent d’un même client à destination d’un même serveur(unicast), soit une seule connexion est ouverte, soit une connexion pour chaque requête est ouverte. Dans le cas d’un transport UDP unicast, la réponse à la requête d’un client est retournée à l’adresse contenue dans le champs d’en-tête Via de la réponse, précisé au paragraphe II.7.6 également. Si la requête est transportée par UDP vers plusieurs serveurs (multicast), la réponse est dirigée vers la même adresse de multicast et le même port de destination.
Le champs Call-ID est un identificateur d’appel. Une conférence entre N interlocuteurs ou un appel téléphonique sur IP sont chacun associés à un Call-ID. Par conséquent, les N interlocuteurs d’une conférence, utilisent le même Call-ID.