N° d’ordre : 19 / RS / TCO Année Universitaire : 2012 / 2013

UNIVERSITÉ D’ANTANANARIVO

----------------------
ÉCOLE SUPÉRIEURE POLYTECHNIQUE
-----------------------
DÉPARTEMENT TÉLÉCOMMUNICATION

MÉMOIRE DE FIN D’ÉTUDES

en vue de l’obtention

du DIPLÔME d’INGÉNIEUR

Spécialité : Télécommunication

Option : Réseaux et Systèmes (RS)

par : RAMAMONJISOA Nomeny

Etude et implémentation du protocole SIP dans la mise en

œuvre des applications orientées téléphonie sur IP
Soutenu le 22 Décembre 2014 devant la Commission d’Examen composée de :

Président : M.RAKOTOMALALA Mamy Alain

Examinateurs : M.BOTO ANDRIANANDRASANA Jean Espérant

M.RAKOTONDRAINA Tahina Ezéchiel

M. ANDRIAMIHAJARISON Jimmy

Directeur de mémoire : M. RATSIHOARANA Constant

« Pour moi, m'approcher de Dieu, c'est mon bien : Je place mon refuge dans le
Seigneur, l'Éternel, Afin de raconter toutes tes œuvres».

Psaumes 73 : 28
 REMERCIEMENTS

Avant tout, loué soit l’Eternel tout puissant de m’avoir conseillé et indiqué le chemin à suivre dans
la réalisation de cet ouvrage comme il m’a promis au Psaumes 37 : 4 - 6 :

« Fais de l'Éternel tes délices, Et il te donnera ce que ton cœur désire. Recommande ton sort à
l'Éternel, Mets en lui ta confiance, et il agira. Il fera paraître ta justice comme la lumière, Et ton
droit comme le soleil à son midi ».

Ensuite, il ne serait possible d’aboutir à cette fin sans le concours de plusieurs personnes à qui nous
aimerons adresser notre profonde gratitude et vifs remerciements :

- Monsieur ANDRIANARY Philippe, professeur Titulaire, Directeur de l’Ecole Supérieure

Polytechnique d'Antananarivo, qui m'a donné l'opportunité de suivre mes études plus élevées
au sein de l’établissement
- Monsieur RAKOTOMALALA Mamy Alain, Maître de conférences, Chef de Département
Télécommunication, qui s’est toujours efforcé de trouver la meilleure voie pour nous, lors
de notre formation et qui a fait l’honneur d’accepter la présidence du Jury.
- Monsieur RATSIHOARANA Constant qui m’a apporté aides et conseils inestimables durant
toute la préparation de ce travail en tant que Directeur de mémoire.

Mes vifs remerciements s’adressent aux autres membres de Jury, pour leur contribution significative
à l’amélioration de ce travail :

- M.BOTO ANDRIANANDRASANA Jean Espérant, Assistant d’Enseignement et de

Recherche, membre de Jury.
- M. RAKOTONDRAINA Tahina Ezéchiel, Maître de Conférences, membre de Jury.
- M. ANDRIAMIHAJARISON Jimmy, Enseignant Chercheur, membre de Jury.

Je joins à ce témoignage de reconnaissance tous nos Enseignants et Personnels de l’École Supérieure

Polytechnique d'Antananarivo pour le dévouement exemplaire qu’ils ont manifesté durant ces cinq
années d’étude pour notre réussite.

Ma très grande attention sera naturellement à ma famille pour leur amour et leur soutien Je reconnais
les sacrifices que ces longues années ont représentés et je les remercie d'avoir appuyé mes choix et
d'avoir toujours su m'encourager.

i
Mes pensées particulières vont à l’endroit de mes amis et mes collègues pour leur aide et appui.
Qu’ils trouvent dans ces lignes tous mes remerciements.

Et que tous ceux qui ont contribué de près ou de loin à l’élaboration de ce présent mémoire trouvent
ici l’expression de ma profonde gratitude. MERCI à tous.

ii
 TABLE DES MATIÈRES

REMERCIEMENTS ...................................................................................................................................... i

TABLE DES MATIÈRES ........................................................................................................................... iii

NOTATIONS ET ABRÉVIATIONS .......................................................................................................... vi

INTRODUCTION GÉNÉRALE.................................................................................................................. 1

CHAPITRE 1 ................................................................................................................................................. 3

LES RESEAUX NGN ET LE PROTOCOLE SIP ..................................................................................... 3

1.1 Introduction ......................................................................................................................................... 3

1.2 Architecture du réseau NGN[1][2] .................................................................................................... 3

1.3 Le réseau d'accès ................................................................................................................................. 4

1.3.1 Les réseaux d'accès fixes .............................................................................................................. 5

1.3.2 Les technologies radio locale ....................................................................................................... 5

1.3.3 Les réseaux d'accès mobiles ......................................................................................................... 5

1.4 La couche transport ............................................................................................................................ 5

1.5 La couche contrôle[4][5][7] ................................................................................................................ 6

1.5.1 Les entités fonctionnelles au cœur du réseau .............................................................................. 7

1.5.2 Les familles protocolaires ............................................................................................................. 8

1.6 Le protocole SIP .................................................................................................................................. 9

1.6.1 format d’adresse SIP[10] ............................................................................................................ 10

1.6.2 Les messages SIP ........................................................................................................................ 12

1.6.3 Transaction et dialogue SIP ....................................................................................................... 20

1.6.4 Architecture et entité SIP ........................................................................................................... 22

1.7 La couche service .............................................................................................................................. 24

1.8 Comparaison entre les protocoles H323 et SIP : ............................................................................ 24

1.9 Conclusion ......................................................................................................................................... 25

CHAPITRE 2 ............................................................................................................................................... 26

LA TECHNOLOGIE JAIN ........................................................................................................................ 26

iii
 2.1 Introduction ....................................................................................................................................... 26

2.2 Aperçu historique de JAIN[9][10] ................................................................................................... 26

2.3 API SIP dans l’architecture JAIN ................................................................................................... 27

2.4 L'Architecture et les interfaces JAIN[11] ....................................................................................... 28

2.4.1 Les couches d'abstractions ......................................................................................................... 29

2.4.2 Principe des interfaces de JAIN[12] .......................................................................................... 30

2.4.3 L'architecture de JAIN ............................................................................................................... 31

2.5 Les différentes APIs de JAIN[13] .................................................................................................... 31

2.6 Présentation générale de l’API JAIN-SIP....................................................................................... 32

2.7 Conclusion ......................................................................................................................................... 35

CHAPITRE 3 ............................................................................................................................................... 36

ANALYSE ET CONCEPTION DANS L’ENVIRONNEMENT SIP ..................................................... 36

3.1 Introduction ....................................................................................................................................... 36

3.2 Approches de développement de services SIP[11][12] ................................................................... 36

3.3 La conception de services de la téléphonie IP en utilisant SIP ........................................................ 37

3.4 Analyse[15] ........................................................................................................................................ 38

3.4.1 Expression des besoins ............................................................................................................... 39

3.4.2 Besoin non fonctionnels ............................................................................................................. 41

3.5 Spécification....................................................................................................................................... 42

3.6 Diagrammes d’activité ...................................................................................................................... 43

3.7 Schéma de fonctionnement et acheminement des messages SIP dans l’architecture ................. 44

3.8 Choix des scénarios pour le développement des applications et la mise en œuvre des services . 46

3.8.1 Identification des scénarios ........................................................................................................ 46

3.8.2 Diagramme de logique de fonctionnement dans l’environnement SIP .................................... 47

3.9 Conclusion ......................................................................................................................................... 49

CHAPITRE 4 ............................................................................................................................................... 50

Mise en œuvre et simulation des applications Proxy Server et Softphone ............................................. 50

4.1 Introduction[15][16][17] ................................................................................................................... 50

iv
 4.2 Conception globale ............................................................................................................................ 50

4.2.1 Diagramme de paquetage ........................................................................................................... 50

4.3 Programmation du proxy ................................................................................................................. 52

4.4 Simulation et validation .................................................................................................................... 52

4.4.1 Outils logiciels tests..................................................................................................................... 52

4.4.2 Matériels utilisés ......................................................................................................................... 52

4.4.3 Résultat de la simulation des différents scénarios établis ......................................................... 53

4.5 Discussion........................................................................................................................................... 53

4.6 Conclusion ......................................................................................................................................... 54

CONCLUSION GÉNÉRALE .................................................................................................................... 55

BIBLIOGRAPHIE ...................................................................................................................................... 56

FICHE DE RENSEIGNEMENTS ............................................................................................................. 58

RESUME ...................................................................................................................................................... 59

ABSTRACT ................................................................................................................................................. 59

v
 NOTATIONS ET ABRÉVIATIONS

Abréviations

AEG Application Expert Group

API Application Program Interfaces
ATM Asynchronous Transfer Mode
B2BUA Back to Back User Agent
BICC Bearer Independant Call Control
BSC Base Station Controllers
DNS Domain Name Service
GPRS General Packet Radio Service
GSM Global System for Mobile
HLR Home Location Registers
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IPSec Internet Protocol Security
ISUP ISDN User Part signaling
JMF Java Media Framework
LDAP Light weight Directory Access Protocol
MG Média Gateway
MGC Media Gateway Controller
MGCP Media Gateway Control Protocol
NAP Network Access Protection
NGN Next Generation Network
PDA Personal Digital Assistant
PEG Protocol Expert Group
PSTN Public Switched Telephone Network
RTC Réseau téléphonique commuté
RTSP Real Time Streaming Protocol
RSVP Resource Reservation Protocol
SAP Session Announcement Protocol
SCP Service Contrôle points

vi
SDP Session Description Protocol
SCTP Stream Control Transmission Protocol
SIGTRAN Signaling Transport over IP
SMTP Simple Message Transfert Protocole
SRTP Secure Real-time Transport Protocol
SSP Signaling Service Point
TCP Transmission Control Protocol
TCAP Transaction Capabilities Application Part
TDM Time Division Multiplexing
TU Transaction User
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
URL Uniform Resout Locator
WDM Wavelength Division Multiplexing
WLAN Wireless Local Area Network
xDSL x Digital Subscriber Line

vii
 INTRODUCTION GÉNÉRALE

Suite à l'explosion de la bande passante sur les réseaux IP et à l'avènement du haut débit chez les
professionnels comme chez les particuliers, de nouvelles techniques de communication sont
apparues ces dernières années. L'une des plus en vogue et des plus prometteuses actuellement, est
la « Voix sur IP ».

Dans le contexte actuel de mondialisation des échanges économiques et de l’information, une

demande toujours grandissante liée aux télécommunications s’exprime. Le principal frein au
déploiement de ces services réside dans le fort coût de facturation des fournisseurs de service
téléphoniques classiques. De plus, les fournisseurs de services ont toujours tendance à développer
des services propriétaires suivant leurs propres normes. En parallèle de ce fait, l’émergence aussi
violente que rapide de l’Internet témoigne des possibilités d’accès à l’information sans aucune
considération liée aux distances. C’est rare de nos jours de trouver une entreprise ne possédant pas
au moins un accès à Internet. Il est indéniable que la technologie paquet IP constitue alors la
technologie-clé pour le transport et la fourniture de services télécommunications et plus
particulièrement pour les services de téléphonie sur IP. A titre d’exemple, le nombre d’abonnés au
service Voix sur IP passera de 4,8 millions en 2004 à près de 300 millions en 2013.

Le domaine de l'Internet est global, ce qui a nécessité le développement de protocoles de

signalisation standardisés afin de garantir l'interopérabilité entre les différentes implantations de la
téléphonie IP. Parmi ces protocoles, on peut citer le protocole SIP. Il fournit la signalisation
nécessaire à la création, sur réseaux IP, des fonctions de téléphonie similaires à celles du protocole
ISUP dans le monde SS7. Les opportunités de développement de ce protocole suscitent depuis
quelques années un engouement considérable des communautés informatiques et des
télécommunications. Ceci laisse à penser que les futurs services de communication multimédia dans
les réseaux seront en grande partie basés sur le protocole SIP. Dû à ses avantages, SIP a été choisi
lors de cette étude.
C’est dans ces contextes que la technologie JAIN, basée sur la plateforme JAVA, introduit la
portabilité des services entre systèmes et permet des accès sécurisés aux ressources des différents
réseaux. Elle constitue ainsi une architecture de nouvelle génération qui permet de remplacer toutes
les interfaces propriétaires par d’autres qui sont standards. En effet, la spécification des APIs JAIN
se fait au sein du JCP (Java Community Process) ce qui permet à tout ce qui est intéressé de
participer.

1
Une demande des services de télécommunications plus avancés et plus complexes qui s'intègrent
facilement aux applications et aux protocoles de l'Internet est en augmentation. Ce qui a engendré
un besoin important de méthodes efficaces de création de services.
Ainsi le travail présenté dans ce mémoire de fin d’étude porte sur l’étude théorique du protocole SIP
et de l’architecture JAIN ainsi que la conception et le développement d'une architecture SIP orientée
traitement d’appels avec proposition de méthode de création de service. Les méthodes de réalisation
ainsi que les outils de mise en œuvre de services de la téléphonie IP en utilisant SIP sont variés. Le
choix effectué comporte l'API JAIN-SIP et JMF.
Ce mémoire est composé de quatre grands chapitres :
- La première partie parle du protocole SIP et d’une vue assez général le réseau NGN ;
- La deuxième partie présente la technologie JAIN;
- La troisième partie considère l’analyse et conception dans l’environnement SIP
- Enfin, la dernière partie constitue la mise en œuvre et simulation des applications Proxy
Server et softphone User Agent

2
 CHAPITRE 1
LES RESEAUX NGN ET LE PROTOCOLE SIP

1.1 Introduction

De nos jours, le monde des télécoms est une tendance forte qui suit une évolution plus moderne vers
des réseaux et des services de nouvelle génération en attirant une majorité d’acteurs. C’est le résultat
de la conjonction d’un ensemble de facteurs favorables dont :
 les évolutions profondes du secteur des télécommunications ;
 le développement de gammes de services nouveaux ;
 les progressions technologiques d'envergure dans le domaine des réseaux de données.

A partir de ce contexte, afin de moderniser le monde des télécoms, il faut une recherche de souplesse
d’évolution du réseau, une distribution de l’intelligence dans le réseau, et une ouverture à des
services tiers, c’est ainsi qu’a été créé un nouveau modèle de réseaux et de services appelé NGN
(Next Generation Networks).

Les NGN sont basés sur une évolution progressive vers le « tout IP » et sont modélisées en couches
indépendantes dialoguant via des interfaces ouvertes et normalisées. Les réseaux de
télécommunications traditionnels évolueront vers un modèle ouvert, distribué, fortement basé sur le
protocole IP et la transmission en mode paquet en général. Cette évolution technologique, tout en
étant transparente pour les utilisateurs, se fera de manière progressive pour les opérateurs.
Ce chapitre présentera une étude descriptive de l'ensemble de ces nouveaux concepts globalement
désignés sous l'appellation NGN. Il inclut aussi une synthèse des évolutions technologiques
majeures et le détail des nouveaux concepts liés aux NGN.

1.2 Architecture du réseau NGN[1][2]

Les réseaux de nouvelle génération peuvent être présentés comme un concept permettant de définir
et déployer des réseaux évolutifs et favorisant pour les fournisseurs de services et les opérateurs la
création et la gestion de services innovants. Les services doivent être évolutifs et accessibles
indépendamment du réseau d'accès utilisé.
Le NGN est caractérisé par plusieurs éléments essentiels :
 Un cœur de réseau unique et mutualisé pour tous types d'accès et de services ;
 Une architecture de cœur de réseau en trois couches : Transport, Contrôle et Services.

3
  Une évolution du transport en mode paquet (une convergence progressive vers le tout IP) ;
 Des interfaces ouvertes et normalisées entre chaque couche, et notamment au niveau des
couches contrôle et services afin de permettre la réalisation de services indépendants du
réseau ;
 Le support d'applications multiples, multimédia, temps réel, en mobilité totale, adaptables à
l'utilisateur et aux capacités des réseaux d'accès et des terminaux ;
 La prise en compte de réseaux d'accès multiples ;
 La prise en compte de terminaux multiples.

Figure 1.01: Principe d'architecture d'un réseau NGN

1.3 Le réseau d'accès

Actuellement, les principales technologies d’accès connues dont la généralisation contribuera à

alimenter le besoin et le développement des NGN sont les suivants : les réseaux d’accès fixes, les
technologies radio locale et les réseaux d’accès mobiles.

4
1.3.1 Les réseaux d'accès fixes

Les réseaux d'accès fixes s'adaptent progressivement au support de services de données à haut débit:

 Le réseau téléphonique commuté, initialement support des services voix, a permis une
ouverture à des services voix/données haut débit grâce aux technologies xDSL accessibles
aux nouveaux opérateurs par le biais du dégroupage de la boucle locale.

 L'accès Ethernet, initialement conçu pour fournir des services de données en entreprises,
voit son usage s'étendre en termes de débit, de périmètre d'utilisation et de services
transportés (voix et donnée, multimédia).

1.3.2 Les technologies radio locale

Plusieurs technologies permettent de fournir des services voix et données fixes en utilisant un accès
radio. On citera notamment la boucle locale radio. Les réseaux locaux sans fil et Bluetooth. Ces
technologies assez récentes, seront l'objet de mutations et développements très importants. Quant
aux réseaux satellitaires, plusieurs tentatives de déploiement déjà relativement anciennes ont mené
à des échecs (avant tout d'ordre économique du fait des coûts particulièrement élevés de
déploiement), mais ils pourraient, dans les prochaines années, trouver enfin leur place parmi les
réseaux d'accès effectivement utilisés pour fournir des services « fixes ».

1.3.3 Les réseaux d'accès mobiles

Plusieurs réseaux d'accès radio fournissant des services de radiocommunications mobiles publics
sont présentés.

Le GSM est une technologie historiquement orientée vers les services voix et données bas débit
mature et très largement répandue, mais évolue actuellement avec l'ajout de services de transmission
de données en mode paquet (GPRS), et à court terme avec l'émergence de la nouvelle génération «
convergente » voix/données/multimédia: l'UMTS.

1.4 La couche transport

La couche Transport gère l'acheminement du trafic vers sa destination. Les principales évolutions
du réseau de transport concernent les technologies de transmission et de commutation utilisées sur
les liaisons qui interconnectent les réseaux d'accès au cœur de réseau.

5
Maintenant, la question pertinente est de savoir comment les backbones sont susceptibles d'évoluer
afin de supporter un très haut débit, et surtout le transport unifié de flux mixtes
voix/donnée/multimédia avec une qualité de service adéquate.
Tout d'abord il faut distinguer entre le niveau réseau de transmission et le niveau réseau de
commutation dans un «réseau de transport» (couche transport) :
 Le réseau de transmission correspond au réseau physique de liens et de nœuds qui desservent
une zone (un immeuble, une ville, une région, un pays ou un continent).
 Le réseau de commutation correspond à certains nœuds qui permettent d'acheminer une
communication à travers le réseau de transmission en fonction de sa destination
Dans les architectures traditionnelles, un opérateur possède (ou loue) un réseau de transmission sur
lequel s'appuient en général plusieurs réseaux de commutation, le premier est consacré uniquement
à la commutation de la voix, le second pour la commutation de données.
Ainsi, pour les NGN, on parvient à fusionner ces deux réseaux en un seul. Si l'on visualise les
technologies mises en jeu en s'appuyant sur le modèle en couches OSI (Open System
Interconnection), la séparation entre réseau de transmission et réseau de commutation est très nette.
Pour la mise en œuvre de ces réseaux de transport « de nouvelle génération », on peut mettre en
évidence deux évolutions majeures des réseaux de transport au niveau des réseaux de transmission
et des réseaux de commutation.
Concernant les réseaux de transmission, les techniques dominantes sont remises en cause. En
effet, le multiplexage TDM (Time Division Multiplexing), utilisé en grande majorité dans les réseaux
actuels, est une technique de transmission adaptée pour la commutation de circuits alors que la
tendance actuelle est de migrer les réseaux de transmission actuels vers un réseau de transmission
unique, neutre, voire favorable à la commutation de paquets et donc on assiste aujourd'hui à des
nombreux développements autour du multiplexage WDM et aussi à des plusieurs évolutions liées à
l'optique et au WDM.

1.5 La couche contrôle[4][5][7]

Les évolutions au niveau de la couche contrôle sont majeures. Plusieurs nouveaux mécanismes
et protocoles sont mis en jeu et donc une nouvelle architecture qui découle. La couche Contrôle se
compose de serveurs dits « Softswitch » gérant d'une part les mécanismes de contrôle d'appel
(pilotage de la couche transport, gestion des adresses), et d'autre part l'accès aux services (profils
d'abonnés, accès aux plates-formes de services à valeur ajoutée).

6
1.5.1 Les entités fonctionnelles au cœur du réseau

a. La Média Gateway (MG)

Les Gateways ont un rôle essentiel: elles assurent non seulement l'acheminement du trafic, mais
aussi l'inter fonctionnement avec les réseaux externes et avec les divers réseaux d'accès. La Media
Gateway est située au niveau du transport des flux média entre le réseau RTC et les réseaux en mode
paquet, ou entre le cœur de réseau NGN et les réseaux d'accès. Elle a pour rôle le codage et la mise
en paquets du flux média reçu du RTC et vice versa (conversion du trafic TDM IP) et aussi la
transmission, suivant les instructions du Media Gateway Controller, des flux média reçus de part et
d'autre.
b. La Signalling Gateway (SG)

La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le réseau
NGN et le réseau externe interconnecté selon un format compréhensible par les équipements chargés
de la traiter, mais sans l'interpréter (ce rôle étant dévolu au Media Gateway Controller). Notamment,
elle assure l'adaptation de la signalisation par rapport au protocole de transport utilisé. Cette fonction
est souvent implémentée physiquement dans le même équipement que la Media Gateway, d'où le
fait que ce dernier terme est parfois employé abusivement pour recouvrir les deux fonctions MG +
SG.

c. Le serveur d'appel

Dans un réseau NGN, c'est le MGC qui possède « l'intelligence ». Il gère:

 L'échange des messages de signalisation transmise de part et d'autre avec les passerelles de
signalisation, et l'interprétation de cette signalisation.
 Le traitement des appels: dialogue avec les terminaux H.323, SIP voire MGCP,
communication avec les serveurs d'application pour la fourniture des services.
 Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du réseau,
etc.
 La réservation des ressources dans le MG et le contrôle des connexions internes au MG
(commande des Media Gateways).
Donc dans l'architecture des réseaux NGN, le serveur d'appel, aussi appelé Softswitch ou Media
Gateway Controller (MGC) est le nœud central qui supporte l'intelligence de communication.

7
1.5.2 Les familles protocolaires

La convergence des réseaux voix/données ainsi que le fait d'utiliser un réseau en mode paquet
pour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessité l'adaptation
de la couche Contrôle, en effet, ces réseaux en mode paquet étaient généralement utilisés comme
réseau de transport mais n'offraient pas de services permettant la gestion des appels et des
communications multimédia. Cette évolution a conduit à l'apparition de nouveaux protocoles,
principalement concernant la gestion des flux multimédia, au sein de la couche Contrôle.
On peut classer les protocoles de contrôle en différents groupes:
 Les protocoles de contrôle d'appel permettant l'établissement, généralement à l'initiative d'un
utilisateur, d'une communication entre deux terminaux ou entre un terminal et un serveur;
les deux principaux protocoles sont H.323, norme de l'UIT et SIP, standard développé à
l'IETF.
 Les protocoles de commande de Media Gateway qui sont issus de la séparation entre les
couches Transport et Contrôle permettent au Softswitch ou Media Gateway Controller de
gérer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control
Protocol) de l'IETF et H.248/MEGACO, développé conjointement par l'UIT et l'IETF, sont
actuellement les protocoles prédominants.
 Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway Controller)
permettant la gestion du plan contrôle au niveau du coeur de réseau avec des protocoles tels
que BICC (Bearer Independant Call Control), SIP-T (SIP pour la téléphonie) et H.323.
L'interconnexion avec les réseaux de signalisation SS7 se fait généralement via des
passerelles de signalisation ou Signalling Gateways par l'utilisation de protocole tel que
SIGTRAN.
De plus, l'interconnexion de ces réseaux de données avec les réseaux existants de téléphonie
(TDM avec signalisation SS7) a nécessité le développement de protocoles dédiés à l'interconnexion
des réseaux et au transport de la signalisation SS7 sur des réseaux en mode paquet.

8
 67
SIP
63
CONTROL/SIGNALING PROTOCOLS

46
H.248/MeGaCo
38

50
H.323 v1/2/3/4
38

42
MGCP
42

8
Vendor proprietary
17

0 10 20 30 40 50 60 70 80
PERSENT OF RESPONSABLE

2011 2010

Figure 1.02: Taux de déploiement des protocoles de signalisation IP

1.6 Le protocole SIP

Le protocole SIP est aujourd'hui un des protocoles dominants pour le support services télécoms
dans les réseaux IP.
Le protocole SIP a été défini à l'origine (1996) comme une combinaison de deux protocoles existants
: le protocole Session Invitation Protocol développé par Handley et E. Schooler et le protocole
Simple Conférence Invitation Protocol conçu par H. Schulzrinne. SIP est passé d'un protocole «
d'invitation » à un protocole d'établissement et de contrôle de sessions multimédia IP lui permettant
non seulement la fourniture et la gestion de services de type téléphonique mais aussi, non
téléphonique tels que : vidéoconférence, messagerie instantanée, présence ou encore transfert de
données. Une session SIP implique deux, voire plusieurs, participants qui peuvent être des
utilisateurs Internet ou plus généralement des systèmes possédant des adresses de type URI
(Uniform Resource Indicator).
SIP est essentiellement orienté point à point. Les spécifications de base de ce protocole sont définies
dans les RFC 3261 à 3266.

9
 Le protocole SIP était déjà à partir de 2007 le protocole privilégié par les opérateurs
(essentiellement Amérique du Nord, Europe et Asie) en termes de taux de déploiement dans les
équipements (63 % en 2007 et 67 % en 2008).
SIP fait référence non seulement à un protocole mais aussi à une architecture constituée de plusieurs
entités spécifiques et qui communiquent à travers ce protocole.SIP est un protocole client/serveur,
de niveau application, orienté transaction. Il utilise une syntaxe au format textuel qui s'inspire de
celles des protocoles SMTP et HTTP 1.1 (RFC 822, UTF-8). SIP se veut indépendant de la couche
transport et peut s'appuyer sur tout type de protocole de niveau 4 comme TCP, UDP ou SCTP
(couches « non fiables ») ou encore TLS/TCP, IPSec (couches « fiables »). SIP ne traite pas non
plus du transport des données de la session, d'autres protocoles sont utilisés pour cela comme par
exemple RTP, SRTP. RTSP, etc.
En termes de fonctionnalité, SIP fournit les éléments suivants :
 la possibilité de localiser simplement dans le réseau des terminaux associés aux usagers ;
 la possibilité de déterminer la disponibilité des participants, c'est-à-dire leur accessibilité
préalablement à l'établissement de la session ;
 la possibilité de déterminer la capacité ou les paramètres des terminaux ;
 la gestion de l'établissement et le contrôle de la session ;
 l'association possible ou la combinaison de SIP avec des mécanismes ad hoc de réservation
de ressources réseaux (QoS) ou de mécanismes de sécurité.
Les principales caractéristiques qui ont guidé les spécifications SIP sont les suivantes :
 une flexibilité par l'ajout possible d'extensions protocolaires « propriétaires» sous la forme
de structures de données encapsulées de manière opaque dans les messages SIP. Ces données
ne sont pas traitées par le niveau « SIP » ;
 un support du nomadisme en permettant l'appel simultané sur plusieurs terminaux (« forking
») et la détection de boucle réseaux, garantissant ainsi une certaine mobilité ;
 des capacités de passage à l’échelle ou « scalabilité » de par sa nature à fonctionner en mode
sans état et en mode «softstate ».

1.6.1 format d’adresse SIP[10]

Le format dresse SIP utilise une syntaxe de type URL qui est similaire à celle spécifiée dans le
protocole HTTP. Dans le cas de SIP, URL (Uniform Résout Locator) est appelée URI (Uniform
Resource Identifier), simplement pour indiquer les adresses de contact SIP sont associées à une

10
adresse que SIP identifiant l’utilisateur ou le service (l'URI SIP). Ces URI peuvent être multiples et
dynamiques (mobilité de l'utilisateur ou des terminaux dans le cas de la téléphonie par exemple).
Différents formats d'adresse SIP sont possibles en fonction de l'usage :
 pour faire référence à un domaine SIP (nom de domaine ou adresse IP) :
Exemple :sip : univ.mg
sip : 196.46.252.10
 pour faire référence à un identifiant d'appel : URI SIP d'appel (AoR,Adress Of Record)
Exemple :sip : Jean@univ.mg
 pour faire référence à un contact SIP correspondant à la localisation courante de l’utilisateur
:
Exemple :sip : jean@PC1.univ.mg
 pour faire référence à un service SIP (serveur vocal ou de conférence) :
Exemple :sip : messagerievocale@server_audiomail.eu
De manière générale une adresse SIP est de type :sip:nom_domaine et pour contacter un
utilisateur ou un service particulier:sip:utilisateur@nom_domaine ou sip:service@nom_domaine.
Le nom_domaine peut être décrit sous la forme d'une adresse numérique IP (par exemple
196.49.251.86) ou d'un nom DNS (Domain Name Service) de type :
nom_machine.sous_domaine.domaine
Dans ce cas l'adresse SIP identifie une adresse de contact.
Une adresse SIP peut être accompagnée de paramètres supplémentaires, la syntaxe de l'adresse est
alors du type :
sip:utilisateur@nom_machine:port;paramètres_uri_supplémentaires ?entêtes.
Le port SIP par défaut est le port UDP 5060. Si le protocole TLS est utilisé, le port est alors 5061.
Le champ paramètres_uri_supplémentaires peut correspondre par exemple :
 à une adresse multicast sur laquelle le service cible est accessible : maddr=adresse IP
multicast ;
 au type de protocole de transport : transport=udp ou tcp ;
 au type de terminal : user=phone ou IP;
 aux types de méthodes (ou requêtes) supportées :method= INVITE, ACK, OPTIONS, BYE,
CANCEL. REGISTER, etc.

11
1.6.2 Les messages SIP

Le protocole SIP est un protocole orienté transaction. Une session ou un dialogue SIP est
constitué d'une succession de transactions qui correspondent chacune à l'envoi d'une requête, suivi
de la réception d'une ou plusieurs réponses « provisoires » et d'une réponse « finale ». Chaque
transaction entraîne un changement état de la session. Toute requête générée ou envoyée doit donc
être suivie par une réponse associée sinon une erreur est déclenchée.

Il existe deux types de messages SIP qui sont les requêtes et les réponses, les requêtes sont à
l'origine des transactions et sont caractérisées par un type appelé méthode conformément à la
terminologie SIP. La figure 1.02 montre un format générique des messages SIP.

a. Champs d'en-tête SIP

Les champs d'en-tête contenus dans les messages SIP (« headers ») sont regroupés quatre catégories
:
 champs d'en-tête généraux : présent dans les requêtes et réponses ;
 champs d'en-tête de requête : présent uniquement dans les requêtes ;
 champs d'en-tête de réponse : présent uniquement dans les réponses ;
 champs d'en-tête d'entité : relatif au corps du message.

Figure 1.03: Format générique des messages SIP

Les spécifications SIP définissent un nombre important de champs d'en-tête. Nous n’en présentons
qu'un sous-ensemble constitué de ceux qui sont obligatoires. Ces champs d'en-têtes sont les
suivants :

12
  Via : ce champ d'en-tête permet de « tracer » le chemin de la requête. Ce champ est important
car il permet d'éviter les boucles et permet aux réponses de suivre le même chemin, ce qui
est utile par exemple pour la facturation. Dans ce champ, un paramètre branch contribue à
l'identification d'une branche de communication ;
 Max-Forwards : ce champ d'en-tête indique une durée de vie du message. Il correspond à
un compteur qui est décrémenté à chaque fois qu'une entité traite le message. Il peut être
assimilé au «Time To Live » géré par le niveau 3 IP. Une entité qui reçoit un message avec
une valeur égale à 0 pour ce champ doit le supprimer ;
 From : ce champ d'en-tête identifie l'appelant ou la source du message et a comme valeur
une URI SIP :
 To : ce champ d'en-tête identifie le destinataire ou le service cible du message et a comme
valeur une URI SIP :
 Call-Id : ce champ d'en-tête contient un identifiant de session qui doit être unique. En
général, cet identifiant est construit à partir d'une clé à laquelle est rajoutée l’adresse IP de
la machine ayant initié la session. Cet identifiant est réutilisé dans toutes les requêtes et
réponses appartenant à la même session ;
 Cseq : ce champ d'en-tête contient un numéro de séquence suivi du nom de la méthode
(requête). Le numéro de séquence est incrémenté à chaque nouvelle requête générée au sein
d'une session sauf pour les requêtes ACK ou CANCEL qui reprennent le numéro de la requête
qu'elles concernent;
 Contact : ce champ d'en-tête est utilisé pour fournir l'adresse de contact associé à l'URI SIP
contenu dans le champ From :
 Contact-type : Ce champ d'en-tête indique le type de média contenu dans le corps du
message. Ce type est au format MIME. Des exemples sont le type application/sdp ou
application/xml.
Le tableau 1.01 résume et donne pour chaque méthode ou requête SIP, les champs d'en-tête
compatibles avec les spécifications données dans les différentes RFC et qui doivent être présents
dans le contenu de ces messages de type requête.

13
 SUBSCRIBE
REGISTER

MESSAGE
PUBLISH
CANCEL

UPDATE
OPTION
NOTIFY

PRACK
INVITE

REFER

INFO

ACK
BYE
Call-Id X X X X X X X X X X X X X X
Cseq X X X X X X X X X X X X X X
From X X X X X X X X X X X X X X
To X X X X X X X X X X X X X X
Via X X X X X X X X X X X X X X
Contact X X X X X X
Max-Forwards X X X X X X X X X X X X X X
Refer-To X
Event X X X
Allow-Events X X X
Subscription-State X
Rack X
Expires X
Min-Expires X
Info-Package X

Tableau 1.01 :En-têtes exigées pour les principales requêtes SIP

b. Les requêtes SIP

Les requêtes SIP sont générées par une entité SIP cliente (« User Agent Client » ou « Back-to-Back.
User Agent» par exemple) à destination d'une entité SIP serveur (« User Agent Server » ou « proxy
SIP »). Inversement, les réponses sont générées par une entité SIP serveur suite au traitement de la
requête correspondante et renvoyées à une entité SIP cliente.

Les principales requêtes définies par l'IETF sont :

 INVITE : utilisée pour l'établissement de la session média, ce type de requête est l'équivalent
du message SETUP utilisé dans le RNIS (réseau TDM) ou encore du message de
signalisation SS7 (ISUP) IAM.

14
 REGISTER : ce type de requête est utilisé en général par un Agent Utilisateur ou User Agent
SIP pour gérer (ajout, mise à jour, suppression) des liaisons (identifiant logique de
l'utilisateur, adresses IP ou URI de contact associées) auprès d'un serveur fournissant un
service de localisation.

 BYE : ce type de requête est utilisé pour terminer un dialogue SIP. II correspond au message
de libération de la session et peut être initiée par l'un des participants à la session (l'appelant
ou l'appelé).

 ACK : le type de requête ACK est utilisé pour acquitter les différentes réponses de type final
(codes 2xx, 3xx ... 6xx) aux requêtes INVITE.

 CANCEL : ce type de requête permet d'annuler l'établissement d'appel en cours. La requête

CANCEL est générée soit par la pile SIP du User Agent soit par le serveur proxy SIP quand
la session est annulée avant sa confirmation, c'est-à-dire la réception de la réponse finale
(200 OK).

 OPTIONS : la méthode OPTIONS permet d'obtenir des informations sur les capacités
(exemple : méthodes et extensions supportées, type de contenu, etc.) d'un agent utilisateur

15
 ou d'un serveur sans nécessité l'établissement d'une session au préalable.La liste des
capacités est renvoyée par l'entité serveur dans une réponse et dépend de l'URI de la requête.
Les capacités sont contenues dans les attributs d'en-têtes tels que: Supported, Allow, Accept,
Accept-Encoding, Accept-Language. Cette requête peut être émise en dehors ou à l'intérieur
d'une session.

 REFER : dans le cas de services de téléphonie comme le transfert d'appel (« sûr », « aveugle
» ou « avec consultation ») le type de requête REFER est utilisé. Cette requête spécifie un
champ en-tête particulier Refer-To dans laquelle se trouve l'URI du terminal cible vers lequel
l'appel est transféré. Cette URI contient généralement une URI SIP dans le cas de la
téléphonie mais peut aussi contenir une URL HTTP pour le transfert de l'appel vers une page
web par exemple (via le protocole HTTP).

 UPDATE : ce type de requête définie dans la RFC 3311 sert pour la mise à jour des
paramètres de la session lors de la phase d'établissement de cette session. Si la session a déjà
été établie, une nouvelle requête INVITE doit être utilisée à la place. La mise à jour des
paramètres d'une session peut être intéressante pour le support de services comme par
exemple activer/désactiver la fonction « silence » (mute en anglais) en cours de session ou
encore renégocier le type de codeurs média (audio, vidéo) dans le cadre d'une négociation
ou renégociation d'une qualité de service si les performances réseau se sont dégradées en
cours de session.

 INFO : ce type de requête est utilisé pour le transport d'informations de signalisation de bout
en bout comme par exemple des éléments de signalisation SS7 (ISUP), des événements ou
des tonalités DTMF.La méthode INFO est plus généralement utilisée pour le transport ou
l'encapsulation d'information de signalisation non-SIP dans le flux SIP. Cette encapsulation
permet de supporter l'interconnexion et une certaine interopérabilité entre des réseaux
classiques (RTC) et des îlots IP. Cette méthode permet aussi l'encapsulation d'événements
ou de signaux téléphoniques de type « DTMF » pour interagir avec un serveur de média IP
par exemple.

 PRACK : dans certaines situations, par exemple dans le cas d'une interconnexion SIP avec
le réseau mobile « GSM », la transmission des réponses de type provisoire (code 1xx) doit
aussi être fiabilisée. Cette transmission fiable des réponses provisoires est assurée par le type
de requête PRACK définie dans la RFC 3262. Les autres types de réponses (codes : 2xx,

16
 3xx... 6xx) sont acquittés par une requête ACK. Une requête PRACK est générée par une
entité cliente si la réponse provisoire reçue contient dans les champs d'en-
têteRseqetSupported respectivement un numéro de séquence et la valeur 100rel (acquitter le
message code 100). Dans le cas où le message PRACK n'a pas été reçu la réponse provisoire
est renvoyée jusqu'à réception du PRACK qui est lui-même acquitté par un message réponse
200 OK. La requête PRACK peut être aussi utilisée dans le cadre du mécanisme
d'offre/réponse pour la négociation de capacités. Dans ce cas, une telle requête peut contenir
un corps de message au format SDP.

 MESSAGE : ce type de requête défini dans la RFC 3428 est essentiellement utilisé pour
l'envoi de messages instantanés quelconques ou pour la messagerie dite conversationnelle
(le « chat »). Les requêtes MESSAGE peuvent être envoyées en dehors d'une session donnée
(champ Call-Id indépendant de celui identifiant la session). Le corps du message MESSAGE
contient le contenu des messages conversationnels qui sont généralement au format texte
(ascii). Le format utilisé est indiqué par le champ Content-type avec une valeur de type
MIME plain/text par exemple. Un message instantané est acquitté en retour par une réponse
200 OK.

 NOTIFY : ce type de méthode définie dans la RFC 3265 est utilisé essentiellement pour
notifier à une entité SIP un ou plusieurs événements particuliers. Les requêtes NOTIFY
possèdent un numéro de séquence Cseq qui garantit au niveau du récepteur le séquencement
et l'ordre des messages reçus.

 SUBSCRIBE : le type de requête SUBSCRIBE est défini dans la RFC 3265 pour permettre à
un agent utilisateur SIP de s'abonner (souscrire) auprès d'une entité serveur afin de recevoir
la notification de certains événements particuliers. Le type d'événements sélectionnés par
l'entité cliente est spécifié dans le champ d'en-tête Event de la requête SUBSCRIBE mais les
types des événements acceptés par l’entité serveur sont indiqués dans le champ d'en-tête
Allow-Events de la réponse.

 PUBLISH : le type de requête PUBLISH est utilisé par un entité SIP pour publier ou envoyer
principalement des informations ou des états relatifs à la présence de l'utilisateur comme par
exemple sa disponibilité, le filtrage de certains appels ou son terminal préféré pour la
réception de certains appels, etc.). Les requêtes PUBLISH peuvent provenir de plusieurs
terminaux différents mais ceux qui sont associés à un même utilisateur (même adresse

17
 logique ou « Adress of Record ») peuvent être agrégées par un serveur (tel un serveur de
présence SIP par exemple).

c. Réponses SIP

Les réponses SIP sont envoyées par une entité serveur en réponse aux requêtes. La majorité des
réponses SIP sont des réponses dites finales et terminent la transaction courante. Certaines réponses
sont des réponses dites provisoires («provisional ») c'est-à-dire générées entre la requête initiale et
la réponse finale. Elles ne terminent donc pas la transaction courante. Le type d'une réponse est
donné par son code statut qui est un entier. Les réponses sont regroupées en six catégories. Chaque
catégorie correspond à une plage de valeur pour le code statut :

 1xx : les réponses de cette catégorie donne une information sur le traitement en cours de la
requête. Par exemple, les réponses 100 Trying ou 180 Ringing font partie de cette catégorie.

 2xx : les réponses de cette catégorie indique le succès de la requête. Cette catégorie comporte
la réponse 200 OK qui est très utilisée dans les échanges SIP.

 3xx : dans cette catégorie, on trouve les réponses qui indiquent la nécessité d'une redirection
de la requête. Des exemples de réponse appartenant à cette catégorie sont la réponse 300
Multiple Choices précisant que plusieurs adresses de contact existent et la réponse 302
Moved Temporarily contenant un URI pour rediriger la requête.

18
  4xx : les réponses de cette catégorie correspondent à des erreurs provoquées par une requête,
telle que le message 401 Unauthorized qui indique que la requête associée nécessite une
authentification pour être traitée.

 5xx : les réponses de cette catégorie correspondent à des erreurs liées à un traitement côté
serveur. Comme exemple de réponses issues de cette catégorie, on trouve la réponse 501 Not
Implemented pour signaler que la fonctionnalité demandée n'est pas implantée et la réponse
503 sendeeunavailable indiquant un service indisponible;

 6xx : les réponses de cette catégorie signalent une erreur globale. C'est dans cette catégorie
que se trouvent les réponses 600 Busy, 601 Decline, 606 Not Acceptable pour indiquer
respectivement la non-disponibilité de l'appelé, un rejet d'appel et une non-acceptation des
paramètres de la session.

d. Routage et acquittement des messages SIP

Au cours de son routage, un message SIP peut être amené à traverser une série d’entités SIP
intermédiaires. Deux modes de routage sont possibles pour les messages dans ce cas :

 un mode de bout en bout (end to end) : dans ce mode, l'entité qui reçoit une requête ne fait
que la relayer vers le destinataire sans retourner de réponse immédiate, la réponse étant
produite par le destinataire. Ce mode de routage est utilisé pour la plupart de requêtes
échangées entre les entités SIP d'extrémités. Par exemple, dans une architecture où les entités
intermédiaires sont des proxys, la requête INVITE est relayée successivement par chaque
proxy de l'appelant jusqu'à l'appelé et il est en de même pour la réponse 200 OK dans le sens
inverse mais aussi pour l'acquittement de le réponse ;

 un mode saut par saut (hop by hop) : dans ce mode, l'entité qui reçoit une requête entrante la
traite et répond immédiatement. Si le traitement de la requête le nécessite, une nouvelle
transaction sortante est créée pour propager la requête. Le fonctionnement est analogue pour
les réponses de la requête. Ce mode est utilisé dans le cas d'acquittement de réponses de type
3xx, 4xx... 6xx et d'annulation d'une requête avec la méthode CANCEL pour accélérer le
traitement.

Il est à noter qu'en mode saut par saut (« hop by hop ») le proxy exploite un attribut d’en-tête
particulier (branch) contenu dans les messages qui sont relayés de façon à corréler les requêtes
entrantes, sortantes et le dialogue/session associé. L'identifiant contenu dans l'attribut branch

19
constitue donc un identifiant de transaction, et permet pour le proxy par exemple de déterminer
l'action à entreprendre en fonction du type d’acquittement ACK. En effet, si l’ACK correspond à un
acquittement de bout en bout (cas du 200 OK) il est simplement relayé de manière quasi transparente
par les proxys successifs jusqu'au User Agent SIP, et s'il correspond à un acquittement en mode saut
par saut, l’ACK est généré successivement au niveau de chaque proxy traversé par le message de
réponse (3xx, 4xx ... 6xx) c'est-à-dire sur chaque entité traversée. En mode saut par saut,
l'acquittement ACK est considéré comme appartenant à la même Transaction que la requête d'origine
(exemple : INVITE) : la valeur de son attribut branch aura donc la même valeur que celle contenue
dans la requête d'origine INVITE.A l’inverse, dans le mode bout en bout, l'acquittement ACK est
considéré comme faisant partie d'une nouvelle transaction : la valeur de son attribut d'en-tête branch
sera donc différent.

1.6.3 Transaction et dialogue SIP

a. 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

20
 Figure 1.04: Transaction SIP

b. 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 1.05: Dialogue SIP

21
1.6.4 Architecture et entité SIP

Les entités pouvant intervenir dans une architecture SIP sont de deux types :

 les entités utilisatrices appelées « User Agent » ou « UA » qui sont situées aux extrémités
de la chaîne de communication ;

 les entités intermédiaires qui supportent la communication en apportant des fonctions plus
ou moins sophistiquées entre les entités utilisatrices.

La figure 1.06 montre une architecture SIP constituée d'entités utilisatrices et d'entités
intermédiaires et le cheminement des échanges entre ces entités.

Figure 1.06: Appel SIP via serveurs proxy

Les détails de ces éléments architecturaux de SIP :

 l'agent utilisateur Client (« UAC») ou Serveur (« UAS ») : ce sont des points terminaux
capables d'émettre (UAC) ou de recevoir (UAS) des requêtes SIP. Un UA est la partie qui
permet de recevoir et d'établir les sessions SIP au sein de l'application multimédia du
terminal utilisateur. On distingue deux composantes d'UA : la première qui agit en tant que
client (UAC) initie les sessions à la demande de l'utilisateur ; la seconde qui agit en tant que
serveur (UAS) est responsable de la gestion ou du traitement des requêtes d'établissement

22
 des sessions. Les UA conservent des informations sur l'état de la session, ils sont dits
«stateful ». Les UA SIP qui combinent à la fois UAC et UAS sont généralement les
terminaux VoIP ou systèmes de conférence audio ou vidéo. Les UA SIP intégrant
uniquement un module UAS sont typiquement des serveurs de média (exemple : serveurs
vocaux, de imagerie ou des serveurs VoD, etc.) qui ne font généralement que répondre à des
requêtes;

 le proxy server : c'est une entité intermédiaire de type serveur qui a une fonction de relais.
Un proxy accepte les requêtes ou des réponses SIP en provenance d'un UA ou d'un autre
serveur proxy et les fait suivre (routage d'appels) en s'appuyant sur son service de
localisation. Un proxy peut conserver des états relatifs à l'avancement des sessions pour
lequel il intervient. Dans ce cas il est ditstateful (exemple : pour le support de fonctions de
type « pare-feu » oubilling) sinon il est ditstateless. Un proxy effectue un traitement minimal
sur le message relayé (principalement sur le champ d’en-tête « via »). Ce traitement est limité
principalement à une analyse des champs d’en-tête pour tracer le message (champ « via »),
effectuer une diffusion multiple (support de la mobilité) ou encore traiter l'authentification
utilisateur ;

 le serveur de redirection ou redirect server : il s'agit d'une entité intermédiaire qui répond
aux requêtes en spécifiant le ou les localisations potentielles du destinataire. A la différence
du proxy, ce serveur ne relaie pas les messages de signalisation. Le redirect server est utile
pour effectuer du partage de charge entre différents serveurs ou pour rediriger l'appel si le
proxy appartient à un domaine visité (visited domain) qui n'est pas celui de
l'utilisateur/abonné mobile habituel (home domain) ;

 le registrar server : c'est une entité utilisée par les entités précédentes pour enregistrer les
liaisons (identifiant logique de l'utilisateur, adresses IP ou URI de contact associées). Cette
entité renseigne ensuite le service de localisation à l'aide in protocole ad hoc (externe à la
spécification SIP). Le protocole généralement utilisé pour accéder à ce service est LDAP
(Lightweight Directory Access Protocol) ;

 le serveur de localisation : cette entité offre des services pour obtenir et mettre à jour des
informations sur le destinataire (adresse courante et multiple, droit, mot de disponibilité,
etc.). C'est l'entité utilisée par les serveurs proxy et serveurs de redirection pour relayer ou
rediriger les messages ;

23
  le Back to Back User Agent (B2BUA) : cette entité est un proxy SIP évolué. Un B2BUA
maintient en mémoire les états relatifs à l'appel (call stateful) permettant si un traitement
beaucoup plus sophistiqué des appels (contrairement au proxy qui fait que relayer l'appel).
Il participe activement au dialogue SIP en maintenant de chaque côté des dialogues ou
sessions SIP indépendantes et est capable d’initier ou de libérer une session SIP de sa propre
initiative. Le B2BUA peut ainsi supporter des applications ou des services évolués tels que
: carte prépayée, conférence multipoints multi-utilisateurs, click to dial, etc.

1.7 La couche service

Actuellement, les services sont dédiés à un type de réseau; services Réseau Intelligent sur le
réseau téléphonique pour les terminaux téléphoniques (fixes ou mobiles), et services mail, web,
news sur les réseaux IP.

L'apparition des nouveaux réseaux d'accès tels que l'UMTS, le GPRS, I'xDSL, l'Ethernet longue
distance, et la multiplication des terminaux communicants (téléphone mobile GPRS/UMTS, PDA)
et la convergence des cœurs de réseaux, poussent à une transformation de l'architecture des plates-
formes de services.

Cette nouvelle architecture doit offrir la possibilité aux clients d'accéder aux services, quelle que
soit la nature des terminaux et le type de protocole utilisé pour accéder aux plates-formes de
services, via un réseau de transport unifié, en mode paquet. Le service rendu doit être adapté aux
besoins et aux moyens des clients.

1.8 Comparaison entre les protocoles H323 et SIP :

La simplicité, la rapidité et la légèreté d'utilisation, tout en étant très complet, du protocole SIP sont
autant d'arguments qui pourraient permettre à SIP de convaincre les investisseurs. De plus, ses
avancées en matière de sécurité des messages sont un atout important par rapport à ses concurrents,
d’où notre choix d’utilisation de ce protocole.

SIP H323

24
 Nombre échanges pour 1,5 aller-retour 6 à 7 aller-retour
établir la connexion
Maintenance du code Simple par sa nature textuelle à Complexe et nécessitant un
protocolaire l'exemple de Http compilateur
Evolution du protocole Protocole ouvert à de nouvelles Ajout d'extensions propriétaires
fonctions sans concertation entre
vendeurs
Fonction de conférence Distribuée Centralisée par l'unité MC
Fonction de téléservices Oui, par défaut H.323 v2 + H.450
Détection d'un appel en Oui Inexistante sur la version 1
boucle un appel routé sur l'appelant
provoque une infinité de
requêtes
Signalisation multicast Oui, par défaut Non

Figure 1.07: Comparaison entre H323 et SIP

1.9 Conclusion

En tout, l'évolution vers les NGN représente encore à ce jour un sujet relativement en amont,
notamment du point de vue des opérateurs et dans une moindre mesure des purs fournisseurs de
services.

En effet, la conjoncture actuelle influe fortement sur les positions vis-à-vis des NGN puisque les
acteurs sont confrontés à des problématiques de financement et de pérennité, ce qui les met dans un
contexte peu favorable à des évolutions techniques et à l'apparition de nouveaux business models.

Mais on peut dire que la migration vers les NGN apparaît comme un processus inévitable du fait de
la convergence voix/données/image et fixe/mobile. Elle a déjà attiré l'intérêt d'un certain nombre
d'acteurs en France, en Europe et dans d'autres continents. Encore faut-il anticiper pour suivre et
analyser ses impacts.

Dans le chapitre suivant on va présenter JAIN qui un exemple d’architecture de réseau NGN. On va
scruter tous les détails qui se rapportent à cette technologie. On va surtout mettre l’accent sur le
point fort de cette architecture : le développement des services.

25
 CHAPITRE 2
LA TECHNOLOGIE JAIN

2.1 Introduction

JAIN est un ensemble d'API (Application Program Interfaces) JAVA qui permet de développer
rapidement de nouveaux services pour des réseaux de télécommunication voix ou données,
indépendamment des serveurs utilisés (matériel). De plus, JAIN étant basé sur la plateforme JAVA,
il introduit la portabilité des services entre systèmes et permet des accès sécurisés aux ressources
des différents réseaux.

La technologie JAIN change radicalement le marché des télécommunications en permettant le

passage de systèmes fermés et propriétaires à des systèmes ouverts offrant une interconnexion totale
des différents réseaux existant (PSTN, IP, ATM, GSM, WLAN). Ceci peut être constaté dans la
figure 2.1 qui donne un premier aperçu sur l'architecture de JAIN

Actuellement, plus de 80 entreprises font partie et sont actives dans la communauté de

développement de la technologie JAIN sous le contrôle de SUN, qui garantit ainsi la qualité des
nouvelles APIs, leur homogénéité et leur compatibilité à long terme.

2.2 Aperçu historique de JAIN[9][10]

Créé par SUN en 1998, JAIN étend la plate-forme JAVA à l'industrie des fournisseurs de services.
Son but est de répondre aux exigences des réseaux de télécommunication de la nouvelle génération,
en offrant des API permettant de développer des applications et services pour les réseaux
intelligents. Les développements des API JAIN sont menés de front en Asie, en Europe et aux Etats-
Unis par les membres de la communauté. Celle-ci se compose de plus de 80 entreprises comprenant
des fournisseurs de matériels, des fournisseurs d'équipements réseaux, des fournisseurs de
protocoles et des développeurs de services.

La communauté de JAIN travaille en étroite collaboration avec d'autre groupement d'entreprises tel
que l'ETSI, le Parlay Group et 3GPP afin de garantir des API de qualités.

26
2.3 API SIP dans l’architecture JAIN

L'objectif de SUN est le développement d'API Java pour concevoir, intégrer et déployer rapidement
des services tout en permettant leur portabilité et leur fonctionnement à des réseaux orientés paquets,
des réseaux circuits et des réseaux sansfil.

La volonté de la communauté JAIN est de faire évoluer le domaine des réseaux de communications
qui repose sur une architecture de boites matérielles et logicielles propriétaires vers une architecture
ouverte où les services peuvent être rapidement créés et déployés quels que soient la plate-forme et
le réseau supportés.

L'approche JAIN définit un cadre de développement pour créer, tester et déployer des services de
communications basés sur Java. Avec cette approche, le Java peut être utilisé pour créer des serveurs
de communications au sein d'un même réseau mais aussi créer des interfaces de communications
entre entités appartenant à différents réseaux de communications. Les avantages majeurs de JAIN
sont d'apporter pour les fournisseurs de services :

 la portabilité des services (Write one, Run Anywhere) : les technologies et le développement
d'applications sont généralement contraintes par des interfaces propriétaires. La portabilité
des applications est généralement difficile à obtenir ce qui augmente les coûts de
développement, le temps de mise sur le marché et les besoins de maintenance. Un des
objectifs de l'approche JAIN est de faire évoluer les interfaces propriétaires en interfaces
uniformes permettant ainsi d'aboutir à des applications et services portables sur différentes
infrastructures réseau ;

 la convergence des réseaux (Any Network) : dans la plupart des applications et services de
communications actuelles, la gestion et le contrôle des appels ou des sessions sont
circonscrits à un seul type de réseau bien que des passerelles entre les réseaux existent. Le
modèle d'appel de haut niveau proposé par JAIN inclut des facilités pour observer, initier,
traiter et manipuler des appels qui peuvent être multimédias, multiparties, multiprotocoles
et multiréseaux ;

 l'accès sécurisé aux réseaux (By Anyone) : en général, l'accès aux ressources du réseau est
limité aux applications et services des opérateurs. JAIN prévoit des interfaces « Parlay » afin
d'offrir une ouverture contrôlée et sécurisée aux capacités du réseau. Ces interfaces vont

27
 permettre à des applications ou services tierces de réaliser des actions ou des fonctions
spécifiques au sein du réseau intégré.

JAIN crée donc un nouvel environnement pour que les utilisateurs et les développeurs de services
de communications puissent construire des systèmes reposant sur un ensemble de standards et
s'exécutant sur des réseaux compatibles avec ces standards. Cet environnement va permettre aux
services de devenir indépendant du matériel des opérateurs mais aussi donner l'opportunité à des
sociétés tierces de développer des services intéressants augmentant ainsi considérablement le
nombre de services disponibles dans ces réseaux. Grâce à la technologie Java, ces services pourront
être proposés sous la forme de composants logiciels prêts à l'emploi. De tels composants pourront
alors être assemblés pour offrir des services portables de haut niveau à forte valeur ajoutée puis
pourront être déployés au sein des réseaux en toute sécurité. Enfin, les possibilités d'intégration des
différents réseaux offertes par JAIN vont permettre d'accélérer et d'améliorer la convergence de
l'internet et des réseaux de téléphonie permettant ainsi le développement de nouvelles applications
combinant des informations et des fonctionnalités issues des différents réseaux.

Figure 2.01: Passage des systèmes propriétaires aux systèmes ouverts

2.4 L'Architecture et les interfaces JAIN[11]

Avant de scruter l'architecture de JAIN, faut-il tout d'abord, présenter la communauté qui a défini
les notions de base de cette technologie. En fait, il s'agit de deux groupes de recherches. Le premier
est spécialisé dans la définition des interfaces standards pour les différents protocoles de
signalisation d'où le nom PEG (Protocol Expert Group). Alors que la spécification des APIs requis
pour la création des services était dédiée à l’AEG (Application Expert Group). Cette « divergence

28
» brossée à travers cette séparation ne va pas contourner les objectifs de JAIN puisque la
spécialisation à mon sens permet de créer des gens plus compétents dans le domaine. Ce qui va
entraîner plus de précision et de performance au niveau des spécifications.

2.4.1 Les couches d'abstractions

Il a donc été nécessaire de définir un environnement d'exécution indépendant du protocole de

signalisation. Pour cela, plusieurs couches d'abstraction ont été créees, il définit aussi une librairie
de composant, d'outils de développement et un environnement de création de services Comme nous
l'avons dit, JAIN définit des couches d'abstractions, elles sont au nombre de trois :

 Network layer: Il s'agit d'une couche définissant le protocole de communication choisit.

 Télécommunication : Réseaux intelligent (AIN/IN) ou SS7 avec beaucoup de
protocole ISUP, TCAP, NAP ...
 Wireless : SS7 avec des applications mobiles
 VoIP : SIP, MGCP, Megaco, H.323
 Signaling layer:

Il s'agit d'une couche représentant les logiciels chargés de la gestion des communications.

 Télécommunication : Signaling Service Point (SSP)

 Wireless : Mobile Switching Centers (MSC)
 VoIP : Proxy, redirect serveur, H 323 gatekeeper, media gateway controllers
 Service layer :

Il s'agit d'une couche représentant les services de base.

 Télécommunication : Service Contrôle Points (SCP)

 Wireless : Base Station Controllers (BSC), Home Location Registers (HLR) ...
 VoIP : Serveur d'applications internet

29
 Figure 2.02: Les différentes couches et APIs de JAIN

2.4.2 Principe des interfaces de JAIN[12]

JAIN propose des API qui interfacent les différentes couches des réseaux. Ainsi, un développeur de
services peut créer des services en se basant sur l'interface utilisée.

Figure 2.03: Exemple d'introduction d' une interface JAIN

30
2.4.3 L'architecture de JAIN

Figure 2.04: Architecture en couche de JAIN

2.5 Les différentes APIs de JAIN[13]

Plusieurs API JAIN ont été définies pour SIP. Ces API définissent des interfaces standardisées pour
simplifier le développement d'applications Java utilisant le protocole SIP. Il s'agit de :

 JAIN-SIP est l'API de base fournissant un accès standardisé et complet aux fonctionnalités
des piles de signalisation SIP propriétaires ;

 SIP for J2ME définit une interface SIP pour des plates-formes à capacités réduites comme
celles utilisées dans les terminaux mobiles ou les téléphones portables. SIP a été retenu
comme protocole de signalisation dans le cadre de l’architecture 3GGP et cette spécification
répond directement aux besoins de développement d'applications dans ce cadre ;

 JAIN-SIP Lite est une API Java de haut niveau permettant au développeur de créer des
applications SIP (de type user-agent) rapidement et sans avoir besoin de connaître en détail
la spécification du protocole SIP ;

 SIP Servlet définit une API de haut niveau et un environnement pour l'exécution
d’applications SIP dans des serveurs. Il permet de développer des applications SIP selon un
modèle similaire à celui des « servlets » basées sur le protocole http. Il permet également à
ces applications d'être déployées dynamiquement dans les serveurs à l'instar des applications
web dans la plate-forme J2EE

31
Il existe encore d'autres API en relation avec SIP au sein de JAIN. On peut citer l’API JAIN-
SIMPLE qui est une interface prenant en compte les extensions de SIP services de présence et la
messagerie instantanée. Une autre API est JAIN-SDP. Cette dernière API fournit une interface pour
encoder, décoder et manipuler la description d'attributs de session au format SDP.

Figure 2.05: Différents APIs de JAIN

2.6 Présentation générale de l’API JAIN-SIP

L'API JAIN SIP est la première spécification basée sur SIP à avoir été standardisée. Cette
spécification a été conçue pour développer des applications JAVA qui requièrent un accès complet
au protocole SIP. Elle fournit une interface pour accéder aux fonctionnalités d'une pile de
signalisation SIP dans une application JAVA comme par exemple la création, l'envoi et le traitement
de messages. Cette spécification garantit également la portabilité des applications JAVA sur
différents piles SIP.

32
L'API JAIN SIP peut être utilisée de façon multiple. Elle peut être utilisée dans le développement
d'agent utilisateur et de proxy. Elle peut aussi être embarquée dans un conteneur de service comme
par exemple un environnement d'exécution ou JAIN SLEE.
Lorsque l'on utilise l'API JAIN-SIP pour développer une application, il est important de bien
connaître et de comprendre la répartition des responsabilités entre celle-ci et l'API.
Les responsabilités de l'API sont les suivantes :
 elle fournit les mécanismes pour construire des messages SIP selon les règles de formatage
standard ;
 elle fournit les moyens d'envoyer et de recevoir des messages SIP en prenant en charge leur
transport et éventuellement leur retransmission ;
 elle analyse les messages SIP entrants puis en construit une représentation sous forme
d'objets que l'application peut accéder et modifier à travers des interfaces Java standardisées
;
 elle invoque (appelle, réclame) les écouteurs d'événements (arrivée d'un message, time-out,
etc. .) configurés par l'application quand un événement se produit ;
 elle fournit le support des transactions et gère leur état et leur cycle de vie pour le compte de
l'application ;
 elle fournit le support des dialogues et gère leur état et leur cycle pour le compte de
l'application.
De son côté, l'application a les responsabilités suivantes :
 elle doit utiliser les interfaces offertes pour tout accès à la pile et l'envoi de messages SIP ;
 elle doit enregistrer ses écouteurs d'évènements auprès de la pile pour qu'ils soient notifiés
des événements correspondants ;
 elle est responsable du traitement des messages fournis par la pile et de la logique
applicative.

L'API JAIN SIP est construite autour de plusieurs concepts qui sont spécifiés par des interfaces
Java. Ces interfaces sont regroupées dans différents paquetages de l'API en fonction de leurs rôles.
Ces concepts vont permettre à une application de construire des requêtes SIP selon les règles de
formatage standard et de les envoyer à travers le réseau selon des modes avec ou sans état. Ces
concepts vont également permettre la réception de réponses SIP selon un modèle événementiel et le
traitement de ces réponses.

33
Le premier concept est celui de fabrique (SipFactory). Une fabrique est un objet qui permet de créer
d’autres objets. L'API comporte plusieurs fabriques pour créer des objets correspondant aux
différents concepts.

Le second concept est celui de pile (SipStack). Ce concept représente et encapsule une pile SIP. Il
sert à configurer ses propriétés comme les ports d'écoute, le protocole de transport utilisé ou encore
les stratégies de retransmission.

Le troisième concept est celui de message (SipMessage). Ce concept représente une requête ou une
réponse SIP sous la forme d'objet. Ces messages peuvent être construits à l'aide de la fabrique
correspondante selon les règles de formatages standard.

Le concept suivant est celui de fournisseur de services (SipProvider). Ce fournit un point d'accès
aux fonctionnalités de la pile. Il fournit les moyens d'envoyer des messages SIP en prenant en charge
des aspects comme le transport,la retransmission ou les transactions. Il se charge également de
notifier l'application quand un événement se produit au niveau de la pile (arrivée d'un message,
expiration d'un temporisateur, etc.).

Enfin, le dernier concept est celui d'écouteur d'événements SIP (SipListener). Un écouteur est un
gestionnaire d'événement créé et fourni par l'application. Un écouteur est invoqué par un
SipProvider pour traiter un événement particulier (par exemple réception d'un message SIP). Le
concept d'événement (SipEvent) sert à encapsuler des informations comme par exemple le message
reçu.

Figure 2.06: Principaux concepts de l’API JAIN SIP

34
 Figure 2.07: Processus d’activation d’un objet écouteur côté serveur

2.7 Conclusion

Actuellement les solutions viennent d'un vendeur qui fournit dans une grande boite totalement
propriétaire du matériel, logiciel du serveur et des services. Les clients dépendent donc de ce
vendeur, il en résulte des coûts d'extensions et de maintenances élevés.

La technologie JAIN a un potentiel immense. Elle bouleverse complètement le marché des

télécommunications en permettant un accès direct au développement de services par tous les acteurs
de télécommunications dans le monde indépendamment des systèmes.

Avec le principe adopté par la communauté JAIN qui supprime les différences entre réseaux et qui
apporte la sécurité, il n'existe plus que deux limites à la création de services. La première est
physique, c'est la taille du réseau mondial, la seconde est l'imagination.

35
 CHAPITRE 3
ANALYSE ET CONCEPTION DANS L’ENVIRONNEMENT SIP

3.1 Introduction

Ce chapitre présente l'approche proposée de conception des services de téléphonie IP en utilisant le

protocole SIP. Cette approche montre comment les messages du protocole SIP peuvent s'intégrer
dans les logiques de fonctionnement des services à concevoir. Cette conception se fait plus
facilement avec SIP qu'avec H.323 et MGCP.

La procédure de conception de services est basée sur une étude approfondie de spécifications de SIP
afin de proposer et de construire les logiques des services. Des diagrammes de services ont été
construits afin de montrer comment les messages (requêtes et réponses) SIP interviennent dans la
logique et le fonctionnement de chaque service, c'est-à-dire que chaque service conçu est présenté
par un diagramme qui montre sa logique conformément aux spécifications du protocole SIP.

3.2 Approches de développement de services SIP[11][12]

L’approche JAIN-SIP fait partie des approches de développement d'application SIP qui se repose
sur l'utilisation d'une bibliothèque dans un langage de programmation généraliste. En général, une
telle bibliothèque implante une pile protocolaire qui réalise l’analyse et la construction des messages
du protocole selon le standard SIP et vérifie la cohérence des échanges.

Il existe une autre catégorie d'approches destinée au développement de services ou d'applications

SIP. Cette catégorie alternative est celle des langages dédiés. Contrairement aux approches
précédentes qui permettent la mise en œuvre de services ou d'applications SIP de tout type, ces
langages ont par nature un pouvoir d’expression plus limités et sont réservés à un type d’applications
SIP bien précis.

Les approches de la première catégorie sont plus souples que les langages dédiés et contrairement à
ces derniers, ils permettent le développement de tout type d'applications et de service SIP grâce aux
langages généralistes. Cependant, ces approches nécessitent généralement une plus grande expertise
dans les domaines de la programmation mais aussi des systèmes distribués et des protocoles car de
nombreuses tâches sont souvent à la charge du programmeur. A l'inverse, les langages dédiés
fournissent des abstractions et des opérations spécialisées de haut niveau qui simplifient la

36
conception applications. En revanche, ces langages manquent généralement d'expressivité pour
implanter des applications et des services SIP de tous types.

3.3 La conception de services de la téléphonie IP en utilisant SIP

En général, selon leurs types et leurs logiques de fonctionnement, certains services de

télécommunication sont de préférence localisés du côté serveur Proxy ou bien du côté UA, voici des
exemples brefs:

Des services devant être localisés du côté réseau (spécifiques aux serveurs):

 La distribution des appels.

 Les services aux utilisateurs utilisant ayant l'accès à distance (Dial-up) pour se brancher sur
le réseau. Ceux-ci n'ont pas d'adresses IP, car ils s'adressent à des utilisateurs n'ayant pas de
téléphones SIP.
Des services devant être localisés des deux côtés serveurs Proxy et UAs :

 Le renvoi d'appel, par exemple, si le client est occupé.

 Les services qui demeurent du côté client.
 Les sonneries distinctes ou personnalisées.
Le tableau 3.01 ci-dessous montre quelques exemples de services avec leurs localisations. Il y a des
services qui sont habituellement partagés entre les serveurs Proxy et d'autres serveurs réseautiques,
comme par exemple le service d'afficheur.

Tableau 3.01 : Exemple des services de télécommunications selon leurs localisations

37
L'approche proposée de conception et de réalisation de services de télécommunications en SIP est
comme suit :

 Concevoir ou choisir le service. Un service donné peut être conçu s'il est nouveau ou bien
être choisi s'il est existant. Les services existants sont des services traditionnels dans le
domaine de la téléphonie IP et la téléphonie PSTN tels que la boîte vocale, le transfert d'appel
et la conférence. Par contre, un nouveau service apporte à l'utilisateur de nouvelles
fonctionnalités soit en ajoutant des nouvelles options à des services existants ou en créant
un service basé sur un nouveau concept tel qu'une boîte vocale adaptée qui accepte l'audio,
la vidéo, un site Web et du texte.

Un service peut être nouveau en SIP sans l'être selon l'utilisateur, car SIP est un protocole de
signalisation qui interagit avec l'application. Une application peut utiliser plusieurs protocoles afin
de réaliser un service donné.

 Décrire à l'aide de diagrammes la logique du fonctionnement du service dans

l'environnement SIP. Ceci doit se faire d'une façon à respecter les spécifications du
protocole SIP, A noter que ces diagrammes sont indépendants de l'environnement de
programmation. C’est ce qu’on va essentiellement réaliser dans ce chapitre.
 Proposer des solutions de réalisation, de mise en œuvre et d'implantation des services
conçus. Les méthodes et les outils de mise en œuvre des services de la téléphonie IP en
utilisant SIP sont variés. Plusieurs choix (par exemple, l'API JAIN-SIP et les logiciels
comme JMF….) ont été décidés après une recherche sélective afin de proposer une solution
adéquate de réalisation en tenant compte du matériel et du logiciel disponible.
 Effectuer des tests de validations des services conçus et mis en œuvre.

3.4 Analyse[15]

L’objectif de notre projet est de proposer un prototype de softphone et de Proxy server. Dans la mise
en œuvre de cette architecture SIP, c’est le proxy qui gère et contrôle les agents utilisateurs. Ces
agents utilisateurs qu’on va concevoir sont capables, de recevoir un appel SIP pour échanger des
flux audio avec l'autre session. De son côté, le proxy offre la redirection des appels vers les
destinataires mais a aussi comme particularité d'être interfacé avec un service d’envoi de courriels
pour avertir les utilisateurs des tentatives d'appels. A travers ce projet, on pourra examiner les

38
aspects comme l’articulation de SIP avec un autre protocole de communication pour l’échange de
flux.

La figure 3.01 montre l’architecture en couches de SIP, telle que la présente le modèle OSI, fait
apparaître une palette de nombreux protocoles;
A chacune des couches de l’architecture SIP sont associés des protocoles tels que :
 RSVP est un protocole utilisé pour réserver les ressources réseaux sur IP avec une
excellente qualité de service (QoS) ;
 R.T.P (Real-time Transport Protocol) pour transporter des informations en temps réel avec
une excellente qualité de services;
 R.T.C.P (Real-Time streaming Control Protocol) pour assurer le contrôle de flux des
données multimédia;
 S.A.P (Session Announcement Protocol) pour préciser si les sessions multimédia ouvertes
le sont en multicast ;
 S.D.P (Session Description Protocol) est un protocole de description des sessions
multimédia.
Comme tout processus de réalisation d’un projet, nous commençons par identifier l’acteur de notre
application et exprimer les services que doit lui offrir l’application. Ensuite, nous présentons la
spécification semi-formelle, suivant la norme UML 2.0, de ces besoins à travers des diagrammes de
cas d’utilisation et leurs scénarios respectifs.

3.4.1 Expression des besoins

On a décidé qu’on va mettre en œuvre une architecture qui permettra à un utilisateur appartenant à
un domaine de recevoir des appels voix mais aussi de recevoir une notification qui laisse une trace
de toutes les personnes qui ont cherché à joindre cet utilisateur.

La figure 3.02 présente un aperçu de l’architecture qu’on va mettre en place. Cette architecture est
composée d’une part d’un domaine SIP comprenant un proxy SIP et plusieurs agents serveurs
enregistrés dans le proxy et d’autre part d’agents clients extérieurs au domaine.

39
 Figure 3.01: L’architecture en couches de SIP

(*)SIP peut être également utilisé sur ATM(AAL5), X25 et frame relay.

a) Identification des acteurs

Nous avons un seul acteur pour notre application (softphone) qui est l’utilisateur qui peut être à la
fois appelant (émettre des appels) et appelé (recevoir des appels).

b) Besoins fonctionnels

L’application « softphone » doit fournir les fonctionnalités suivantes :

 Enregistrement de l’agent utilisateur dans le proxy du domaine : pour pouvoir aboutir

convenablement un appel, l’appelant doit s’enregistrer auprès d’un proxy serveur
 Etablissement d’un appel avec un autre agent :

Deux cas de figures se présentent :

 L’application doit permettre à l’utilisateur de composer directement une URI SIP et

d’émettre un appel vers cet URI
 L’application doit permettre à l’utilisateur de choisir un contact SIP enregistré et de
l’appeler.

40
  Réception et gestion des appels entrants :

L’application dit permettre à l’utilisateur de recevoir des appels sur son compte SIP.

 Annulation et terminaison d’appel.

 Transfert des flux audio en mode full-duplex basé sur le protocole RTP.
 Gestion d’une base de contacts
- Ajouter un nouveau contact : l’application doit permettre l’ajout d’un nouveau contact.
- Supprimer un contact existant : l’application doit permettre la suppression des contacts.
- Modifier un contact existant: l’application doit permettre la mise-à-jour des
informations d’un contact

L’application « Proxy Server » comporte les fonctionnalités suivantes :

 Gestion de l’enregistrement des agents utilisateurs du domaine

 Gestion des appels en provenance des clients SIP extérieurs au domaine avec
redirection de ces appels vers les agents SIP du domaine en utilisant les adresses
physiques de contact enregistrés. On va enregistrer qu’une seule association (adresse
logique, adresse physique) par utilisateur.
 Gestion de l’absence ou de l’état occupé d’un agent utilisateur.

Le proxy qu’on a développé est avec état (« stateful ») et aura comme particularité de contrôler
l’ensemble de la signalisation entre 2 agents utilisateurs participant à la session. Concrètement, cela
signifie que la totalité des messages SIP de la session transitera par le proxy, de la requête INVITE
jusqu’à la réponse OK du BYE.

Ce choix d’un contrôle complet de la signalisation a été retenu pour plusieurs raisons :

 Il permet de mieux rendre compte de l’utilisation de proxy dans une problématique

d’opérateurs.
 Il fait intervenir les champs d’en-tête spécifiquement conçus pour forcer le routage de la
signalisation comme Record-Route et Route.

3.4.2 Besoin non fonctionnels

L’application doit satisfaire les facteurs de qualité suivants :

Réutilisabilité

41
Le code source des applications doit être bien organisé, lisible et compréhensible. Les tabulations,
espacements, indentations et autres normes (appellation des variables, paramètres, classes,
méthodes, attributs doit être significative) sont recommandés.

Ergonomie

L’interface doit être conviviale et le passage entre les différents menus doit être intuitif.

Généricité

L’application doit pouvoir communiquer avec n’importe quelle entité SIP.

3.5 Spécification

Les diagrammes de cas d'utilisation servent à illustrer le comportement fonctionnel de notre

application. Chaque cas d'utilisation représente un type d'interaction entre l'utilisateur et notre
système.

42
3.6 Diagrammes d’activité

Figure 3.02: Diagramme d’établissement de service appel dans une session SIP

Le diagramme d’activité permet de décrire toutes sortes de processus : des processus industriels,
des processus métier, le déroulement d'un cas d'utilisation ou encore un algorithme.

43
3.7 Schéma de fonctionnement et acheminement des messages SIP dans l’architecture

Figure 3.03: Envoi d’une requête invite à travers le proxy Server développé

Si un Proxy server est utilisé, l'agent utilisateur de l'appelant transmet une requête INVITE au Proxy
server, le proxy server détermine le chemin et achemine la requête vers la partie appelée. La partie
appelée répond au Proxy Server qui à son tour achemine la réponse vers l'appelant. Le Proxy Server
achemine les acquittements des deux parties. Une session est ensuite établie entre les parties
appelante et appelée. RTP (Real-time Transfer Protocol) est utilisé pour la communication entre les
parties appelante et appelée.

44
Figure 3.04: Réponse de la requête Invite

Figure 3.05: Dialogue entre les softphones

45
3.8 Choix des scénarios pour le développement des applications et la mise en œuvre des
services

3.8.1 Identification des scénarios

Il est important d'identifier les différents scénarios utilisateurs qui sont à prendre en compte de façon
à pouvoir déduire les échanges de messages à gérer au niveau de chaque participant. Nous supposons
pour chaque scénario que l'agent utilisateur appelé est enregistré dans le proxy avec une adresse
logique (Address of Record) et que l'agent utilisateur appelant externe au domaine passe par le
proxy pour inviter l'utilisateur enregistré. En se basant sur ces hypothèses, nous proposons la prise
en compte des scénarios suivants:

 Scénario de base: l'agent utilisateur appelé accepte l’appel audio qui est intégralement
contrôlé et relayé par le proxy. Après l'établissement de la session SIP. chaque agent
utilisateur échange le flux audio avec l'autre agent. Dans cet échange de flux audio, le proxy
n'intervient pas. La fin de l'appel est initiée par l'un des deux agents en passant par le proxy
;
 un scénario de rejet d'appel par l'utilisateur appelé : ce rejet sera notifié par un message à
l'agent utilisateur appelant ;
 un scénario d'utilisateur appelé qui est déjà occupé par un autre appel : comme
précédemment, l'utilisateur appelant aura une notification indiquant la raison de non -
établissement de la session. De son côté, l'utilisateur appelé recevra une notification
indiquant qu'un utilisateur a réalisé un appel qu’il n'a pas pu avoir.
 un scénario d’utilisateur absent : ce scénario conduit aux mêmes actions que le précédent.
La détection de l'absence sera gérée par le proxy ;
 un scénario d'annulation de l'invitation : dans ce scénario, l'utilisateur appelant décide de
stopper la demande d'appel avant qu'il soit confirmé par l'utilisateur appelé.

Ces différents scénarios seront supportés symétriquement par l'agent utilisateur. Cela signifie que
l'agent permettra à son utilisateur de jouer aussi bien le rôle de celui qui initie un appel que le rôle
de celui qui s'enregistre auprès du proxy et reçoit un appel.

46
3.8.2 Diagramme de logique de fonctionnement dans l’environnement SIP

a) Enregistrement d’un utilisateur

Pour l’enregistrement d'un agent utilisateur dans le proxy, l'échange de messages est simple comme
le montre la figure 3.17. Il consiste en l'envoi d'une requête REGISTER au proxy qui répond par une
réponse OK si l'enregistrement a bien été pris en compte. II est intéressant de noter que l'annulation
d'un enregistrement s’effectue d'une façon similaire. La différence se situe dans le champ d'en-tête
Contact de la requête REGISTER qui doit avoir un délai d'expiration égal à 0 (paramètre « expires »).
Signalons également que, pour permettre l'envoi de courriel automatique, l’adresse email de
l'utilisateur sera donnée en tant que paramètre de ce champ Contact.

b) Etablissement de la session SIP et utilisateur non enregistré

L’échange de message SIP commence par l'envoi de la requête INVITE au proxy. A la réception de
la requête INVITE, le proxy retourne une réponse provisionnelle 100 Trying de façon à indiquer que
la demande d'établissement de session a bien été priser en compte et qu'elle est en cours de
traitement. Si l'adresse logique peut être résolue, le proxy relaie la requête INVITE vers l'adresse
physique destinataire sinon le proxy répond avec une réponse 604 Does Not Exist Anywhere comme
illustré à la figure 3.18. Quand l'agent utilisateur appelé reçoit la requête INVITE, celui-ci avertit
l'utilisateur par une sonnerie et lui demande son choix (acception ou rejet) en présentant une boîte
de dialogue. Tant que l'utilisateur ne fournit pas de décision, l'agent envoie une réponse Ringing à
intervalle régulier au proxy que celui-ci « repropage » à l'agent utilisateur appelant. Quand
l'utilisateur appelé accepte l'appel (décrochage) une réponse 200 OK est retournée au proxy qui la
renvoie à l'agent utilisateur appelant. Ce dernier confirme l'établissement de la session avec l'envoi
d'une requête ACK qui est relayée par le proxy jusqu'à l'agent concerné. Ce dernier échange met en
évidence le statut de proxy avec état puisque celui-ci relaie l'acquittement en s'appuyant sur la
mémorisation de l'adresse physique destinataire pour la session. En fin de session, le requête BYE
correspondante est envoyée au proxy par l'un des deux agents part participant à l’appel puis le proxy
se charge de la retransmettre à l'autre agent. Puisque cette requête peut provenir de l'un ou de l'autre
agent, son traitement diffère des autres types de requêtes dans la gestion de la réponse 200 OK. Cette
réponse est directement fournie par le proxy sans attendre la réponse de l'autre agent. Ainsi, la
terminaison de la session peut être plus rapidement confirmée. Celte façon de procéder correspond
à un fonctionnement du proxy en mode saut-par-saut (Hop-by-Hop).

47
 a) Appel Décliné et utilisateur occupé

La figure 3.19 montre l'échange de messages quand l'utilisateur appelé décline l'appel. Dans ce
scénario, les premiers échanges sont similaires au cas précédent. Le changement intervient au niveau
du rejet de l'appel par l'utilisateur appelé. Cette décision de rejet se traduit par l'envoi de la réponse
603 Décline au proxy qui retransmet à l'agent appelant.
Pour le scénario d'un utilisateur occupé par une autre session, l'échange de messages est donné à la
figure 3.20. Comme nous pouvons le constater, cet échange présente une structure assez proche du
premier scénario. La différence de ce scénario réside dans la réponse 486 Btisy Here de l'agent
utilisateur appelé au lieu des réponses 180 Ringing dans le cas précédent. Cela s'explique par la
détection immédiate de l'état occupé par l'agent utilisateur appelé. Quand le proxy reçoit la réponse
486 Busy Here de cet agent, celui-ci retransmet bien sûr cette réponse à l'agent utilisateur appelant
mais il peut également établir un dialogue avec le serveur de messagerie par exemple pour émettre
l’email de notification automatique d'appel à l'utilisateur appelé avec des informations utiles comme
l'adresse SIP de l'appelant.

b) Absence d’utilisateur et annulation d’appel

Pour le scénario correspondant à l'absence d'utilisateur, l'échange de message est donné à la figure
3.21. En analysant cet échange, nous pouvons voir que scénario débute comme le scénario de base,
par l'envoi de la requête INVITE. Ce scénario diffère au niveau du proxy dans le traitement des
réponses 180 Ringing de l'agent utilisateur appelé. Dès que le nombre de réponses Ringing atteint
un seuil prédéterminé (par exemple 10), le proxy considère que l'utilisateur est absent. Cette
détection d'absence de l'utilisateur se traduit par l'envoi d'une réponse 480 Temporarily Unavailable
à l'agent utilisateur appelant et l'envoi d'une requête CANCEL à l'agent utilisateur appelé de façon à
annuler l'appel. Cet envoi de requête CANCEL donne lieu à une réponse 200 OK et une deuxième
réponse 486 Request Terminated liée à la requête INVITE.

48
Enfin scénario d'annulation de l'invitation est présenté à la figure 3.21. Ce scénario caractérise par
l'envoi d'une requête CANCEL avant la confirmation d’établissement de session. Cette requête
CANCEL dispose des mêmes champs d'en- tête CSEQ et CallID que la requête INVITE. Dans la
figure 3.21, nous avons fait le choix de faire intervenir cette annulation juste après la deuxième
réponse Ringing. Cette annulation est retransmise par le proxy à l'agent utilisateur appelé. Il est
importé noter que dans ce cas d'annulation, le proxy n'attend pas la réponse de l'agent utilisateur
appelé et répond immédiatement à l'agent appelant avec un message 200 OK et une réponse 486
Request Terminated pour la requête INVITE. De son côté, l’agent utilisateur appelé confirme
l'annulation au proxy en répondant un message 200 OK confondant à la requête CANCEL et un
message Request Terminated pour la requête INVITE.

3.9 Conclusion

L’analyse des besoins est achevée, et comme les différents cas d’utilisation ainsi que les activités
sont extraites, la phase de conception dispose maintenant de la matière d’œuvre pour mener sa
mission. La conception, qui se base sur cette spécification, fera l'objet du prochain chapitre.

49
 CHAPITRE 4
Mise en œuvre et simulation des applications Proxy Server et Softphone

4.1 Introduction[15][16][17]

Après avoir pris connaissance des différents scénarios envisagés et des échanges de messages à
mettre en œuvre, nous allons nous intéresser dans la suite à la réalisation logicielle des applications.

Nous présentons dans la partie conception globale de ce chapitre, les différents composants de notre
application à travers un diagramme de paquetage. Dans la conception détaillée, nous illustrons la
vue structurelle par des diagrammes de classes.

4.2 Conception globale

4.2.1 Diagramme de paquetage

L'organisation en paquetages de l'agent utilisateur est montrée à la figure 4.01 Le paquetage

principale ne comporte pas de classes mais inclut cinq sous-paquetages qui sont :
 le paquetage softphone.rtp: ce paquetage contient les deux classes qui forment la couche de
contrôle RTP. On y trouve ainsi la classe AudioReceiver qui gère la réception des paquets
RTP contenant le flux audio et restitue leur contenu sur la sortie audio. Il y a aussi la classe
AudioTransmitter qui gère l'émission depuis l’entrée audio;
 le paquetage softphone.media : ce paquetage contient deux classes pour gérer et diffuser les
sonneries liées à des événements comme par exemple un nouvel appel. La classe Tone sert
à représenter et à jouer une sonnerie préenregistrée dans un fichier audio. La classe
TonePlayer permet de gérer facilement l'ensemble des sonneries.
 le paquetage softphone.ui : ce paquetage contient les classes qui constituent la couche
UserAgent UI. Ces classes sont au nombre de trois. Il y a tout d’abord la classe UserAgentUI
qui construit et gère l’interface utilisateur. Cette classe contient le point d’entrée de
l'application. Une autre classe de ce paquetage est la classe Contact qui sert à représenter les
contacts édités par l'utilisateur. La dernière classe est la classe TextAreaAppender. Cette
classe implante un type de composant d’interface facilitant l’affichage de traces émises à
partir de la bibliothèque de journalisation Log4j ;
 le paquetage softphone.event : ce paquetage regroupe toutes les classes qui matérialisent des
événements de haut niveau liés à la signalisation SIP. Par exemple, on peut citer la classe

50
 BusyCallEvent qui représente un événement matérialisant un appel occupé ou encore la
classe DeclinedEvent matérialisant un appel refusé. Ces classes d’évènements sont
notamment utilisées par la couche UserAgent SIP pour remonter des changements d’état à
la couche UserAgentUI;
 le paquetage softphone.sip : ce paquetage correspond à la couche UserAgentSIP. Il contient
une classe UserAgentSip et une interface UserAgent gère toute la signalisation SIP
correspondant aux différents scénarios envisagés précédemment. Elle implante notamment
l'interface SipListener afin de traiter les événements survenant dans la couche JAlNSip.
L’interface UserAgentListener définit le protocole pour transmettre à la couche d’interface
utilisateur les événements de haut niveau mentionnés précédemment

Nous proposons de bien séparée la partie logicielle qui s'occupe de l'interface utilisateur de la partie
logicielle chargée de la communication réseau. La figure 4.02 montre la structuration en couches de
l'application ainsi que les interactions entre les couches. L'ensemble des couches est composé de :

 la couche UserAgent UI se charge de construire et de gérer l’interface utilisateur.

 la couche UserAgent SIP se charge de gérer les différents schémas d communications SIP
que nous avons explicités précédemment mais pilote aussi le flux audio RTP quand la session
est confirmée ou terminée. Cette propos également des opérations à la couche UserAgent UI
afin de créer et de contrôler u ¡op mais aussi d'en connaître l'état ;

 la couche JAIN-SIP correspond à la pile SIP ;

 la couche Contrôle RTP se charge de gérer la transmission et la réception du flux RTP si1
s'appuyant sur la couche JMF ;

 la couche JMF (Java Media Framework) comprend la pile RTP et les gestionnaires de
contenu audio.

Ces couches interagissent entre elles. Ces interactions supportent soit des demandes d'exécution de
traitement à une couche inférieure, soit des notifications de changement d'état d'une couche
inférieure vers une couche supérieure. L'architecture précédente donne une vue de haut niveau de
l'application.

51
4.3 Programmation du proxy

Un proxy est une entité importante des architectures SIP. En effet, proxy, la réception d'une requête
entraîne l'envoi d'une nouvelle requête et la réception d'une réponse entraîne l'envoi d'une nouvelle
réponse.

Le Proxy ne dispose pas d'interface d'administration. C’est encore une version simplifiée,
néanmoins, le proxy proposé a été conçu de façon à ce que son noyau inclut les fonctionnalités de
base attendues dans un proxy SIP, sans toutefois respecter intégralement la spécification SIP. Il a
également été pensé afin que les principales difficultés qui se posent dans la conception d'une telle
entité soient abordées. Ces difficultés sont par exemple la gestion d'une communication multiparties,
le parallélisme des échanges, la mise en relation des messages d'une même session, le de contrôler
la totalité de la signalisation.

4.4 Simulation et validation

4.4.1 Outils logiciels tests

Cette section présente les deux outils de test utilisés : la fenêtre de validation dont l'interface
graphique est montrée sur la figure 4.04 et le logiciel Wireshark.

 La fenêtre de validation. Cette fenêtre (a été conçue totalement et implanté lors de la

réalisation de l'application SoftPhone dans le but de vérifier tous les messages (requêtes-
réponses) reçues et envoyées, ainsi que leur contenu. Ces messages sont échangés au niveau
de l’application. Cette fenêtre se trouve dans l’onglet SIP de l’interface utilisateur.
 Le logiciel Wireshark : c’est un analyseur de paquets réseau qui va essayer de capturer des
paquets réseau et tente d'afficher que les données de paquets aussi détaillée que possible.

4.4.2 Matériels utilisés

Le matériel utilisé (disponible) pour implanter les services comporte 2 ordinateurs et des accessoires
périphériques audio, ainsi qu'un serveur Proxy qu’on a developpé.

a) Les ordinateurs

Un ordinateur portable DELL : intel core 2duo , 1,73 GHz, windows 7 32 bits

Un ordinateur portable Asus core i5, 2.67 GHz, windows 8 64 bits

Tous les ordinateurs sont munis d'une carte réseau, d'une carte vidéo et d'une carte de son.

52
 b) Les périphériques audio

Ecouteurs (micro casque)

Haut-parleur intégré de l’ordinateur

4.4.3 Résultat de la simulation des différents scénarios établis

Interprétation

A travers les figures de capture d’écran lors du lancement des applications, on peut constater que
les résultats sont tout à fait conformes au diagramme SIP établie dans le chapitre 3 avec les différents
scénarios.

Figure 4.01: Capture des paquets pendant l’établissement d’un appel VoIP avec le softphone

4.5 Discussion

De manière évidente, l’application permet bien à l’utilisateur d’initier des appels sur IP et qu’on est
arrivé à bien intégré le protocole SIP lors de son utilisation. La conduite de ce projet de fin d’étude
a été une expérience très particulière et une opportunité réelle pour mettre en pratique les
connaissances acquises durant les années de formation d’ingénieur.

53
Bien que le projet soit concluant, on a rencontré au cours du développement du projet quelques
remodélisations du système: après réflexion. Cependant, il faut noter que le proxy est encore une
version vraiment simplifié. Il est tout à fait possible d’envisager l’intégration d’autres
fonctionnalités plus ou moins sophistiquées comme par exemple la redirection automatique d’appel
vers l’email pour certains créneaux horaires ou pour certaines adresses SIP, la redirection vers une
messagerie vocale ou encore l’envoi d’un SMS à la place d’un email.

4.6 Conclusion

Dans ce chapitre nous avons décrit l'environnement de travail. Ensuite, nous avons argumenté les
différents choix technologiques que nous avons pris. Les services et les scénarios qui ont été mis en
œuvre ont été validés.

54
 CONCLUSION GÉNÉRALE

Les services de télécommunications ont préoccupé les chercheurs afín de trouver une solution à la
problématique de création de services de télécommunications qui a émergé de l'évolution rapide de
l'Internet et de la téléphonie sur Internet (ou téléphonie IP). Des protocoles de signalisation ont été
standardisés afin d'élargir globalement le domaine d'utilisation de la téléphonie IP. Au début de
l'Internet, les différentes applications (solutions) n'étaient pas compatibles entre elles. Les premiers
outils de conférences n'utilisaient aucun protocole de signalisation. Les grandes compagnies
d'Internet et de télécommunications ont réalisé l'importance de la téléphonie IP, ce qui a établi un
forum spécifique à la téléphonie IP afin de partager les connaissances dans ce domaine. Ces efforts
ont produit le premier protocole de signalisation H.323 qui était suivit plus tard par MGCP et SIP.

Ce travail a permis d'étudier des protocoles de signalisation afin de proposer une solution efficace
répondant au besoin de la création des services de télécommunications plus facilement. Lors de la
recherche, une étude comparative a été faite premièrement afin de choisir entre les 2 protocoles
H.323, et SIP qui a plusieurs avantages par rapport aux deux autres.

Par la suite, une étude a été effectuée afin de montrer comment les messages engendrés par SIP
peuvent s'intégrer dans les logiques des services à concevoir. Également, des solutions de réalisation
et d'implantation de ces services ont été proposées lors de ce travail. À noter que tous les services
réalisés ont été testés avec succès selon plusieurs scénarios.

Ce travail a démontré l'avantage d'utiliser le protocole SIP et l'API JAIN-SIP afin de concevoir,
réaliser et de mettre en œuvre des services facilement, ce qui ouvre l'opportunité de créer de
nouveaux services de télécommunications plus avancés, soit du côté terminal ou du côté serveur.

55
 BIBLIOGRAPHIE

[1] M. A. Rakotomalala, « Réseau NGN », cours 5ème année, Dpt TCO, ESPA-UA, 2012-
2013
[2] A. Ratsimbazafy., « Téléinformatique et télématique », cours 4ème année, Dpt TCO,
ESPA-UA, 2011-2012
[3] D. Tait , J. Keijzer,R. Goedman , « JAIN: A New Approach to Services in Communication
Networks », IEEE Communications Magazine 2000.

[4] R. Gupta , « JAIN Protocol APIs », IEEE Communications Magazine, Janvier 2000

[5] C. Harris , « JAIN SIP Release 1.0 Specification », Sun Microsystems 2001

[6] P. Asprino , A. Fresa , M. Longo , « Developing new generation network services »,

2010

[7] M. Day Lotus , H. Sugano , « A Model for Presence and Instant Messaging » , Février
2000

[8] E. Campbell , J. Rosenberg , H. Schulzrinne , C. Huitema, D. Gurle, «Session Initiation

Protocol (SIP) Extension for Instant Messaging - RFC 3428. », Décembre 2002

[9] A. Delley, « Réseaux IP - Voix et multimédia sur IP. », EPFL FLASH INFORMATIQUE
, 21 janvier 2003

[10] J. Rosenberg , H. Schulzrinne , G. Camarillo ,A. Johnston, J. Peterson ,E. Schooler « la

RFC 3261 SIP: Session Initiation Protocol », Juin 2002

[11] L. Schweizer, « Script et APIs pour la gestion des serveurs SIP », Juin 2002

[12] S. Donovan, « The SIP INFO Method - RFC 2976» , http://

www.faqs.org/rfcs/rfc2976.html., octobre 2000

[13] S. Kundan, H. Schulzrinne, «Failover and Load Sharing in SIP Telephony», janvier 2004

[14] P. O'Doherty , M. Ranganathan , « JAINTM SIP API Specification»

[15] P. O'Doherty , A. Kristensen , C. Bouret , « SIP and the Java Platforms», White Paper.,
juin 2003

56
[16] A.Roach « Session Initiation Protocol (SlP)-Specific Event Notification -RFC 3265»,
http://www.faqs.org/rfcs/rfc3265.htmt, juin 2002.
[17] S. Baset,, H. Schulzrinne, « An Analysis of the Skype Peer-to-Peer Internet Telephony
Protocol. » , Septembre 2004

57
 FICHE DE RENSEIGNEMENTS

Nom: RAMAMONJISOA
Prénom: Nomeny
Adresse: 58, La résidence d’Ambatobe
Antananarivo 101
Madagascar
Tel : +261 33 04 602 80
E-mail : nomeny.ramamonjisoa@gmail.com
Titre du mémoire :
«ETUDE ET IMPLEMENTATION DU PROTOCOLE SIP DANS LA MISE EN ŒUVRE DES
APPLICATIONS ORIENTEES TELEPHONIE SUR IP»
Nombre de pages : 69

Nombre de figures : 54

Nombre de tableaux : 01

Mots clés : NGN, JAIN API, protocole SIP, VoIP softphone, RTP

Directeur de mémoire : Nom: RATSIHOARANA

Prénom: Constant
Grade : Maître de conférences
Tel : +261 33 16 023 76

58
 RESUME

Ce mémoire nous a permis de mieux cerner le domaine du développement d’application orienté

réseau en java, et des architectures SIP. Dans sa première partie nous avons vu les bases théoriques
sur le réseau de nouvelle génération ou NGN, d’un point de vue plutôt généraliste avec une étude
un peu approfondie sur les différents protocoles de signalisation. Après, la place de l’API JAIN
dans le développement des services de nouvelle génération. Dans la dernière partie de ce travail,
plusieurs scénarios ont été simulés avec les applications qu’on a développées en JAVA (API JAIN)
après une présentation des applications proprement dites. Ainsi, des méthodes de développement de
service ont été citées pour aider les ingénieurs dans la création ou la mise en œuvre des services en
télécommunications.

ABSTRACT

This research has helped us to master the field of network application development in java, and SIP
architectures. Firstly, we have already seen theorics basics about NGN, according to the knowledge
about different signaling protocols. Secondly, the API JAIN’s importance in the development of the
new generation services. Finally, many scenarios have been simulated with the applications which
we have developed in JAVA (API JAIN) after the presentation of the applications. Therefore,
methods for developing service have been cited to help engineers to create something new in
telecommunications

59