2 SIP (Session Initiation Protocol)
Transcription
2 SIP (Session Initiation Protocol)
SIP Session Initiation Protocol Introduction ..............................................................................................................3 SIP (Session Initiation Protocol) ...............................................................................3 2.1 But ....................................................................................................................3 2.2 SIP URI (Uniform Resource Identifier)...............................................................3 2.3 Eléments réseaux du SIP..................................................................................3 2.3.1 User Agents (UA) .......................................................................................3 2.3.2 Serveur Proxy ............................................................................................4 2.3.3 Registrar ....................................................................................................4 2.3.4 Redirect Server ..........................................................................................4 2.4 Messages SIP...................................................................................................5 2.5 Transaction SIP ................................................................................................7 2.6 Dialogue SIP .....................................................................................................8 2.7 Scénarios SIP typiques .....................................................................................8 2.7.1 Inscription ..................................................................................................8 2.7.2 Invitation à la session.................................................................................8 2.7.3 Fin de la session ........................................................................................9 2.7.4 Record routing ...........................................................................................9 2.7.5 Strict versus loose routing ........................................................................10 2.7.6 Souscription à un événement et notification .............................................10 2.7.7 Messages instantanés .............................................................................11 3 Conclusion .............................................................................................................12 4 Références.............................................................................................................13 1 2 1 Introduction Ce document décrit les grandes lignes de la Session Initiation Protocol SIP. Nous allons voir dans les différentes sections le but du SIP, les différentes entités qui le composent, le format de message qu’il utilise. Nous allons également définir ce que c’est une transaction, dialogue SIP pour enfin voir un scénario typique du SIP. 2 SIP (Session Initiation Protocol) 2.1 But SIP est un protocole de contrôle de la couche application. Ce protocole (basé sur le protocole http : hypertext transfert protocol) est utilisé pour créer, modifier et terminer des sessions. Une session est l’ensemble d' émetteur et récepteurs qui communiquent entre eux ainsi que l' état à conserver pendant la communication. Une session peut inclure des appels téléphoniques Internet, une distribution multimédia, une conférence multimédia …avec un participant ou plus. But du SIP: • Rendre la communication possible. La communication elle-même doit être accomplie par un autre moyen. Les 2 protocoles utilisés le plus souvent avec SIP sont RTP (Real Time Transport) et SDP (Session Data Point), lequel est utilisé pour décrire et encoder les capacités des participants de la session. • SIP est utilisé pour transporter la description des paramètres de la session. Cette description est encodée dans un document qui utilise SDP. 2.2 SIP URI (Uniform Resource Identifier) Un SIP URI est de la forme sip :username@domain. 2.3 Eléments réseaux du SIP 2.3.1 User Agents (UA) Les UAs sont des end points Internet qui utilisent SIP pour se trouver et pour négocier une session. Habituellement, les UAs résident sur l' ordinateur d' un utilisateur comme application, mais peuvent être aussi un téléphone cellulaire, PSTN (Public Switched Telephone Network), PDAs (Personal Digital Assistant)... Chaque UA contient un UAC (User Agent Client) et un UAS (User Agent Server) : UAC: partie d' UA qui envoie la requête et reçoit la réponse. UAS: partie d' UA qui envoie des réponses et reçoit la requête. 2.3.2 Serveur Proxy Le proxy exécute l’acheminement d' une invitation à une session - d' après l' emplacement de l’actuel invité -, l’authentification, la comptabilité... Il existe deux types de serveur proxy : Serveurs stateless : ils acheminent les messages indépendamment les uns des autres, ils ne prennent pas soin des transactions. Serveurs stateful : ils maintiennent l’état des requêtes pour la durée de la transaction. Ils absorbent la rediffusion, et ils peuvent exécuter des méthodes plus compliquées pour trouver un utilisateur. 2.3.3 Registrar Un registrar est une entité qui reçoit les inscriptions des utilisateurs. Elle extrait l’information au sujet de l’emplacement (adresse IP, port, username) de ces utilisateurs et l’entrepose dans une base de données : la location database. L' UA doit rafraîchir régulièrement son inscription. Figure 1- Vue d'ensemble du registrar 2.3.4 Redirect Server Un redirect server est une entité qui reçoit une requête et renvoie une réponse. Il reçoit des requêtes et cherche le destinataire prévu dans la location database créée par un registrar. Il crée alors une liste d' emplacements courants des utilisateurs et l' envoie à l' initiateur de la requête dans une réponse classe 3xx. L' initiateur de la requête extrait la liste des destinations et leur envoie directement une autre requête. Figure 2 - Réacheminement 2.4 Messages SIP La communication qui utilise SIP (souvent appelé signalling) comprend une série de messages. Les messages sont soit une requête d' un client à un serveur soit une réponse d' un serveur à un client. Les messages peuvent être transportés indépendamment par le réseau. Requêtes: utilisées pour commencer des actions ou informer un destinataire de la requête. Réponses: utilisées pour confirmer qu' une requête a été reçue et traitée, ou pour indiquer le statut du traitement. Format d’un message générique : start-line *message-header CRLF [message-body] En détail: start-line = Request-line/Status-line Requêtes start-line = Request-line Request-line = Methods (sp) Request-URI (sp) SIP-Version REGISTER INVITE ACK CANCEL BYE OPTIONS Réponses : lie une adresse permanente à l’emplacement courant : : : : : commence une session confirme l’établissement de la session annule un ‘’pending’’ INVITE termine la session demande au serveur ses capacités start-line = Status-line Status-line = SIP-Version (sp) Status-Code (sp) Reason-Phrase Status-code : code de 3 nombres entiers qui est le résultat d' une tentative de compréhension et de satisfaction d’une requête. Il y 6 classes de réponses : 1xx : Provisoire la requête a été reçue, et est en train d’être traitée. 2xx: Succès 3xx : Réacheminement 100 Trying, 180 Ringing, 181 Call is being forwarded l' action a été reçue avec succès, comprise et acceptée. 200 Ok des actions supplémentaires sont nécessaires afin de compléter la requête. 300 Multiple choice, 301 Moved permanently, 302 Moved temporarily 4xx: Erreur client la requête contient une mauvaise syntaxe ou ne peut pas être accomplie sur ce serveur. 400 Bad request, 401 Unauthorized, 482 Loop detect, 486 Busy here 5xx: Erreur serveur 6xx : Échec global le serveur a échoué à l’accomplissement d’une requête apparemment valide. la requête ne peut être accomplie par aucun serveur La Reason-Phrase est prévue pour donner une courte description textuelle du Statuscode. 2.5 Transaction SIP Transaction: séquence de messages SIP (une requête et toutes les réponses à cette requête) échangés entre les différents éléments du SIP. Si une transaction avait été commencée par une requête INVITE, alors la même transaction inclut aussi l’ACK, mais seulement dans le cas où la dernière réponse n' était pas une réponse de la classe 2xx. Si la dernière réponse était une réponse 2xx, alors l' ACK n' est pas considéré comme faisant partie de la transaction. Une transaction a un aspect client – client transaction - et un aspect serveur – server transaction -, qui changent en fonction de l’activité à un moment donné. Client transaction : reçoit la requête d' un TU (Transaction User) qui est un UA ou un stateful proxy, et délivre la requête à un serveur de transactions. Server transaction : reçoit la requête de la couche transport et la délivre au TU. Filtre toute rediffusion de la requête, accepte la réponse du TU et la délivre à la couche transport Un stateless proxy n’a ni un client, ni un serveur de transaction. La transaction existe entre l' UA ou un stateful proxy d’un côté, et l' UA ou un stateful proxy de l’autre côté. Figure 3 - transaction SIP 2.6 Dialogue SIP Les dialogues sont identifiés en utilisant le call-ID, l’étiquette From et l’étiquette To. Les messages dont ces 3 champs sont respectivement identiques appartiennent à un même dialogue. Figure 4 - Dialogue SIP 2.7 Scénarios SIP typiques Cette section donne une brève vue d' ensemble de scénarios SIP typiques qui habituellement composent la circulation SIP. 2.7.1 Inscription Comprend un message REGISTER suivi par un 200 Ok envoyé par le registrar si l' inscription est réussie. 2.7.2 Invitation à la session Une requête INVITE est envoyée habituellement à un proxy. Un 200 Ok est produit une fois que l’appelé prend le téléphone. La session est établie au moment où l’appelé reçoit l’ACK de l’appelant. Figure 5 - Flux du message INVITE 2.7.3 Fin de la session La fin de la session est faite en envoyant une requête BYE dans le dialogue établi par INVITE. Les messages BYE sont envoyés directement d’un UA à l' autre à moins qu' un proxy soit sur le chemin (path) de la requête INVITE, indiquant qu' il est souhaité rester sur le chemin défini dans le record routing. 2.7.4 Record routing Toutes les requêtes dans un dialogue sont envoyées, par défaut, directement d' un UA à l' autre. Seules les requêtes hors du dialogue traversent le proxy. Un tel proxy insérerait le champ en-tête Record-route dans les messages SIP. Les messages envoyés dans un dialogue traverseront alors tous le proxy SIP qui a mis un champ en-tête Record-route dans le message. Figure 6 - Flux du Message BYE avec et sans Record routing 2.7.5 Strict versus loose routing Strict routing : sauve le request-URI original comme le dernier champ de l' en-tête de la Route. Loose routing : le request-URI contient toujours l’URI de l’UA de la destination. S' il n’y a aucun en-tête du champ Route dans un message, le message est envoyé à l' URI du Route le plus élevé. 2.7.6 Souscription à un événement et notification La spécification du SIP a été étendue pour supporter un mécanisme général qui autorise la souscription aux événements asynchrones. De tels événements peuvent inclure un changement statistique du proxy SIP, une information sur la présence, un changement au niveau de la session etc. Ce mécanisme est utilisé principalement pour transmettre de l' information sur la présence de l’utilisateur. Figure 7 - Souscription aux événements et notification 2.7.7 Messages instantanés Les messages instantanés sont envoyés en utilisant une requête MESSAGE. Ces requêtes n' établissent pas de dialogue et par conséquent ils traverseront toujours le même ensemble de proxy. C' est la forme la plus simple pour envoyer des messages instantanés. Le texte du message est envoyé dans le corps de la requête SIP. Figure 8 - Messages instantanés 3 Conclusion SIP est un protocole de signalisation pour les applications de téléphonie et la visioconférence sur Internet. Sa simplicité et son intégration au monde IP, fait qu' il vient bousculer le mastodonte H.323 déjà bien implanté. Il intervient aux différentes phases de l' appel. SIP fournit les mécanismes protocolaires nécessaires pour que les machines et des serveurs puissent fournir des services comme la redirection d’appel…Il permet de joindre les utilisateurs par des adresses de type e-mail, et réutilise l’infrastructure du courrier électronique. Des adresses SIP ( URLs ) peuvent également être incluses dans des pages WEB. Etant utilisé typiquement au-dessus d’UDP ou de TCP, SIP peut être utilisé au-dessus d’IPX ou d’autres protocoles. Bien sûr SIP n’est pas le seul standard de la téléphonie sur IP. L’approche qui s’impose aujourd’hui est basée sur la norme H.323 de l’UIT(Union Internationale des Télecommunications). Conçue initialement pour les conférences multimédia sur les LANs sans garantie de qualité de service, et donc couvrant un spectre plus large que la téléphonie, H.323 se révèle bien adapté pour fédérer les différents systèmes existants de voix sur IP. Depuis son approbation en 1996, le standard H.323 fournit un cadre pour les communications audio, vidéo et de données sur les réseaux IP. Il concerne le contrôle des appels, la gestion du multimédia, la gestion de la bande passante pour les conférences point-à-point et multipoints. Dans ce cadre, H.323 traite essentiellement de l’interfaçage entre le LAN et les réseaux commutés, tels que le réseau téléphoniques ou le RNIS. La norme H.323 spécifie toute une suite de protocoles qui doivent être supportés pour garantir l.interopérabilité entre produits conformes au standard. Dans le domaine de la téléphonie sur IP, ces protocoles couvrent notamment le codage et la transmission de la voix ainsi que la signalisation et certains éléments d’adressage. 4 Références [1] D.Sisalem, J.Kuthan, ‘’Understanding SIP’’. [2] H.Schulzrinne, ‘’The Session Initiation Protocol (SIP)’’, septembre 2000. [3] J.Rosenberg, H.Schulzrinne, ‘’SIP : Session Initiation Protocol’’, RFC 3261, juin 2002. [4] A. Gomez, ‘’Téléphonie sur réseaux de données’’, 2002. [5] H.T. Kung, ‘’Computer Networks (SIP)”, avril 2003 [6] J. Janak, ‘’SIP Introduction’’, 2003.