Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

CONCEPTION ET MISE EN ŒUVRE SERVICE VOIP SUR

SERVEURS IMS OUVERTS ET ASTERISK
INTERCONNECTÉ VIA LE SERVEUR ENUM

Rendy Munadi 1), Effan Najwaini 2), Asep Mulyana 3), R.Rumani.M4)
Telkom Institute of Technology, Bandung 40257 West Java-INDONESIE Email : rnd@ittelkom.ac.id.1)
effan_86@yahoo.com2), asm@ittelkom.ac.id3), rrm@ittelkom.ac.id4)

ABSTRAIT
Asterisk et Open IMS utilisent le protocole de signal SIP pour permettre aux deux d'être connectés. Pour
faciliter les deux relations, le serveur Enum - capable de traduire l'adresse de numérotation telle que PSTN (E.164) en
adresse URI (Uniform Resource Identifier) - peut être utilisé. Dans cette recherche, nous interconnectons Open IMS et le
serveur Enum du serveur Asterisk. Nous analysons ensuite les performances du serveur et les valeurs PDD (Post Dial
Delay) générées par le système.
À la suite de l'expérience, nous avons constaté que, pour un appel d'un utilisateur Open IMS vers un téléphone
analogique Asterisk (FXS) avec un appel d'arrivée de chaque serveur est de 30 appels/ sec, la valeur PDD maximale est de 493,656 ms.
Open IMS est capable de servir un maximum de 30 appels/ s avec un processeur informatique de 1,55 GHz, tandis que
l'Asterisk avec un processeur informatique de 3,0 GHz peut servir jusqu'à 55 appels/ sec. Enum on server avec un
processeur informatique de 1,15 GHz a la capacité de traiter un maximum de 8156 requêtes/ sec.
MOTS CLÉS
Voice Over Internet Protocol (VoIP), Open IMS, serveur Asterisk et ENUM, Post Dial Delay (PDD).

1. PRÉSENTATION
L'interconnexion et la convergence entre le RTPC, le PLMN et le réseau de données devraient développer un système
très puissantÿ; ce système fournira des services PSTN, la mobilité, des fonctionnalités PLMN et une application basée
sur Internet. Cette convergence prendra en charge un service multimédia avec une bande passante adéquate et une
grande mobilité. La technologie IMS est issue de la combinaison des concepts multimédia, mobile et IP afin de compléter
la technologie NGN [3,4].
.IMS agit comme une plate-forme standard de service multimédia via le protocole IP/SIP avec lequel il
est possible pour l'opérateur d'utiliser sa plate-forme pour de nombreux services multimédia. IMS fait
partie de la norme d'architecture du réseau de nouvelle génération (NGN). Les services pour les
réseaux fixes, mobiles et sans fil peuvent être exploités via la plate-forme IMS avec un service basé
sur IP et pris en charge par le protocole SIP [1,5].
.À l'origine, IMS est développé pour la connexion téléphonique dans le réseau mobile, mais avec la
version 7 de TISPAN, il a également la possibilité pour le réseau fixe, d'où le terme convergence fixe-
mobile (FMC) qui est une tendance clé de l'industrie en 2005 [5 ].
Des logiciels basés sur l'architecture NGN ont été développés aujourd'hui. OpenIMS est constitué du
logiciel basé sur l'architecture IMSÿ; il a la capacité de diverses fonctionnalités multimédias. D'autre
part, Asterisk est un logiciel basé sur l'architecture softswitch qui est capable de connecter un réseau
de paquets et un réseau de circuits. Avec ces deux logiciels, nous pouvons construire une technologie
NGN simple avec un investissement à moindre coût.
Pour illustrer les cas ci-dessus, nous concevons et mettons en œuvre un service VoIP, en utilisant le
logiciel ci-dessus, à l'aide du serveur Enum dont la fonction est de cartographier le nombre parmi
les serveurs.

2. CONCEPT DE BASE
2.1. Open IMS OpenIMS
(Open Source IMS) est un logiciel créé par FOKUS (Institut allemand) en décembre
2006. FOKUS implémenté de manière intégrée pour certains composants IMS, tels que

10.5121/ijngn.2010.2201 1
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

CSCF, HSS, serveurs d'application et autres, que l'on peut voir sur la figure.1. Ce logiciel dispose de différents
services de plate-forme, tels que "Open Service Access (OSA)/Parlay, JAIN Service Logic Execution Environment
(SLEE), Web services/Parlay X, SIP Servlets, Call Processing Language (CPL)" [16].

Figure 1 Vue d'ensemble du réseau OpenIMS

2.2. Astérisque

Asterisk est un logiciel open source qui peut être utilisé pour développer des services de communication.
Asterisk lui-même permet aux utilisateurs d'améliorer eux-mêmes les services téléphoniques avec une
personnalisation flexible par les utilisateurs. Open source signifie que le développeur peut modifier les codes
sources afin que les applications puissent être ajoutées facilement par le développeur.
Asterisk peut être considéré comme un PBX complet ou un PBX logiciel complet et fournir toutes les fonctionnalités
du PBX. L'avantage d'Asterisk: peut fonctionner sous certains systèmes d'exploitation tels que Linux, Windows,
BSD et OS X. Une autre chose est qu'il peut être connecté à presque tous les standards POTS avec un matériel
supplémentaire minimum / bon marché comme passerelle. Certaines fonctionnalités sont fournies telles que la
messagerie vocale, la conférence téléphonique, la réponse vocale interactive, la mise en file d'attente des appels,
l'appel à trois, les services d'identification de l'appelant, l'interface de service d'affichage analogique, le protocole
SIP VoIP, H323 (en tant que client et passerelle), IAX, MGCP (fournir des appels fonction de gestionnaire uniquement), SCCP/Skinny et autres [2].
Le titre doit être écrit en 20 pt. Police Garamond, centrée et utilisant les formats gras et "Small Caps". Il devrait
y avoir 24 pt. (paragraphe) espacement après la dernière ligne.

2.3. Présentation de l'énumération

Le mappage électronique des numéros (ENUM) est un mécanisme de mappage des numéros. Le mappage
des numéros signifie les numéros d'identité des équipements électroniques (recommandation ITU-T E.164) vers
le système DNS Uniform Resource Identifier (URI) [10]. L'URI DNS a été globalement utilisé sur Internet. ENUM
est une norme recommandée par l'IETF (RFC 3761). Il permet à l'utilisateur d'utiliser un numéro de téléphone
pour accéder au DNS. Ensuite, l'utilisateur peut accéder à l'enregistrement Universal Resource Identifier à l'
intérieur de l'enregistrement de ressources NAPTR qui appartient à ses numéros, comme on peut le voir sur la figure.2.
Le mappage électronique des numéros est un mécanisme de mappage.

2
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

Figure 2. Communication de flux via ENUM

2.4. Délai après numérotation (PDD)

Retarder la configuration d'appel mentionnée comme Post Dial Delay (PDD). Basé sur l'IETF, PDD est une période
commençant par le dernier chiffre composé jusqu'à l'état du message de destination (sonnerie ou occupé). Basé
sur ITU-T, PDD est un intervalle entre le dernier chiffre composé jusqu'à l'acceptation de la tonalité de retour d'appel.
Le PDD sur le réseau de données par paquets, en particulier sur la communication SIP VoIP, peut être mesuré à
partir de l'étape INVITE (demande d'appel au serveur) jusqu'à la tonalité d'état de destination, telle que le code
180 (sonnerie). On peut le voir sur la Figure.3 [2].

Figure 3. Configuration d'appel entre client-serveur SIP

3. CONCEPTION ET MISE EN ŒUVRE DU SYSTÈME

Le test de score PDD peut être effectué une fois que le système s'est assuré qu'il peut fonctionner correctement.
Le système est configuré à partir du serveur OpenIMS, du serveur Enum et du serveur Asterisk pour les services VoIP.

3
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

3.1. Topologie du réseau du service VoIP Cette

recherche vise à analyser la relation des terminaux SIP, en particulier le processus du serveur de
temps, le temps PDD et l'utilisation du processeur. Pour mettre en œuvre la relation, un scénario de
modèle de topologie de réseau est appliqué. Ceci peut être vu sur la figure 4.

Figure 4. Topologie du réseau

3,2, Support d'équipement

Matériel :
• Processeur 1,55 GHz (serveur OpenIMS)
• Processeur
• d'échange IP PBX 3,0 GHz (serveur Asterisk)
• Processeur 1,15 GHz (serveur ENUM)
• Ordinateur (Client)
• Commutateur
• Ethernet Haut-parleur et Microphone
Logiciel :
• Système d'exploitation Gentoo
2007 (OpenIMS)
• Système d'exploitation Trixbox (astérisque)
• Système d'exploitation Ubuntu 8.04
(ENUM) • Serveur DNS (BIND-9.3.2)
• Analyseur de protocole réseau Wireshark
version-0.99.2 3.3. Évaluation du système

Une fois le système installé et bien configuré, les prochaines étapes sont les mesures et l'analyse
des données. a) Traitement du temps dans chaque mesure de serveur.

Pour OpenIMS et Asterisk, la mesure prendra en compte le temps requis par le signal SIP à
l'intérieur du serveur avant qu'il ne passe à la destination. Alors que le serveur Enum sera mesuré

4
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

le temps nécessaire pour répondre à la requête. Cette mesure est effectuée en tant que données
d'analyse pour la mesure PDD [6,7] Mesure effectuée sans trafic d'appels/autres requêtes.
b) Mesure du PDD (délai après numérotation)
Les mesures PDD sont effectuées avec les scénarios suivants.
1. Appel entre OpenIMS sans Enum 2. Appel
entre utilisateur OpenIMS via Enum 3. Appel
utilisateur d'OpenIMS via Enum vers des numéros FXS (2003) Astérisque
Chaque scénario de mesure est effectué avec une quantité d'appels ou une requête par seconde
différente. Collectes de données réalisées 30 fois et moyennées. c) Mesure de l'utilisation de l'unité
centrale Les mesures sont effectuées pour chaque serveur pour différentes quantités d'appels ou
requêtes par seconde afin d'obtenir une valeur d'appel ou une requête maximale par seconde.

4. ANALYSE DU SYSTÈME

Dans ce chapitre, nous examinerons les tests et l'analyse des résultats de la mise en œuvre qui ont été
effectués. L'objectif des tests et des analyses est de mesurer les performances des serveurs OpenIMS et
Asterisk via l'interconnexion des serveurs Enum. Comme mentionné dans la section précédente, cette
recherche se concentrera sur l'analyse du service de temps dans chaque serveur, PDD et l'utilisation du
processeur. Plusieurs logiciels ont été utilisés tels que wireshark, SIPp, Top et Queryperf-nominum [12,14]
Comme référence de valeur maximale de PDD, la norme IETF a recommandé une recommandation comme
suit [15] :

Tableau 1. Norme de valeur maximale de PDD

PDD sans WDD avec
Catégorie ENUM ENUM
(seconde) (seconde)
PC à PC 2,23 2,25
PC à
RTPC 3,79 4.11
RTPC vers
PC 3.41 3,95

4.1. Mesure du processus de retard dans le serveur

L'objectif de la mesure du processus de retard est de mesurer combien de temps le serveur peut servir un
appel ou une requête. La valeur du temps de service peut influencer la valeur PDD atteinte. Le résultat de
la mesure dans les serveurs OpenIMS et Asterisk conduira à des informations importantes sur le composant
de signal SIP, qui a une longue durée de service.

Figure 5. Processus de retard OpenIMS

5
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

D'après la figure 5, on peut voir que le signal d'invitation nécessite un temps de traitement plus long. Lorsque le
serveur accepte le signal INVITE, il effectuera une vérification. Le serveur vérifiera l'état d'enregistrement de
l'utilisateur appelé, pour récupérer l'adresse IP et le port utilisateur de l'utilisateur appelé, puis transmettra le
signal INVITE à la destination en fonction de l'adresse IP appelée et de l'utilisateur du port. Pour l'autre signal, le
serveur n'effectue qu'une vérification simpleÿ; il agit simplement comme proxy qui a passé les appels. Ainsi, les
autres signaux ne nécessitent que peu de temps pour le traitement du serveur. • Astérisque

Figure 6. Processus de délai d'astérisque

Identique au calcul du processus de signal à partir d'OpenIMS, le signal INVITE nécessite le temps de traitement
le plus long. Cette chose s'est produite en raison de l'acceptation du signal INVITE, elle sera traitée de la même
manière que dans le serveur OpenIMS.
• Énumération
Basé sur le résultat de la capture, le processus moyen dans le côté Enum : 0,345400 ms, signifie que le serveur
est capable de traiter une requête en très peu de temps.

• Comparaison

Figure 7. Comparaisons des délais de traitement

D'après la figure 7, il existe une grande différence entre le processus du serveur Asterisk et IMS Server.
Le serveur OpenIMS nécessite 9,00 ms pour une communication mais Asterisk nécessite 257,48 ms. Cela signifie
que le serveur Asterisk consomme 28,6 fois le temps de service IMS. On peut en conclure que l'astérisque
fonctionne de manière inefficace dans le processus de configuration d'appel.
Les données utilisateur dans le serveur Enum seront dans la base de données Mysql, mais dans Asterisk, ce
n'est qu'une gorgée. conf, donc le temps requis relativement court lors de la vérification du compte utilisateur. Le
processus de routage sur Open IMS sera enregistré sur le fichier scsf.cfg (langage C utilisé). Dans le serveur Asterisk présent sur extension.cnf

6
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

et extension supplémentaire. conf (pour un PBX gratuit). Il contient un fichier de configuration. Ce fichier
sera exécuté par le langage de programmation. Pour modifier le plan de numérotation dans Asterisk,
l'utilisateur peut modifier les paramètres de configuration dans ce fichier. C'est un moyen simple mais qui
entraînera des conséquences à long terme. Asterisk trixbox a des plans de numérotation compliqués qui
prendront beaucoup de temps à modifier.
Le serveur Enum a un processus de courte durée, il a donc la capacité de gérer certaines requêtes
simultanément. Nous discuterons de la capacité maximale de requêtes à traiter dans la section suivante.
Tous les encarts, figures, diagrammes, photographies et tableaux doivent être alignés au centre, clairs et
appropriés pour une reproduction en noir/blanc ou en niveaux de gris.

4.2. Mesure PDD et utilisation du processeur

Mesure PDD, commencez à partir de zéro trafic jusqu'à un certain trafic qui entraîne une valeur PDD
supérieure à la norme IETF. Le trafic d'appels sera augmenté de 5 appels par seconde jusqu'à une valeur PDD
supérieure à la norme IETF. Valeur PDDÿ: temps requis entre le signal INIVITE envoyé par l'appelant et
l'acceptation du signal de sonnerie de réponse (180). Pour collecter les valeurs PDD, le logiciel wireshark
sera utilisé pour capturer certaines données transmises à l'ordinateur de l'appelant (UAC). Chaque scénario
sera exécuté 30 fois et moyenné.
La mesure de l'utilisation du processeur utilise les meilleurs logiciels installés sur le serveur. Chaque valeur
de capacité de trafic sera observée pour l'utilisation maximale de l'UC de chaque serveur.
• Résultat
Premier scénario (entre utilisateur OpenIMS sans Enum)

INVITE et le temps de traitement du signal de sonnerie à l'intérieur du serveur auparavant de 3,92 ms, le PDD
mesuré pour le trafic 0 est de 107,87 ms peut être vu à la Figure.8. Cela signifie qu'en plus du délai du serveur,
il existe d'autres composants de délai qui influencent le temps PDD. Le client et le processus de commutation
ajouteront du temps PDD. L'assemblage et le désassemblage des paquets côté client sont difficiles à
observer, ainsi que le processus de lecture des commutateurs sur la couche 2.

Scénario 1

140.000000

120.000000
Scénario 1

100.000000

0 5 dix 15 20 25 30

Trafic

(appel/s)

Figure.8 Premier scénario PDD

L'augmentation du trafic d'appel vers le serveur augmentera le temps PDD et augmentera l'utilité du processeur.
Jusqu'à 30 appels/sec PDD toujours acceptables (selon la norme IETF). Incrément de PDD de 0 à 30 appels/
sec : moins de 20 ms

sept
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

Tableau 2. Mesure du PDD du premier scénario

Trafic Utilisation du

(appel/s) processeur

5 10 (pourcentage)

10 15

15 35
20 50
25 65
30 78
35 100 (surcharge)

Pour un trafic d'appel supérieur à 30 appels/sec, le serveur OpenIMS ne peut pas gérer l'appel. Le résultat de
la surveillance sur les SIP a montré qu'un si grand nombre de retransmissions se sont produites, Timeout et
Unxpected-Msg. Il affiche l'état du serveurÿ: surcharge et incapable de servir, comme indiqué dans le
Tableau.2. Mesure PDD, l'établissement de l'appel sera trop long. Ces faits de surveillance montrés par le
client wireshark sont retransmis encore et encore. Ainsi, pour le trafic d'appels supérieur à 30 appels/sec, le
serveur est incapable de servir les appels. Si cette situation oblige à gérer plus de 30 appels/sec, le serveur sera en panne (redémarrage).

Deuxième scénario (entre utilisateur OpenIMS via Enum).

À partir du résultat de la mesure, l'incrémentation des composants Enum lors de l'établissement de l'appel
augmentera la valeur PDD. Pour le trafic jusqu'à 30 appels/s, la valeur PDD est toujours conforme à la norme
IETF, comme indiqué dans le tableau 3.
Tableau 3. Mesure PDD du deuxième scénario

OpenIMS-ENUM-OpenIMS
Trafic PDD

(appel/sec) (ms)
0 108,8
109,5
5 10 110,4
15 114.1
20 116.4
25 118.6
30 133.1

Cela est dû à un processus plus rapide dans le serveur Enumÿ; La valeur PDD avec Enum n'augmente que
de 0 à 10 ms, si elle est comparée sans Enum. Il est visible sur la figure 9 ci-dessous.

Figure 9. Comparaison des premier et deuxième scénarios PDD

8
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

Tableau 4. Mesure de l'utilisation du processeur via le trafic

Enum OpenIMS-ENUM-OpenIMS
Utilisation du

(requête/s) processeur

5 10 (pourcentage)

0,3 0,3

15 0,3
20 0,3
25 0,7
30 0,7
35 0,7

D'après les résultats ci-dessus, le serveur OpenIMS n'a la capacité d'effectuer des appels de trafic simultanés qu'à 30
appels/s, de sorte que le trafic de données pour ce scénario n'est limité qu'à 30 appels/s. Sur un trafic d'appel de
30ÿappels/s, l'utilisation du processeur dans le serveur Enum n'est que de 0,7ÿ%, comme dans le tableau 4ÿ; ce chiffre
est supérieur à la valeur maximale. La requête maximale par seconde peut être traitée à l'aide d'un logiciel appelé
queryperf. À partir du résultat de la mesure avec queryperf, il peut être démontré que le serveur Enum peut atteindre
8156,87 requêtes/seconde.

Troisième scénario (de l'utilisateur OpenIMS à FXS

Astérisque via Enum)

Le troisième scénario peut montrer les résultats de PDD qui est toujours conforme à la norme IETF. Dans ce scénario,
la valeur PDD utilisée est supérieure à celle des autres scénarios. Cette condition est causée par le processus
temporel dans le serveur Asterisk pour qu'un signal d'invitation consomme plus de temps soit 254,5 ms. La
comparaison de tous les scénarios pour la valeur PDD peut être vue dans la figure 10 ci-dessous

Figure 10. Comparaison des PDD pour tous les scénarios

Le tableau 5 montre que pour un trafic d'appels de 35ÿappels par seconde, l'utilisation du processeur dans Asterisk
ne peut pas atteindre la valeur maximale. Le prochain test consiste à trouver le maximum d'appels avec l'aide du
logiciel SIP. Lorsque l'appel d'arrivée est supérieur à 55 appels par seconde, l'utilisation du processeur sera en condition de surcharge.
À partir de ce test, nous avons constaté que le serveur Asterisk ne peut gérer qu'un maximum de 55 appels par seconde.

9
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

Tableau 5. Astérisque d'utilisation du CPU

OpenIMS-ENUM-Asterisk
Trafic Utilisation du

(appel/s) processeur

35 (pourcentage) 51

40 60
45 69
50 79
55 92
60 100 (surcharge)

La figure 11 montre une comparaison de l'utilisation du processeur pour tous les serveurs en tenant compte du trafic de
charge pour chaque serveur.

Figure 11. Comparaison de l'utilisation du CPU

Sur cette implémentation, le serveur OpenIMS ne peut assurer un service maximum que de 30 appels par seconde, mais
pour le serveur Asterisk, il peut atteindre 60 appels par seconde. Le serveur Asterisk peut gérer un grand nombre d'appels,
car il utilise un processeur à haut débit - 3,0 GHz ; OpenIMS utilise uniquement la fréquence du processeur de 1,55ÿGHz.
Un autre serveur pour Enum avec un taux de processeur de 1,15 GHz a la capacité de gérer jusqu'à 8156 requêtes par
seconde.

5. CONCLUSION

Sur la base de l'implémentation, des tests et de l'analyse, nous pouvons conclure quelques résultats comme suit :
1. L'interconnexion entre OpenIMS et Asterisk via le serveur Enum a été réalisée avec de bons résultats. Cette
interconnexion montre qu'il est possible que deux utilisateurs puissent être connectés en utilisant Asterisk comme
passerelle dans un réseau de circuits.
2. Pour la phase d'établissement d'appel, le temps de traitement dans le serveur Asterisk est plus long que dans le serveur
openIMS. Le serveur Asterisk se concentre davantage sur l'utilisateur dans un processus de routage fixe facile à
gérer, tandis qu'OpenIMS se concentre sur le taux de processus de routage.
3. Certains cas affectant les valeurs PDD sont le traitement du temps d'appel du serveur et la quantité de trafic vers le
serveur. De tous les scénarios, le résultat de la valeur PDD qui se situe sous la plage de la norme IETF est de 2,3
secondes. La valeur maximale moyenne du PDD est de 493,66 secondes, trouvée dans le scénario 3, avec une
quantité de trafic en arrière-plan de 30 appels par seconde. Dans ce scénario, un appel passera par les trois serveurs :
Open IMS, Enum et Asterisk.

dix
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

4. La quantité de trafic d'arrivée ou de requête pouvant être traitée par le serveur, en

fonction des types de serveur et des spécifications de l'ordinateur utilisé dans le système.

REMERCIEMENTS

Les auteurs tiennent à remercier ITTelkom et YPT à Bandung pour leur soutien financier.
Ils expriment également leurs sincères remerciements et leur gratitude à tous les collègues d'ITTelkom
pour leur aimable aide et leurs suggestions utiles.

RÉFÉRENCES
[1] Architecture de service du sous-système multimédia IP (IMS), Lucent Technologies Inc., www.lucent.com/
accelerate. 2005
[2] Rosenberg, JV et H. Schulzrinne, 2002, SIP:Session Initiation Protocol, Request for Comments
3261, Internet Engineering Task Force. Projet de partenariat de 3e générationÿ; Services du
[3] groupe de spécifications techniques et aspects systèmeÿ; sous-système multimédia IP (IMS); Étape 2
(version 6). www.3gpp

[4] Gonzalo Camrillo, Miguel A. Garcia-Martin, "The 3G IP Mulitmedia Subsystem (IMS)", ISBN 0-470-018118-6,
mai 2006 The IMS:IP Multimedia Concepts and Services, Second Edition Miikka poikselka, Georg Mayer,
[5] Hisham Khartabil et Aki Niemi @ 2006 Jon Wiley & Sons, Ltd. ISBN : 0-470-01906-9 Purbo, Onno W (2007).
VoIP Précurseur de « Telkom Rakyat ». Jakarta : Gramedia.
[6]
[7] Schulzrinne, Henning (2000). Prévision du délai d'établissement des appels de téléphonie Internet.
Université Columbia, États-Unis.
[8] Sharif, Ben (2007). Trixbox-2 sans larmes. Australie.
[9] Albitz, Paul (2006). DNS et BIND. États-Unis : O'Reilly Media, Inc.
[10] Shockey, Richard (2006). Révision ENUM. États-Unis : Neustar, Inc.
[11] http://f1naj.blogspot.com/2008/03/install-open-ims-gentoo.html http://
[12] uctimsclient.berlios.de/openimscore_on_ubuntu_howto.html http://
[13] www.digium.com/en/products/
[14] http://wiki.wireshark.org
[15] http://ietf.org
[16] http://www.openimscore.com
[17] http://openmaniak.com/iperf.php

Courte biographie Photo

Rendy Munadi a reçu son doctorat de l'Université d'Indonésie.
Il est maître de conférences à ITTelkom Bandung-INDONESIA et
il est actuellement directeur du programme de troisième cycle.
Le Dr Rendy Munadi a siégé au comité de programme de
plusieurs conférences. Il fait actuellement des recherches dans
le domaine du réseau de nouvelle génération, IMS, réseau sans
fil, réseau IP/MPLS, gestion du routage et protocole SIP, H323, ,
etc. e-mail : rnd@ittelkom.ac.id).

Asep Mulyana a reçu son MT de Bandung Institute of Technology-

Indonesia. Il a une expérience dans le domaine du système de
commutation (échange), expérimenté en tant que formateur sur
diverses technologies de système de commutation, de système
de signalisation et de réseaux de télécommunication au Centre de formation PT.
TELKOM Bandung. Il est actuellement chargé de cours sur la
technique de commutation, les réseaux de télécommunication,
l'ingénierie du trafic, les réseaux d'accès, le système de
signalisation et les réseaux de nouvelle génération (NGN). En
ce moment, il s'intéresse et se préoccupe de la recherche sur les NGN et l'IMS

11
Machine Translated by Google

International Journal of Next-Generation Networks (IJNGN) Vol.2, No.2, juin 2010

R. Rumani Mangkudjaja; Département d'électricité et de

communication, Telkom Institute of Technology, Bandung 40257,
INDONÉSIE. R. Rumani Mangkudjaja est né à
Balikpapan, INDONÉSIE, le 4 avril 1947. Il a obtenu les diplômes
BS en éducation de l'Institut d'enseignement et d'éducation,
Bandung, Indonésie, en 1978, et en génie électrique de l'Université
chrétienne Maranatha, Bandung, Indonésie en 1981, et le diplôme
MS en Communications de la George Washington University,
Washington, DC, USA, en 1994.

Actuellement, il est chargé de cours en génie électrique et

communication à l'Institut de technologie Telkom, Bandung,
Indonésie, depuis 1994.
Ses intérêts de recherche comprennent les réseaux informatiques et de
communication, les réseaux de nouvelle génération, le RNIS, les réseaux
intelligents, la théorie des files d'attente, la théorie du trafic et les domaines connexes.
.

12