Services Télécoms («IP»): architecture et signalisation

Transcription

1 Objectifs: ervices Télécoms («IP»): architecture et signalisation Ahmed MEDDAHI Analyser et comprendre: Les architectures et modèles sur lesquels s'appuient les services "Télécom" (ex les services "voix"). Les "contraintes" en particulier dans le contexte des réseaux paquets "IP". Illustration des différents concepts (problèmes liées au support de services de type "temps réel" dans les réseaux paquets) la "téléphonie" (sur IP) est le principal service télécom considéré. Deux aspects: Les mécanismes et architectures de signalisation (Ex. IP) généralement associés à "l'intelligence" du réseau ("équivalent" au protocole "7" dans les réseaux circuits). La Qualité de ervice réseaux qui représente un élément essentiel des réseaux IP est également étudier à travers l'analyse des principaux mécanismes de gestion de Qo et modèles associés (ex. Differv, Interv). Mais aussi: exploitation à un "haut niveau" des mécanismes de signalisation et de la Qo : introduction aux environnements ("API") de création/déploiement de services télécom IP: concepts JAIN (Java Api for Intelligent/Integrated Networks) (ex. JAIN IP, JAIN LEE). Aspect création/déploiement de services télécom. Remarque: Ces différents aspects seront illustrés à travers des séances de travaux dirigés et Travaux Pratiques. 1 2 Contenu: Partie "ignalisation". Rappels des mécanismes de signalisation dans les réseaux classiques "circuit" (ex. 7). Principes et concepts de la signalisation IP (ex. IP) et exemples de scénario d'appels. Analyse et comparaison avec les mécanismes supportés par les réseaux "classiques". Partie "Qualité de service" dans les réseaux. Les principaux modèles de Qo (Differv et Interv), de mécanismes de gestion et de contrôle de file d'attentes (ex. Algorithme VA, Leacky Bucket, Token Bucket) dans les réseaux IP sont présentés et analysés. Des illustrations de ces mécanismes de Qo en particulier liées à leur configuration dans les réseaux, sont donnés à travers des exemples concrets et pratiques. Partie "Création de services" (introduction). Principes et concepts des environnements pour la création/déploiement de service Télécom dans les réseaux IP.Cette partie est illustrée en particulier à travers le modèle d'architecture JAIN (Java Api for Intelligent/Integrated Networks). Application (ervices) Transport Réseau Liaison Physique Cohabitation des protocoles «IP» Flux (Audio/Video) ervices (Applications) Flux (ignalisation) JMF JAIN «call control» JAIN «IP» RTP RTCP IP INAP IUP TCAP UDP TCP IP, Differv, Interv TL TCP GMPL MPL Ethernet HDLC/PPP ATM DH/WDM/DWDM Cuivre /Fibre Optique. IP Transmission (ervices) (Qo) 3 4

2 ervices «Télécoms» Introduction Rappels Réseaux «classiques» Architecture et signalisation ex. RNI et 7 Réseaux «IP» Architecture et signalisation ex. IP, MEGACO, CTP Eléments critiques et Conclusion Introduction 5 6 ervices Télécom. IP: Introduction Architecture générale de référence «ervices Télécom.»: Moyens mis en œuvre tels que : signalisation, ressources (commutation, transmission ) pour la fourniture et la gestion d accès à un «service» # services fournis par voie de télécommunications (notion de contenu, ex. service d annuaire) Téléphonie (sur IP) Fax temps réel (G3/G4) Transmission données Vidéo conférence Fax store & Forward «Video On demand" «Live treaming» (TVoIP) «Messagerie Instantanée» «Push to talk» «context aware VoIP». PTN/7 Analog./Digital 7 CTP Gw MGw (services API) erveur contrôle d appels Coeur réseau: Internet + Qo (Diffserv/Intserv) ignalisation:ip, Megaco/H.248 H.323/IP Flux media (RTP/RTCP/ ) RTP/RTCP Plate-forme de services (services API) IP, Megaco/H.248 RGw Terminal (services API 7 «Circuit» «Paquet» Gw: signaling gateway MGw: media gateway RGw: residential gateway Remarque (sur IP): intelligence à la périphérie du réseau circuit de sig. Indépendant du circuit de transport (du flux) 8

3 Réseaux de niveau 1, 2 et 3 IP Niveau Paquet Gestion de l accès au support Codage et traitement du signal pour adaptation au support *RPR MAC Ethernet MAC HDLC/PPP ATM IEEE IEEE PRC-PHY 10 Gig E PHY Gig E PHY Packet Over onet (PO) AAL.5 Niveau trame Rappels Gestion de la transmission Réseau de transmission (ex. onet/dh, WDM, DWDM ) Niveau physique upport physique Lien (ex. Fibre Optique) La Qo dépend aussi de l architecture et des performances du réseau de transmission * RPR, Resilient Packet Ring 9 10 Commutation de messages#commutation de paquets Commutation de messages#commutation de paquets paquets de 1.5 Kb D Commutation de messages pas de segmentation par la source. Ex: message de 7,5Mb D 2 commutateurs de paquets -0 Message 3 liens à 1.5 Mb/s -5 Message -10 Message -15 Message Tps (sec) Tps (msec) -La commutation de paquet réduit le délai de commutation par un facteur 3 -i perte d un paquet, uniquement le paquet perdu est envoyé et non le message complet 11 12

4 ervice orienté connexion ervice sans connexion Échange de messages de ignalisation entre l émetteur, le récepteur et le réseau avant l échange du flux de donnée. service fournissant :acquittement, contrôle de flux, contrôle de congestion. dans l Internet,TCP offre un service orienté connexion. l émetteur envoie simplement le paquet d information dans le réseau pas de contrôle de flux pas d acquittement Pas de contrôle de congestion UDP (téléphonie/ip, Audio/Vidéo à la demande, vidéoconférence ) Commutation synchrone Commutation Asynchrone Mémoire tampon Mémoire tampon ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 ITj ITx IT0 Mémoire de commande (table de routage) Réseau d aiguillage (matrice de connexion, bus ) Mémoire de commande (table de routage) Réseau d aiguillage (matrice de connexion, bus ) 15 16

5 Multiplexage temporel ynchrone # Asynchrone 8 eb 125 µs B B B C B A C B A MUX ligne multiplex A B C C A B ync. Async. Rqs: -multiplex de sortie partagé dans le temps entre les différentes voies incidentes Debit sortie=somme (debit entrée) 8 eb voie n 1 voie n 30 Hiérarchie Numérique Plésiochrone (PDH) 30 voies TN1 TN1 30 TN2 TN1 TN1 120 voies TN3 TN1 TN1 480 voies TN4 voie n 1 à n 30 8 bits toutes les 125 µs 1920 voies -en asynchrone: -motif de début/fin de trame ou debut/longueur de trame nécessaire -débits multiples et quelconques possibles -meilleur optimisation du lien -perte de synchro. (flux temps réel) voies 139,264 Mb/s 18 Multiplex primaire Européen (TN1 ou T1) Débit : 2048 kb/s = 32 x 64 kb/s 30 voies de communication IT 1 à 15 IT 17 à 31 1 voie de verrouillage trame ( IT 0 ) 1 voie de signalisation ( IT 16 ) "économique" Multiplexage statistique (asynchrone) ex:un lien 1Mb/ec. Débit de chaque utilisateur -> 100 Kb/s profil du débit «Bursty» (on/off) chaque utilisateur n envoie des data que pendant 10% du tps. Multiplexeur statique: chaque utilisateur a 100 kb/s. 10 utilisateurs maxi. Multiplexeur statistique ou de paquet: 35 utilisateurs. Probabilité d avoir 10 «collisions» <0,0004. On peut supporter beaucoup plus d utilisateurs avec une probabilité de «collision» faible

6 Multiplexage # Commutation # Acheminement Multiplexage Temporelle ynchrone (circuit) # Asynchrone (paquet) Commutation temporelle ynchrone (circuit) #Asynchrone (paquet) Acheminement dans le réseau circuit (RTC,RNI..) circuit virtuel (F.R, X25, ATM, ) permanent ou commuté datagramme (IP,..) Auto-acheminement (802.5 "source routing",..) RQs: commutation: technique "Hard tate" nécessite une signalisation de mise en place et destruction modification du path "lourd" Routage: technique "oft tate" premier paquet établit la route rafraîchissement obligatoire modification dynamique de la route («path») ignalisation ignalisation: définition Échange d informations entre les éléments d un réseau, nécessaire pour fournir et maintenir des services. Mise en œuvre d un «circuit» ou d une connexion: pour l établissement d appel ou l accès à un service: ignalisation (usager) messagerie vocale videoconference N vert carte prépayée 23 24

7 Exemple de configuration à bus passif Exemple de configuration à "étoile de bus" Terminaux "classiques" adaptateur Bus TNR accès de base NUMERI télécopieur groupe 4 Commutateur NUMERI ou PABX TNR TNR TNR Groupement d'accès de base NUMERI Domaine de responsabilité OPERATEUR télécopieur Domaine de responsabilité OPERATEUR 25 codeurdécodeur Terminal audioconférence 26 Numéris : Utilisation des différents canaux Numéris : Accès d'usager NUMERI Canal B 1 Canal B 2 Canal D ignalisation minimessages, identification d'appel, etc. Modes de raccordement au RNI Côté "réseau" L'Accès de base (144 kbit/s; 2B + D) - 2 canaux B à 64 kbit/s pour la parole, les données, le texte et les images - 1 canal D à 16 kbit/s pour la signalisation et la mini-messagerie L'Accès Primaire (2 Mbit/s; 30B + D) - Connexion de PABX, d'ordinateurs ou de serveurs ignalisation "out band" Transfert en mode paquet Côté "terminal" Le bus - 10 prises, 5 terminaux - Bus long ou court - Contact permanent avec le réseau 27 28

8 ignalisation «UAGER-REEAU» exemple (RNI) Format de trame (niveau 1) 48 bits 250 µs tructure de la trame LAP D (niveau 2) tructure générale des trames du LAP D DL F L B1 EDAF a N B2 EDM B1 ED B2 EDL F L TNR TE Fanion Contrôle d'erreur Information Commande Adresse Fanion 2 bits de décalage Q DL F L B1 LDLF a L B2 LDL B1 LDL B2 LDL F L TE TNR tructure du champ adresse API C/R 0/1 E/A 0 API: 0 API: 16 API: 63. signalisation données paquet/canal D maintenance/gestion TEI E/A Répertoire des trames utilisées dans le LAP D (niveau 2) Application Format Commandes Réponses Codage Transfert d'information à trames multiples avec accusé de réception et sans accusé de réception Transfert d'information upervision Non numéroté I (information) RR (prêt à recevoir) RNR (non prêt à recevoir) REJ (rejet) ABME (mettre en mode asyn. équilibré étendu) UI (informations non numérotées) DIC (déconnexion) XID (échange d'identificateur) RR (prêt à recevoir) RNR (non prêt à recevoir) REJ (rejet) DM (mode déconnecté) UA (accusé de réception non numéroté FRMR (rejet de trame) XID (échange d'identificateur) N() 0 o. 4 N(R) P o o. 4 N(R) P/F o o. 4 N(R) P/F o o. 4 N(R) P/F o P F P P F F P/F o. 4 o. 4 o. 4 o. 4 o. 4 o. 4 o. 4 tructure des messages (niveau 3) Discriminateur de Protocole (1 Oct.) (data # info de gestion/contrôle) Référence Appel (2 Oct.) (ex.identifie le dialogue d établissement) Type de message (1 Oct.) Elément d info. I (au format TLV:Type, Longueur, Valeur) Elément d info. j Elément d info. K 32

9 Les principaux messages utilisés par le protocole D Nom du message Etablissement Accusé de réception d'établissement Appel en cours Alerte Connexion Accusé de réception Appel acheminé Déconnexion Libération Fin de libération Phase d établissement Phase de déconnexion ignification Demande d'établissement d'appel Le numéro de destination reçu est réputé incomplet L'information relative à l'appel est incomplète; l'appel est en cours d'établissement L'usager destinataire est alerté Réponse de l'usager Ex. éléments d info: adresse source et dest. ervice support n canal info des couches 4 à 7 DA ig. Usager/usager Confirme la prise en compte de la réponse Indique une situation d'inter fonctionnement ou d'informations fournies par le réseau dans le canal B Invitation à libérer la communication Confirme que la demande de libération est en cours Confirme la libération de toutes les ressources allouées à l'appel 33 Indication de sonnerie Arrêt de l'indication de retour d'appel Exemple de procédure pour un appel simple à commutation de circuits Usager Terminal d'abonné demandeur demandeur (A) par chevauchement Décrochage Etablissement Le terminal du demandé raccroche en premier Raccrochage A.R. d'établissement Info chevauchement Appel en cours Alerte Connexion A.R. de connexion Déconnexion Libération Déconnexion Libération Fin de libération Flux de données Terminal d'abonné demandé (Y) Etablissement Alerte Alerte Connexion A.R. de connexion Libération Fin de libération Déconnexion Libération Fin de libération Déconnexion Libération Fin de libération Terminal d'abonné demandé (X) onnerie Décrochage Raccrochage Usager demandé (X) Le terminal du demandeur raccroche en premier 34 Contention d'accès au canal D Résultat des conflits d'accès au bus Exemple de résolution de conflit terminal A 1 terminal B 1 terminal C 1 canal écho 0 Terminal A Terminal B ignal sur le BU terminal A abandonne terminal C abandonne tructure de trame HDLC adresse commande données FC Données reçues par la TNR Emission de polarités opposées la loi ET n'est pas réalisée 35 36

10 ignalisation «REEAU» ignalisation (réseau) ignalisation sémaphore Abonné Numéris C N C 5 ( ) C 5 C N Abonné Numéris Protocole D 7 (ignaling ystem 7) Protocole D Réseau de signalisation Une architecture en couche Réseau de signalisation serveur P PT PT P P P PT PT C4 C4 C5 C5 C4 C5 C5 Réseau de transport des informations Modèle MTP: Message Transfert Part routage mode datagramme CP:ignaling Connection Control Part ervice: Connectionless/Connection oriented TCAP: Transaction Capabilities Application Part Applicatif TUP: Telephone User Part Applicatif DUP: Data User Part Applicatif INAP: IN application part MAP : Mobile Application Part... MAP INAP TUP TCAP CCP IUP MTP Level 3 MTP Level 2 MTP Level

11 Les couches applicatives Les couches applicatives IUP: définit le protocole et les procédures pour l établissement, la gestion des circuits destinés au transport de la voix et des données sur PTN. Exemple:établissement d appel IAM :initial adress message REL: release RLC: release message ACM: adress complete message ANM: answer message (5) REL (1) IAM TP W P A (4) ACM (6) ANM (8)RLC Liens ss7 (6) REL (2) IAM «voice trunk» (0) switch A analyse du n doit envoyer vers B réservation d un circuit libre TP X (3) ACM (5)ANM (7) RLC P B CCP: offre un service orienté "connexion" (pas d'établissement de connexion mais assure sequencement, contrôle de flux ) identifie l application de niveau supérieur fonction d appellation globale «global title representation» P A (4) response (1) «800» query TP W TP X (3) response (2) «800» query CP L CP M La couche physique et liaison La couche réseau MTP L1= lien 2Mbs («T2»), 64 kbs (V35), 64 Kbs (0), ATM MTP L2 MTP L3: IF (ignaling Info. Field) Données De Contrôle Fill In ignal Unit FIU Link tatus ignal LU Flag Bsn Bib Fsn Fib Li pare Crc Flag Bsn Bib Fsn Fib Li pare tatus Crc 279 oc. Maxi 8 ou 16 1 oc. 3 bits 5 bits Dpc Dpc Dpc Opc Opc Opc pare ls CIC member cluster network member cluster network bits. Routing Label ANI point code: 24 bits ITU-T point code: 14 bits Circuit Identification code dans le cas des messages Isup Mess. type ex itu-t point code 5557 peut être codé ( ) Couches up. (ex. IUP) Données d info. Message ignal Unit Flag Bsn Bib Fsn Fib Li pare io if Crc MU 8 bits <=272oc. 16 MTP L3 zone région ignaling point ls : signaling link selection: partage du trafic sur plusieurs liens 43 44

12 ignalisation: suite "courant continu" ("DC" signaling) analogique nombre d'états limité (tension, courant ) ex: «Ear&Mouth», Accès RTC "binaire" ("digital " signaling ou Common Associated ignaling:c.a..) les 4 bits de l IT16 du Mic E1 (C.A.. E1) le 7éme bit d un IT voix (64->56Kbs) " dans la bande " ("in band») «diffserv (ip)» : numérique DTMF (usager/réseau 300<<3400Hz): analogique "hors bande" ("out of band "/Common Channel ig. :CC) > bande 3.5 à 4 Khz (analogique) 7, canal D (RNI), «rsvp (IP)»: numérique ervices Télécom.: ignalisation IP TP C TP A D D D D A P E TP C TP E Rappel: Architecture RTC B B B B *P:ervice witching Point *TP: ignal Transfert Point *CP: ervice Control Point Réseau de signalisation A P TP C TP A A A A A CP CP ervices télécoms dans les réseaux «circuit»: Constats Topologie hiérarchique--> adaptée au transport de la voix (protocoles orientés circuit) mais pas optimisés pour le transport des données (~3/4 du trafic globale) 7 standard international mais implémentation différente (version Fr, U ) Commutateurs "classe 5" --> "complexes" (# classe 3 et 4 pour le transit) fournit les services de bases (signal d'appel, identifiant d'appel, transfert.) Congestion des commutateurs classes "5" et "4" Besoin d'un retour sur investissement rapide lié au déploiement des réseaux d'accès (Xdsl, BLR, 3GPP ) C3 Liens «TRUNK» C3 Besoin de standards simplifiés et "accessible" pour le développement et le déploiement rapide de nouveaux services C4 C4 Réseau de transport C4 C4 C5 C5 C5 C5 C5 C

13 ervices télécoms dans les réseaux «Paquet» (IP): Atouts Un seul réseau de transport principal (paquet «IP») --> Réseau Multiservices Topologie linéaire--> réseaux de «routeurs» Le "réseau intelligent" sur RTC se "résume" sur «IP» au serveur de contrôle d appels (oftwitch ou Call Agent) --> signalisation (ex.ip) architecture centralisée facilite la création et le déploiement de services # architecture distribuée du RTC Connectivité vers les réseaux existants (Mobile, Adsl, RI (7), ) Media gateways ignaling gateways "API" pour la création de services (ex service voix) ouvertes et supportées par tout type de technologie réseaux--> JAIN (ex. JAINIP) Convergence Fixe-Mobile Architecture IP orientée «IP», dans les réseaux mobiles (3G/IM: Internet Multimedia ubsystem) pour le transport voix/video/données. Convergence des services: accès au «même» service quelque soit le réseau (filaire ou sans fil) Convergence des terminaux: accès au «même» service à partir d un même type de terminal (ex: PDA ou portable avec plusieurs interfaces réseaux) Convergence des réseaux: accès au «même» service à partir d une seule et même techno. réseau (IP) quelque soit le réseau d accès Concept "d'ubiquité réseau " ("Any Where, Any device, Any Network") 49 PTN/7 «Circuit» «Paquet» Architecture générale (architecture dite Next Generation Network ) 7 CTP (IP) Gw MGw Gw: signaling gateway MGw: media gateway RGw: residential gateway erveur contrôle d appels Internet + Qo (Diffserv/Intserv) ignalisation: Megaco/H.248 H.323/IP Flux media (RTP/RTCP/ ) RTP/RTCP Plate-forme (services API) Megaco/H.248 (IP) RGw Remarque: circuit de sig. Indépendant du circuit de transport (du flux) 50 BT ignalisation 7 pour réseaux intelligents convergents HLR VLR BC TCAP CCP MTP3 MTP2 MTP1 CP IN (7 ou sémaphore) TP TP G Cohabitation des protocoles «IP» Création et établissement de séssion. BT BT Mobile CCP MTP3 MTP2 MTP1 MC MTP3 MTP2 MTP1 MGC OFTWITCH Réseaux Ip IP Media erver Appli. RV P Audio/Video RT P RTC P Appli. partagées Mcast Fiable H3 23 RT P AP DP IP HTT P MTP BC BT GM MAP IUP TCAP CCP MTP3 TCAP IUP CCP MTP3 MTP2 MTP1 N P CO Fixe P CO IPe MG VoIP Gateway INAP TCAP CCP MTP3 MTP2 MTP1 Transport Réseau Liaison Physique CRTP/MLPP UDP IP, IP Mcast,WFQ, Ip Precedence... TCP Ethernet/metroEthernet/PO/RNI/ATM.. MTP2 MTP

14 Protocole IP (ession Initiation/Invitation Protocol): Principales caractéristiques Protocole IP: Architecture RFC 2543/ (IETF IP WG depuis 1999) Pour l établissement de session «téléphoniques» et non téléphoniques (multimédia) : «services télécom +» VoIP, IM, data conferencing... Protocole de signalisation client/serveur, de niveau 7. Protocole orienté Internet: inspire de mtp et Http Format des messages textuel, ré-utilise la syntaxe HTTP 1.1 (RFC 822, UTF-8) Indépendant de la couche transport: TCP, UDP, «CTP» (couche «non-fiable») TL/TCP, IPec (couche «fiable»): Pb délai d établissement de session car mécanismes «hop by hop». Mécanisme d'adressage + Localisation : terminal serveur, "user" Protocole orienté Transactions: un dialogue (session) IP: séquence de «requête/reponse» Permet de garder un nombre minimal d états (info) au niveau des proxys. («scalabilité») erveur Redirect /Proxy Terminal IP Agent Utilisateur (AU) IP IP UA Entité Administrative: (erveur IP du réseau local) erveur Localisation Terminal IP IP UA IP erveur Registrar Réseau «IP» Terminal IP IP UA Passerelle IP IP UA Passerelle IP IP UA Passerelle IP IP UA erveur de média IP IP UA RTC Mobile H UAC Appelant Entités et Flux d appel IP (exemple) erveur IP erveur IP UA Appelé INVITE(Cseq1 INVITE) INVITE(Cseq1 INVITE) INVITE(Cseq1 INVITE) 180 Ringing(Cseq1 INVITE) 180 Ringing(Cseq1.) 180 Ringing(Cseq1 INVITE) Transaction 1 Etablissement 200 OK(Cseq1 INVITE) Transaction 2 Communication Transaction 3 Libération 100 Trying(Cseq1 INVITE) Cancel(Cseq1 INVITE) ACK(Cseq1 ACK) BYE(Cseq2 BYE) 200 OK(Cseq2 BYE) -Localization -Registration -Redirection OK(Cseq1 INVITE) 200 OK(Cseq1 INVITE) ACK(Cseq1 ACK) ou ACK (Cseq1 ACK) Flux MEDIA (ex. Audio) BYE(Cseq2 BYE) 200 OK(Cseq2 BYE) ACK(Cseq1 ACK) Remarque: canal (port) de signalisation distinct et non lié au canal (port) de transport du flux Dialogue IP 55 Entités principales d une architecture IP 1 (ession Invitation/Initiation Protocol) Agent Utilisateur Client et erveur Points terminaux capables d émettre (Uac) ou de recevoir (Uas) des requêtes IP (pour traitement et réponses) Terminaux IP (Uas+Uac) Terminaux VoIP, pont de conférence, contrôleur IP («B2Bua») Terminaux IP (UAs) enregistreur de message («voice mail»), serveur vidéo à la demande,... erveur de localisation Offre des services pour obtenir et mettre à jour des informations sur le destinataire (adresse courante et multiple, droit, mot de passe, disponibilité,...) Entité utilisée par les serveurs proxy et serveurs de redirection relayer ou rediriger les messages 56

15 Entités d une architecture IP 2 erveur proxy Entité intermédiaire active, à la fois client et serveur Retransmet les requêtes vers le destinataire (Routage) en s appuyant sur son service de localisation Traite les requêtes (analyse pour authentification, transformation, multi-diffusion,..) Mode opératoire tateless («scalabilité», robustesse aux «attaques»), Conserve un minimum d états relatif à l appel tatefull («Firewall») Conserve un maximum d états relatif à l appel erveur de redirection Reçoit des requêtes et renvoie à l émetteur une ou plusieurs adresses pour contacter le destinataire (régulation de charge) A la différence du serveur proxy, ce serveur n initie pas de requêtes Entités d une architecture IP 3 Back to Back User Agent (B2BUa) Maintien en mémoire des états relatifs à l appel (call statefull) Traitement sophistiqué des appels Participe plus activement au dialogue IP Capable de terminer ou initier la session (ex. carte prépayée; pont de conférence ) Contrôleur de sessions IP Carte pré-payée, pont de conférence, «click to dial» UA UA Dialogue X Dialogue X PROXY B2B Dialogue X Dialogue y UA UA Messages Requêtes: INVITE ACK BYE CANCEL OPTION REGITER.. Principaux messages IP : En-tête de message (générale): call-id Contact Date From To Via... Messages Réponses: Informational uccess Redirection Client Error erver Error Global Failure.. Corps d en-tête : Content-Encod. Content-Length Content-type. code 1xx 2xx 3xx 4xx 5xx 6xx 59 Méthodes («messages») de requête Méthode INVITE Initie une session en invitant un agent utilisateur à une conférence ou à simple appel Le corps du message contient généralement une description de la session (utilisation de DP: type de média audio, vidéo, data, format, codage en vigueur) Méthode ACK Indique que l appelant a reçu une réponse final à l invitation Le corps du message peut contenir la description finale de la session (négociation des capacités) Un corps vide indique que la description du message Invite sera utilisée 60

16 Méthodes de requête (suite) Méthode REGITER Gestion (ajout, maj, suppression) des liaisons (identifiant agent utilisateur, adresse contact) enregistrées dans le service de localisation Egalement utilisé pour interroger le service de liaison (serveur proxy, redirection) L agent utilisateur doit indiquer la durée de vie de la liaison (champ «expire») L agent utilisateur est également responsable du rafraîchissement de la liaison Méthode OPTION Permet d obtenir des informations sur les capacités d un agent utilisateur ou d un serveur sans avoir besoin d établir une session Informations : méthodes supportées, extension, type contenu,.. Peut être émis en dehors ou à l intérieur d une session 61 Méthodes de type requête (suite) Méthode CANCEL Annule un requête (Invite) émise par l appelant Requête «Hop-by-hop» Doit être utilisé après la réception d une première réponse Utilisé par les serveurs proxy lors d appels parallèles. Méthode BYE indique à l autre participant la clôture de la session Autres méthodes (pour le support de services évolués) PRACK (RFC3262) MEAGE, PUBLIH,UBCRIBE & NOTIFY (RFC3265) - ervice de présence (ex. pour les appli. de messagerie instantanée: MN) Pb: congestion (1 «subscribe/notify» et 1 «message» par RTT, ex toutes les 5sec.) mais aussi durée de vie des batteries (Pda, terminal mobile ) Pb: fiabilité des MEAGE (IP sur UDP) 62 tatut (code) des réponses 1xx : information sur le traitement des requêtes 100 trying, 180 ringing 2xx : succès 200 Ok 3xx : redirection 300 multiples choices, 302 moved temporarily 4xx : erreur client (client:cause de l erreur) 401 unauthorized, 404 not found 5xx : erreur serveur (serveur:cause de l erreur) 501 not implemented, 503 service unavailable 6xx : erreur globale 600 busy, 601 decline, 606 not acceptable Principaux champs d entêtes TO: URL-IP de la destination From: URL-IP de la source Call-ID: identifiant de session (vers.simple local-id@host) Maxforward: nombre max de sauts pour traiter le message Cseq(Command equence) : Numéro de transaction dans la session + méthode Via: route empruntée par un message jusqu à ce noeud prévention des boucles, garantie le chemin de retour (billing,...) Contact : pour l enregistrement d informations (Register) Content-type : type de média du corps (ex. application/sdp, application/xml, texte/plain )

17 méthode URL IP/2.0 Via: From: To: Call-ID: Cseq: Content-Length Content-Type: Champ: ligne vide Message IP RFC 822 (idem HTTP) : Ex. requête sip Ligne de début (méthode URL IP/2.0) En-tête de message IP/2.0/protocole hôte:port username <sip:from_user@source> username <sip:to_user@destination> localid@hôte numéro_seq méthode longueur du corps type de média du corps paramètre ;par1=valeur; par2= valeur V=0 o= user_origine timestamp timestamp IN IP4 hôte c=in IP4 média adresse_destination t=0 0 m= type_média port RTP/AVP types_payload INVITE sip:pascal@int.fr IP/2.0 Via:IP/2.0/UDP durer.enic.fr From:Ahmed<sip:ahmed@enic.fr> To:Pascal<sip:pascal@int.fr> Call-ID: @rodin.enic.fr Cseq:1 INVITE Contact::<sip:ahmed@ > Content-Type:application/DP Content-Lengh:.. v=0 o=ffl IN IP s=nom de la session P= c=in IP4 durer.enic.fr m=audio 5004 RTP/AVP IP/2.0 status reason-phrase Via: From: To: Call-ID: Cseq: Content-Length Content-Type: Champ: ligne vide Réponse IP : Ex. de réponse sip Type réponse IP/2.0/protocole hôte:port username <sip:from_user@source> username <sip:to_user@destination> localid@hôte numéro_seq méthode longueur du corps type de média du corps paramètre ;par1=valeur; par2= valeur V=0 o= user_origine timestamp timestamp IN IP4 hôte c=in IP4 média adresse_destination t=0 0 m= type_média port RTP/AVP types_payload en-tête message IP/ OK Via:IP/2.0/UDP sip-proxy.int.fr Via:IP/2.0/UDP ahmed.enic.fr From:meddahi<sip:ahmed@enic.fr> To:Pascal<sip:pascal@int.fr> :tag=2544 Call-ID: @rodin.enic.fr Cseq:1 INVITE Content-Type:application/DP Content-Lengh:.. v=0 o=pascal IN IP s=ok c=in IP4 goujon.int.fr m=audio 5004 RTP/AVP 0 3 corps de message (ex.format DP) 65 corps message 66 ession Description Protocol IP utilise le protocole DP (session description protocol, RFC 2237) DP est employé pour définir les attributs d une session IP avec une syntaxe standard. Les paramètres DP sont placés dans le corps d une requête IP Les entêtes DP sont encodées en format text et sont de la forme <champ>=<valeur>. Le <champ> est toujours un simple caractère et la <valeur> est une chaine de caractères formatée selon le champ Format DP <type>=<valeur> Description v= Version Protocole o= créateur/propriétaire & Id session s= nom de la session i*= info. ur la session u*= url contenant description p*= numéro de tel. c*= info. ur la connexion b*= info. Bande passante z*= fuseau horaire k*= clef de crytpo. a*= attributs de session t= durée de session r*= occurrence de la session m= media transport i*= nom du media c*= info. connexion b*= info. Bande passante k*= clef de crypto. a*= une ou plusieurs lignes attributs media Description de la session Description «temporel» Description «réseau» 67 68

18 Adresse IP IP exploite des formats d adresses de type user/service_id@domaine/host_name Adresse logique indépendante de «physique» (IP) Identifie un utilisateur (user_id peut être un individu, un groupe) ou un service (service Id) Identifie l adresse de contact (nom DN, adresse IP ) Différents formes possibles user@domain ahmed@tl1.fr user@host ahmed@pc.tl1.fr ou ahmed@ service@ip_adress AudioconfA45@mcu.tl1.fr phone-number@gateway @passerelle.tl1.fr Mécanisme de résolution des adresses (ex. DN) 69 Les URI IP Utilisé dans les requêtes (entêtes: From, To, Contact) Intégration dans des pages HTML, s sip ou sips: host ;paramètres?en-têtes infos_utilisateur (nom de l utilisateur:mot de passe) ou (numéro téléphone, si user=phone) host nom de domaine ou nom d hôte ou adresse IP: port paramètres en-têtes ;transport=udp ou tcp ;user=phone ou IP ;method=invite, ACK, OPTION, BYE, CANCEL, REGITER ;ttl=0 à 255 (time-to-live d un paquet IP multicast) ;maddr=adresse IP multicast ;tag=compteur? par1=valeur1 & par2=valeur2 & par3=valeur3... Exemples : Ahmed@tl1.fr-> sip:meddahi@pc1.enic.fr;maddr= ;q=0.8 Ahmed@tl1.fr -> sip: @passerelle.tl1.fr;user=phone;q=0.8 Ahmed@tl1.fr -> sip:voic @media-engine.tl1.fr;msgid=78;q= Entité Administrative: IP@tl1.fr (erveur IP du domaine «tl1.fr») erveur Redirect /Proxy sip:ahmed@tl1.fr BD erveur Localisation 2 Enregistrement des info. de localisation dans la Base de Données Protocole IP : processus d enregistrement erveur Registrar sip:ampc@ sip:amtel@ REGITER sip:tl1.fr IP/2.0 To: sip:ahmed@tl1.fr From: sip:ahmed@tl1.fr Contact: sip:ampc@ , sip:amtel@ IP/ OK Expires: tl1.fr DN Requête IP du proxy INT? ahmed@tl1.fr term1 term1.tl1.fr Protocole IP : Exemple "INVITATION" dans le cas du «Proxy» INVITE sip:pascal@int.fr IP/2.0 To: sip:pascal@int.fr From: sip:am@enic.fr;tag=4711 Contact: sip:amtel@ INVITE pascal@int.fr OK 7 ACK serveur de localisation pascal 2 Flux média (ex. audio) 3 ip proxy Pascal@term2.int.fr int.fr INVITE pascal@term2.int.fr OK 6 term2 9 ACK pascal@term2.int.fr 5 pascal@term2.int.fr 72

19 Protocole IP : Exemple "INVITATION" dans le cas d'une «redirection» int.fr ervice «Click to dial» (utilisation du sip «B2Bua») tl1.fr ahmed@tl1.fr term1.tl1.fr 8 6 INVITE pascal@int.fr 1 IP/ Moved temporarily Contact : pascal@term2.int.fr 4 5 INVITE pascal@term2.int.fr 200 OK ACK ACK 7 erveur de localisation pascal 2 3 ip Redirect Pascal@term2.int.fr term2.int.fr pascal@term2.int.fr A «Client» 0. HTTP 2. Ok (DP A) 1. Invite (No DP) 5. Ack (DP B) Média RTP (flux audio) 3. Invite (DP A) B «fournisseur» 4. Ok (DP B) 5. Ack sip «B2Bua» erveur web ervice «audioconf.» (utilisation du sip «B2Bua») A Media RTP Audio ->A <- B+C 1. Invite (DP Mixer) 3. Ack 2. Ok (DP A) PC Administrateur de la conf: «création, activation, joindre, quitter, inviter» 0. HTTP ConfA45@TL1.fr MCU: Pont audioconférence Mixer audio sip «B2Bua» (Focus) erveur web 1. Invite (DP Mixer) Ok (DP B) Media RTP Audio ->A+C <- B 3. Ack 1. Invite (DP Mixer) 2. Ok (DP C) 3. Ack B sip:confa45@enic.fr Media RTP Audio ->A+B <- C c sip:a@enic.fr sip:b@int.fr sip:c@enst.fr 75 INTERNET gilles@tl1.fr Mobilité (nomadisme) et IP: exemple de scénario IP erver int.fr BACKBONE IP erver enst.fr enst.fr Exercice: Détailler le schéma en précisant les méthodes/messages et les enregistrements contenus au niveau des serveurs «IP». 76

20 cénario: description (suite) cénario: description (suite) Ahmed est potentiellement joignable sur trois sites: l INT (bureau) et l ENT (bureau et labo.) Ahmed publie un seul identifiant d appel: ahmed@int.fr Ahmed est en déplacement à l ENT et enregistre sur le serveur IP de l INT l adresse ahmed@enst.fr (1) Il enregistre aussi sur le serveur de l ENT, ses deux adresses de contact (2, 3) ahmed@office.enst.fr, ahmed@lab.enst.fr Ahmed «oublie» de supprimer un précédent renvoie d appel qu il avait effectué sur son poste du labo à l ENT. gilles@tl1.fr appel ahmed@int.fr (4) (résolution DN = erveur IP Lucent) Le serveur IP de l INT localise l adresse courante de Ahmed (5) et retransmet donc l appel à ahmed@enst.fr (6) Le ervice IP de l ENT détermine qu il existe deux adresses possibles (7) et diffuse l appel (i.e «fork») vers celles-ci (8,9) Le poste du labo selon sa configuration redirige l appel vers le serveur IP de l INT, qui détecte une boucle et retourne un message d erreur (10,11) L erreur est propagée par le poste au serveur IP de l ENT(12) Dans le même temps, Ahmed a répondu à l appel depuis son bureau (13) cénario: description (suite) Le serveur IP de l ENT a maintenant les deux réponses et peut retourné l acceptation de l appel au erveur IP de l INT (14) qui fait de même vers l agent client «Gilles» (15) A ce stade, Les serveurs peuvent «détruire» les états liés à l appel. Ahmed et Gilles communiquent directement (flux média) sans passer par les serveurs intermédiaires (16) IP et «IMPP» (Présentité et messagerie instantanée ) ensibilité au contexte du terminal/utilisateur: Localisation, disponibilité, «humeur» de l utilisateur Permettre le support des applications classiques mais aussi nouvelles: Transfert d appels, suivie d appels (classique) messagerie instantanée, applications basées localisation. Modèle IMPP: Caractéristiques de IP mises en évidence par ce scénario Forking Mobilité (utilisateur) Détection de boucle 79 80

21 IP «Watcher» UA PDA UBCRIBE Event:presence Expires:3600 Accept: text/plain. 200 OK Event:presence Expires:1800 NOTIFY Event:presence ubscr-tate:pending 200 OK NOTIFY Event:presence Expires:1759 ubscr-tate:active. MEAGE Accept: text/plain Content-Type:text/plain Content-Lengh:29 «Bonjour ça va comme tu veux» IP et IMPP: erveur de présence PA serveur 200 OK PUBLIH Event:presence Expires:3600 Accept: text/plain Content-Type:application/XML. 200 OK Event:presence Expires:1800 NOTIFY Event:presence Expires:1759 ubscr-tate:active 202 ACCEPTED Event:presence IP Presence UA 81 Données de présence au format PIDF: Pres. info. Data Format (XML) <presence... <tuple id="mobile-im"> <status> <basic>open</basic> </status> <contact <note xml:lang="en">don't Disturb Please!</note> <note xml:lang="fr">ne me dérangez pas, s'il vous plaît</note> <timestamp> t10:49:29z</timestamp> </tuple> <tuple id="interactive-mm"> <status> <basic>closed</basic> </status> <contact </tuple> <note>je serai en déplacement la semaine prochaine</note> </presence> Remarques: Pb: congestion (1 «subscribe/notify» et 1 «message» par RTT, ex 1/ 5sec.) durée de vie des batteries (Pda, terminal mobile ); fiabilité des MEAGE (IP sur UDP) 82 IP et la Qo (plusieurs constats) Qualité «best effort» pas suffisant pour la VoIP Nécessité de supporter des mécanismes de réservation de ressources dans IP pour assurer une Qo (BP, Délai, perte minimale) écurité des canaux ou flux média Empêcher la fraude ou le vol de service Etablir la connexion uniquement si des pré-conditions sont remplies (sécurité, Qo ) Le appels ne sont pas facturés si ressources réseau non suffisantes Faire sonner l appelant uniquement si Qo Appel en mode dégradé: ex. en utilisant des codecs bas débit ou uniquement l audio (sans la vidéo) 83 m=audio RTP/AVP 0 IP UAC c=in IP a=curr curr:qos e2e none a=des:qos mandatory e2e sendrecv rcv Qo snd rcv Qo snd Qo snd rcv Cur. Cur. x Cur. x x Des. Des. m=audio RTP/AVP 0 c=in IP a=curr curr:qos e2e send a=des:qos mandatory e2e sendrecv Des. IP et la Qo (RFC 3312): INVITE Préconditions 183 ession Progress Préconditions confirmation request PRACK 200 OK (PRACK) Réservation ressources (Qo) UPDATE Préconditions confirmation response 200 OK (UPDATE) Préconditions RINGING IP UA Qo snd rcv Qo snd rcv Qo snd rcv m=audio RTP/AVP 0 c=in IP a=curr curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf conf:qos e2e recv Cur. x x x Cur. Cur. Des. Des. Des. m=audio RTP/AVP 0 c=in IP a=curr curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv 84

22 Exemple de négociation de Qo: Requête (corps DP) v=0 o=jo IN IP4 ruin.inf s=ip call t=0 0 c=in IP m=audio RTP/AVP a=rtpmap:98 L8/8000 a=rtpmap:99 L16/8000 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv m=video RTP/AVP 31 a=rtpmap:31 H261/90000 a=curr:qos local send a=curr:qos remote none a=des:qos optional local sendrecv a=des:qos optional remote sendrecv Réponse (corps DP) v=0 o=cabo IN IP4 dmn.inf s=ip call t=0 0 c=in IP m=audio RTP/AVP a=rtpmap:98 L8/8000 a=rtpmap:99 L16/8000 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv m=video RTP/AVP 31 a=rtpmap:31 H261/90000 a=curr:qos local none a=curr:qos remote send a=des:qos failure local sendrecv a=des:qos optional remote sendrecv Confirmation demandée (confirmation request) Autre type de précondition: «sec» : pour sécurité: avant alerte, flux media (ex. voix) protégé -négociation d un algorithme de crypto. «conn»: pour connectivité: avant alerte, flux média passe dans les deux sens -négociation d un mécanisme pour traverser les firewall ou les serveurs NAT. 85 Le protocole IP assure: Localisation du(des) participant(s) à la session terminaux multiple, mobilité, identifiant unique,... Gestion de la disponibilité mise en attente, transfert/déviation (traitements sophistiqués) Transfert vers , messagerie instantanée, page web Gestion des capacités configuration, négociation des paramètres de la session, hétérogénéité des terminaux Etablissement de la session mise en relation des deux participants Gestion de la session modification, terminaison 86 Ce que IP n assure pas: Ne contrôle pas le transfert des flux média Ne décrit pas les sessions Ne contrôle pas les passerelles Ne réserve pas les ressources pour la session Pour cela d autres protocoles/architectures peuvent être utilisés conjointement: RTP (pour le transfert du flux média: audio ou vidéo) RTP (pour le transfert du flux en mode «streaming») DP (pour la description de la session) MEGACO/H.248 (pour le contrôle de passerelles) Diffserv/Intserv (pour la Qo) «Traces» IP (et H.323) 87 88

23 Trace de message IP (texte) Trace de message IP (texte) Format message de signalisation H.225 (éléments d info. de type «user-user» d un message Q931) Les éléments d'informations sont en format TLV (Type/Longueur/Valeur) Type fonction de Type de message (ex. «ALERTING») l'élément d'information Type d élément d info. Longueur de la partie variable Variable peut contenir des éléments d'informations imbriqués ( «user-user») longueur Valeur (corps du message «H.323» codé en AN.1) Trace H225: AN1 (Abstract yntax Notation 1) AN.1 définit une notation ou une syntaxe pour décrire les messages utilises par les protocoles de communication, indépendamment du langage d implémentation, du codage physique Parser AN.1 outil d encodage (BER, PER ) 91 92

24 Trace H225 (suite) AN.1 (Abstract yntax Notation 1) Cette notation fournit un certain nombre de types de base prédéfinis tel que: integers (INTEGER), booleans (BOOLEAN), character strings (IA5tring, Universaltring...), bit strings (BIT TRING), etc., il permet également la définition de type plus complexe structures (EQUENCE), lists (EQUENCE OF), choice between types (CHOICE), etc. 93 Trace H225 (suite): Exemple de message AN.1 H323-MEAGE DEFINITION AUTOMATIC TAG ::= BEGIN H323-UserInformation ::= EQUENCE -- root for all Q.931 related AN.1 { h323-uu-pdu H323-UU-PDU, user-data EQUENCE { protocol-discriminator INTEGER (0..255), user-information OCTET TRING (IZE(1..131)),... } OPTIONAL,... }.....suite.. H323-UU-PDU ::= EQUENCE { h323-message-body CHOICE { setup etup-uuie, alerting Alerting-UUIE, callproceeding CallProceeding-UUIE, connect Connect-UUIE, } nontandarddata NontandardParameter OPTIONAL,... } etup-uuie ::= EQUENCE { activemc BOOLEAN,... } } END 94 Trace de message H225 (AN.1) Trace de message H225 (AN.1) 95 96

25 Trace de message H225 (AN.1) Remarques sur IP (et H323) IP (IETF): «270» pages (130 en 98) «37» en-têtes (+ avec les extensions) représentation «textuelle» 1 requête suffit pour établir la communication. Évolutivité (extension) détection «loop» requête multiple en // possible. Adopté par le 3GPP forum H323 (ITU-T): «700 pages» plusieurs centaines de messages représentation binaire plusieurs échanges avant d établir la communication. (temps d établissement potentiellement long) technologie relativement «mûr» et ayant fait ses preuves adopté par les industriels Nbre d'échanges pour établir la com. Maintenance du code Evolution Conférence ervices Detection boucle Multicast Remarques sur IP (et H323): suite IP (IETF) 1.5 aller-retour imple (format «texte») protocole ouvert distribuée supporté supporté supporté H323 (ITU-T) 6 à 7 aller-retour Complexe (compilateur) ajout d extensions propriétaires Centralisée avec le MCU H323 V2+H.450 non supporté dans la V1 non supporté API API Call control I N V I T E R E F E R U B C. UDP Modèle de création de services IP N O T I F y IM P U B L I h (Applications) Telephonie 3G.. M O e E E P V I C R E N Extensions U A IP R t F A C R L i O k I G A m T e p e é r Pile IP IP/IP Multicast/Qo TCP,CTP, TL.... IP ervices IP et

26 Portabilité du service: «Write Once, Run Anywhere». Indépendance/réseau: «Any Network». ystème/développement ouvert: «By Anyone» ervices télécoms: ervices JAVA API (ource: java.sun.com/products/jain/) Environnement de création de services (CE) Couche signalisation «N importe quel service sur n importe quel réseau» PORTABILITE ervices télécoms: ervices JAVA API Réseau paquet Réseau paquet Plate-forme services X Y Z Couche Réseau ervices télécoms: «ervices JAVA API» Ex. JAIN: «Java Api for IN»; O: «Operations upport ystems» JAIN TCAP Java Call Control JAIN MGCP JAIN IP JAIN INAP JAIN MEGACO JAIN IP Lite JAIN DP JAIN ENUM JAIN Presence JAIN Instant Messaging JAIN IMPLE (Presence +IM) O/Qo O/Billing... ource: java.sun.com/products/jain/ 103 Delai (sec.) Délai Connexion Delai (sec.) Délai pre-selection ,5 2 1,5 1 0,5 0 LAN b Cable Modem Modem 56 Kbs (no TRYING) 3 cenario LAN b Cable Modem Modem 56 Kbs cenario Délai post-selection Delai (sec.) LAN b Cable Modem Modem 56 Kbs cenario 1 1 :1 serveur IP 2 :1 serv. IP (Redirect) 3 :2 serveurs IP ITU-t rec (E.721) Circuit network (charge normale ) Délai post-selection moyenne 95% Appel Local noeuds Appel Regional noeuds International noeuds 3 sec. 6sec. 5 sec. 8sec. 8 sec. 11sec. 104

27 Performance du flux RTP Measures 1 (G.711) Delay(ms) Jitter(ms) Loss (%) 0-9 ITU-t 2 rec Conclusion 1 TERENA Networking Conference 2004(Trans-European Research & Education Network). 2 ITU-T G.113 and G.114 rec. for a G.711 audio codec (w. PLC, w. controlled echo ) Conclusion ervices Télécoms sur IP: Convergence Fixe/mobile et Voix- Vidéo-Données (multiervices): une seule infrastructure réseau pour la «voix» et les données (et vidéo) Administration d une architecture unique réduction des coûts de communication? Administration plus simple et mois onéreuse? Developpement et déploiement rapide d'applications " nouvelles et plus riche" (web call center, «VoIP» contextuel, Appli. Basées localisation ) services de téléphonie existants sur IP? Qualité de ervice? Dépend essentiellement de la technologie réseau sous-jacent (Qo). Facilité et rapidité de création de services réseaux via une certaine «Abstraction» de la «couche réseau» (ex. API JAINxxx) Conclusion (suite) upport des services télécoms architecture et protocoles IP de plus en plus complexes. Impacte sur les performances (ex. VoIP). Les caractéristiques des réseaux IP sont très dynamiques et variables. Impacte sur les performances. Avant un déploiement total des services, les réseaux paquets doivent fournir le même niveau de Qualité de ervice que le réseau commuté (surtout pour les applications de types temps réel ou sensible au délai). Qo compléte (du réseau à l application)

28 Conclusion (suite) Mesures et contrôle des performances IP (IETF IPPM). Fiabilité/disponibilité (99.999% 84%) Intéroperabilité (services transparents entre IP et réseaux classiques ) écurité (média et signalisation) spam téléphonique (+ critique que le mail spam ) Mobilité (utilisateur/terminal) Localisation géographique (applications basées local.) Appels d urgences Interception d appels Performance de la signalisation (ex. IP) Livres: Quelques références (liste non exhaustive) «Understanding the ession Initiation Protocol», Alan B. Johnson, Editions Artech House. «Codecs, H.323, IP, MGCP, déploiement et dimensionnement», Olivier Hersent, David Gurle et Jean-Pierre Petit - Editions Dunod ites web: Protocole MGCP RFC 2885 (MEGACO) Nécessité de séparer les fonctions «typiquement» soft, des fonctions Hardware des passerelles. ANNEXE «Intelligence» au sein du Call Agent Les Fonctions de conversion au sein de la Gateway Protocole utilisé pour contrôler différents types de passerelles : (Trunk Gataway, Residential Gateway, ignaling Gateway, MCU )

29 Exemple de flot «MGCP» Exemple de flot «MGCP»(suite) : Etape Terminale RTC Passerelle MG erveur Terminal «IP» Megaco (MGC) (ex. H323) erveur d appels (ex.h323) Etape Terminale RTC Passerelle MG erveur Megaco (MGC) Terminal «IP» (ex. H323) erveur d appels (ex.h323) 0 <- RQNT Ack -> (ready) 1 Off- NFTY -> hook 2 (dial tone) 3 digit 4 (no dial tone) 5 digit... <- (off-hook recorded) Ack <- RQNT Ack -> 10 digit 10a (match) NFTY <- -> Ack 10b <- RQNT+CRCX Ack(DP) -> 11 ARQ - - -> 12 <- - - ACF 12a <- MDCX 12b Ack(DP) -> 13 ETUP -> 14 ARQ -> 15 <- ACF 16 <- ALERTING 17 (ring back) <- RQNT+ MDFY (DP) Ack -> Rq: en noir signalisation MGCP Etape Exemple de flot «MGCP» (suite) : Terminale RTC 18 <- CONNECT 19 (cutthrough) Passerelle MG erveur Megaco (MGC) <- RQNT+MDFY ACK -> (full duplex media transfer recorded) Terminal «IP» (ex. H323) erveur d appels (ex.h323) Exemple de flot «MGCP» (suite) : Etape Terminale RTC «Acc» 20 on-hook NTFY -> <- Ack 21 RELEAE - - -> 21a 21b Passerelle MG <- RQNT+DLCX Ack -> erveur erveur Megaco (MGC) taxation Terminal «IP» (ex. H323) 22 <- - - RELEAE (Media transfert stopped) COMPLETE erveur d appels (ex.h323) (Accounting) ->

30 0)RQNT 1201 MGCP 0.1 N: X: AB R: hd 0) OK 1)NTFY 2001 MGCP 0.1 N: X: AB O: hd 1) OK 2)RQNT 1202 MGCP 0.1 N: X: AC R: hu, [0-9#*T](D) D: ([2-9]xxxxxx 1xxxxxxxxxx 0T [49]11 011x.T) : dl 2) OK 10a) NTFY 2002 endpoint/1@rgw-2567.enic.fr MGCP 0.1 N: ca@ca1.enic.fr:5678 X: AC O: 2,3,4,5,6,7,8,T 10a) OK Détail des messages MGCP: 10b)CRCX 1204 endpoint/1@rgw-2567.enic.fr MGCP 0.1 C: A3C47F F0 L: p:10, a:pcmu M: recvonly X: AD R: hu 10b) OK I: FDE234C8 v=0 c=in IP m=audio 3456 RTP/AVP 0 12a) MDCX 1205 endpoint/1@rgw-2567.enic.fr MGCP 0.1 C: A3C47F F0 I: FDE234C8 L: p:10, a:pcmu,g729c M: recvonly 12b) OK v=0 c=in IP m=audio 3456 RTP/AVP ) Message H225. RTP receive address: , 3456 RTCP receive address: , ) Message H225. G.711 RTP receive address: , 1296 G.711 RTCP address: , 1297 G.729C RTP receive address:n/a G.729C RTCP address: , )MDCX 1206 endpoint/1@rgw-2567.enic.fr MGCP 0.1 C: A3C47F F0 I: FDE234C8 L: p:10, a:pcmu M: recvonly X: AE R: hu : v v=0 c=in IP m=audio 1296 RTP/AVP 0 a=sendonly m=audio 1298 RTP/AVP 96 a=rtpmap:96 X-G729C/8000 a=recvonly 17) OK Détail des messages MGCP (suite): 19)MDCX 1208 endpoint/1@rgw-2567.enic.fr MGCP 0.1 C: A3C47F F0 I: FDE234C1 M: active X: AF R: hu 19) OK 20)NTFY 2005 endpoint/1@rgw-2567.enic.fr MGCP 0.1 X: AF O: hu 20) OK 21a) DLCX 1210 endpoint/1@rgw-2567.enic.fr MGCP 0.1 C: A3C47F F0 I: FDE234C1 X: B0 R: hd 21b) OK P: P=1245, O=62345, PR=780, OR=45123, PL=0, JI=27, LA= 118 Megaco/h248 Megaco/h248 Dérive de MGCP tandard IETF (rfc3015 ITU-T h248) upporte: services multimédia multipoint syntaxe des messages (commandes/réponses) évolué tcp/udp option (ATM, ) messages texte ou binaire (AN.1) extension des messages support de «package» spécifique 119 MGCP notion: «endpoint», connexions 1 transaction=1 commande 1type de reponse commandes: EndpointConfiguration NotificationRequest Notifications CreateConnection ModifyConnection DeleteConnection AuditEndpoint AuditConnection RestartinProgress TEXTE Megaco/h248 notion: «terminations», context 1 transaction=n actions 1action=N commandes 2 types de reponse (TransactionPending) commandes: Add Modify ubtract Move AuditValue AuditCapabilities Notify ervicechange TEXTE, BINAIRE (asn.1) 120