01 Protocoles SIG NGN [PDF]

Zitiervorschau

21/04/2014

SIGNALISATION DANS LESRESEAUX NGN & IMS: ToIP Mamadou Alpha BARRY www.esmt.sn

Objectif général: Maitriser les principes, l’architecture, et les protocoles de signalisation du réseau NGN (Next Generation Network).

Objectifs spécifiques: - Présenter les évolutions des réseaux - Connaitre les composants de l’architecture d’un réseau NGN - Comprendre les différents protocoles utilisés dans le NGN

Pré requis: - Architectures des réseaux télécoms fixes et mobiles - Réseau IP (LAN, MAN, WAN) 2

1

21/04/2014

I. Rappel sur l’architecture NGN et IMS

3

Arrivée des nouveaux services Dans certaines parties du monde le trafic de données prend rapidement le pas sur le trafic vocal et la tendance est nettement à l’augmentation en bande passante pour les données, tandis que la voix peut suffire de la même bande passante (64 kbit/s), voire d’une moindre. Les opérateurs possédant les deux types de réseaux (réseau voix et réseau de données) utilisent cet argument pour commencer à les unifier. Il est clair d’après les limites du réseau TDM (Time Division Multiplexing) que le réseau de données survivra alors que le réseau TDM (RTC) quittera la scène. Facteur non moins important : le nouveau besoin chez les usagers d’une variété encore plus grande d’applications et de services sophistiqués non possibles sur le RTC (e.g., Push-to-talk, vidéotéléphone, conférence audio et vidéo, messagerie unifié, chat, présence, etc.) dont la plupart n’étaient même pas envisagés lors de la conception des réseaux actuels. 4

2

21/04/2014

Arrivée des nouveaux services Pour les opérateurs, l’accès et le transport ne sont plus assez lucratifs et, pour rester compétitif, il leur faudra donc offrir aux usagers toute une gamme de services utiles, faciles à utiliser et rémunérateurs. Les opérateurs entrants (e.g., opérateurs ADSL) pourront envisager d’investir dans une solution d’emblée NGN. Les réseaux traditionnels sont conçus en prévision de la voix et des données multiplexées par répartition temporelle (TDM). Aujourd’hui, dans la majorité des cas, le trafic de données est supérieur au trafic de la voix. La commutation de circuits s’avère inefficace pour les données.

5

Arrivée des nouveaux services Avec la déréglementation des télécommunications (notamment l’introduction de la sélection du transporteur), plusieurs opérateurs alternatifs ont développé des infrastructures pour offrir des services voix à leurs clients. Parallèlement, ces mêmes opérateurs ont étendu leurs offres de services afin de proposer à leurs clients, majoritairement des entreprises, le transport de données. Ce type d’offre a amené les opérateurs alternatifs présents sur les deux types de marché (voix et données) à développer des réseaux convergents de type paquets, afin d’optimiser leur infrastructure.

6

3

21/04/2014

Arrivée des nouveaux services (suite) Le trafic de la voix est constant. Il est donc normal de réserver un lien pour une communication constante. Le trafic des données se déplace plutôt en rafale : il est donc inutile de réserver un lien complet pour ce genre de trafic.

7

Architecture générale NGN Applications Servers

SCP Application Plane PLMN Call Server

Controll Plane

PSTN Call Server

Multimedia Comm Server SIP/H323

GPRS Call Server

TGW

Tranfer Plane

Server Node

Packet Connectivity Backbone Network

AGW

GW

TGW Other IP Networks

GW

AGW

Other Switched Networks (PLMN, PSTN)

AGW

Access Plane

Wireline Access Network

Wireless Access Network

PBX, Intranet LAN

8

4

21/04/2014

NGN : Téléphonie à 64 Kbits/s

9

NGN à L’Accés

LL : Leased Lines

10

5

21/04/2014

NGN : Téléphonie Voix sur IP

11

NGN : Multimédia

12

6

21/04/2014

Les constituants du Réseau NGN Le réseau de connectivité v

Réseau de connectivité paquet transportant voix, image et données, rendu possible grâce :

•

Aux avancées en optique et en techniques de routage ;

•

A la technologie ATM dans les premières versions (notion de SLA « Service Level Agreement » et utilisation des SVC « Switched Virtual Channel ») ;

•

A la technologie IP, désormais avec QoS différenciée par classes de services (COS, Class of Service). Utilisation de Diffserv en périphérie et de MPLS « Multi Protocole Label Switching » dans le cœur du réseau.

v

Remplacement des matrices de connexion des commutateurs (RCX switching fabric). 13

Les constituants du Réseau NGN Media Gateways (MGW) 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) ; • La transmission, suivant les instructions du Media Gateway Controller, des flux média reçus de part et d'autre ; • L’établissement et la fermeture des communications empruntant le réseau aquet ; • La transition entre réseaux d’accès et le backbone paquet ou entre réseaux d’opérateurs (interface paquet côté backbone) pour les flux média et signalisation. Il dispose d’un minimum d’intelligence.

14

7

21/04/2014

Les constituants du Réseau NGN v Trois grandes classes de gateway :  -

Trunking Gateway (TGW) : raccordement des commutateurs TDM de l’opérateur au réseau NGN pour les communications grande distance (NGN transit).

 -

Access Gateway (AGW) : c’est un multiplexeur d’accès abonnés, il autorise tout type d’accès : analogique, RNIS, xDSL, data IP, ATM,…), la technologie d’accès peut être soit cuivre soit optique.

 -

-

Signalling Gateway (SGW) Il convertit 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), Il assure notamment l’adaptation de la signalisation par rapport au protocole de transport utilisé (ex. : adaptation TDM - IP). 15

Les constituants du Réseau NGN 

Signalling Gateway (SGW)

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 MGW + SGW. 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 en réalisant : - la conversion du trafic (entité fonctionnelle Media Gateway), - la conversion de la signalisation associée (entité fonctionnelle Signalling Gateway). NB : L’architecture d’implantation des gateways basée sur les trois éléments (SGW, MGW et GW) est un modèle proposé par l’ETSI et reprise par les organismes de normalisation IETF, ITU-T,… 16

8

21/04/2014

Les constituants du Réseau NGN Softswitch ou Media Gateway Controller (MGC) Dans un réseau NGN, c’est le MGC qui possède « l'intelligence », c’est le serveur d’appel. Il gère : •

L’échange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation (SGW), et l’interprétation de cette signalisation ;

•

La logique de traitement des appels (routage et acheminement) : dialogue avec les terminaux H.323, SIP voire MGCP, communication avec les serveurs d’application pour la fourniture des services ;

•

Le choix du MGW de sortie selon l'adresse du destinataire, le type d'appel, la charge du réseau, etc ;

17

Les constituants du Réseau NGN • La réservation des ressources dans le MGW et le contrôle des connexions internes au MGW (commande des Media Gateways). Dans l’architecture des réseaux NGN, le serveur d’appel, aussi appelé Softswitch ou (MGC) est le nœud central qui supporte l’intelligence de communication. NB : Suivant les origines industrielles (télécoms ou IP) et donc suivant les protocoles entre MGC et MGW d’une part, entre plates forme de commande de l’autre, on peut l’appeler « call server », « gatekeeper »,… L’appellation softwitch est désormais celle qui est communément retenue

18

9

21/04/2014

II. Généralités sur les protocoles des réseaux NGN et IMS

19

2.1 Généralités sur les protocoles 3 grandes familles 1. protocoles de signalisation établissent, modifient, terminent une session (appel, service), ou une configuration réseau (ressources) – établissement de présence, localisation. Protocoles de commandes : d ’appel, de services piles SS7, BICC,INAP, MAP,…, H323 et SIP (pour le multimédia)  Protocoles de commande de ressources SS7; MGCP, MEGACO/H248; H323; COPS  Orientation nette des nouveaux protocoles à être dédié à un des 2 types de commande précédents (protocoles dits horizontaux / verticaux) 2. Protocoles media protocole adapté à la transmission d ’un média audio, video qui est packetisé par exemple RTP, UDP,TCP, SCTP 3. Protocole support réservation de QoS, AAA interdomaine, translation d ’adresse DNS, RSVP, COPS, Diameter 20

10

21/04/2014

2.1 Généralités sur les protocoles

21

2.1 Généralités sur les protocoles

22

11

21/04/2014

2.1 Généralités sur les protocoles Un monde vivant entre MGC et MG

23

2.2 Le Transport de la Voix La Voix sur IP (Voice over IP ou VoIP) Ou encore téléphonie sur IP (un service « carrier class ») par opposition à la téléphonie sur Internet bien connue des internautes.  C’est-à-dire qu’on se réfère à une ingénierie rigoureuse  À considérer Volet économique général : il n’y a plus de réseau dédié à un type d’application Environnement IP général, car IP est à la base du développement des applications  Le Design de la Qualité : les Paramètres les plus influents  Performance des équipements  Codage de la voix  Efficacité de la packetisation  typiquement : 10 à 30 ms de parole dans les paquets  Suppression des silences  Performance du tandem codec (codeur/décodeur)  maintien QoS entre réseaux (typiquement TDM/IP/TDM) 24

12

21/04/2014

2.2 Le Transport de la Voix

25

2.2 Le Transport de la Voix

26

13

21/04/2014

2.2 Le Transport de la Voix Les protocoles associés : généralités Technologie en mode non connecté => la voix sur IP nécessite l’utilisation de protocoles supplémentaires pour le transport de données en temps réel  RTP Real Time Protocol (RFC 1899 et 1890) révisé RFC 3550 – adopté par UIT (H.225)  RTCP Real Time Control Protocol (intégré dans RTP) : fournit des informations sur la qualité du réseau.(RFC 1899 et 1890, respectivement mis à jour avec RFC 3350 et 3351)  Le protocole UDP (User Datagram Protocol) qui s’impose pour le transfert des flux multimedia (streaming)

27

2.2 Le Transport de la Voix Les protocoles associés : généralités

28

14

21/04/2014

2.2 Le Transport de la Voix Les protocoles associés : généralités Pour des objectifs d’efficacité dans le transmission de flux multimedia : UDP      

Pas d’ouverture ni fermeture de session Pas d’acquittement, ni de reprise sur erreur Pas de contrôle de flux ou de congestion Faible temps de latence Ports sources et destination indiquent le processus qui utilise la trame Le cheksum porte sur l’intégralité de la trame

Protocole IP asynchrone et mode non connecté il faut donc introduire des informations supplémentaires dans les trames IP pour permettre:  la synchronisation émetteurs – récepteurs  Remise en séquence des paquets

29

2.2 Le Transport de la Voix Les protocoles associés : généralités IETF a adopté RTP comme standard de transport des flux stream:  Une session RTP par flux media  Les services de RTP incluent: Identification de la charge utile Numérotation des paquets Le protocole de transport est complété dans les mêmes spécifications par un protocole de contrôle RTCP.  Contrôle les flux véhiculés par RTP  Echange d’informations basiques  Sur les participants d’une session  Sur la qualité de transmission d ’une session  À chaque session RTP est associé un flux de contrôle RTCP RTP et RTCP n’ont aucune influence sur le réseau IP (pas de contrôle de QoS) 30

15

21/04/2014

2.2 Le Transport de la Voix RTP ( Real Time Protocol) est un protocole de transport des applications temps réel sur IP, destiné à limiter (voire résoudre) les effets de la perte de paquets et de la gigue sur le réseaux. RTP est un protocole de contrôle des flux des RTP, permettant de véhiculer des informations sur la qualité de service du réseau IP, et sur les participants d’une conférence. RTP identifie le type d’information transportée(ex: le type de codeur voix):  Ajoute des marqueurs temporels aux paquets.  Ajoute des numéros de séquence  Réordonne les paquets , ou tenir compte de leur arrivée dans le désordre  Informe le récepteur de la perte des paquets (il peut alors mettre en œuvre des mécanismes permettant de compenser ou réparer la perte d’information).  informe le récepteur de la gigue (il peut mettre en place des mecanismes en places pour compenser la gigue). Le RTP est adapté à l’ensemble des standards VoIP: H.323, SIP, MEGACO 31

2.2 Le Transport de la Voix RTP n’offre pas

32

16

21/04/2014

2.2 Le Transport de la Voix Codec Courants  Audio G.711 (64 kbit/s) G.729 (8 kbit/s) G.723.1 (6,3 et 5,3 kbit/s) G.728 (16 kbit/s) G.726 (32 kbit/s) GSM (13 kbit/s) [EDGE] AMR (Adaptive Multi-Rate Codec) (5..12,2 kbit/s) [UMTS  Vidéo H.261 (40 kbit/s - 2Mb/s, en fonction du nombre de pixels/image, nombre d ’images/s,couleur/noir et blanc) H.263, H.263+, H.263++ MPEG4/H.264

33

2.2 Le Transport de la Voix Quelques définitions Session RTP : association de participants communiquant au moyen de RTP  Utilisation de 2 @ de transport pour chaque session (une pour RTP, une pour RTCP)  SSRC : Synchronization Source : identificateur sur 4 octets de la source d’un flux RTP  Paquets RTP avec un même SSRC références temporelles et de numéro de séquences communes  Un SSRC également par récepteur pour émission des RTCP Receiver Report 

 Quand un flux RTP est la combinaison de plusieurs flux , la liste des SSRC de chaque flux est ajoutée à l’en tête des paquets de flux combinés (Ce flux possède son propre SSRC)  Format d’écriture du marqueur temporel : à partir du 1er janvier 1900 0h 34

17

21/04/2014

2.2 Le Transport de la Voix

35

2.2 Le Transport de la Voix

36

18

21/04/2014

2.2 Le Transport de la Voix

37

2.2 Le Transport de la Voix

BP : Bande passante NC : non compressé C : Compressé Header RTP/UDP/IP Compressé = 2-5 octets

38

19

21/04/2014

2.2 Le Transport de la Voix Principes Basé sur des transmissions périodiques de paquets de contrôle par tous les participants à la session. Contrôle des flux RTP permettant de véhiculer des informations basiques sur les participants à une session, sur la QoS . 

5% maximum de bande passante allouée par rapport à celle de RTP, les overheads IP/UDP/RTP

RTCP permet , à la fois à l’émetteur et aux destinateur, d’agir sur l’émission /le traitement des flux RTP, en fonction de la QoS. RTPC diffuse un identifiant (CNAME) pour chaque source RTP, ce qui permet d’attribuer les flux RTP à tel ou tel participant.

39

2.2 Le Transport de la Voix 5 types de messages RTCP  SR (Sender Report) : contient des statistiques sur les paquets recus et les paquets RTP transmis par un participant  RR (Receiver Report) : statistiques de réception pour les participants non actifs.

 SDES (Source Description) : décrit la source : nom; E-mail, tél, etc … Mais seul le CNAME est obligatoire – unique parmi tous les participants, généralement de la forme usager@serveur où serveur est soit un nom DNS ou une @ IP  BYE : une station indique la fin de sa participation à une session  APP : paquet de SIG spécifique à une application 40

20

21/04/2014

2.2 Le Transport de la Voix

41

2.2 Le Transport de la Voix

42

21

21/04/2014

2.3 Protocole SIP Le protocole SIP (RFC 2543), de l’IETF est un protocole de signalisation pour l’établissement d’appel et de conférences temps réel sur des réseaux IP. Proposé comme standard à l’IETF, SIP est rapidement apparu comme une alternative à H.323. Chaque communication doit pouvoir inclure différents types de données telles que l’audio et la vidéo. SIP est indépendant du protocole de transport utilisé. IP Multimedia Subsystem  Nouvelle architecture Supportant sur un réseau « full IP » des sessions applicatives Temps Réel (voix, vidéo, conférence…) et non Temps Réel (Push to talk, Présence, messagerie Instantanée …).  Tout réseau d’accès large bande peut s’interfacer à l’IMS  Considérer : non pas un réseau unique, mais différents réseaux inter – opérant fixe/fixe.  fixe/mobile – mobile/mobile (accords de roaming) « enabler » pour les fournisseurs de service. 43

2.3 Protocole SIP  Services de communication suivant configuration client-serveur ou entre entités paires  Mobilité des services et de l’usager : nomadisme  Plusieurs sessions et services possibles en simultané pour une même connexion réseau

   

Normalisé par le 3GPP pour les release 5 et 6 UMTS (dénomination IMS) Par TISPAN (dénomination Multimedia NGN) En objectif : R7 du 3GPP pour une architecture IMS totalement indépendante de tout type d’accès

44

22

21/04/2014

2.3 Protocole SIP Architecture TDM vs SIP

45

2.3 Protocole SIP Architecture TDM vs SIP

46

23

21/04/2014

2.3 Protocole SIP Les capacités de SIP

v Présence et communications instantanées : La messagerie instantanée permet aux usagers d’échanger des messages courts en temps réel. A la différence de l’e-mail qui utilise un mécanisme de store and forward, bien adapté pour l’échange de messages de taille longue avec des attachements dont la livraison peut prendre un certain temps plus ou moins important, la présence et la communication instantanée peuvent être considérées comme des capacités de services ou des services complémentaires fournis par défaut sur lesquels des services à valeur ajoutée peuvent s’appuyer sur des messages en temps réel ; 47

2.3 Protocole SIP Les capacités de SIP

v Conférence : SIP a été initialement conçu pour les conférences multimédia sur Internet. v Mobilité personnelle : La mobilité personnelle est un élément essentiel de l’architecture SIP. L’usager peut recevoir et établir des appels depuis n’importe quel terminal sur lequel il s’est enregistré. Il y a donc indépendance entre l’usager et le terminal. Il faut bien noter que le GSM fournit la mobilité du terminal qui est un autre concept. 48

24

21/04/2014

2.3 Protocole SIP Les capacités de SIP

v Mobilité des services : SIP fournit aussi la mobilité des services. Cela signifie que les services de l’usager le suivent en fonction de ses déplacements. Lorsque l’usager s’enregistre sur un terminal SIP, les services auxquels il a souscrit deviennent disponibles. v Sécurité : L’usager ne peut pas établir ou recevoir des appels tant qu’il ne s’est pas enregistré. Durant la phase d’enregistrement, l’usager est autorisé et authentifié. ESMT : Evolution des réseaux vers le NGN et IMS

49

2.3 Protocole SIP Les capacités de SIP

 SIP s’appuie sur les protocoles suivant : v SDP (Session Description Protocol RFC 2327) pour la description de la configuration de la session multimédia , p. ex : audio, vidéo, avec quel média,… ; v RTP (Real Time Protocol) pour transfert de la voix et de la vidéo ; v RTCP (RT Control Protocol) pour le contrôle des échanges RTP ; 50

25

21/04/2014

2.3 Protocole SIP Les capacités de SIP

v MSRP (Message Session Relay Protocol) pour la transmission de messages instantanés dans le contexte d’une session. Les sessions de message sont traitées comme n’importe quel flux média par un protocole d’établissement de session comme SIP par exemple. SIP hérite :  du modèle transactionnel (client/serveur) de HTTP; * adressage par URL SIP, * réponses SIP acquittées par des réponses identifiées par un code numérique. 

51

2.3 Protocole SIP Ce que SIP a besoin 

de SMTP utilisés sur Internet avec adressage sur URL (Uniform Resource Locator) : * une requête SIP est constituée de header comme une commande SMT (header et transfert; ascii : from, to, subject…)

52

26

21/04/2014

2.3 Protocole SIP Ce que SIP a besoin

 SIP définit une architecture de service avec : • Un serveur d’appel SIP : Call State Control Function (CSCF); • Un serveur d’application SIP; • Un serveur de média SIP;

• Un serveur de messagerie SIP.

53

2.3 Protocole SIP Ce que SIP n’est pas

v Un protocole de transfert de fichier comme http ; • Conçu pour transmettre des messages courts d’établissement, de modification et de rupture de sessions multimédia; • Permet cependant des messages courts indépendants des appels type SMS; v

Un protocole de session interactive (rew, forward) : * ne permet pas de gérer le droit de parole dans des sessions de conférence ou d’avancer ou reculer dans une session VoD qui est le rôle de RTSP.

54

27

21/04/2014

2.3 Protocole SIP Ce que SIP n’est pas

v Un protocole de réservation de ressources comme H.248 : •Il ne peut pas assurer la QoS. v Un protocol de commande de Gateways : •Les architectes réseaux utilisent le protocole H. 248.

v Un protocole qui prend en charge la mobilité du terminal (fonctionnalité gérée par GPRS/UMTS). Il utilise le protocole SDP (Session Description Protocol) pour la description des communications média. 55

Architecture SIP

2.3 Protocole SIP

56

28

21/04/2014

Architecture SIP

2.3 Protocole SIP

 Proxy server  Sert de point de rendez vous à partir duquel le terminal fixe ou mobile est globalement accessible ;  Traite la requête SIP et route vers le bon destinataire (appelle éventuellement le location server) ;  Il ne contrôle pas les canaux transportant les média (canaux RTP p.ex.).  Etablit, modifie et rompt une session. NB : Proxy server = CSCF (Call State Control Function) dans IMS. 57

2.3 Protocole SIP Architecture SIP Proxy server  2 Modes d’exploitation : Mode statefull ou stateless:  Statefull : garde trace des requêtes et réponses relayées et utilisent cette information afin de traiter les messages à venir – arme aussi un temporisateur à l’envoi d’une requête – mode indispensable pour le service « one number »  Stateless: ne fait que traiter chaque requête ou réponse SIP à partir du contenu du message

58

29

21/04/2014

2.3 Protocole SIP Les entités SIP

 Redirect server  Accepte les requêtes SIP mais ne les traite pas ;  Traduit les @SIP en de nouvelles @ réseau et retourne ces dernières au client. Il dispose d’une base de données ou de localisation) ;  Les services sont mis en œuvre par l’équipement client.  Registar server  Enregistre les Uger Agent ;  Accepte les requêtes REGISTRER (contient l’@ du client). 59

2.3 Protocole SIP Les entités SIP Un Registar est généralement co-localisé avec un serveur Proxy ou un serveur Redirect et peut offrir des services de localisation. Il est en générale une fonction logique

 Location server ou BD  Contient les informations de localisation et les fournit aux autres servers ;  Location server = HSS (Home Subscriber Server) dans IMS.

60

30

21/04/2014

2.3 Protocole SIP L’adressage SIP Les adresses utilisent la syntaxe définie dans le RFC 2396 pour les URI (Uniform Resource Identifier) ou URL (Uniform Resource Locator) identificateur de schéma de nommage (scheme) suivi de deux points « : » Forme générale: sip:user@host user part est au format « user name » ou N° E164 host est un nom de domaine ou une @ IP Ex sip: [email protected] SIP utilise aussi un schéma de nommage pour transport sécurisé avec SIPS URI Ex sips: [email protected] Dans ces conditions, les entités utilisent TLS (Transport Layer Security) adresse du SIP server configurée dans le terminal client sinon , passage par un URI (Uniform Resource Identifier) pour obtenir l ’@ IP du serveur, N° de port, protocole de transport.

61

2.3 Protocole SIP L’adressage SIP Format des messages  codés en mode texte similaire à HTTP .  REQUEST: consiste en une request line, plusieurs headers, une empty line et un message body. Le « message body » est optionnel; certaines requêtes SIP ne le transportent pas. Une Request line a trois éléments : method, Request URI, et protocol version. La « method » indique le type de requête. La « request-URI » indique le nœud suivant où la requête doit être routée. Finalement, la « protocol version » est SIP/2.0.  

INVITE sip: [email protected] SIP/2.0 BYE sip: [email protected] SIP/2.0

62

31

21/04/2014

2.3 Protocole SIP Les réponses SIP Les RESPONS SIP consiste en une status line, plusieurs headers, une empty line, et un message body. Le « message body » est optionnel; certaines requêtes SIP ne le transportent pas. Les réponses SIP sont identifiées par des numéros organisés comme suit : INFORAMTION : 1XX, requête reçue et le traitement de celle-ci continue ; Ex : 100 = trying ; 180 = ringing ; 181 = appel en cours…. SUCCES : 2XX, demande bien reçue, comprise et acceptée ; Ex : 200 = OK seule réponse de type 2XX définie actuellement). REDIRECTION : 3XX, action supplémentaire à faire pour satisfaire complètement la requête ; Ex : 300 = « multiple choices » (cas où le destinataire s’est enregistré auprès de plusieurs TE) ou 301/302 = « moved peranently/temporarily (l’appelé peut être joint à l’@ fournie en retour dans le header contact. 63

2.3 Protocole SIP Les réponses SIP ERREUR du client : 4XX, requête avec syntaxe erronée ou que le serveur ne peut satisfaire; Ex : 401, « unauthorized » (l’utilisateur doit s’authentifier avant d’effectuer la requête) ou 403, « forbidden » (cas du filtrage à l’arrivée) ou encore 404, « not found ». EURREUR du serveur : 5XX, requête en apparence valide que le serveur ne peut satisfaire (6 codes spécifiés) ; Ex : 501, « not implemented » ou 503, service unavailable » ou 505, « version not supported ». ERRUR générale : 6XX, aucun serveur ne peut satisfaire la requête; Ex : 600, « busy everywhere » ou 603, « decline » (refus d’appel).

64

32

21/04/2014

2.3 Protocole SIP Request Line

INVITE:sip : [email protected] sip/2.0

• Via : SIP/2.0/UDP station1.esmt.sn:5060 • Max-Forwards : 70 • To : Bobo Thiam < [email protected]

Several Headers

• From : Baba Sylla < [email protected]; tag=1492194421 • Call-id : [email protected] • Cseq : INVITE • Contact : [email protected] • Content-Type : application/sdp • Content-Length:162

Empty Line V=0

Body

C=IN IP 192.190.132.20 M+audio45450 RTP/AVP.0 65

2.3 Protocole SIP Request Line

SIP/2.0 200 OK

• Via: SIP/2.0/UDP proxy1.tn.com:5060;branch=z9hG4bK07asdhds •Via: SIP/2.0/UDP station1.esmt.sn:5060 • Max-Forwards : 70

Several Headers

• To : Bobo Thiam < [email protected] • From : Baba Sylla < [email protected]; tag=1492194421 • Call-id : [email protected] • Cseq : INVITE • Contact : [email protected] • Content-Type : application/sdp • Content-Length:162

Empty Line V=0

Body

C=IN IP 192.190.23.16 M+audio45450 RTP/AVP.0 66

33

21/04/2014

2.3 Protocole SIP Bobo

Baba

NB : l’adresse du SIP server est configurée dans le terminal du client sinon on passe par un URI pour obtenir l’@ serveur, N° de port et le protocole de transport. 67

2.3 Protocole SIP les messages SIP  méthodes SIP et « Request » émises par le client. 6 méthodes ont été définies dans le RFC 3261)  INVITE : pour initialiser un dialogue SIP. Contient les informations : demandeur – demandé ; type de flux qui seront échangés En cours de session, un nouveau INVITE modifie la session en cours  ACK : en réponse à une SIP Request (réponse à INVITE seulement)  CANCEL : pour annuler des requêtes sur l ’INVITE en cours Ex : utilisateur prend des terminaux sur lesquels a été lancé l’INVITE  BYE : pour terminer la session  OPTIONS : pour découvrir les capacités d ’un agent sans signalisation explicite: ex : type de codec supporté – UA disponible ou non 68

34

21/04/2014

2.3 Protocole SIP les messages SIP  REGISTER : pour s’enregistrer (et fournir la mobilité personnelle) L’UA communique son @ IP et son @ SIP (SIP URL) au Rgistrar @ IP du Registrar préconfigurée dans l’UA – sinon envoi du REGISTER en mulicast (224.0.1.175)

69

2.3 Protocole SIP

70

35

21/04/2014

2.3 Protocole SIP La méthode REGISTER  Est utilisée par un User Agent pour informer le réseau SIP de son adresse IP et de son URL pour laquelle il souhaite recevoir des appels.  L’enregistrement SIP est similaire à l’enregistrement du terminal mobile lors de son attachement au réseau GSM.  L’enregistrement n’est pas requis pour un User Agent souhaitant utiliser un Proxy server SIP pour des appels sortants. Il est requis par contre pour un User Agent de s’enregistrer afin de recevoir des appels entrants depuis des Proxy servers qui servent ce domaine.

71

2.3 Protocole SIP  La méthode REGISTER est utilisée par un User agent afin d’indiquer au Registrar son adresse de localisation (e.g., adresse IP) ainsi que son adresse SIP (SIP URL).  le User Agent peut connaître par avance son Registrar par configuration (adresse IP du Registrar préconfigurée dans le User Agent) auquel cas il émet une méthode REGISTER uniquement à ce Registrar.  Le User agent peut construire l ’adresse du Registrar. Si l ’adresse SIP de l ’usager est sip:[email protected], alors l ’adresse du registrar est sip:registrar.esmt.sn  Sinon, le User agent émet le message à tous les Registrars en utilisant la Well Known Address (adresse multicast :224.0.1.175).

72

36

21/04/2014

2.3 Protocole SIP SIP REGISTER UA 1 (Baba)

Base de donnée de localisation

Registrar sip:registrar.esmt.sn

REGISTER sip:registrar.esmt.sn SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 From: Baba Sylla To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :Mon, 11 Feb 2002 16:00:00 GMT Contact : sip: [email protected] Content-Length: 0

sip: [email protected] Sip: [email protected]

SIP/2.0 200 OK Via: SIP/2.0/UDP station1.tn.com:5060 From: Baba Sylla To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :Mon, 11 Feb 2002 16:00:00 GMT Contact : sip: [email protected] Content-Length: 0

73

2.3 Protocole SIP

Plusieurs enregistrements du même utilisateur SIP: UA 1 (Baba)

Registrar sip:registrar.esmt.sn

UA 2 (Baba)

REGISTER sip:registrar.esmt.sn SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 From: Baba Sylla To: Baba Sylla Call-Id: [email protected] CSeq: 2 REGISTER Expires :3600 Contact : sip: [email protected] Content-Length: 0

REGISTER sip:registrar.esmt.sn SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 From: Baba Sylla To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :7200 Contact : sip: [email protected] Content-Length: 0

200 OK

200 OK 74

37

21/04/2014

2.3 Protocole SIP

Base de donnée de localisation

Enregistrement par tiers partie UA 1 (Baba)

Registrar sip:registrar.esmt.sn

REGISTER sip:registrar.esmt.sn SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 From: Bobo Thiam To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :3600 Contact : sip: [email protected] Content-Length: 0 sip: [email protected] Sip: [email protected] SIP/2.0 200 OK Via: SIP/2.0/UDP station1.tn.com:5060 From: Bobo Thiam To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :3600 Contact : sip: [email protected] Content-Length: 0

75

2.3 Protocole SIP Annulation d’Enregistrement Annulation d’un enregistrement avant l’expiration : envoi d’une commande REGISTER avec header Expires dont la valeur est positionnée à 0. Annulation enregistrement de tous les terminaux : Expires positionné à 0, et Contact avec la valeur « * ». UA 1 (Baba)

Registrar sip:registrar.esmt.sn

REGISTER sip:registrar.esmt.sn SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 From: Bobo Thiam To: Baba Sylla Call-Id: [email protected] CSeq: 1 REGISTER Expires :0 Contact : sip: [email protected] Content-Length: 0

200 OK 76

38

21/04/2014

2.3 Protocole SIP Etablissement d’une session

Méthode INVITE. INVITE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP station1.tn.com:5060 Max-Forward : 70 To: Baba Sylla From: Bobo Thiam Call-Id: [email protected] CSeq: 1 INVITE Contact : sip :[email protected] Content-Type: application/sdp Content-Length:162 v=0 c = IN IP4 192.190.132.20 m = audio 45450 RTP/AVP 0

77

2.3 Protocole SIP UA 1 (Baba.sylla@)esmt.sn)

UA 2 ([email protected])

INVITE Call-ID : [email protected], Cseq : 1 INVITE 200 OK Call-ID : [email protected], Cseq : 1 INVITE ACK Call-ID : [email protected], Cseq : 1 INVITE BYE Call-ID : [email protected], Cseq : 2 BYE 200 OK Call-ID : [email protected], Cseq : 2BYE 78

39

21/04/2014

2.3 Protocole SIP ACK non routé

UA 1 (Baba.sylla@)esmt.sn)

UA 2 Registrar ([email protected]) sip:registrar.esmt.sn

INVITE INVITE 200 OK

200 OK ACK Conversation BYE 200 OK

79

2.3 Protocole SIP UA 1 (Baba.sylla@)esmt.sn)

Enregistrement routé

UA 2 Registrar ([email protected]) sip:registrar.esmt.sn

INVITE

INVITE 200 OK

200 OK ACK

ACK Conversation

BYE 200 OK

BYE 200 OK

80

40

21/04/2014

2.3 Protocole SIP

Enregistrement routé avec 3 PS PS1 PS2 PS3 UA1

1.INVITE

2.INVITE

3.INVITE

Route: PS1

8.200 OK 9.ACK

UA3

PS2 ne souhaite pas rester sur le chemin de signalisation au delà de l ’INVITE/200 OK

Route: PS1

4.INVITE Route: PS1 et PS3

5.200 OK

6.200 OK

7.200 OK 10.ACK

11.ACK

Conversation 12.BYE

17.200 OK

13.BYE

14.BYE

16.200 OK

15.200 OK 81

2.3 Protocole SIP

82

41

21/04/2014

2.3 Protocole SIP Stateful PROXY

83

2.3 Protocole SIP Stateless PROXY

84

42

21/04/2014

2.3 Protocole SIP Exemple général

85

2.3 Protocole SIP Exemple général

86

43

21/04/2014

2.3 Protocole SIP

87

2.3 Protocole SIP Gateways SIP Entreprise

88

44

21/04/2014

2.3 Protocole SIP Extensions SIP : RFC 3261 complété par des méthodes supplémentaires  SUBSCRIBE : RFC 3265 Demande de notification d’événement d’appel  NOTIFY : RFC 3265 Notifie un événement pour lequel une souscription a été effectuée par SUBSCRIBE  MESSAGE : RFC 3428 Émulation du service SMS avec le protocole SIP  REFER : RFC 3515 Transfère l’utilisateur à une URL  UPDATE : RFC 3311 Modifie la session avant son acceptation  INFO : RFC 2976 transfert des informations de SIG durant l’appel (ex : signaux DTMF, infos de taxation …)  PRACK : RFC 3262 Permet d’acquitter la réception d’informations provisoires  PUBLISH : RFC 3903 Permet d’afficher l’état d’une requête à laquelle on a souscrit par SUBSCRIBE 89

2.3 Protocole SIP

Services supplémentaires

90

45

21/04/2014

2.3 Protocole SIP

Services supplémentaires

91

2.3 Protocole SIP

Services supplémentaires

92

46

21/04/2014

2.3 Protocole SIP

Services supplémentaires

93

2.3 Protocole SIP

Services supplémentaires

94

47

21/04/2014

2.3 Protocole SIP

Services supplémentaires

95

2.3 Protocole SIP SIP User Agents

96

48

21/04/2014

2.3 Protocole SIP-T NGN interfonctionnement entre softswitches

97

2.3 Protocole SIP-T NGN interfonctionnement entre softswitches

98

49

21/04/2014

2.3 Protocole SIP-T INVITE et IAM encapsulé

99

2.4 Protocole H323 Généralités sur le multimédia: H323 échange de signalisation à l’aide des protocole RAS (RAS : Registration, Admission and Status) utilisé entre GK et les endpoints , et Q931 (H.225) et le Contrôle des communications multimédia H.245 Communications multimédia en environnement IP nécessitent: Protocoles temps réels pour le transport et contrôle des flux : RTP et RTCP Protocoles Peer to peer pour établir des appels ou sessions : H.323 ; SIP Protocole du type maître – esclave pour la commande des gateways : H.248 … Quant aux tâches du protocole peer to peer:  Localisation du (ou des) participant (s) et obtenir l’@IP pour établir une session  Établir l’appel entre les participants  Négocier le type de session correspondant à l’appel  Créer et fermer le flux media  Établir et modifier une session  Clore la session 100

50

21/04/2014

2.4 Protocole H323 Généralités sur le multimédia:

101

2.4 Protocole H323 Description fonctionnelle Norme « parapluie » H323 définit des procédures communes minimales pour assurer l’interopérabilité entre différents produits – s’appuie sur un ensemble de normes déjà définies

102

51

21/04/2014

2.4 Protocole H323 Architecture: Composé de garde barrière (Gatekeeper GK ) fourni des services majeurs.  Adresse, gestion des autorisation, authentification des terminaux et des passerelles, gestion de la bande passante et de la facturation. Les Endpoints au nombre de 3 :  Les terminaux : IP phone, PC, PDA, set top box  Les gateways (GW) : assurent l’interface entre un réseau H.323 et un réseau non H.323 (typiquement interface entre réseau IP et le PSTN). La conversion de signalisation H.323 SS7 assurée généralement par une plate forme indépendante appelée passerelle de signalisation  Multi Control Unit (MCU) qui servent pour établissement de conférences multipoints en multimedia – les MCU doivent contenir un MC et peuvent contenir aussi un MP  MC : Multipoint Controller : traite la signalisation et assure le contrôle des messages pour initialiser et gérer la conférence  MP : Multiprocessor : accepte les streams des différents endpoints, les réplique et les transmet aux participants – assure aussi le mixage des flux media ( ajout d’un canal video à un canal audio) 103

2.4 Protocole H323 RAS : Registration, Admission and Status (H.225) Utilisé entre GK et Endpoints, ou entre GK pour des tâches qui ne sont strictement du traitement d’appel: Les messages non liés au traitement d’appel:  GRQ (Gatekeeper Request) : envoyé par un terminal pour determiner son GK (cas où @ du GK n’est pas chargée statiquement sur le terminal)  GCF Gatekeeper Confirm : envoyé du GK vers le terminal pour confirmer l’@ du GK.  RRQ Registration Request : @ transport pour SIG (Endpoint vers GK)  RCF Registration Confirm: confirmer un message RRQ (GK vers Endpoint)    

GRJ : Gatekeeper Reject en réponse à un message GRQ RRJ : Registration Reject en réponse à un message RRQ URQ : Unregistration Request : pour annulation enregistrement (from Endpoint or GK) UCF: Unregistration Confirm pour confirmation annulation enregistrement. 104

52

21/04/2014

2.4 Protocole H323 RAS : Registration, Admission and Status (H.225)

105

2.4 Protocole H323 RAS : Registration, Admission and Status (H.225) ARQ : Admission Request – envoyé pour demander autorisation d’établir une connexion au GK – réponse du GK:  ACF : Admission Confirm contenant l’@IP du demandé ART : Admission Reject sinon

106

53

21/04/2014

2.4 Protocole H323 Message liés à l’établissement de l’appel (H.225)

107

2.4 Protocole H323 Message liés au relâchement de l’appel (H.225)  DRQ : Disengage Request : informe le GK que l’appel et ressources associées ont été libérés DCF : Disengage Confirm  Autres types de messages RAS Messages liés au contrôle de la bande passante BRQ (après établissement de la session) ; BCF; BRJ. Messages Status Messages entre GK : localisation

108

54

21/04/2014

2.4 Protocole H323 Q.931 (H.225) Est utilisé pour établissement d’appel entre EndPoints:  Quand un Endpoint a eu son ACF, il essaie d’établir l’appel selon la procédure H225 (Q.931)  Q.931 est transporté par TCP – La port à utiliser est donné au cours des échanges RAS (typiquement port 1920 , mais une autre configuration est possible)  H (225) Q.931 reprend les spécifications de Q.931 du RNIS, mais sous forme allégée. • • • • • •

Setup Call Proceeding (Optionnel) Alerting Connect Release complete Facility (Optionnel)

H225 (Q931) n’établit pas de canal media comme en RNIS (ce sera le rôle de H245). 109

2.4 Protocole H323 Q.931 (H.225)

110

55

21/04/2014

2.4 Protocole H323 H.245 Description fonctionnelle H 245 : établissement des flux media  Après la « call setup » , établissement d’un canal de contrôle H245 pour établir la session media et le contrôle des sessions  Les @ H245 IP et ports sont échangés dans la procédure Q931 pour permettre ensuite à H245 d’être transporté sur TCP (allocation de port dynamique)  La procédure H245 démarre avec la phase « Terminal Capacity Negociation »  Les Endpoints échangent leurs capacités : voixn, video, données, fax et donnent aussi leur préférence (ex G711préféré)  Se poursuit avec établissement des rôles Maître /esclave Négociation également de la taille maximum du payload pour chaque codec voix (par défaut 20ms)  Se termine avec l’ouverture des canaux media  Chaque Endpoint peut alors ouvrir un forward channel indépendamment  L’Endpoint demande à l’autre Endpoint : l’@IP et le port à utiliser pour envoyer son flux media 111

2.4 Protocole H323 H.245

112

56

21/04/2014

2.4 Protocole H323 H.245

113

2.5 Protocole SigTran Transport de SS7 au dessus de IP SIGTRAN (SIGnaling TRANsport) de l’IETF  Suite de protocoles spécifiées pour le transport de la signalisation  Transport des protocoles de la suite SS7 au dessus d’un réseau IP  Destinée à des applications spécifiques basés sur le SS7. • Rendre transparent le protocole IP. SIGTRAN defini une architecture à deux couches:  Une couche SCTP RFC 2960 (Stream Control Transport Protocol) • Protocole de transport fiable de message de signalisation au dessus de IP • Entre point terminaux SCTP (addresse IP , port SCTP) • Assure une livraison des messages dans l’ordre et sans erreurs • Contrôle de congestion et gestion de la taille des messages.  Une couche d’adaptation (IUA, M2UA, M3UA,et TUA). • Emule les couches SS7: ISUP, TCAP, SCCP, MTP2, et 3 et Q931

114

57

21/04/2014

2.5 Protocole SigTran Transport de SS7 au dessus de IP

115

2.5 Protocole SigTran Fonctionnalité de SIGTRAN  Identification des points de signalisation  Livraison des messages de signalisation dans l’ordre  Contrôle et la gestion du flux  Détection des erreurs et retransmission des messages  Fourniture des mécanismes de securité.  M2UA (MTP2 User adaptation Layer).  Transport des messages de signalisation SS7 de la couche MTP2  La passerelle de la signalisation recoit un message du RTC (transporté par MTP2 à partir d’un point terminal de signalisation (SCP ou SSP) du RTC et route les messages M2UA vers le MGC en utilisant les mecanismes d’association SCTP.   

M3UA (MTP3 User Adaptation Layer) Transporte les messages de signalisation SS7 de la couche MTP3. La passerelle de la signalisation recoit un message du RTC (transporté par MTP3 et delivre des messages à l’ISUP . 116

58

21/04/2014

2.5 Protocole SigTran Exemple de passerelle de signalisation (SGW)

117

2.5 Protocole SigTran Améliorations apportées par SIGTRAN  SIGTRAN supporte la fragmentation :un message de signalisation peut être découpé pour s’adapter à la PDU  Data Chunk pour transport de message. Chaque Chunk a une Transmission Sequence Number unique  Il est orienté message, définissant des trames de données structurées. TCP à la différence, n’impose aucune structure du flux d’octets transmis.  Multi streaming possible: données réparties en plusieurs flux avec chemins indépendants (TCP n’a pas cette fonctionnalité)

118

59

21/04/2014

2.5 Protocole SigTran Les chunks sont des blocs de données de taille variable qui peuvent appartenir à des flux différents. Chaque chunk débute par un champ Chunk ID (8bits) indiquant le type de chunk afin de distinguer les chunks de données et les différents chunks de contrôle.   

Chunk (Chunk Flags): Fanion (8bits) Chunk (Chunk Length): Taille variable d’un chunk (16bits) Chunk (Chunk Value) :es utiles ou de contrôle

119

2.5 Protocole SigTran

120

60

21/04/2014

2.5 Protocole SigTran

121

2.6 Protocole H245/Megaco Généralités Défini par l’IETF et l’IUT (RFC 3015) en novembre 2000 – La recommandation H.248 a été publiée en février 2001 Called Megaco by the IETF and H.248 by the ITU Megaco est un protocole de contrôle entre le Media Gateway et le Media Gateway Controller comme MGCP. Supporte les applications multimédia. – MGCP ne supporte que la voix Ce standard est appelé Megaco par l’IETF et H.248 par l’UIT.

122

61

21/04/2014

2.6 Protocole H245/Megaco Généralités Protocole maître/esclave de commande des passerelles média • MGC alloue, dés-alloue des ressources media MG pour un appel donné. • MGC connaît toutes les ressources des MG • MGC commande connexions entre différents « bearer » , uni / bi-directionnelle, • multipoint et pour différents média simultanément (audio, texte, vidéo). • • •

MGC contrôle le lien MGC/MG (sécurité du lien, basculage vers autre MGC ou MG …) MGC peut commander autres process : suppression d ’écho, de silence…

H248 ou MEGACO permet aussi : • Remontée par la MG des réponses aux actions demandées par MGC • Notification par MG d’événements survenus au niveau media (détection DTMF par ex …)

123

2.6 Protocole H245/Megaco Architecture Megaco/H.248

124

62

21/04/2014

2.6 Protocole H245/Megaco MEGACO spécifie des commandes pour:   

Créer des contextes Modifier les valeurs de leurs paramètres Rajouter ou supprimer des terminaisons à des contextes.

Contextes : est créé par MG sur commande de MGC • les terminaisons existent dans un contexte qui est une association entre groupes de terminaisons (contextes ‘’NULL ‘’ pour terminaisons physiques inactives) Une terminaison est donc décrite à travers les informations suivantes: • Properties : mode (receive-only, send-and-receive) et état (in / out-ofservice, intest). • Events : événements détectables (e.g., on-hook, off-hook, flash-hook). • Signals : signaux que la terminaison peut générer (e.g., dial-tone, callwaiting tone) • Statistics : e.g., number of packets/cells sent, number of packets/cells received,etc. 125

2.6 Protocole H245/Megaco Notion de commande MEGACO Elle agit sur les Terminaisons et les Contextes: • Une commande contient le nom de la commande, le(s) Termination Id impliqué(s) et des paramètres appelés « Descriptors » . •

 ADD : Rajoute une terminaison à un contexte existant ou à un nouveau créer par la même occasion. Une terminaison permanente est connue du MGC et la commande ADD précise son identifiant – une terminaison temporaire est créée par la MG avec son identifiant  MODIFY : pour modifier les propriétés, les événements, et les signaux d’une terminaison 126

63

21/04/2014

2.6 Protocole H245/Megaco Notion de commande MEGACO  SUBSTRACT : déconnecte une terminaison. Le contexte est détruit avec le retrait de la dernière terminaison . Provoque envoi de statistiques au MGC 

MOVE : passer une terminaison d ’un contexte à un autre.



AUDIT VALUE : retourne la valeur courante des propriétés, événements, signaux et statistiques relatifs à une ou plusieurs terminaisons



AUDIT CAPABILITIES : retourne l’ensemble des valeurs possibles



NOTIFY : le MG informe le MGC d’événements sur une terminaison du MGW (ex : signalisation du niveau media) • Les événements à rapporter sont spécifiés par le MGC dans les commande Add ou Modify. 127

2.6 Protocole H245/Megaco Notion de commande MEGACO 

SERVICE CHANGE : • MG pour informer MGC qu’une terminaison (ou groupe) est sur le point d’être mis HS ou remis en service • MGC pour informer la MG de son passage sous un autre MGC – en réception, MG émet un ServiceChange vers le nouveau MGC

128

64

21/04/2014

2.6 Protocole H245/Megaco

129

2.6 Protocole H245/Megaco Descripteurs MEGACO:  Le descripteur de Modem : spécifie le type de modem (V.18, V.22, etc… pour les conversation en mode texte) et ses paramètres. 

Le descripteur de multiplexage: spécifie pour les appels multimédias, un type transport, un type de multiplexage (H.221, H.223, etc.…) ainsi qu’un ensemble d’identifiants de terminaisons représentants les flux en entrée.



Les descripteur de media: specifie les parametres des flux media.



Le descripteur d’etat de terminaison: contient les proprietés d’état de service (test, hors service, ou en service).



Le descripteur de contrôle local: contient pour un flux spécifique, la propriété mode ( send-only, receive-only, send/recive…)



Le descripteur local et distant: réserve et valide les ressources MG pour le et le décodage de flux et de terminaison. 130

65

21/04/2014

2.6 Protocole H245/Megaco

MGC1

ISUP

BICC

H248

(1) IAM

ISUP

H248 T2

T1 CAA1

MGC2

ATM

T4

T3

MG1

CAA2

MG2

(2) C$ {Add T$ {AESA$, BNCid$}} (3) Reply C1 {Add T2 {AESA, BNCid}} (4)

(5) IAM

(6) C1 {Add T1} ((8) C$ {Add T$ {AESA, BNCid}}

(7) Reply C1 {Add T1}

(9) (10) Reply C9 {Add T3} (11) C9 {Add T4} (12) Reply C9 {Add T4} (13)

131

ESMT : Signalisation dans les réseaux NG et IMS

2.6 Protocole H245/Megaco

MGC1

ISUP

BICC

H248

ISUP

H248 T2

T1 CAA1

MGC2

ATM

MG1

T4

T3

CAA2

MG2 ((14) C9 {Notify T3}

(15) COT

(18) ACM

(21) ACM

(16) ACM

(17)

(19) ANM

(20)

132

66

21/04/2014

2.7 Protocole BICC Objectif de BICC :  Modification du protocole SS7/ISUP pour devenir un protocole de commande d’appel en association avec un protocole de commande de ressources. • BICC hérite de toutes les fonctionnalités et services ISUP • réseaux paquets peuvent être utilisés pour transport du media (voix)

Architecture de référence BICC ISN Interface Serving Node , comporte:  CSF Call State Function (« équivalent » du call server/softswitch) fonctions classiques du traitement d ’appel (traduction, comptage, détails de communication, traitement de la SIG…fonctions CAS).  Le BCF Bearer Control Function : traite la signalisation du transport traite le protocole de commande du support, gère les informations propres au plan de transfert (adresses passerelles, identifiant de corrélation appel/support...  Le BF : Bearer Function assure conversion des signaux et leur transport. 133

2.7 Protocole BICC Architecture de référence BICC Deux autres nœuds sont définis dans l’architecture  TSN : Transit Serving Node Traite BICC des 2 côtés Peut être utilisé pour offre de services RI Peut transformer aussi le bearer entre deux types de réseau paquet  GSN : Gateway Serving Node Similaire au TSN car traite BICC des 2 côtés Gateway entre réseaux d’opérateurs différents dans un contexte full BICC.

134

67

21/04/2014

2.7 Protocole BICC Architecture de référence BICC

135

2.7 Protocole BICC Le protocole 4 phases dans la signalisation dans un réseau BICC  Incoming « bearer + Call SET UP request »  Établissement d’appel (call set up) avec BICC en signalisation d’appel  Établissement des ressources (« bearer ») avec utilisation d’un détecteur de la signalisation de commande de ressources  L’appel est pouirsuivi par un outgoing « bearer + Call SET UP request »

136

68

21/04/2014

2.7 Protocole BICC

MGC1

ISUP

H248

(1) IAM

ISUP

H248 T2

T1 CAA1

MGC2

BICC

ATM

T4

T3

MG1

CAA2

MG2

(2) C$ {Add T$ {AESA$, BNCid$}} (3) Reply C1 {Add T2 {AESA, BNCid}} (4) BICC IAM {Backward setup, AESA, BNCid}

(5) IAM

(6) C1 {Add T1} ((8) C$ {Add T$ {AESA, BNCid}}

(7) Reply C1 {Add T1}

(9) B-SETUP {BNCid} (10) Reply C9 {Add T3} (11) C9 {Add T4} (12) Reply C9 {Add T4} ((13) B-CONNECT

137

2.7 Protocole BICC

MGC1

ISUP

H248

ISUP

H248 T2

T1 CAA1

MGC2

BICC

ATM

MG1

T4

T3

CAA2

MG2 ((14) C9 {Notify T3}

(15) COT

(18) ACM

(21) ACM

(16) ACM

(16) BICC ACM

(19) ANM

(19) BICC ANM

138

69