multimédia sur ip

Téléphonie(et vidéo) sur Internet

Téléphonie sur IP 1

Ahmed MEDDAHI

Téléphonie (et visioconférence) sur Internet

� Introduction� Contexte,enjeux et objectifs de la VoIp

� Architectures� Les composantes et les différentes architectures (H 323/SIP…)� Net to Net� Phone to Phone� Phone to Net� …� Étapes d ’une migration vers la Voix sur Ip

� Protocoles de niveau application (>4) issus de l ’IT U-T� H320, H323, T120…


� H320, H323, T120…� Scénarios d ’appel « H323 »

� Points « faibles », points « forts » de la suite protoc olaire TCP/IP� Contraintes liées aux flux temps réel sur IP

� Délai, Jitter, pertes…� Qualité de Service:

� Protocole « Ip Multicast »� les principaux modèles Diffserv et Intserv (RSVP)

� Conclusion

Introduction

� Dérégulation des télécommunications (juillet 1996)

� Intérêt (court terme) : baisse des coûts de télécom munication

� Intérêt (long terme): intégration voix-données sur un seul réseau,

enrichissement applicatif, nouveaux services.

� Solution indépendante de l’infrastructure de transport.


� Standard ouvert (on ne retombe pas dans un marché verticale)

� Convergence Fixe Mobile (Internet Multimedia Subsystem de la 3G+).

� « Résout » les problèmes de compensation inter-opérateurs (« clearing house »).

� "API" pour la création de services (ex service voix) ouvertes et supportées par tout type

de technologie réseaux--> technologies: “JAIN“ (Java API for Integrated Networks),

SIP CPL, SIP Servlets, SIP CGI.

� Avantage compétitif du routage IP sur la commutatio n :� La fonction d ’aiguillage des commutateurs assurée par des routeurs� Commutateurs : faible temps de latence, extrêmement sophistiqués,

marché peu concurrentiel, pour des réseaux nationaux très spécifiques

Coût « élevé »

� Routeurs: base ordinateurs, économie d ’échelle, forte

Introduction(suite)


� Routeurs: base ordinateurs, économie d ’échelle, forteconcurrence dans ce secteur

Coût « faible »

� Débit de la parole sur RTC (commutateurs) : 64Kb/s� Débit de la parole sur IP (routeurs) : entre 4 et 8 Kb/s

réduction d ’un facteur 10 des capacités de transmission nécessaire

Enjeux: �Enjeux

» QoS• Performance du réseau IP best effort variable et très dynamique

» Evaluation de la qualité de la voix

» « Complexité » du réseau (nombre de serveurs, configuration de la QoS, …)• Impact sur la fiabilité, administration, coût

» Sécurité Spam téléphonique (plus critique que le « mail » spam), cryptage des flux de signalisation


• Spam téléphonique (plus critique que le « mail » spam), cryptage des flux de signalisation et média, …

» Disponibilité (99.9% : indispo. ~48h/an # 99,999% pour le RTC ~ 5’/an),

» Gestion localisation (géographique), interceptions d’appels (Session Border Controller) , numéros d’urgence.

�Economiques: Gain Ip Pbx/Pbx non IP.

�Usage: groupe « zeroconf » de l’IETF.

PABX classique (architecture)

Carte Processeur« proprietaire »

Carte Commutation« proprietaire »

Voice mail+

IVR

Interface proprietaire

Signalisation

Sig.Sig.

Voix. Voix.


Carte Lignes« propr. »

Carte Trunks« propr. »

PSTN

Voix. Voix.

Voix.

Voix.

Sig.

Sig. Voix.



Lan Pbx IP/H323 (→architecture « distribuée »)

Serveur d ’Appli.(Voice

Standard: SIPMegaco/H.248H.323…

Applicationcontrole d ’appel

ProcesseurIntel/Risc…

Serveur (ex Linux, windows ou OS temps réel)


PasserelleIP/RTC

(Voice mail+IVR+Présence, MCU…)

RéseauTCP/IP

…

Standard

Standard

ReseauRTC

Terminaux Internetou

Application PC

StandardStandard

« Price Quality Tresholds for Customer Calling »

Quelques chiffres (Source: The Yankee Group)

Source: The Yankee Group

48

3022

05

101520253035404550

« Other Success Criteria»

48

3022


Percent Savings Required

040 50 80

28%-Required 72%-Essential


42%-Required 55%-Essential 3%-Not Required


SLAs/Performance Guarantees Help with Implementation

Help with Net Planning and Design Traffic Reports

« Other Success Criteria»

Source: The Yankee Group

STP

STP STP

STP

STP

STP

SSPSSP

SCP

SCP

B

D D

D

D

CC

E

E

A

A

B

B

B

A

A

AAC

AA

*SSP:Service Switching Point*STP: Signal Transfert Point*SCP: Service Control Point

Rappel: Architecture RTC

Réseau de signalisation


C4

Liens « TRUNKS »

C5

C3C3

C4 C4

C4

C5 C5C5C5C5

Réseau de signalisation

Réseau de transport

� Topologie hiérarchique--> adaptée au transport de l a voix (protocoles orientés circuit) mais pas optimisés pour le transp ort des données (~3/4 du trafic globale)

� SS7 standard international mais implémentation diff érente (version Fr, US…)

� Commutateurs "classe 5" --> "complexes" (# classe 3 et 4 pour le transit)

� fournit les services de bases (signal d'appel, identifiant d'appel, transfert

Services télécoms: (« réseau Circuit »)


� 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…)

� Besoin de standards simplifiés et "accessible" pour le développement et le déploiement rapide de nouveaux services

� 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 (SoftSwitch ou Call Agent) --> signalisation (ex.SI P)

� 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, Ad sl, RI (SS7),…)

� Media gateways

� Signaling gateways

Services télécoms IP: (« réseau Paquet »)


� "API" pour la création de services (ex service voix ) ouvertes et supportées par tout type de technologie réseaux--> “JAIN “ (ex. JAINSIP )

� Convergence Fixe-Mobile

� Architecture IP orientée « SIP », dans les réseaux m obiles (3G/IMS: Internet Multimedia Subsystem) pour le transport voix/Video/données.

» Convergence des services: accès au « même » service q uelque 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 devic e, Any Network")

Les réseaux: Le contexte

ngSDH/Ethernet

DWDM IP/(G)MPLS Core

xDSLEthernet Transport

Vehicular

Ubiquité des services

et mobilité globale


Ad-HocWSN

WiMAXWiFi

FTTx

Cellular2G, 3G�LTEDVB-H

BTS

BTS

BSC

HLRVLR

MTP1

MTP2

MTP3

SCCP

SCP

STP STP SG

MSC

MGCSOFTSWITCH

IP Media

MTP2MTP3

SCCPTCAP

MTP1

MTP2

MTP3

MTP1

IN (SS7 ou sémaphore)

Réseaux IpMobile

Signalisation SS7 pour réseaux intelligents converg ents


BTS

BTS

BSC

MTP1

SSP SSP

IPe

MG

CO COSN

MSC

VoIPGateway

Server

MTP2MTP3

SCCPTCAPINAP

MTP1

MTP2

MTP3

SCCP

TCAP ISUP

MTP1

MTP2

MTP3

SCCP

TCAP

GSM MAPISUP

MTP1

Fixe

Architecture générale de référence

Coeur réseau:

Serveurcontrôle d’appels

PSTN/SS7

Plate-forme de services(services API)

(services API)


«Circuit»«Paquet»

RGw

MGw

Coeur réseau:Internet + QoS (Diffserv/Intserv)

Flux media (RTP/RTCP/…)

RTP/RTCP

SGw

PSTN/SS7

Analog./Digital

SGw: “signaling gateway”MGw: “media gateway”RGw: “residential gateway”

Remarque (sur IP) : intelligence à la périphérie du réseaucircuit de sig. Indépendant du circuit de transport (du flux)

Terminal(services API)

INTERNET opérateur X

INTERNET opérateur Y

Net to Net

Architectures


Client H323Client H323

INTRANET

Net to Net

IntranetPasserelle H324/H323

Passerelle H324/H323

Architectures (suite)


RTC RTC

Phone to PhonePhone to Net

INTRANET

Réseau local Réseau local

Architectures: transport Ip

Routeur @IP 193.48.251.1

!dial peer voice 6 potsdestination pattern 0Port 1/1/0dial peer voice 1 voipdestination pattern 1session target 193.48.251.2!

!dial peer voice 7 potsdestination pattern 1Port 1/1/0dial peer voice 8 voipdestination pattern 0session target 193.48.251.1!


Pabx

Pabx

RTC

Réseau local Réseau localRouteur @IP 193.48.251.1

@IP 193.48.251.2 Routeur

Préfixe «0»

Préfixe «1»

INTRANET

Architectures: passerelle Ip/Rtc

Réseau local: @IP 193.48.251.1 @IP 193.48.251.2

!……….dial peer voice 6 potsdestination pattern 0Port 1/1/0dial peer voice 1 voipdestination pattern 1session target 193.48.251.2dial peer voice 4 voipdestination pattern 2session target 194.48.251.108!


Pabx

Pabx RTC

Réseau local:



Routeur

Id: 2

@ip: 194.48.251.108

INTRANET

Architectures: tout Ip!……….dial peer voice 6 potsdestination pattern 0Port 1/1/0dial peer voice 1 voipdestination pattern 1session target 193.48.251.2dial peer voice 4 voipdestination pattern 2session target 194.48.251.108!

Réseau local: Réseau local: @IP 195.48.251.0

!Ip route 195.48.251.0 255.255.255.0 Dialer 1 250!


Pabx Ip

«Pabx IP» (serveur de contrôle d’appels)

RTC



Routeur Routeur

Réseau local: @IP 194.48.251.0 associé au Préfixe « 2 »

Id: 6062

@ip: 194.48.251.108

@IP 195.48.251.0préfixe « 3 »

Id: 7062

@ip: 195.48.251.208

Pabx

Internet

MCU H320

Routeur

Architecture (Plate-forme ENIC)

RTC

RASServeur de « streaming » Audio/video


RNIS

INTRANET

MCU H323


Client H320Individual system

Client H320group system(classroom)Client H323

WAN

Call agent

SipH323Megaco/H248

RéseauIP

-

RouterIP

Lan client

Wireless clientPC/PDA (802.11)

Cable modem client

Serveur de Contrôle d'appels

QoS (signalisation) : Plate-forme1

Serveur de Contrôle

d'appels (SIP Server)

TerminalSIP

Serveur de Contrôle

d'appels (SIP Server)


PSTN

-

Terminal

IntranetAdsl client

Modem client

SIP Gateway

FXS

SIP Gateway FXO

Contrôle d'appels

(gatekeeper H323)

H323 Gateway

"Generateur"(generateur de charge

SIPlinéaire, Gaussien,

exponentielle,Poisson)

Protocoles niveau « applications » (> 4)

� Norme H320 (ITU)





� Norme T120 (ITU)

Source: Infonetics research

Organisations

� ITU-T (International Telecommunication Union-Teleco m)� Study Group 16 (Multimédia)

� IETF (Internet Engeneering Task Force)� mmusic,avt,...


� IMTC (International Multimedia Teleconferencing Con sortium)� VoIp Forum, InterOP, SuperOP

� ETSI (UE)� TYPHON

…..

H323 et les autres normes

� H321- vidéoconférence sur ATM– qualité business 384Kb/s-2Mb/S

� H320 - vidéoconférence sur ISDN– qualité business 64Kb/s-128Kb/s

� H323 - vidéoconférence sur IP/Ethernet


� H323 - vidéoconférence sur IP/Ethernet– qualité best effort 128Kb/s-384Kb/s….

� H324 - vidéoconférence sur RTC– qualité faible 28.8Kb/S-64Kb/s

� H310 - vidéoconférence M-Peg2 sur ATM– qualité broadcast 3Mb/s-16Mb/s

Terminal H.320


ChiffrementH.323

A

A

A

T

p

h

Terminal H321


H.221L

5/1

T

M

h

y

ATM

Débit H320

� 64 Kb/s------------------ visioconférence pour le « particulier »

� 128Kb/s----------------- visioconférence dans l ’entreprise

� 384 Kb/s ---------------- visioconférence dans l ’entrepise


� 384 Kb/s ---------------- visioconférence dans l ’entrepise

� 512 Kb/s---------------- visioconférence dans l ’entreprise

� 768 Kb/s+(2Mb/s)---- télé-enseignement, télé-médecine

Norme H320

� Composantes:

� Audio : G711 (64 K) , G728 (16k), G729 (8 K), iLBC(~15Kbs)...

� Vidéo : H261(n*64K) , H263 (<64K) , H263+ (V2), H264 (MPEG4: 5Kbs à 10Mbs), MPEG2 (2 à 16 Mbs ), MJPEG (~24Mbs) …


� Gestion, contrôle (signalisation) : H242

� Structure de la trame : H221

(cod+dec)

Codec débit moyen

a.pcm

16, 24, 32, 40k

4.1/3.3 (à 32/16k)

12

Ethernet phone

300µs

Codec bas débit

Standard FRF 11

16k

4

3ms

Codecs Audio: Caractéristiques des différents Algorithmes Audio

G726/727 G728G711Codec Haut débit

pcm

pas de compression

64k

m.o.s 4.5

m.i.p.s 0.5

pas d'annuleur écho

retard 125µs

(codec+dec)


Echo cancellation:G165-> «ancien» standard G167->annuleur d ’écho acoustiqueG168->35 db de perte pour l ’écho retour

H323 « mandatory »

8k

m.o.s 4

26/13.1(G729/729.a)

G729a-vad, cng

Taille Frame: 10byt.

Durée Frame:10ms

Fr./Paquet:3

(Silence:6by/15ms/2)

VoFR

5.3/6.4k

3.5/4 (à 5.6/6.4)

16

G723a-vad,cng

Taille Fr.: 20byt.

Durée Frame:30ms

Fr./Paquet:1(Silence:4by/30m/1)

G729/729a G723.1/723.1a

Internet

13.3K

3.7

iLBC (Internet Low Bitrate Codec)

Autres mécanismes pour la QoS (ex. adaptés à la voix):

� En tête IP/UDP/RTP varie relativement peu ou d ’une manière prédictible.� Nécessité de multiplexer les paquets court pour aug menter l ’efficacité

du protocole « IP »-CRTP (Compressed Real Time Protocol, RFC 2509, 354 5 )-TCRTP (Tunneling Multiplexed Compressed RTP, RFC 4 170)

Mod. Mod.


Internet RAS Mod.RASMod.

RTP CRTP TCRTP CRTP

Mod. Mod.

H.320 H.321 H.323 H.324

RéseauRéseau BandeétroiteRNIS

Réseau Large Bande

(ex. ATM)

Réseau B.Pnon garantie

(paquet) ethernet

Réseau Téléphon.RTC

VidéoH261H263

H261H263

H261H263

H261H263

Récapitulatif

� Recommandations ITU pour les communications multimé dia


VidéoAudio

Multipoint

Contrôle

Multiplexage

DataInterface de

com.

H263 H263 H263 H263

G711,722,728

G711,722,728

G711,722,728723,729

G723

H221 H221 H225.0 H223H230H242 H242 H245 H245

H231 H243 H231 H243 H323

T120 T120 T120 T120I400 AAL;I363

I361;I400TCP/IP Modem V34

Norme H.323?

� Standard ITU-T pour la visioconférence multimédia s ur réseaux à commutation de paquets

� Internet (limité par les performances internet)

� LANs et Intranets

Rq: Sur LAN, un appel visio utilise en moyenne ~450kbit/s de la


» Rq: Sur LAN, un appel visio utilise en moyenne ~450kbit/s de la capacité du réseau:

• 200Kbs (overhead) 2*128 Kbs (visio full duplex)– sur les 128 Kbs :

30K pour les data, 128 -30 -16 (G728) pour la vidéo

» Le trafic LAN peut être géré et contrôlé.

Norme H.323

� Mai 1995 - l ’étude sur H.323 démarre

� Juin 1996 - H323 v.1 normalisé par ITU-T

� Janvier 1998 - Version 2 de H323 .» H235 -> sécurité» H450 1,2 et 3 ->services minimum

� Mai 99- Version 3 de H323.


» T38 -> fax temps réel» H450-> services supplémentaires (~10 aujourd ’hui H.450.11)» HGCP->inter-fonctionnement avec le RTC existant (SS7,RI)» prise en compte de nouveaux codecs

� 2000- Version 4 de H323» H248->ex HGCP, meilleure gestion de la B.P, « tunneling » de la sig. PSTN,

tarification avancée (carte « pré-payée », ….)

� 2005-version 5 de H323 (…nov. 2009-version 7, H.325 ~ 2012)» SCTP, Securité, Mobilité, IPSec, IPv6, Presence, ..

Etat de la Recommandation H323 (version 4)

� H.323� version 4

� H.225� version 4

� H.245 � version 7


� H.235 (“H.Secure”) - Encryption� version 2

� H.332 (“H.Loosely Coupled”) � version 1

� H.341 (Multimedia MIB)� version1

� H.450.1-12

Cohabitation des protocoles « IP »

SAPRTCPRSVPMcast Fiable

RTSP

RTP SIP SMTPHTT

P

SDPAppli. Audio/Video Appli.

partagées

Création et établissement de séssion.

H323


UDP TCP

IP, IP Mcast ,WFQ, Ip Precedence...

CRTP/MLPP

Transport

Réseau

SAP

Liaison

Physique

RTCPRSVP Fiable SPRTP SIP SMTP

P

Ethernet/metroEthernet/POS/RNIS/ATM…..

23

Norme H323: les composantes

Gwayterminal

mcu

gkeeper


pstn

H320 system Pots phone

Gwayterminal

Terminal

Gatekeepers

Norme H323 composants


Gateways (H.323->H.320/H.324)

Multipoint (MCUs)

Terminal H.323

� Deux Versions

� Réseaux d ’entreprise (très bonne qualité)� Internet (adapté aux faibles débits 28.8 / 33.6 - G.723.1 et H.263)

� Intègre des fonctionnalités « Multipoint »


� Support du Multicast, permettant une conférence à 3 - 4 utilisateurs sans MCU.

Gatekeeper H.323

� Translation d ’Adresse

� Alias H.323 vers adresse IP via le protocole de déclaration du terminal (terminal registration)

� Des noms de type « e.mail » ou « n°Tel. » possibles.

� Admission control


Admission control

� Autorisation d ’établir un appel� Possibilité de fixer une Bande Passante limite Maxi� Méthode pour le contrôle du trafic LAN

Gatekeeper (suite)

� Signalisation d ’appel

� Possibilité de router les appels en fonction de différents critères (sécurité, fourniture de services supplémentaires de type multipoint …)


� Gestion (commande) de la passerelle� H.323/H.320, H.324, etc..

� Gestion des Appels / Status / Journal des Log

Passerelle(Gateway) H.323

� Fournit une interconnexion et interopérabilité entr e WAN et LAN� H.320 (RNIS), H.324 (RTC), …

� Conversion de la signalisation (ex: Q.931 vers H.22 5.0)� Conversion des données de contrôle : (H.242/H.243 v ers H.245)

� Conversion des flux


� Conversion des flux � FEC, tramage, débit, transcodage audio, translation T.123

.

Multipoint (MCU) : MC+MP

� MC - Multipoint Contrôleur est un sous ensemble d ’un MCU classique

supporte la « Logique » pour le contrôle de la conf.� Gestion des appels point à point et multipoints

» Join, invite, contrôle des différents modes de conférences.

� Négociation des capacités différentes (Multi-débits?)

� MP - Multipoint Processeur


� MP - Multipoint Processeur� 2ème sous ensemble du MCU

gère mixage et commutation audio/vidéoex: pour la vidéo commutation automatique à la voix, manuelle ou « présence continue ».

� Applications classiques MCU (planification, sécurité, taxation..)

� Multiprotocole via Gateways

� MC et MP sont des fonctions pouvant résider sur des plates-formes différentes

Norme T.120 ?

� Permet le « Data Conferencing » et le contrôle de la conférence� « Multicast applicatif # multicast réseau ».

� Ne traite pas de la vidéo ni de l ’audio mais coopèr e en harmonie.

� Supportée par plusieurs types de réseaux


� Supporte le multipoint et le point à point.

La pile T.120

� Quel type de Données ?� Photos et Documents (T.126)� Pointeur et annotation (T.126)� Transfert de fichier (T.127)� Partage d ’application PC (T.128)� ...

Quel type de contrôle?


� Quel type de contrôle?� Conférence: définir, participer, modifier, quitter (T.124)� contrôle de la caméra, mic., et autres périphériques(T.130)� Director control, browsing, … (T.130)� Réservations (T.RES)� Ajouter un site, prolonger la durer de la conférence, … (T.RES)

Tabl

eau

Bla

nc

Pho

tos

Doc

umen

ts

Tran

sfer

t Fic

hier

Par

tage

d’A

ppli.

Rés

erva

tions

A/V

Con

trol

Application Protocols

T.126 T.127T

ER

MIN

AL

com

mut

atio

n

T.130 T.128

La pile T.120 (suite)


Application ProtocolsT.126 - Still Image, T.127 - File Transfer

T.128 - App Sharing, T.RES

T.124 - Generic Conference Control

T.123 - Transport Stacks

ISDN POTSVoice/Data

LAN ATM

MC

U T.122 / T.125 - Multipoint Comm. Service

TE

RM

INA

L

Applications:Transfert de fichier binaire

Annotation+transfert d’imagePartage d’application

« Domaine x » (une conférence)

Mécanismes pour notifier tous les participants d’un nouveau participant ou d’un départ:Mecanismes: « join »; « leave », « invite »; « password »

T.125

Tshare

T126

T127

La pile T.120 (suite)


« Domaine x » (une conférence)

Canal « privé » (1 vers 1)

Canal «Canal « broadcastbroadcast » (1 vers n)» (1 vers n)

Mécanismes fournissant une interface commune quelque soit le réseau sous jacent (+ un servicede contrôle d’erreurs et de contrôle de flux)

T.123

T.122

T.125T.124

SocketH221com.drv

RTC IPRNIS

Terminal H.323

RTPRTCP

Interface LAN

IP

TCPUDP

T.123

T.122


Codec AudioG711G722G723G728G729

Codec Vidéo

H261H263

Microphone/H.P Caméra/Moniteur Informatique« Data »

Interface utilisateurpour le contrôleProtocoles « obligatoires »

T.122

T.125T.124

Tshare

T126

T127

InterfaceGatekeeper

RAS

Contrôle de la conf.&sign. d ’appel

Etablissementd'appelH.225

Contrôle

H.245

Contrôle Data Audio Vidéo A/V Cntl Contrôle

H.225 0 H.245 T.120

G.7xx H.26x

RTCP

Norme H.323 Pile de protocoles

Gate-keeper

Reg,Adm,Status


IP

TCP UDP

RTP

Status(RAS)

(1) Ecoutent l ’adresse multicast 224.0.1.41 sur le port udp 1718.

GKs

Première phase d ’un appel « H323 » localisation du GateKeeper

(2)Gatekeeper ReQuest (sur udp)@ip+port RAS type de terminal

(2)

(3) GatekeeperConFirmationnom du GK@+port RAS...

(4)RegistrationRequest vers le GK choisi sur le port udp 1719

même info que GRQ


PictureTelPictureTel

Martin

(2)

(3)même info que GRQ...

(4)(5)RegistrationConFirmation vers le port RAS specifié par le terminal

*@+port h225 pour les messages de contrôles à envoyer vers ce GK*alias par lequel ce terminal sera connu à l ’ext. Du Lan (@E164 ou chaîne..)*identifiant unique attribué pour l ’appel...

(5)

GK

Deuxième phase d ’un appel « H323 » trouver le destinataire

(1)LocalisationReQuest (sur port udp 1719 ou @ 224.0.1.41/1718 )alias du destinataire@ +port pour la reponse

(1)



Martin

(1)

(2)LocalisationResPonse@+port Q931 du dest. (passerelle ou terminal h323)@+port RAS à utiliser

(2)

(2a) GK:“Dupont”->IP adressevia H.323 registration ouservice de nomage externe(DNS,..)(2b)sécurité (filtre..)

GK

Troisième phase d ’un appel « H323 » Demande d ’admission

(1) AdmissionReQuestn°sequence du messagetype d ’appel (pt à pt…)modèle d ’appel (direct ou via GK)identifiant du terminal (celui du « RCF »)@ du dest (E164 ou Ip)@ de la sourceBP bidirectionnelle (ex 2*64K pour appel G711)



(3) AdmissionConFirmationBP maxi alloué@+port Q931 (Gk ou dest.selon routage)

MartinDupont

(1)

GK

(5) ARQ

(6) ACF

Quatrième phase d ’un appel « H323 » Connexion

SETUP (sur @/port tcp 1720 du dest.)capacité de transportbloc d ’info. « user to user »

*@ E164 souce*@E164 dest. canal h245 (@+port)identité de la source (chaîne)type de la source (ex: poste lan)identifiant de la conf.Type d ’appel



PictureTel

MartinDupont

(8) ALERTING (sur @/port tcp 1720 toute les 4s.)

(9) CONNECTref. de l ’appelcapacité transportdate/heurebloc d ’info.« user to user »

(4) SETUP

(7) CALL PROCESSING@/port contrôle d ’appel h245


PictureTel

MartinDupont

Cinquième phase d ’un appel « H323 » Connexion H245

(9) connexion H.245Capacités du terminal

type de codage video/audioparamêtres T120

Capacités du terminalOK


Celui qui devient maître, assurera la fonction multipoint pour la configuration.

Capacités du terminalOKDeterminationMaître/EsclaveDeterminationMaître/EsclaveOKOuvrirCanalLogique

@/port RTPet RTCP pour le flux audio/videoOuvrirCanalLogiqueOk

@/port RTPet RTCP pour le flux audio/video

GK

(10) ARQInviteAhmed (11) ACF

Ahmed->@IP

Martin invite Ahmed

(13) ARQdois je accepter?

(14) ACFOui



PictureTel

Ahmed

(12) SETUP

(15) ALERTING(16) CONNECT

(17) CONNECTION H245Martin


PictureTel

MartinDupont

Sixième phase d ’un appel « H323 » Libération

(9) libération H.245FermerCanalLogiqueFermerCanalLogiqueOKFinSessionCommandeFinSessionCommandeOK


FinSessionCommandeOK

GK

H323 et les services « intelligents »

PictureTel

�Transfert aveugle

�Le routage au travers de un ou plusieurs garde barr ierespermet d ’envisager des services de type réseau inte lligent dans le contexte de la téléphonie sur Ip



PictureTel

AhmedMartin

Dupont

(1) FacilityCallTransfert (ds le champ FacilityReason)

CallTransfertInvoke (informant Martin de l ’@ de Dup ont)

(2)Close

(3)RLC

GK


PictureTel

Dupont

�Transfert sûr



PictureTel

AhmedMartin

(1) FacilityCallTransfert (ds le champ FacilityReason)

CallTransfertInvoke (informant Martin de l ’@ de D)

(4)FacilityCallTransfertResult=success ou failure

(6)RLC

(5)CLOSE


PictureTel

secrétaire

�Transfert avec consultation



PictureTel

AhmedMartin

(6) Setup

H.323 (suite)

� Cryptage, authentification, sécurité.

� MCU en Cascade (protocole de mise en cascade => « sca lability »

� Définition de MIB pour les différentes entités H.32 3

H323 M (Mobility)


� H323 M (Mobility)� ….

Protocole SIP (Session Initiation/Invitation Protocol):Principales caractéristiques

� Protocol « dominant » (sipforum, 3GPP, Voipforum).� 1996: Combinaison de 2 protocoles existants: Sessio n Invitation

Protocol[Handley/Schooler] et Simple Conf. Invitat ion Protocol[Schulzrinne]� Pour l ’établissement de session « téléphoniques » et non téléphoniques

(multimédia) : « services télécom + »� VoIP, IM, data conferencing...

� 1999: Défini par MMUSIC (1999) RFC 2543 � Aujourd’hui: RFC 3261-3266 (IETF SIP WG): 150 RFC et 500 Draft (actifs)� Protocole de signalisation client/serveur, de nivea u 7.� Point à point ou multiutilisateurs (multipoints).

Téléphonie sur IP 60�60

� Point à point ou multiutilisateurs (multipoints).� Protocole orienté Internet:

� S’inspire de Smtp 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, « SCTP » (couche « non-fiable »)� TLS/TCP, IPSec (couche « fiable »): Pb délai d’établissement de session car mécanismes « hop by hop ».

� Mécanisme d'Adressage de type URI + Localisation � Protocole orienté Transactions:

� un dialogue (session) SIP: séquence de « requête/reponse »

� Permet de garder un nombre minimal d’états (info) a u niveau des proxys. (« scalabilité »)

Protocole SIP (Session Initiation/Invitation Protocol):Principales caractéristiques

� Une architecture simplifiée au maximum (réseau de s erveurs).

� La possibilité de localiser simplement des terminau x (usagers).

� La possibilité de déterminer la disponibilité des p articipants

(accessibilité).

� La possibilité de déterminer la capacité ou des paramètres des

terminaux.


terminaux.

� La gestion de l'établissement et le contrôle de la session.

� L'association possible avec des mécanismes ad-hoc d e réservation de

ressources réseaux (QoS)

� Appels simultanés sur plusieurs terminaux (« forkin g ») et la détection

de boucle réseaux, garantissant une certaine mobili té (nomadisme) pour

l'utilisateur .

Cohabitation des protocoles « IP »

UDP TCPTransport

RTP TCAP

JMF

INAPSIP

JAIN «call control»

Application

(Services)

Services (Applications)

ISUP

Flux ( Audio /Video ) Flux (Signalisation )

JAIN «SIP»

RTCP

(Services)

STCPTLS


UDP TCP

IP, DiffServ, IntServ

Cuivre /Fibre Optique….

Réseau

Liaison

Physique

SDH/WDM/DWDM

MPLS

ATMEthernet HDLC/PPP

GMPLS (QoS

)Transmission

STCPTLS

IP

Serveur

Redirect /Proxy

Serveur

Localisation

ServeurRegistrar

Passerelle SIP

SIP UA

Passerelle SIP

SIP UA

RTC

Mobile

Entité Administrative:(Serveur SIP du réseau local)

Protocole SIP: Architecture

SIP


Passerelle SIP

SIP UA

Terminal SIP

SIP UA

Terminal SIP

SIP UA

Terminal SIP

Agent Utilisateur (AU) SIP

SIP UA

H.323

Réseau « IP »

SIP

Serveur de média SIP

SIP UA

Entités et Flux d’appel SIP (exemple)UAC Appelant UAS AppeléServeurSIP

ServeurSIP

INVITE (Cseq1 INVITE) INVITE (Cseq1 INVITE) INVITE (Cseq1 INVITE)

180 Ringing (Cseq1 INVITE) 180 Ringing (Cseq1 INVITE)

200 OK (Cseq1 INVITE) 200 OK (Cseq1 INVITE)200 OK (Cseq1 INVITE)

180 Ringing (Cseq1.)

-Localization-Registration-Redirection…...

Transaction 1

EtablissementCancel (Cseq1 INVITE)

100 Trying (Cseq1 INVITE)


ACK ( Cseq1 ACK)

ACK(Cseq1 ACK) ACK(Cseq1 ACK)ou

Flux MEDIA (ex. Audio)

ACK(Cseq1 ACK)

Remarque : canal (port) de signalisation distinct et non li é au canal (port) de transport du flux

200 OK (Cseq2 BYE)

BYE(Cseq2 BYE)

Transaction 2

Transaction 3Libération

DialogueSIP

Cancel

BYE(Cseq2 BYE)

200 OK (Cseq2 BYE)

Communication

Adresse SIP

� SIP exploite des formats d’adresses de type e-mail : sip: user/service_Id@domaine/host_name� Adresse logique indépendante de l’@ « physique » (IP)� Identifie un utilisateur (user_Id peut être un individu, un groupe) ou un service

(service Id) � Identifie l’adresse de contact (nom DNS, adresse IP…)

� Différents formes possibles


� Différents formes possibles� Sip:domain (réf. à un domaine SIP) sip:TL1.eu ou sip:193.48.251.12� Sip:user@domain (réf. à numéro d’appel, AoR) ,sip:[email protected]� Sip:user@host, (réf. À un contact), sip:[email protected] ou

[email protected]� Sip:service@IP_adress (réf. à un service),[email protected]� phone-number@gateway (réf. À une passerelle),

[email protected]

��Mécanisme de résolution des adresses (ex. DNS)

Les URI SIP

� Utilisé dans les requêtes (entêtes: From, To, Conta ct)� Intégration dans des pages HTML, emails

(nom de l’utilisateur:mot de passe) ou(numéro téléphone, si user=phone)

sip ou sips: infos_utilisateur @ host ;paramètres ?en-têtes

infos_utilisateur

host nom de domaine ou nom d’hôte ou adresse IP: port


Exemples : sip:[email protected]; ;transport=udp; user=IP;q=0.8

[email protected] -> sip:[email protected];user=phone;q=0.8sip:[email protected];msgid=78;q=0.1

paramètres

en-têtes

;transport=udp ou tcp;user=phone ou IP;method=INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER;ttl=0 à 255 (time-to-live d’un paquet IP multicast);maddr=adresse IP multicast;tag=compteur

? par1=valeur1 & par2=valeur2 & par3=valeur3...

Entités principales d’une architecture SIP1

(Session Invitation/Initiation Protocol)

� Agent Utilisateur Client et Serveur� Points terminaux capables d’émettre (Uac) ou de recevoir (Uas) des requêtes

SIP (pour traitement et réponses)� Terminaux SIP (Uas+Uac)

» Terminaux VoIP, pont de conférence, contrôleur SIP (« B2Bua »)…� Terminaux SIP (UAs)

» enregistreur de message (« voice mail »), serveur vidéo à la demande, ...

� Serveur proxy


� Serveur 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

» Stateless (« scalabilité », robustesse aux « attaques »),• Conserve un minimum d ’états relatif à l’appel

» Statefull (« Firewall »)• Conserve un maximum d’états relatif à l’appel

Entités d’une architecture SIP2

� Serveur 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


� Serveur 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 SIP3

� 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 SIP

» Capable de terminer ou initier la session (ex. carte prépayée; pont de conférence…)

� Contrôleur de sessions SIP» Carte pré-payée, pont de conférence, « click to dial »


» Carte pré-payée, pont de conférence, « click to dial »

PROXYUA UA

Dialogue XDialogue X

B2BUA UA

Dialogue XDialogue y

Message SIP RFC 822 (idem HTTP) : Ex. requête sip

En-tête de message: Info. Utilisateur-Rés.Ligne de début

(méthode URL SIP/2.0)

INVITE sip:[email protected] SIP/2.0Via:SIP/2.0/UDP durer.enic.frFrom:Ahmed<sip:[email protected]>To:Pascal<sip:[email protected]>Call-ID: [email protected]:1 INVITEContact::<sip:[email protected]>Content-Type:application/SDPContent -Lengh:..

méthode URL SIP/2.0

Via:From:To:Call-ID:Cseq:Content-LengthContent -Type:

SIP/2.0/protocole hôte:portusername <sip:from_user@source>username <sip:to_user@destination>localid@hôtenuméro_seq méthodelongueur du corpstype de média du corps


corps de message: information utilisateur-utilisate ur(ex.format SDP)

Content -Lengh:..

v=0o=ffl 53655765 536..5 IN IP4 123.4.5.6s=nom de la sessionP=+33 3 20 33 55 65c=IN IP4 durer.enic.frm=audio 5004 RTP/AVP 0 3 5

Content -Type:Champ:

type de média du corpsparamètre ;par1=valeur; par2= valeur

ligne vide

V=0o= user_origine timestamp timestamp IN IP4 hôtec=IN IP4 média adresse_destinationt=0 0m= type_média port RTP/AVP types_payload

Réponse SIP : Ex. de réponse sip

Type réponse en-têtemessage

Via:From:To:Call-ID:Cseq:Content-LengthContent-Type:Champ:

SIP/2.0/protocole hôte:portusername <sip:from_user@source>username <sip:to_user@destination>localid@hôtenuméro_seq méthodelongueur du corpstype de média du corpsparamètre ;par1=valeur; par2= valeur

SIP/2.0 status reason-phraseSIP/2.0 200 OKVia:SIP/2.0/UDP sip-proxy.int.frVia:SIP/2.0/UDP ahmed.enic.frFrom:meddahi<sip:[email protected]>To:Pascal<sip:[email protected]> :tag=2544Call-ID: [email protected]:1 INVITEContent-Type:application/SDPContent -Lengh:..


corpsmessage

Champ: paramètre ;par1=valeur; par2= valeur

ligne vide

V=0o= user_origine timestamp timestamp IN IP4 hôtec=IN IP4 média adresse_destinationt=0 0m= type_média port RTP/AVP types_payload

Content -Lengh:..

v=0o=pascal 4858949 48..9 IN IP4 198.7.6.5s=Okc=IN IP4 goujon.int.frm=audio 5004 RTP/AVP 0 3

Principaux champs d’entêtes

� TO: URL-SIP de la destination

� From : URL-SIP de la source

� Call-ID : identifiant de session (vers.simple local-id@host)

� Maxforward : nombre max de sauts pour traiter le message

� Cseq(Command Sequence) : Numéro de transaction dans la session + méthode

� Via: route empruntée par un message jusqu’à ce noeud


� 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, applic ation/xml, texte/plain

…)

� ...

Session Description Protocol

� SIP utilise le protocole SDP (session description p rotocol, RFC 2237)

� SDP est employ é pour d éfinir les attributs d ’une session SIP avec une

syntaxe standard.

� Les param ètres SDP sont plac és dans le corps d ’une requête SIP

Les entêtes SDP sont encod ées en format text et sont de la forme


� Les entêtes SDP 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

v= Version Protocole

b*= info. Bande passante

s= nom de la sessioni*= info. Sur la sessionu*= url contenant descriptione*= @ emailp*= numéro de tel.

o= créateur/propriétaire & Id session

c*= info. Sur la connexion

Description de la session

Format SDP <type>=<valeur>Description


b*= info. Bande passantez*= fuseau horaire k*= clef de crytpo.a*= attributs de sessiont= durée de sessionr*= occurrence de la sessionm= media & @ transport

k*= clef de crypto.

i*= nom du media

b*= info. Bande passantec*= info. connexion

a*= une ou plusieurs lignes attributs media

Description « temporel »

Description « réseau »

UAC A UAS B

INVITE (offre = Capacités A)

180 Ringing (réponse = Capacités AnB)

200 OK PRACK

PRACK

Réseaux «circuits»: QoS statique Réseaux « IP »:QoS «aléatoire» (impact sur le «call f low»)


UPDATE (offre = Capacités A’)

Re-INVITE (offre = Capacités A”)

200 OK Re-INVITE (réponse = Capacités A”nB”)

200 OK UPDATE (réponse = Capacités A’nB’)

200 OK INVITE

ACK INVITE

Modèle offre/réponse SIP

v=0o=gilles 53655765536 IN IP4 durer.tl1.frs=appel SIPt=0 0c=IN IP4 193.48.251.6m=audio 5623 RTP/AVP 0 8 3 98 101a=rtpmap:0 pcmu/8000a=rtpmap:8 pcma/8000a=rtpmap:3 gsm/8000a=rtpmap:98 iLBC/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15m=video 6325 RTP/AVP 31a=rtpmap:31 H261/90000

v=0o=ahmed 459888877785 IN IP4 rodin.tl1.frs=appel SIPt=0 0c=IN IP4 193.48.251.9m=audio 8312 RTP/AVP 0 3 98 97a=rtpmap:0 pcmu/8000a=rtpmap:3 gsm/8000a=rtpmap:98 iLBC/8000a=rtpmap:97 speex/8000m=video 0 RTP/AVP 31

INVITE


a=rtpmap:31 H261/90000

200 OK

Résultat de la configuration des flux

Audio:codec: pcmu/8000

Pas de vidéo

:5623 :8312

[email protected]

[email protected]

Messages Requêtes:INVITEACKBYECANCEL OPTIONREGISTER

Messages Réponses: codeInformational 1xxSuccess 2xxRedirection 3xxClient Error 4xxServer Error 5xxGlobal Failure 6xx

Principaux messages SIP :


REGISTER…..

Global Failure 6xx…..

En-tête de message (générale):call-IDContactDateFromToVia...

Corps d’en-tête :Content-Encod.Content-LengthContent-type….

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 SDP: type de média audio, vidéo, data, format, codage en vigueur)

Méthode ACK


� 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

Méthodes de requête (suite)

� Méthode REGISTER

� 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


� L’agent utilisateur est également responsable du rafraîchissement de la liaison

� Méthode OPTIONS

� 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

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


� indique à l’autre participant la clôture de la session

� Autres méthodes (pour le support de services évolués)

� PRACK (RFC3262)

� MESSAGE, PUBLISH,SUBSCRIBE & NOTIFY (RFC3265) - Service de présence (ex. pour les appli. de messagerie instantanée: MSN)

» 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 MESSAGES (SIP sur UDP)

Statut (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)


� 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

Serveur

Redirect /Proxy

Serveur

Localisation

ServeurRegistrar

Entité Administrative:[email protected] (Serveur SIP du domaine « tl1.fr »)

REGISTER sip:tl1.fr SIP/2.0

To: sip:[email protected]

From: sip:[email protected]

Contact:1 sip:[email protected]

Contact2:sip:[email protected]…

1

Protocole SIP : processus d’enregistrement


BD

183.48.251.107

183.48.251.108

1

sip:[email protected]

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

2Enregistrement des info. de localisationdans la Base de Données

SIP/2.0 200 OKExpires: 3600…

3

tl1.frtl1.fr

pasc

alpa

scal

Pas

cal@

term

2.tl2

.frP

asca

l@te

rm2.

tl2.fr

3

INVITEINVITE

tl2.frtl2.fr

INVITE sip:[email protected] SIP/2.0

To: sip:[email protected]

From: sip:[email protected];tag=4711

Contact: sip:[email protected]

INVITEINVITE

Appel SIP en mode Proxy

DNSServeur de Localisation


term1

[email protected]@tl1.fr

term1.tl1.frterm1.tl1.fr

Sipproxy

term2Pas

cal@

term

2.tl2

.frP

asca

l@te

rm2.

tl2.fr

[email protected]

[email protected]

[email protected]@term2.tl2.fr5

200 OK200 OK200 OK200 OK

ACKACK [email protected]

[email protected]

[email protected]

[email protected]

Flux média (ex. audio)

1

7

8

2

4

6

9

tl2.frtl2.fr

[email protected]@tl1.fr

tl1.frtl1.fr

INVITE [email protected] [email protected]

pasc

alpa

scal

Pas

cal@

tl3.fr

Pas

cal@

tl3.fr

SIP/2.0 302 Moved temporarilySIP/2.0 302 Moved temporarily

Appel SIP en mode Redirection

Serveur de

Localisation

1 2

3


term1.tl1.frterm1.tl1.fr

Proxy du domaine tl3.frProxy du domaine tl3.fr

[email protected]@term2.tl3.fr

Pas

cal@

tl3.fr

Pas

cal@

tl3.fr

SIP/2.0 302 Moved temporarilyContact : [email protected]/2.0 302 Moved temporarilyContact : [email protected]

INVITE [email protected] [email protected]

200 OK200 OK

ACKACK

ACKACK

Serveur en mode

« Redirect »4

6

7

8

5

1. Refer

A B

Flux d’appel SIP pour le transfert d’appel

0. Flux média (ex: audio)

2. Accepted

3a. Notify

3c. 200 OK 3b. Invite

�C


3c. 200 OK 3b. Invite

4a. 200 OK4b. Notify

4c. 200 OK

1. Invite(No SDP) 3. Invite

(SDP A)2. Ok(SDP A)

4. Ok(SDP B)

A« Client »

B« fournisseur»

Média RTP (flux audio)


Serveur web:(Technologies:

SIP Servlet ou SIP CGI, ou API JAIN…)

sip « B2Bua »0. HTTP

(SDP A)

5. Ack(SDP B) 5. Ack

�Flux d’appel «Click to Dial »

Service « audioconf. » (utilisation du sip « B2Bua »)

AB

Mixer audio

c

Media RTPAudio ->A<- B+C

Media RTPAudio ->A+C<- B

Media RTPAudio ->A+B<- C

MCU:Pont audioconférence



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


1.PC Administrateur de la conf: « création, activation , joindre, quitter, inviter… »

0. HTTPServeur web (SIP Servlet, SIP CGI,

API JAIN…)[email protected]

sip «B2Bua»(Focus)

1

10116

5

Flux d’appel « nomadisme »

Serveur SIP

TL2


[email protected]@TL1.fr

INTERNETINTERNET BACKBONEBACKBONE

1014

28

12

13397

4

15

16

Serveur SIP

TL3

Scénario: description (suite)

� Ahmed est potentiellement joignable sur trois sites: TL2 (bureau) et TL3 (bureau et labo.)

� Ahmed publie un seul identifiant d’appel: [email protected]� Ahmed est en déplacement à TL3 et enregistre sur le serveur SIP de TL2

l’adresse [email protected] (1)


� Il enregistre aussi sur le serveur de TL3, ses deux adresses de contact (2, 3)» [email protected], [email protected]

� Ahmed « oublie » de supprimer un précédent renvoie d’appel qu’il avait effectué sur son poste du labo à TL3.


�[email protected] appel [email protected] (4) (résolution DNS = Serveur SIP TL2)

�Le serveur SIP de TL2 localise l’adresse courante de Ahmed (5) et retransmet donc l’appel à [email protected] (6)

�Le Service SIP de TL3 détermine qu’il existe deux adresses possibles (7) et diffuse l’appel (i.e « fork ») vers celles-ci (8,9)


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 SIP de TL2, qui détecte une boucle et retourne un message d’erreur (10,11)

�L’erreur est propagée par le poste au serveur SIP de TL3(12)�Dans le même temps, Ahmed a répondu à l’appel depuis son

bureau (13)


�Le serveur SIP de TL3 a maintenant les deux réponses et peut retourné l’acceptation de l’appel au Serveur SIP de TL2 (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


liés à l’appel. Ahmed et Gilles communiquent directement (flux média) sans passer par les serveurs intermédiaires (16)

� Caractéristiques de SIP mises en évidence par ce scénario� Forking� Mobilité/nomadisme (utilisateur)� Détection de boucle

SIP et « IMPP » (Présentité et messagerie instantanée)

� Sensibilité au contexte du terminal/utilisateur:

» Localisation, disponibilité, « humeur » de l’utilisateur� Permettre le support des applications classiques ma is aussi nouvelles:

» Transfert d’appels, suivie d’appels… (classique)

» messagerie instantanée, applications basées localisation.

� Modèle IMPP:


200 OKEvent:presenceExpires:1800

PUBLISHEvent:presenceExpires:3600Accept: text/plainContent-Type:application/XML….

200 OKEvent:presenceExpires:1800

Serveur de présencePA serveur

SIP « Watcher » UAPDA

SUBSCRIBE (pres:[email protected])Event:presenceExpires:3600Accept: text/plain…. NOTIFY

Event:presenceExpires:1759Subscr -State:active

SIP Presence UA

SIP et IMPP:


MESSAGEAccept: text/plainContent-Type:text/plainContent-Lengh:29« Bonjour ça va comme tu veux »

Expires:1800

NOTIFYEvent:presenceExpires:1759Subscr-State:active….

200 OK

200 OK

202 ACCEPTEDEvent:presence

Expires:1759Subscr -State:activeSip:[email protected]….

NOTIFYEvent:presenceSubscr-State:pending

<presence ... entity=" pres:[email protected] ">

<tuple id=" mobile-im ">

<status>

<basic> open </basic>

</status>

<contact priority="0.8"> im:[email protected] </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> 2005-01-14T10:49:29Z </timestamp>

</tuple>

Données de présence au format PIDF: Pres. info. Dat a Format (XML)


</tuple>

<tuple id=" interactive-mm ">

<status>

<basic> closed </basic>

</status>

<contact priority="1.0"> sip:[email protected] </contact>

</tuple>

<note> je suis en déplacement cette semaine </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 MESSAGES (SIP sur UDP)

SIP et la QoS (plusieurs constats)

� Qualité « best effort » pas suffisant pour la VoIP

� Nécessité de supporter des mécanismes de réservation de ressources dans

SIP

� pour assurer une QoS (BP, Délai, perte minimale)

� Sécurité des canaux ou flux média

» Empêcher la fraude ou le vol de service


» Empêcher la fraude ou le vol de service

� Etablir la connexion uniquement si des pré-conditions sont remplies (sécurité,

QoS …)

� Le appels ne sont pas facturés si ressources réseau non suffisantes

� Faire sonner l’appelant uniquement si QoS

� Appel en mode dégradé: ex. en utilisant des codecs bas débit ou

uniquement l’audio (sans la vidéo)

Réseau IPIntra-

Domaine

SIPUaC

SIPUaS

Liaison de bout en bout

Réseau IPIntra-

Domaine

Réseau IPInter-Domaine

avec « QdS»

RouteurR1

RouteurR2


Domaineavec «QdS»

-Segment UaC-R 1 -Segment R 1-R 2 -Segment R 2-UaS

Domaineavec «QdS»

avec « QdS»

INVITEPréconditions

SIP UAS

SIP et la QoS (RFC 3312):

SIP UAC

QoS Cur. Des.

snd x \/

rcv x \/QoS Cur. Des.

snd x \/

rcv x \/183 Session ProgressPréconditionsconfirmation request

PRACK

m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 a=curr:qos e2e none a=curr:qos e2e none a=curr:qos e2e none a=curr:qos e2e none a=des:qos mandatory e2e sendrecva=des:qos mandatory e2e sendrecva=des:qos mandatory e2e sendrecva=des:qos mandatory e2e sendrecv

m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 a=curr:qos e2e none a=curr:qos e2e none a=curr:qos e2e none a=curr:qos e2e none a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=conf:qos e2e recv a=conf:qos e2e recv a=conf:qos e2e recv a=conf:qos e2e recv


200 OK (PRACK)

Réservation ressources (QoS)

UPDATEPréconditionsconfirmation response

200 OK (UPDATE)Préconditions

RINGING

QoS Cur. Des.

snd \/ \/

rcv x \/QoS Cur. Des.

snd \/ \/

rcv x \/

QoS Cur. Des.

snd \/ \/

rcv \/ \/

QoS Cur. Des.

snd \/ \/

rcv \/ \/

m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 m=audio 20000 RTP/AVP 0 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1 a=curr:qos e2e send a=curr:qos e2e send a=curr:qos e2e send a=curr:qos e2e send a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv

m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv a=curr:qos e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv a=des:qos mandatory e2e sendrecv

v=0o=jo 7849 2873246 IN IP4 ruin.inf…s=SIP callt=0 0c=IN IP4 134.102.218.1m=audio 52392 RTP/AVP 98 99a=rtpmap:98 L8/8000a=rtpmap:99 L16/8000a=curr:qos e2e nonea=des:qos mandatory e2e sendrecv

v=0o=cabo 2552 892834 IN IP4 dmn.inf…s=SIP callt=0 0c=IN IP4 134.102.218.46m=audio 50239 RTP/AVP 98 99a=rtpmap:98 L8/8000a=rtpmap:99 L16/8000a=curr:qos e2e nonea=des:qos mandatory e2e sendrecv

Exemple de négociation de QoS:

Requête (corps SDP) Réponse (corps SDP)


a=des:qos mandatory e2e sendrecvm=video 59485 RTP/AVP 31a=rtpmap:31 H261/90000a=curr:qos local senda=curr:qos remote nonea=des:qos optional local sendrecva=des:qos optional remote sendrecv

a=des:qos mandatory e2e sendrecva=conf:qos e2e recvm=video 56112 RTP/AVP 31a=rtpmap:31 H261/90000a=curr:qos local nonea=curr:qos remote senda=des:qos failure local sendrecva=des:qos optional remote sendrecv

Confirmation demandée (confirmation request)

Autre type de précondition:« sec » : pour sécurité: avant alerte, flux media (e x. voix) protégé

-négociation d’un algorithme de crypto.« conn »: pour connectivité: avant alerte, flux médi a passe dans les deux sens

-négociation d’un mécanisme pour traverser les fire wall ou les serveurs NAT.

Le protocole SIP 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 email, messagerie instantanée, page web…

� Gestion des capacités


� 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

Ce que SIP 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:


conjointement:

� RTP (pour le transfert du flux média: audio ou vidéo)

� RTSP (pour le transfert du flux en mode « streaming »)

� SDP (pour la description de la session)

� MEGACO/H.248 (pour le contrôle de passerelles)

� Diffserv/Intserv (pour la QoS)

� Exploitation à « plus ou moins » haut niveau des protocoles réseaux

� Faire « abstraction » des technologies réseaux , au niveau applicatif.

� Différentes approches (API):

� SIP Servlets:

L’API SIP Servlet est une API de haut niveau, qui a été définie pour le développement d’applications destinées à étre exécutées sur des s erveurs (SIP). Elle est basée sur le concept ou modèle des "‘servlet"’ HTTP, pour le dép loiement et la gestion d’applications ou de services orientées client-serveur. Le principe d es servlet est similaire au concept des "‘CGI"’. Néanmoins et contrairement à un "‘CGI"’, q ui peut être vu comme un processus séparé, la servlet fait partie du même processus qu e le serveur qui reçoit les requêtes

Développement de services Telecom (SIP)


séparé, la servlet fait partie du même processus qu e le serveur qui reçoit les requêtes "‘clientes"’. Dans le cas d’une servlet, les messag es ou événements sont simplement passés à une classe JAVA, s’exécutant sur la machin e virtuel (JVM, Java Virtual Machine).

� SIP CGI

Comme pour les CGI HTTP, un CGI SIP "‘tourne"’ sur le serveur et transmet les requêtes et paramètres à un processus "‘externe"’ à travers des variables d’environnement. Le processus renvoie en retour les réponses au serveur à travers la sortie standard (fichier). Les CGI SIP sont quasiment identiques au CGI HTTP a vec la particularité qu’ils sont adaptés à la création de services orientés WEB (services co ntenant des composants WEB). Un script CGI peut être implanté dans différents langages tel s que : C++, Tcl, Perl ou encore JAVA, et être accessible à une large communauté de développe urs.Les spécifications complètes concernant les scripts CGI sont disponibles en particulier sur le sîte de l’IETF : RFC 3050

� SIP CPL (Call processing language) CPL a été la première API développée pour SIP. CPl n’est pas vraiment une API mais définie un langage de script, dont la syntaxe s’appuie sur les spécifications XML. CPL permet de décrire et contrôler des services orientés traiteme nt d’appels. Les caractéristiques du langage CPL sont simplicité, fléxibilité (possibili tés d’extensions), éditable à partir d’interface graphique et portabilité (indépendant d u système d’exploitation ou encore du protocole de signalisation). CPL permet de créer de s services utilisateurs : un interpréteur CPL correspond à un processus "‘légé"’et un script CPL peut être rapidement interprété et exécuté par le serveur. un script CPL ne contient p as d’éléments de type : variables, boucles ou encore n’est pas capable d’exécuter des programm es externes. Pour Cela CPL permet de garantir au niveau du serveur une certaine étanchéi té vis à vis des processus ou programmes exécutés du côté "‘client"’. Les spécifi cations du langage CPl sont définis en

� Développement de services Telecom (SIP)


programmes exécutés du côté "‘client"’. Les spécifi cations du langage CPl sont définis en particulier dans la RFC IETF 3380.

< ?xml version="1.0" encoding="UTF-8" ?> <cpl xmlns="urn :ietf :params :xml :ns :cpl"

xmlns :xsi="http ://www.w3.org/2001/XMLSchema-instance" xsi :schemaLocation="urn :ietf :params

:xml :ns :cpl cpl.xsd "> <incoming> <location url="sip :[email protected]">

<redirect/> </location> </incoming> </cpl>

� JAIN API (SUN) Les API JAIN (Java Api for Integrated/Intelligent N etworks) sont une extension au standard JAVA. Ils fournissent un certain niveau d’abstracti on des couches "‘réseaux"’ à travers une série d’interfaces JAVA ouvertes et de "‘haut nivea ux"’, pour la création de services supportés à la fois par les réseaux "‘circuits"’ et "‘paquets"’ IP (favorise la convergence, interopérabilité des réseaux)

Modèle de création de services SIP

REFER

IMCall control

MESSAG

SUBSC.

NOTIFy

PUBLIS

Telephonie 3G …..

PRACk

SeSSti

m

OVERLA

SECURIT

.

.

.

.

UPDATE

SIP

Services

SIP

(Applications)

API

API

INVITE

ExtensionsSIP

……..


R

Pile SIP

UDP TCP,SCTP, TLS

IP/IP Multicast/QoS

Ge

C.y

Sh

mer

Ap

Té

ES

IPE

Services télécoms: Services JAVA API (Source: java.sun.com/products/jain/)

Couche signalisation

« N ’importe quel service sur n ’importe quel réseau » �� PORTABILITE

Environnement de création de services (SCE)

Portabilité du service: « Write Once, Run Anywhere ».Indépendance/réseau: « Any Network ».Système/développement ouvert: « By Anyone »


Couche Réseau

YX Z

Plate-forme services

Services télécoms: Services JAVA API


– JAIN TCAP – Java Call Control–JAIN MGCP– JAIN SIP– JAIN INAP– JAIN MEGACO– JAIN SIP Lite– JAIN SDP

Services télécoms: « Services JAVA API »

Ex. JAIN: « Java Api for IN »; OSS: « Operations Support Systems »


– JAIN SDP– JAIN ENUM– JAIN Presence– JAIN Instant Messaging– JAIN SIMPLE (Presence +IM)– OSS/QoS– OSS/Billing…...

Source: java.sun.com/products/jain/

Exemples de « traces » H323/SIP


Format message de signalisation H.323 (éléments d’info. de type «user-user » d ’un message Q931)

� Les éléments d'informations sont en format TLV (Typ e/Longueur/Valeur)

� Type» fonction de

l'élément d'information

� Longueur» de la partie

variable

Type d’élément d’info. Type d’élément d’info. («(« useruser--useruser »)»)

longueurlongueur

Type de message (ex. « ALERTING »)


variable

� Valeur (longueur variable)» peut contenir

des éléments d'informationsimbriqués

Valeur(corps du message « H.323 »

codé en ASN.1)

� ASN.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 ASN.1

» outil d ’encodage (ex. BER: Basic Encoding Rule, PER : Packet Encoding Rule)

Trace H323: ASN1 (Abstract Syntax Notation 1)


� Cette notation fournit un certain nombre de types de base prédéfinis tel que:

• integers ( INTEGER),

• booleans ( BOOLEAN),

• character strings ( IA5String, UniversalString...),

• bit strings ( BIT STRING),

• etc.,

Trace H323 (suite) ASN.1 (Abstract Syntax Notation 1)


• il permet également la définition de type plus complexe

• structures ( SEQUENCE),

• lists ( SEQUENCE OF),

• choice between types ( CHOICE),

• etc.

H323-MESSAGES DEFINITIONS AUTOMATIC TAGS ::=

BEGIN

H323-UserInformation ::= SEQUENCE --root for all Q.931 related ASN.1

{

h323-uu-pdu H323-UU-PDU,

user-data SEQUENCE

{

protocol - discriminator INTEGER

suiteH323-UU-PDU ::= SEQUENCE{h323-message-body CHOICE

{setup Setup-UUIE,callProceeding CallProceeding-UUIE,connect Connect-UUIE,alerting Alerting-UUIE,}

Trace H323 (suite): Exemple de message ASN.1 (H323/H225)


protocol - discriminator INTEGER (0..255),

user-information OCTET STRING (SIZE(1..131)),

...

} OPTIONAL,

...

}.

.

.

.

}nonStandardData NonStandardParameter

OPTIONAL,...}Setup-UUIE ::= SEQUENCE

{…activeMC BOOLEAN,...}

}

END

Trace de message H323/H225 (ASN.1)








Trace de message SIP (texte)


Trace de message SIP (texte)


Remarques sur SIP (et H323)� SIP (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 pr euves

• adopté par les industriels

� SIP (IETF)

1.5 aller-retour

Simple (format «texte»)

protocole ouvert

distribuée

Remarques sur SIP (et H323): suite

� H323 (ITU-T)

6 à 7 aller-retour

Complexe (compilateur)

ajout d ’extensions propriétaires

Nbre d'échangespour établir la com.

Maintenance du code

Evolution


distribuée

supporté

supporté

supporté

Centralisée avec le MCU

H323 V2+H.450

non supporté dans la V1

non supporté

Conférence

Services

Detection boucle

Multicast

www.sipcenter.com et www.openh323.org


Eléments critiques (signalisation et flux)

LAN

pre-selection delay

0

0,5

1

1,5

2

2,5

3

S11 S2( no TRYING ) S 3

ScenarioDe

lay

(se

c.)

LAN802.11bCable ModemModem 56 Kbs

post-selection delay

0

5

10

15

20

25

30

S1 S2 S3ScenarioD

ela

y (s

ec.

)


1S :1 SIP Proxy S :1 SIP Proxy (Redirect)


Connection delay

0

5

10

15

20

25

30

35

40

S1 S2 S3ScenarioD

ela

y (s

ec.

)


ITU-t rec (E.721)Circuit network (normal load)

post-selection delay average 95%

3 sec. 6sec.

8 sec. 11sec.“International” 1 call1 8-10 nodes

“Local” 1 call11-4 nodes

“Regional” 1 call15-7 nodes

5 sec. 8sec.

1S1:1 SIP Proxy S2:1 SIP Proxy (Redirect)S3:2 SIP Proxys

Performance du flux RTP

Delay(ms) 13.5 - 490

0.5 - 20Jitter(ms)

Loss (%) 0 - 9

150

20

5

Measures1

(G.711)

ITU-t2 rec.


Loss (%) 0 - 9 5

1TERENA Networking Conference 2004(Trans-European Research & Education Network).

2ITU-T G.113 and G.114 rec. for a G.711 audio codec (w. PLC, w. controlled echo ).

1

Client H323

Télé maintenanceCommerce électronique...2

Architecture: (intégration téléphonie et Web)


Pabx

Serveur WEB


Rq: si @IP dynamique(DHCP) utilisation de serveurs d ’ annuaire

Rq: Pbs Firewalls Retard supplémentaire dû à l ’analyse des paquets+h323 utilise des ports udp établis de manière dynamique.

Réseau Internet

Client reçoit sur le port 5060

Envoie d’une requête STUN à partir du port 5060

Serveur STUN reçoit un paquet de 193.48.251.77 port 56540

Serveur STUN (Simple Traversal of UDP Through NATs, RFC 3489)

�Permet aux clients de decouvrir la presence d’un NA T, adresse etport publics à utiliser.

�Protocole leger (“simple”), implementation aisée, c onsomme peu de ressources CPU.


ClientIP: 10.0.0.1Port: 5060

IP: 193.48.251.77Port: 56540 STUN Server

Port: 3478

NAT

Serveur STUN envoie la reponse au client, avec adresse et port public: 193.48.251.77

et 56540

STUN et SIP “Register”

�Utilisation du port 5060 pour envoyer une requête a u serveur STUN

�Réception des adresses et ports publics associés au client: du serveur STUN vers port 5060

�Utilisation du message SIP register avec adresse et port publics du client,envoyés au serveur proxy.


IP: 193.48.251.77Port: 56540 STUN Server

Port: 3478

NAT

Proxy ServerPort: 5060

REGISTER sip:proxy.enic.fr SIP/2.0Via: SIP/2.0/UDP 10.0.0.1:5060From: Med <sip:[email protected]:5060>To: Med <sip:[email protected]:5060>…Contact: Med <sip:[email protected]:56540>…

ClientIP: 10.0.0.1Port: 5060

IP: 193.48.251.77Port: 56539Port: 56541

STUN ServerPort: 3478

NATClient

IP: 10.0.0.1RTP Port: 9000RTP Port: 9002

STUN et flux RTP

�Envoie de 2 requêtes STUN au serveur (à partir des ports RTP: 9000 et 9002)

�Corps du message SIP (SDP) contient les adresses et ports publics


Proxy ServerPort: 5060

INVITE ……Content-Type: application/sdp

c=IN IP4 193.48.251.77m=audio 56539 RTP/AVP 0 8 3 18m=video 56541 RTP/AVP 34 96

RTP Port: 9002

UARTP Port: 9000RTP Port: 9002

�Remarques: -Envoie périodique de requêtes STUN pour conserver le « binding » NAT.-Consommation d’énergie (terminaux mobiles)-NAT symétrique?

��0��1��2��3��4��5��6��7��8��9��1�0

��1��2��3��4��5��6��7��8��9��2�0

��1��2��3��4��5��6��7��8��9��3�0

�1

��Version ��IHL ��Type de service ��Longueur Totale

��Identification � ��D��M ��Taille Fragment

0 1 2 3 4 5 6 7 8 910

1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 920

30

1

version 4 IHL 5 Type de service 00 Longueur totale 0020

Identification 0001DF0

MF0

offset fragment 000

Protocole de niveau 3 (IP)

� Structure du paquet IP


��Identification � ��D�F

��M�F

��Taille Fragment

��Durée de vie ��Protocole ��Vérification Entête

��Adresse Source

��Adresse Destination

��Options "Padding"

�

��Données

�

0 0Durée de vie FE Protocole 01 Vérification en-tête 57 81

Adresse source C0 6C 72 77 (192.108.114.119)

Adresse destination C0 6C 72 0A (192.108.114.10)

Options ou padding

Données

Le Protocole niveau 4 (UDP)

� Structure du paquet UDP

0 1 2 3 4 5 6 7 8 910

1 2 3 4 5

Port source


Port destination

Longueur du message

Checksum

Données

0 1 2 3 4 5 6 7 8 910

1 2 3 4 5

Port source

Port destination

Numéro de séquence

Numéro d'acquittement

P S

protocole niveau 4 (TCP)

� Structure du paquet TCP


Checksum

Dataoffset

URG

ACK

Fenêtre

réservé

Pointeur d'urgence

PUSH

RST

SYNC

FIN

Option + padding

Données

Contrôle de flux et de congestion

� Contrôle de flux : « mapping » du débit et des ressources entre l ’émette ur et le récepteur.

– Peut être explicite ou implicite

� Contrôle de congestion : réaction à une situation de congestion dans le rése au

– de bout en bout (TCP)


– de bout en bout (TCP)– explicite (indiqué par le réseau, ex. FECN/BECN du FR)– « anticipé » (réseaux haut débit)

- Fonctions de police (« leacky bucket » pour éviter les pointes de trafic)

Ex: contrôle de flux dans TCP

<seq=2048,data>•4 •3

Récepteur retarde l ’envoie de l ’ack (pas d ’ack généré)

<seq=1024,data>•2

•1<win=2048>

Récepteur informe qu ’il peut recevoir 2K(maxi 64k)

Envoie d ’1 paquet

Envoie du 2° paquet -fenêtre de contrôle


<seq=3072,data>•6

<ack=2049,win=1024>•5

Récepteur génère ack, informe qu ’il peutrecevoir 1 nouveau paquet

-fenêtre de contrôlede flux fermée

-émetteur ne peut plus envoyer

Envoie d ’1 paquet - fenêtre de contrôlede flux fermée-émetteur ne peut plus envoyer

« end to end congestion control »dans TCP (slow/start de Van Jacobson)

� « window-based congestion control :slow start + évit e congestion

� 2 variables utilisées:-cwnd:taille de la fenêtre de congestion.-sthresh:seuil à partir duquel il faut le débit


Principe:segment TCP de 4 ktaille fenêtre TCP =min(taille fenêtre flow control ,taille fenêtre congestion control)

« end to end congestion control »(suite)

Initialize: cwnd=1sthresh=16

loop:

for each received Ack do:if(ack received and cwnd <= sthresh)


cwnd=cwnd+1else if(ack received and cwnd>stresh)

cwnd=cwnd+1/cwndelse if packet timeout

sthresh=cwnd/2 /*nouveau seuil*/cwnd=1 /*taille fenêtre redémarre à 1*/

Transmission de flux « Temps réel »

Encodeur

RTP RTCP RTP RTCP

Décodeur


UDPCouche transport

Couche réseau

TCP

IP

Internet

Délai de transit….gigue...Perte

UDP TCP

IP

Chaîne de communication IP:

Internet Réseaud’accès

Réseaud’accès

Temps d ’acheminement:

50ms < T < 100à 200ms 50ms < T < plusieurs sec. 200ms < T < plusieurs sec .


-Temps de traitement émetteur :* numérisation*compression Tps réel (cpu)* « paquetisation »* transmission

Temps d ’acheminement:-Temps de traitement récepteur :

* réception des paquets*restitution base de temps (buffer

dde gigue)* restauration* décompression* conversion Num/Anal.* diffusion

300ms < Total < plusieurs sec.

Densité de

probabilité

Délai de transmissiond’un paquet

t r

D

g

QoS (média)

Niveau de qualité de la parole en fonction du retar d (ITU-T G.114/G.113/131)

Pertes : 5 à 10% maxi

Retard Interactivité

Délai

unidirectionne

l

Indice de

dégradation

de la conversation

0-150ms

Acceptable pour la

plupart des conversations 200ms 28%


Gigue :20 à 80ms maxi

150 à 300ms.

Acceptable pour les

conversations faiblement

interactives

450ms 35%

300 à 700ms

Devient pratiquement

une conversation type « talkie-

walkie »

700ms 46%

>700ms

Inutilisable sans une bonne

pratique

de la conversation « talkie-

walkie »

Qualité de la voix

R MOS Qualité

100-90 5-4,5 Excel.

90-80 4,5-4 Bon.

80-70 4-3,5 Moy.

70-60 3,5-3 Médi.

60-0 <3 Pauv.

El:Echo level

(R)

El=infinite El=51dB El=41dBEl=31dB El=21dB El=11dB

60G.711 + PlcG,729(A)+VadG.723.1(6Kbs)+Vad

G.711 Wo Plc

GSM EFR

Delai(ms) 13.5-490

0.5-20Gigue (ms)

Pertes (%) 0-9

150

20

5

Mesures1

(G.711)

ITU-t rec.2

1TERENA Networking Conference 2004(Trans-European Research & Education Network).2ITU-T G.113 and G.114 rec. for a G.711 audio codec (w. PLC, w. controlled echo ).*Pertes et Délai: sources “Alcatel review”


El:Echo level

0

20

40

60

80

100

0 50 100 150 200 250 300 350 400Délai (ms)F

act

eu

r d

ég

rad

atio

n(R

)

0

10

20

30

40

50

0 2 4 6 8

10

12

14

16

pertes(%)Fa

cte

ur

dé

gra

da

tion

(Ie

)

G.711 Wo Plc

Notions de QoS(Qualité de Service)

� Notion relativement large» nécessité de la normaliser (ETSI)

� sous ensemble du SLA (service Level Agreement)• Services couverts (spécifications, réalisation, cycle de vie,

durée du contrat)

• Engagements (mise en place, exploitation, ruptures de service, gestion des pannes, engagement de moyens)


service, gestion des pannes, engagement de moyens)

• Support utilisateur (Help Desk, traitement pannes)

• Suivi (rapports de consommation, d'incidents, de Qos, coûts)

– méthodologie de mesure : "quoi" mesurer, échantillon d'utilisateurs, valeurs de référence (MOS)...

– paramètres de QoS

Paramétres de QoS

� Paramétres generiques:

� pour le service– Echec, temps d'établissement de la com., déconnexion

après l'établissement de la com., défauts gênants de la com.

� Pour les défaillances du service


� Pour les défaillances du service– performances garanties en fonctionnement dégradé,

fréquences d'interruption, délai de remise en état…� pour la mise à disposition

– délai, respect du délai, conformité aux spec., doc.� Pour le service support client

– temps d'accès, pertinence réponse� pour la facturation:

– clarté, exactitude

Paramètres spécifiques au service

� Paramètres » pour les com. Vocales

• délai d'établissement de la com., taux d'échecs, coupures, qualité audio (param. QoS de niveau « Appli. »)

• latence, gigue , taux de pertes (param. QoS de niveau « Réseau »)» les com. Mobiles

• coupures, couverture, qualité audio• latence, gigue , taux de pertes


• latence, gigue , taux de pertes» connexion internet

• nbre nécessaire pour établir la com.• délai d'établissement à charge moyenne et élevée• durée d'indisponibilité du FAI• vitesse de connexion, fréquence de rupture des connexions• vitesse de téléchargement depuis/vers le serveur du FAI (ex: serveur

mail, web…• latence, gigue, taux de pertes

RTP RTCP

Interface socket

Codec Audio Codec vidéo

30000

Espaceapplication

Multiplexage de flux multimédia RTP / RTCP (RFC 1889)

50000

30001

50001

�Windsock DLL


UDP TCP

IP

30000

EspaceOperating

systemDriver NDIS

Carte (NIC)

50000

30001

50001

Real Time Protocole(RTP) (RFC 1889)

� RTP définie un format de paquet pour le transport d u flux ayant un caractère temps réel(audio et vidéo)

� Paquets RTP fournit : -identification de la charge .Indique le type de codage utilisé par la source ( PCM, APCM…).

L ’encodage peut changé dynamiquement.-numéro de séquence .-info d ’horodatage (TimeStamping)

Appli .RTP

UDP

InterfaceSocket


-info d ’horodatage (TimeStamping)contient un « time stamping » et un numéro de séquence permettant au récepteur de reconstruire l ’horloge d ’émission.Le numéro de séquence peut être utilisée par le récepteur pour estimer les paquets perdus.

� RTP est supporté par UDP� RTP+UDP peut être « vu » comme une couche transport� RTP fait partie de l ’application

IP

D.L

Phys.

En tête RTP

•Horodatage

•Version •Padding •Extension•Marqueur

•Nbre de sources contributives

Non utilisé en H.323 ou SIP

Ex: ds profil RTP en H.323:M=1: période de paroleM=0: période de silence


0: pcm µlaw à 64Kbs

3: gsm, 32 Kbs

7: lpc, 2.4 Kbs

18: G.729

26: Motion jpeg

31: H261

33: mpeg 2 video

……

•Détecte paquets perdus

ou perte de sequencement

Non utilisé en H.323 ou SIP

www.iana.org

RTCP (Real Time Control Protocol)

� Vérification et surveillance de la QoS (au niveau a pplicatif)� Transmission périodique de messages de contrôle à t ous les

participants d’une session.� Informations concernants le récepteur

» peut être utilisé pour informer d’un nouveau participant.


� Informations concernants la qualité de la réception» Feed-back pouvant être utilisé pour le contrôle adaptatif

� Le débit de transmission est contrôlé

� Un message « RTCP BYE » est envoyé quant un participa nt quitte la conférence.

Real Time Control Protocol (RTCP)

� Associé à RTP

� paquet RTCP fournit statistiques sur:– nombre de paquets envoyés, perdus, gigue…

� peut être utilisé pour l ’adaptation dynamique


� types de paquet:

� « receiver report »: nbre de paquets perdus,dernier n °seq, gigue

� « sender report »: ssrc du stream rtp, marqueur tempo rel « SR » et paquet RTP associé

» « source description »: @ émail et nom de l ’émetteur, ssrc du stream rtp associé

RTCP: Les paquets SR (rapport d’émetteur) et RR (rapport recepteur)

Rap

po

rt d

’em

ette

ur

(SR

)


Rap

po

rt d

’em

ette

ur

(SR

)R

app

ort

rec

epte

ur

(RR

)

RTCP: Les paquets SDES ( source description)


SSRC attribué aléatoirement et de manière uniqueSDES info: nom au format:canonique (CNAME, user@nom dns ou user@adresse ip), Name,

eMAIL, Phone, Loc

B.P généré par RTCP

� Trafic limité à 5% de la B.P totale de la session p our RTCP (ex: vidéo à 2Mb/s, de 1 émetteur vers n récepteurs: trafic max. 100 Kbs).

Le protocole alloue:

� 75% réparti équitablement entre les récepteur� ex: si R récepteurs le trafic rtcp est de 75/R Kbs

•75% de ce trafic au récepteur 75Kb/s•25% de ce trafic à l ’émetteur 25Kb/s


� ex: si R récepteurs le trafic rtcp est de 75/R Kbsl ’émetteur trafic rtcp 25 Kbs

� période d ’émission pour l ’émetteur: T=

� période d ’émission pour les récepteurs: T=

Nbre d ’émetteurs0.25 x 5 x B.P session x Taille paquets rtcp

Nbre de récepteurs0.75 x 5 x B.P sessionx Taille paquets rtcp

Composantes de la QOS (Réseaux Ip)

� Mécanismes d’identification et de Marquage des flux .

� Mécanismes de gestion de la congestion (Algo. d ’ord onnancement des paquets dans les routeurs) : File d'attente FIFO, P Q, CBQ, WFQ, CBWFQ…

� Mécanismes pour éviter la congestion: Algo. RED, WR ED, « Multicast »...

Contrôle d ’admission (CAC)


� Contrôle d ’admission (CAC)

� Fonction de "police" à la périphérie du réseau (UPC)� VSA, Leacky Bucket, Token Bucket …..

� protocole de sig. Pour demander ou réserver une QoS ou prioritiser les flux.

• in-band intégrée dans le flux (ex: modèle "DIFFSERV") • out-band canal séparé (ex: RSVP dans le modè le "IntServ)

FIFO - Pas de QoSLien WAN: B.Passante ~6% Ethernet (seuil de congestion)

QoS: P. Queuing

Congestion démarre à 6% environ

Note: Pour tous les tests la charge est spécifiée en % du trafic Ethernet


QoS: WFQChamp IP précédence Bande

passante allouée

QoS: PQ pour RTP

PQ pour la VoIP (N° port UDP) avec une Bande Passante limite.

8 flux avec IP precedence: 0, 1, 2, 3, 4, 5, 6, 7Poids correspondant: 1, 2, 3, 4, 5, 6, 7, 8 (total = 36)B.P allouée: 1/36, 2/36, 3/36, 4/36, 5/36, 6/36, 7/36, 8/36

ROUTEUR 1 (cisco 1700)- Adresse FastEthernet0: 192.168.10.1-Version Software: 12.2 (4)ROUTEUR 2 (cisco 2600)

- Adresse FastEthernet0: 192.168.11.1-Version Software: 12.2 (5d)- “Clock Rate” serial0/0 56000bps à 800000bps port Serial0 (192.168.12.0)

- Minimum BP: 2,28 Kbps- Maximum BP: 2,78 Mbps


PC 1- Adresse Ethernet: 192.168.11.11-Logiciel “ IP Traffic” en Generateur de trafic de fond (WEB et TELNET) entre 100 et 2000 Kbps

PORTABLE 1- Adresse Ethernet: 192.168.10.11- Logiciel IP TRAFFIC en analyseur

PORTABLE 2- Adresse Ethernet: 192.168.10.12- client VoIP (avec mesure du MOS)

PC 1- Adresse Ethernet: 192.168.11.12- Client VoIP (SIP)

HUB HUB

!access-list 100 permit udp any any range 16384 32000access-list 100 permit tcp any any eq 1720access-list 101 permit tcp any any eq wwwaccess-list 102 permit tcp any any eq telnet!

!class-map match-all t_telnet

!policy-map mapoliceclass t_webbandwidth 16class t_telnetbandwidth 16class t_voippriority 64

class class-default

Ex. configuration QoS sur routeur CISCO 2 (interface « CLI »)


class-map match-all t_telnetmatch access-group 102set ip precedence 0

class-map match-all t_voipmatch access-group 100 /*(oumatch ip precedence 5)*/set ip precedence 5

class-map match-all t_webset ip precedence 2match access-group 101

!

class class-defaultbest-effort

/*(somme < 75% du trafic total)*/!

!interface Serial0bandwidth 128ip address 192.168.12.1 255.255.255.0encapsulation pppservice-policy output mapoliceclockrate 128000!

Routeur 2600 "sans QOS" (par défaut "FQ" si congestion)

-50

0

50

100

150

0 20 40 60 80

Sec

Kbp

sConnexion Voip

Connexion Web

Connexion Telnet

Routeur 2600 avec QoS"bandwidth 64"

-20

0

20

40

60

80

100

120

140

- 20 40 60 80 100Sec

Kbp

s

ConnexionVoipConnexionWebConnexionTelnet


Router 2600 avec QoS "priority 64"

-20

0

20

40

60

80

100

120

140

0 20 40 60 80Sec

Kbp

s

Connexion Voip

Connexion Web

Connexion Telnet

Inter Packet delai

0

50

100

150

200

250

Délai VoIP Délai Web Délai Telnet

ms

Bandwidth 64

Prioritty 64

Sans QOS

« Policing » : Quels sont les paramètres utilisés ?

� Bc Longueur garantie (Bc = Burst Commit)» nombre de bits qu'un usager peut envoyer au réseau pendant

un intervalle de temps (Tc)

� Be Longueur excédentaire» nombre de bits qu'un usager peut envoyer au réseau en plus de

Bc pendant un intervalle de temps (Tc)


Bc pendant un intervalle de temps (Tc)

� Tc Intervalle de mesure du débit garanti (Tc = Time Commit)

» intervalle de temps pendant lequel un usager peut envoyer un nombre de bits Bc + Be

Représentation des paramètres

BcBcBeBe

Débit nominal

CIR

EIREIR Bande passanteBande passanteMoyenne garantieMoyenne garantie

� En valeurs moyennes


T0 Tc

CIR

Bit DE positionné à 1Bit DE positionné à 1

Nb de bitsNb de bits

128kb128kb

Pente correspondantPente correspondant

Vitesse NominaleVitesse Nominale


� Valeurs instantanées pour un respect du contrat


T0T0

T=1sT=1s

Pente correspondantPente correspondantà un débit négocié àà un débit négocié à

64Kb/s (CIR)64Kb/s (CIR)

Volume de donnéesVolume de donnéesacheminé pour un acheminé pour un

CIR de 64 Kb/sCIR de 64 Kb/s

CIR=64KCIR=64K

Nb de bitsNb de bits

128kb128kb

Bc = 90KbitsBc = 90Kbits

Be = 20kbitsBe = 20kbits

Vitesse de transfertVitesse de transfert

Vitesse nominale Vitesse nominale de transfertde transfert

Trame dépassant le contratTrame dépassant le contratdonc détruitedonc détruite


� Valeurs instantanées pour un débordement de contrat


T0T0 T=1sT=1s

CIR=64KCIR=64K

Bc = 90KbitsBc = 90Kbits

TcTc

Vitesse de transfertVitesse de transfertmoyenne garantiemoyenne garantie

Bande passanteBande passanteMoyenne garantieMoyenne garantie

Stratégies de gestion des flux par le réseau

� Nous distinguerons deux types de stratégies :

» Destruction de trames, mais pas de délai de transmission,

BeBe

BcBc

BeBe

BcBc


» Délai de la transmission, mais pas de destruction.

Le « lissage » du trafic permet de fournir à l’utilis ateur une « perception constante » ou homogène du service rendu (quelque so it l’état du réseau)

BeBe

BcBc

BeBe

BcBc

Report deReport detransmissiontransmission

Composantes de la QOS (Réseaux Ip): suite

� Classes de services pour les appli.

� Modèle DiffServ

» équivalent a un service personnalisé de la "poste"

-service Premium -> délai faible-service «Olympic » (gold, silver, bronze)-> B.P assuré


� Modèle IntServ

» équivalent a un service "normal", "lent", "urgent" de la "poste"

-service « guaranted »-> délai Max assuré-service « controlled load »-> B.P assuré-service « best effort » -> classique

-service «Olympic » (gold, silver, bronze)-> B.P assuré -service « best effort » -> classique

Ressource Réservation Protocol (RSVP)

� Protocole de réservation B.P.

� Orienté récepteur.

� Utilisation de messages « PATH » (pas de mécanismes p our envoyer dans l ’autre sens en routage Ip)


� Messages RSVP ne sont pas acquittés par contre il y ’a rafraîchissement.

� Associé à IntServ

RSVP (suite)

Message Path

Req. Rsvp (ex. 100Mbs)

Req. Rsvp (ex. 10Mbs)


RSVP (suite)

RTP RTCP

DécodeurEncodeur

RTP RTCP


UDP UDP TCPCouche transport

Couche réseau

TCP

IP IP

Internet

Délai de transit….gigue...Perte

Architecture « RSVP » fourniel ’identification et la classification de flux.Les stations et Routeurs du réseaudoivent supporter le protocole RSVP

Diffserv (Differentiated services)

� Composante des réseaux « PBM » (Policy Based Manageme nt ) les régles de Qos sont définies au niveau "Busines s" (utilisateur) d'une entreprise

� Napster interdit entre 8h et 19h

� telephone prioritaire


� telephone prioritaire

� web priorité basse

� aucun paquet Oracle (SAP) perdu

� la telesurveillance MPEG2 ne doit pas perturber Ora cle (SAP)

Politique au niveau réseau

� Reconnaissance et interdiction des clients Napster

� telephone: service premium

� web: best effort


� Oracle: Olympic Or

� Mpeg2: Olympic bronze avec priorite complete de l'O r sur le Bronze

Diffserv, Exemple: Politique au niveau noeud

� Configuration Diffserv:

» reconnaissance et classification des applications ( marquage des flux)

» Policing (ex. paramètres BE, BC, TC)


» gestion des buffer (ex. seuil de pertes des BE et O lympic Bronze)

» Scheduling: gestion des priorités (ex. B.P, priorit é alloués)

» Activation des principaux mécanismes de Gestion de files d'attentes (ex. Priority Queing, WFQ (flow/class ba sed), RED, WRED…

QoS: Architecture Diffserv (PBM1 oriented)

PDP

PolicyRepositorySLA

(MOS Cible)

PDP: Policy Decision PointGére la “politique” de QoSPEP:Policy enforcement pointDemande et applique une politique

Boucle de QoS


Systéme de gestion

PEP

PEP

PEP

PEP

Classifier Marker

Meter

Shaper/dropper

Rq: RSVP ou cops SLS, proposition pour gérer dynamiquement les SLA/SLS à partir du terminal (pb trusted terminal)1 Gestion de la QoS management basée sur des “politiques” de haut niveaux (niveau utilisateur).

Multicast

� Multicast: envoie d ’un message à un groupe de récep teurs, via l ’utilisation d ’une seule fonction de type « send »

� unicast envoie à un « utilisateur »� multicast envoie à un groupe d ’utilisateurs

broadcast envoie à tous les utilisateurs


� broadcast envoie à tous les utilisateurs

Quelques applications de types multicast

� diffusion audio/vidéo (« TV sur ADSL »)

� Transfert d ’applications ou de fichiers

� Vidéoconférence (ex: Ivs)


� Vidéoconférence (ex: Ivs)

� jeux distribués (ex:MiMase)

� mise à jour de base de données distribuées.

� ...

Éléments « critiques » du multicast

� « Overhead »� « scalability »� hétérogénéité� routage multicast

� Qos


» support du temps réel� fiabilité

» contrôle de flux

� ...

Routage multicast: principes

� Adressage

– liste d ’adresses (pb de « scalability »)– groupe d ’adresses (pb de contrôle)

� Signalisation� Multicast orienté source

– source établit une connexion avec le groupeex ATM: une connexion explicite est établie avec ch aque


– ex ATM: une connexion explicite est établie avec ch aque récepteur (pb des groupes dynamiques)

� Multicast orienté récepteur Deering,1991

– les groupes peuvent être de taille différente– pas de restriction sur la topologie– adhésion dynamique à un groupe

Routage multicast: suite

� Routage� Multicast via Broadcast:

– filtrage au niveau transport (> niveau réseau)– adapté aux réseaux travaillant en mode diffusion

naturellement (ex: Lan, satellite…)– pbs: sécurité, bande passante.

� Multicast via Routage unicast:liste d ’adresses associée à l ’envoie du message


– liste d ’adresses associée à l ’envoie du message

A

E

B

C

STo (A,B,C,D,E)

To (A,B)To (A,B) To (A)

To (B)

To (C,D)

To (C,D,E) To (C)

A

DE

B

C

STo (A,B,C,D,E)

To (A,B)To (A,B) To (A)

To (B)

To (C,D)

To (C,D,E) To (C)


� Spanning tree forwarding– « shared » ou « source-based »

A

D C

B

Nœud racine


D C

A

DE

B

C

S A

DE

B

C

S


� Reverse Path Forwarding (RPF):

– Dalal et Metcalfe

– utilisation de l ’infrastructure de routage unicast


– DVMRP s ’inspire de RPF

– protocole travaillant en mode broadcast

– utilisation de l ’adressage de groupe

– commutateurs et routeurs « forward » les paquets en s e basant sur l ’adresse source du paquet multicast

Algotithme RPF

1- Un paquet est reçu sur l ’interface I, de S (Sourc e) vers G (Groupe multicast)paquet (S,G)

2- routeur consulte la table de routage unicast pour determiner l ’interface native In utilisée pour envoyer vers S.

3- Si I!=In alors I n ’est pas l ’interface pour recevoir le flux (S,G) -> Discard


3- Si I!=In alors I n ’est pas l ’interface pour recevoir le flux (S,G) -> Discard4- Si I=In alors I est l ’interface pour recevoir le flux (S,G) -> Forward

DVMRP: Principe

S

A

BS

� RPF(+ « looking one step further » DVMRP)


E

D

E C

yw

z

Table de routage:to via

s y

Routage multicast dans l ’Internet

� Adressage de groupe (niveau 3)– class D

� multicast niveau 2 (adressage niveau liaison)

� protocole d ’adhésion de groupe


protocole d ’adhésion de groupe– IGMP (ex. Join, Leave sur le réseau local)

� protocole de routage multicast– DVMRP, MOSPF, CBT, PIM

� utilisation de message « prune » et « graft » dans le r éseau coeur

Classe D adresse IP Adresse MAC

224.0.0.5

224.0.0.6 01005E-000006

01005E-000005

Le Protocole niveau 3 (IP Multicast)

� Correspondance adresseIP / adresse MAC

� Protocole IGMP Internet Group Management Protocole

� Encapsulé dans un datagramme IP identifié par le type 2


0 1 2 3 4 5 6 7 8 9 10

1 2 3 4 5 6 7 8 9 20

1 2 3 4 5 6 7 8 9 30

1

Version Type Version Checksum

Adresse de groupe multicast

� Encapsulé dans un datagramme IP identifié par le type 2

� Format paquet IGMP

Multicast fiable

Ack Ack

� Pb: explosion du trafic « feedback »


Ack

AckAck

Ack

Multicast fiable: approches

� Retransmission sur NAK (pas sur Ack)

� délai de transmission des Nak aléatoire

� server -based


� server -based

� FEC (Forward Error Correction)

� codage source robuste

� ...

Routeur

Routeur

Principe de fonctionnement

� Créer une session� 224.2.17.13


Routeur

Routeur Routeur

v= Version Protocole


s= nom de la session

i*= info. Sur la session

u*= url contenant description

e*= @ email

p*= numero de tel.

o= créateur/propriétaire & Id session

c*= info. Sur la connexion

Description de la session

Format SDP <type>=<value>

Description



z*= fuseau horaire

k*= clef de crytpo.

a*= attributs de session

t= durée de session

r*= occurrence de la sessionm= media & @ transport

k*= clef de crypto.

i*= nom du media


c*= info. connexion

a*= une ou plusieurs lignes attributs media

Description « temporel »

Description « réseau »

Routeur

RouteurSession Description Protocol

Session Annoucement Protocol

draft IETF mmusic-sap-00

224.2.127.254 / UDP port 9875

Annoncer la Session

Créer une session224.2.17.13


Routeur RouteurVersiontype payload,Origine,Crypto.Etc.

SDP n ’est pas un protocolede communication,mais un langage ou formatde description de session

RFC2327Header payload

Descriptionde la session

SAP client

SAP(TTL=4)

Routeur


(TTL=2)

(TTL=0)

Routeur

(TTL=1)

Annoncer la Session


Routeur

Routeur Routeur

SAP client

SAP(TTL=4)

(TTL=3)

(TTL=2)

(TTL=1)

Annuaire de session

ex : sdr.exe

Conférence 1

Participation

Routeur


Routeur


Routeur

Routeur Routeur

SAP client

SAP(TTL=4)

Annuaire de session

ex : sdr.exe Conférence 1

Adhésion d'un participant

Routeur

Routeur


Annuaire de session

Routeur

Internet Group ManagementProtocol IGMP


Routeur

Routeur Routeur

SAP client

SAP(TTL=4)


IGMP

Routeur

Ex : 224.2.17.13

Protocol IGMPRFC2236

type Adresse de groupe

Adhésion d'un participant

Routeur

Routeur


Annuaire de session

Routeur


Routeur

Routeur Routeur

SAP client

SAP(TTL=4)


IGMP

Transfert de données

Routeur

Routeur


Annuaire de session

Routeur


Routeur

Routeur Routeur

Annuaire de session


SDP descriptionO = Meddahi +33 20 33 55 62 +33 20 33 55 98 IN IP4 192.48.251.107

s = Enici = Test Session from ENICm = audio 30000 RTP / AVP 3c = IN IP4 224.2.17.13 /1m = video 50000 RTP / AVP 31c = IN IP4 224.2.17.13 /1

« du point de vue » de la station cliente


SAP

IGMP

Groupe 224.2.17.13

Le Réseau Mbone


Backbone

224.2.10.10

224.2.10.10

LAN 1

LAN 3Routeurmulticast

Tunneling

Réseau« Unicast »


BackbonemulticastMBONE

224.2.10.10

224.2.10.10

LAN 1

LAN 2

Routeurmulticast

Routeurmulticast

Réseau« Unicast »

Protocole niveau 3 (IP multicast)

� Raccorder un site au Mbone:

� mise en œuvre d ’un tunnel IP (tunneling)

� utilisation du « demon » Mrouted sur Unix ou équivalent sur d ’autres Operating System.


Operating System.

Conclusion


� Voix sur IP: « techniquement » au point (Téléphonie s ur IP)

� Qualité de Service (de bout en bout)?Dépend essentiellement de la technologie réseau sous-jacent.

� Convergence Fixe/Mobile (à partir de 3G) et Voix-Do nnées-Image:� une seule infrastructure réseau pour la voix et les

Conclusion (suite)


� une seule infrastructure réseau pour la voix et les données

� Administration d ’une architecture uniqueréduction des coûts de communicationAdministration plus « simple » et moins « onéreuse »

� Rentabilité économique : dépend de plusieurs facteurs, et de l’échéance visée.

Conclusion (suite)

� Support 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 dyn amiques et variables.

� Impacte sur les performances.


�� Avant un déploiement total des services, les réseau x “paquets”doivent fournir le même niveau de Qualité de Service que le réseau “commuté” (surtout pour les applications de types “temps réel” ou sensible au délai).

�� QoS compléte (du réseau à l’application)

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”)� Sécurité (média et signalisation)� spam téléphonique (+ critique que le “mail” spam )

Mobilité (utilisateur/terminal)


� Mobilité (utilisateur/terminal)� Localisation géographique (applications basées loc al.)� Appels d’urgences� Interception d’appels� Performance de la signalisation (ex. SIP)� …

Bibliographie (liste non exhaustive).

• Le protocole TCP : RFC 793

• Le protocole IP (Version 4) : RFC 791

• Le protocole IP (Version 6) : RFC 1883

• Le protocole IP multicast (IGMP) : RFC 1112

• Protocole de transmission pour le multimédia : ITU- T T120/T.123/T.124

• Protocole RTP : RFC 1889

MBone Interactive Multimédia on the Internet : Auteur :Vi nay Kumar.Edition


• MBone Interactive Multimédia on the Internet : Auteur :Vi nay Kumar.Edition:NewRiders

• TCP-IP : architecture, protocoles, .. : Auteur :Com er, Joachim Bruno.Editeur:InterEdition.

• Téléphonie sur l'Internet:: Auteur: Jean-François S usbielle, Editions Eyrolles

• Multipoint communication: a survey of protocols, fun ctions, and mechanism, IEEE Journal on Selected Areas in Communications, 1997, C . Diot, W. Dabbous and al.

• Dlivering Voice over IP Networks: Daniel/Emma Minoli wiley computer publishing

• Qualité de service sur IP, Jean-Louis Mélin, Editio ns Eyrolles.

• www.spirentcom.com

ANNEXES


Protocole MGCP

� RFC 2885 (MEGACO)� Nécessité de séparer les fonctions « typiquement » so ft, des fonctions Hardware

des passerelles.

� « Intelligence » au sein du Call Agent

� Les Fonctions de conversion au sein de la Gateway


� Protocole utilisé pour contrôler différents types d e passerelles :

� (Trunk Gataway, Residential Gateway, Signaling Gateway, MCU…)

Exemple de flot « MGCP »

0 <- RQNTAck ->

(ready)

1 Off- NFTY ->

hook (off-hookrecorded)

Ack<-

TerminaleRTC

PasserelleMG

Serveur Megaco (MGC)

Terminal « IP »(ex. H323)

Serveur d’appels(ex.H323)

Etape


2 (dialtone)

<- RQNTAck ->

3 digit

4 (nodialtone)

5 digit...

Rq: en noir signalisation MGCP

Exemple de flot « MGCP »(suite) :

10 digit

->10a NFTY(match)Ack<-

10b <- RQNT+CRCXAck(SDP) ->

- -11 ARQ ->

12 <- - - ACF

EtapeTerminale

RTCPasserelle

MGServeur

Megaco (MGC)Terminal « IP »

(ex. H323)Serveur d’appels

(ex.H323)


12 <- - - ACFMDCX<-12a

12b Ack(SDP) ->13 SETUP ->

ARQ14 ->ACF15 <-

16 <- ALERTING(ringback)

17 <- RQNT+MDFY (SDP)

Ack ->

Exemple de flot « MGCP » (suite) :

18 CONNECT<-

19 (cut-through)

<- RQNT+MDFY

(fullduplexmedia

->ACK

Etape TerminaleRTC

PasserelleMG





mediatransferrecorded)

Exemple de flot « MGCP » (suite) :

<- Ack20 NTFY ->on-hook

21 RELEASE - - ->

<- RQNT+DLCX21a

Ack ->21b

<-22 - - RELEASE

Etape TerminaleRTC

PasserelleMG




Serveurtaxation« Acc »


<-22 - - RELEASECOMPLETE(Media

transfertstopped)

(Accounting) ->

Détail des messages MGCP:0)RQNT 1201 endpoint/[email protected] MGCP 0.1 N: [email protected]:5678 X: 0123456789AB R: hd 0)200 1201 OK

1)NTFY 2001 endpoint/[email protected] MGCP 0.1 N: [email protected]:5678 X: 0123456789AB O: hd1)200 2001 OK

2)RQNT 1202 endpoint/1@rgw -2567.enic.fr MGCP 0.1

10b)CRCX 1204 endpoint/[email protected] MGCP 0.1

C: A3C47F21456789F0

L: p:10, a:PCMU

M: recvonly

X: 0123456789AD

R: hu

10b) 200 1204 OK

I: FDE234C8

v=0

c=IN IP4 128.96.41.1


2)RQNT 1202 endpoint/1@rgw -2567.enic.fr MGCP 0.1N: [email protected]:5678 X: 0123456789AC R: hu, [0-9#*T](D) D: ([2-9]xxxxxx| 1xxxxxxxxxx| 0T| [49]11| 011x.T) S: dl2)200 1202 OK

10a) NTFY 2002 endpoint/[email protected] MGCP 0.1N: [email protected]:5678 X: 0123456789AC O: 2,3,4,5,6,7,8,T10a)200 2002 OK

c=IN IP4 128.96.41.1

m=audio 3456 RTP/AVP 0

12a) MDCX 1205 endpoint/[email protected] MGCP 0.1

C: A3C47F21456789F0

I: FDE234C8

L: p:10, a:PCMU,G729C

M: recvonly

12b) 200 1205 OK

v=0

c=IN IP4 128.96.41.1

m=audio 3456 RTP/AVP 0 18

13) Message H225….RTP receive address:128.96.41.1, 3456 RTCP receive address:128.96.41.1, 3457

16) Message H225…. G.711 RTP receive address:128.96.63.25, 1296 G.711 RTCP address:128.96.63.25, 1297 G.729C RTP receive address:N/AG.729C RTCP address:128.96.63.25, 1299

17)MDCX 1206 endpoint/[email protected] MGCP 0.1C: A3C47F21456789F0

Détail des messages MGCP (suite):19)MDCX 1208 endpoint/[email protected] MGCP 0.1

C: A3C47F21456789F0 I: FDE234C1 M: active X: 0123456789AF R: hu

19)200 1208 OK

20)NTFY 2005 endpoint/[email protected] MGCP 0.1X: 0123456789AF O: hu

20) 200 2005 OK

21a) DLCX 1210 endpoint/1@rgw -2567.enic.fr MGCP 0.1


C: A3C47F21456789F0 I: FDE234C8 L: p:10, a:PCMUM: recvonly X: 0123456789AE R: hu S: v v=0

c=IN IP4 128.96.63.25 m=audio 1296 RTP/AVP 0 a=sendonly m=audio 1298 RTP/AVP 96 a=rtpmap:96 X-G729C/8000a=recvonly

17)200 1206 OK

21a) DLCX 1210 endpoint/1@rgw -2567.enic.fr MGCP 0.1 C: A3C47F21456789F0 I: FDE234C1 X: 0123456789B0 R: hd

21b)250 1210 OK P: PS=1245, OS=62345, PR=780, OR=45123, PL=0, JI=27 , LA=48

Megaco/h248

� Dérive de MGCP

� Standard IETF (rfc3015 ITU-T h248)

� Supporte:

• services multimédia multipoint


• syntaxe des messages (commandes/réponses) évolué

• tcp/udp � option (ATM,…)

• messages � texte ou binaire (ASN.1)

• extension des messages � support de « package » spécifique

Megaco/h248

� MGCP� notion: « endpoint », connexions� 1 transaction=1 commande� 1type de reponse� commandes:

� EndpointConfiguration� NotificationRequest� Notifications

� Megaco/h248� notion: « terminations », context� 1 transaction=N actions� 1action=N commandes� 2 types de reponse (TransactionPending)� commandes:

� Add� Modify� Subtract


� Notifications� CreateConnection� ModifyConnection� DeleteConnection� AuditEndpoint� AuditConnection� RestartinProgress

� TEXTE

� Subtract� Move� AuditValue� AuditCapabilities� Notify� ServiceChange

� TEXTE, BINAIRE (asn.1)

Megaco/h248

� Exemple: requête de statistiques� MGC->MG

MEGACO/1 [123.123.123.4]:55555Transaction=50009{Context=5000{subtract=A5555{Audit{statistics}};

subtract=A5556{Audit{statistics}};

}}

� MG->MGCMEGACO/1 [125.125.155.111]:55555


MEGACO/1 [125.125.155.111]:55555Reply=50009{Context=5000{subtract=A5555{

statistics{nt/os=45123;nt/dur=40}},

subtract=A5556{ statistics{rtp/ps=1245,nt/os=62345,r tp/pr=780,nt/or=45123,rtp/pl=10,rtp/jit=27,}}

� Modèle pour le transport sur IP de la signalisation mode message

� ex: : SS7,Q931

� Définit la méthode d ’encapsulation des messages

� Utilise IP comme protocole de transport

Protocole SCTP(Stream Control Transport Protocol, RFC 2960)


� Définit les mécanismes ou protocoles de bout en bou t afin d ’assurer un transport performant et robuste des me ssages transportés.

Protocole SCTP: Composantes

Module Adaptation (M2UA)

Ce que doit assurer SCTP:

* fiabilité* faible latence* disponibilité•« multilink »•détection rapide de coupure

Couche Transport (SCTP)


IP

•détection rapide de coupure•fonction « keep alive »* synchro des horloges* sécurité* ...

UDP-TCP

Protocole SCTP: suite

GSM

Appli.orientés « Transaction »

Appli. orienté (« circuit »)« contrôle d ’appels »

Sig. orienté Sig. orientée

« Transactions

MTP: Message Transfert Part

SSCP: Signaling Connection Control Part

TCAP: Transaction Capacitives Application Part

TUP:Téléphone User Part

SCTP: Stream Control Transmission Protocol

M2UA, M3UA, SUA: protocoles « adaptatifs »

INAP: Intelligent Network Application Protocol

ISUP: Isdn User Part


ApplicationSpecificLayers ISUP

TCAPSCCP

MTP Level3

MTP Level2

MTP Level1

GSMMAP/IS-41

INAPTUP

Sig. orienté « contrôle d appels »(niveau 4)

« Transactions

MTP3

M2UAM3UA

SCTP

IP

TCAP

SUA

IP SCP

SGSS7/SCTP

SS7

MGC

[SG]Q931/Q921

(Q931/SCTP) MGCP

Architecture 1: Architecture 2:

Protocole SCTP:

MGCP


MGC

MG

[SG][MG]

Q931/Q921

media

Réseau IP

T2

« RTC » « SS7 » « IP »«Passerelle »

« Etablissement » « IAM » « Invite»

« Ringing»« ACM»« Alerte»

«200 Ok»

« ANM» « Ack»« Connexion»

Serveur

Livret élève: séquence 2 (question a)


« RTC »(transport)

« IP »

SS7(signalisation)

PasserelleSig.

PasserelleMédia

ServeurSIP

STP(Switch)

(Switch)(Switch)

SSPSSP

STP(Switch)

SignalisationSIP

SignalisationSS7

Signalisation « RNIS » Flux

Média (audio)

SS7

question b: plusieurs solutions:*Dans message SIP spécifique: « INFO »

*Dans le contenu média (RTP)

*Message RTP spécifique (RFC 2833)

INFO sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP alice.uk.example.com:5060 From: <sip:[email protected]>;tag=d3f423d To: <sip:[email protected]>;tag=8942 Call-ID: 312352@myphone CSeq: 5 INFO Content-Length: 24 Content-Type: application/dtmf-relay

Signal=5Duration=160


51 #0 t

Offset:11200

Offset: 4800=600ms6400=800ms

1600=200ms 2000=250ms 400=50ms

11600=1,45sec (dernier bit paquet « RTP » envoyé à 1.45 sec)

400=50ms (durée du paquet IP)timestamp:11200

#