1

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

Ahmed MEDDAHI

2

Objectifs:

•Analyser et comprendre: •Les architectures et modèles sur lesquels s'appuient les services "Télécom" (ex les services "voix").•Les "contraintes" en particulier dans le contexte des réseaux paquets "IP" .

•Illustration des différents concepts (problèmes liées au support de services de type "temps réel" dans les réseaux paquets) →→→→ la "téléphonie" (sur IP) est le principal service télécomconsidéré.• Deux aspects:

•Les mécanismes et architectures de signalisation (Ex. SIP) généralement associés à"l'intelligence" du réseau ("équivalent" au protocole "SS7" dans les réseaux circuits). •La Qualité de Service réseaux qui représente un élément essentiel des réseaux IP est également étudier à travers l'analyse des principaux mécanismes de gestion de QoS et modèles associés (ex. DiffServ, IntServ).Mais aussi: exploitation à un "haut niveau" des mécanismes de signalisation et de laQoS : introduction aux environnements ("API") de création/déploiement de servicestélécom IP: concepts JAIN (Java Api for Intelligent/Integrated Networks) (ex. JAIN SIP, JAIN SLEE). →→→→Aspect création/déploiement de services télécom.

Remarque: Ces différents aspects seront illustrés àtravers des séances de travaux dirigés et Travaux Pratiques.

3

Contenu:

Partie "Signalisation".Rappels des mécanismes de signalisation dans les réseaux classiques "circuit" (ex. SS7). Principes et concepts de la signalisation IP (ex. SIP) et exemples de scénario d'appels. Analyse et comparaison avec les mécanismes supportés par les réseaux "classiques".

Partie "Qualité de service" dans les réseaux.Les principaux modèles de QoS (DiffServ et IntServ), de mécanismes de gestion et de contrôle de file d'attentes (ex. Algorithme VSA, Leacky Bucket, Token Bucket) dans les réseaux IP sont présentés et analysés. Des illustrations de ces mécanismes de QoS en particulier liées à leur configuration dans les réseaux, sont donnés à travers des exemples concrets et pratiques.

Partie "Création de services" (introduction).Principes et concepts des environnements pour la création/déploiement de service Télécomdans les réseaux IP.Cette partie est illustrée en particulier à travers le modèle d'architecture JAIN (Java Api for Intelligent/Integrated Networks).

4

Cohabitation des protocoles « IP »

UDP TCP

IP, DiffServ, IntServ

Cuivre /Fibre Optique….

Transport

Réseau

Liaison

Physique

RTP TCAP

JMF

INAPSIP

JAIN «call control»

Application(Services)

Services (Applications)

ISUP

SDH/WDM/DWDM

MPLS

ATMEthernet HDLC/PPP

GMPLS

Flux ( Audio /Video ) Flux (Signalisation )

JAIN «SIP»

RTCP

(QoS

)(S

ervices)

Transm

ission

STCPTLS

IP

5

Services « Télécoms »

• Introduction

• Rappels

• Réseaux « classiques »– Architecture et signalisation

• ex. RNIS et SS7

• Réseaux « IP »– Architecture et signalisation

• ex. SIP, MEGACO, SCTP

• Eléments critiques et Conclusion

6

Introduction

7

Services Télécom. IP: Introduction

« Services Télécom.»:Moyens mis en œuvre tels que : signalisation,

ressources (commutation, transmission…)

pour la fourniture

et la gestion d’accès à un « service »

# services fournis par voie de

télécommunications

(notion de contenu, ex. service d’annuaire)

Téléphonie (sur IP)Fax temps réel (G3/G4)Transmission donnéesVidéo conférenceFax store & Forward« Video On demand"« Live Streaming » (TVoIP)« Messagerie Instantanée »« Push to talk »« context aware VoIP »….

8

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

«Circuit»«Paquet»

RGwRGw

MGwMGw

Coeur réseau:Internet +QoS

(Diffserv/Intserv)

Serveurcontrôle d’appels

Serveurcontrôle d’appels

SCTP

H.323/SIP

Flux media (RTP/RTCP/…)

RTP/RTCP

SGw

Sign

alisa

tion:

SIP,

Meg

aco/

H.2

48

SS7 SIP, Megaco/H

.248

PSTN/SS7

Analog./Digital

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

Plate-forme de services(services API)

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

Terminal(services API

(services API)

9

Réseaux de niveau 1, 2 et 3

IP

*RPR MAC Ethernet MAC HDLC/PPP ATM

PRC-PHY

Réseau de transmission (ex. Sonet/SDH, WDM, DWDM…)

10 Gig EPHY

Gig EPHY

Lien (ex. Fibre Optique)

IEEE 802.17 IEEE 802.3Packet Over Sonet

(POS)

Niveauphysique

Niveautrame

NiveauPaquet

AAL.5

Gestion de l’accèsau support

Codage et traitement du signal pour adaptation au

support

Support physique

Gestion de la transmission

* RPR, Resilient Packet Ring

La QoS dépend aussi de l’architecture et des performances d u réseau de transmission

10

Rappels

11

Commutation de messages#commutation de paquets

S D

Tps (msec)

-0-1

-2-3

-5002

5000... 3 2 1

5000

5000

1

1

1

1

2

2

5000

123...

123..

3

paquets de 1.5 Kb

-La commutation de paquet réduit le délai de commutation par u n facteur 3-Si perte d’un paquet, uniquement le paquet perdu est envoyé etnon le message complet

12

Commutation de messages#Commutation de paquets

• Commutation de messages pas de segmentation pa r la source .

Ex: message de 7,5Mb2 commutateurs de paquets3 liens à 1.5 Mb/s

Message

Message

Message

S D

Tps (sec)

-0

Message

-5-10-15

13

Service orienté connexion

• Échange de messages de Signalisation entre l ’émetteur, le récepteur et le réseau avant l ’échan ge du flux de donnée.

• service fournissant :acquittement , contrôle de flu x, contrôle de congestion.

• dans l ’Internet,TCP offre un service orienté connex ion.

14

• l ’émetteur envoie simplement le paquet d ’information dans le réseau

• pas de contrôle de flux • pas d ’acquittement• Pas de contrôle de congestion

UDP (téléphonie/Ip, Audio/Vidéo à la demande, vidéoconférence…)

Service sans connexion

15

Commutation synchrone

Réseau d ’aiguillage (matrice de connexion, bus…)

ITj ITx IT0

ITj ITx IT0

ITj ITx IT0

ITj ITx IT0

Mémoire de commande (table de routage)

Mémoire tampon

16

Commutation Asynchrone

Réseau d ’aiguillage (matrice de connexion, bus…)

ITj ITx IT0

ITj’ ITx’ IT0’

ITj’ ITx’ IT0’

ITj ITx IT0

Mémoire de commande (table de routage)

Mémoire tampon

17

8 eb

Multiplexage temporel Synchrone # Asynchrone

MUXB B B C B A C B A

ligne multiplex

8 eb

125 µµµµs

Rqs: -multiplex de sortie partagé dans le tempsentre les différentes voies incidentesDebit sortie=somme (debit entrée)

-en asynchrone:-motif de début/fin de trame ou debut/longueur de trame nécessaire-débits multiples et quelconques possibles-meilleur optimisation du lien-perte de synchro. (flux temps réel)

A B C C A B

Sync.

Async.

18

Hiérarchie Numérique Plésiochrone (PDH)

TN1TN1TN1TN1

voie n°1

voie n°30

30 voies303030

120 voies120120120TN1TN1TN1TN2

TN1TN1TN1TN3

480 voies480480480 TN4

1920voies

voie n°1 à n°30 8 bits toutes les 125 µµµµs

1920 voies 139,264 Mb/s

19

Multiplex primaire Européen (TN1 ou T1)

Débit : 2048 kb/s = 32 x 64 kb/s

30 voies de communication IT1 à 15

IT17 à 31

1 voie de verrouillage trame ( IT0 )

1 voie de signalisation ( IT16 )

20

Multiplexage statistique (asynchrone)

• "économique"

• ex:un lien 1Mb/Sec.Débit de chaque utilisateur -> 100 Kb/s

profil du débit « Bursty » (on/off)chaque utilisateur n ’envoie des data que pendant 10% du tps.

• Multiplexeur statique:chaque utilisateur a 100 kb/s.10 utilisateurs maxi.

• Multiplexeur statistique ou de paquet:35 utilisateurs.Probabilité d ’avoir 10 « collisions » <0,0004.

On peut supporter beaucoup plus d ’utilisateursavec une probabilité de « collision » faible.

21

• Multiplexage– Temporelle Synchrone (circuit) # Asynchrone (paquet)

• Commutation – temporelle Synchrone (circuit) #Asynchrone (paquet)

• Acheminement dans le réseau • circuit (RTC,RNIS..)• circuit virtuel (F.R, X25, ATM,…)

–permanent ou commuté• datagramme (IP,..)• Auto-acheminement (802.5 "source routing",..)

• RQs: – commutation: technique "Hard State"

• nécessite une signalisation de mise en place et des truction• modification du path "lourd"

– Routage: technique "Soft State"• premier paquet établit la route• rafraîchissement obligatoire

���� modification dynamique de la route (« path »)

Multiplexage # Commutation # Acheminement

22

Signalisation

23

Signalisation: définition

• Échange d ’informations entre les éléments d ’un réseau, nécessaire pour fournir et maintenir des services.

• Mise en œuvre d’un « circuit » ou d’une connexion:� pour l’établissement d’appel ou l’accès à un servic e:

� messagerie vocale� videoconference� N° vert� carte prépayée�…

24

Signalisation (usager)

25

NUMERISTNR

S

S S

SBus

adaptateur

télécopieur

Domaine de responsabilité

OPERATEUR

accèsde base

Exemple de configuration à bus passif

26

NUMERIS

S

Domaine de responsabilité

OPERATEUR

Groupementd'accèsde base

Exemple de configuration à "étoile de bus"

TNR

TNR

TNR

S

SSS

S

Terminaux "classiques"

codeur-décodeur

Terminalaudio-

conférence

CommutateurNUMERIS

ouPABX

télécopieurgroupe 4

27

NUMERISCanal B 1

Canal B 2

Canal D

Signalisationmini-messages,identification d'appel, etc.

Transferten mode paquet

Numéris : Utilisation des différents canaux

Signalisation"out band"

28

Numéris : Accès d'usager

Modes de raccordement au RNIS

• Côté "réseau"� L'Accès de base (144 kbit/s; 2B + D)

- 2 canaux B à 64 kbit/s pour la parole, les données,le texte et les images

- 1 canal D à 16 kbit/s pour la signalisation et lamini-messagerie

� L'Accès Primaire (2 Mbit/s; 30B + D)- Connexion de PABX, d'ordinateurs ou de serveurs

• Côté "terminal"� Le bus S

- 10 prises, 5 terminaux- Bus long ou court- Contact permanent avec le réseau

29

Signalisation « USAGER-RESEAU » exemple (RNIS)Format de trame (niveau 1)

DL F L B1 EDAFaN B2 EDM B1 EDS B2 EDL F L

48 bits250 µµµµs

DL F L B1 L DLFaL B2 L DL B1 L DL B2 L DL F L

2 bitsde décalage

Q

TNR TE

TNRTE

30

Structure de la trame LAP D (niveau 2)

Structure générale des trames du LAP D

FanionFanion ContrôleContrôled'erreurd'erreur InformationInformation CommandeCommande AdresseAdresse FanionFanion

Structure du champ adresse

8 7 6 5 4 3 2 1

SAPISAPI C/RC/R0/10/1

E/AE/A00

TEITEI E/AE/A11

SAPI: 0 signalisationSAPI: 16 données paquet/canal DSAPI: 63 maintenance/gestion….

31

Répertoire des trames utilisées dans le LAP D (niveau 2)

Application Format Commandes Réponses Codage8 7 6 5 4 3 2 1

Transfert d'information à trames multiples avec accusé de réception et sans accusé de réception

Transfertd'information

Supervision

Non numéroté

I (information)

RR (prêt à recevoir)

RNR(non prêt à recevoir)

REJ (rejet)

SABME (mettre enmode asyn. équilibréétendu)

UI (informations nonnumérotées)

DISC (déconnexion)

XID (échanged'identificateur)

RR (prêt à recevoir)

RNR(non prêt à recevoir)

REJ (rejet)

DM (modedéconnecté)

UA (accusé de réception non

numérotéFRMR (rejet de

trame)XID (échanged'identificateur)

N(S) 0

N(R) P

o. 4

0 0 0 0 0 0 0 1

N(R) P/F

0 0 0 0 0 1 0 1

N(R) P/F

0 0 0 0 1 0 0 1

N(R) P/F

o. 5

0 1 1 P 1 1 1 1

0 0 0 F 1 1 1 1

0 0 0 P 0 0 1 1

0 1 0 P 0 0 1 1

0 1 1 F 0 0 1 1

1 0 0 F 0 1 1 1

1 0 1 P/F 1 1 1 1

o. 4

o. 5

o. 4

o. 5

o. 4

o. 5

o. 4

o. 4

o. 4

o. 4

o. 4

o. 4

o. 4

32

Structure des messages (niveau 3)

Référence Appel (2 Oct.)(ex.identifie le dialogue d ’établissement)

Elément d’info. I(au format TLV:Type, Longueur, Valeur)

Elément d’info. j

Discriminateur de Protocole (1 Oct.)(data # info de gestion/contrôle)

Elément d’info. K

Type de message (1 Oct.)

33

Les principaux messagesutilisés par le protocole D

Nom du message SignificationEtablissement Demande d'établissement d'appel

Accusé de réception d'établissement Le numéro de destination reçu est réputéincomplet

Appel en coursL'information relative à l'appel est incomplète; l'appel est en coursd'établissement

Alerte L'usager destinataire est alerté

Connexion Réponse de l'usager

Accusé de réception Confirme la prise en compte de la réponse

Appel acheminéIndique une situation d'inter fonctionnement ou d'informations fournies par le réseau dans le canal B

Déconnexion Invitation à libérer la communication

Libération Confirme que la demande de libération est en cours

Fin de libération Confirme la libération de toutes les ressources allouées à l'appel

Ex. éléments d ’info:adresse source et dest.Service supportn°canalinfo des couches 4 à 7SDASig. Usager/usager

Phase d’établissem

entP

hase de déconnexion

34

Exemple de procédure pour un appelsimple à commutation de circuits

Décrochage EtablissementEtablissement

A.R. d'établissement

Info chevauchement

Appel en cours SonnerieAlerte

AlerteIndication de sonnerie Alerte Décrochage

Connexion

ConnexionArrêt de l'indication deretour d'appel

A.R. de connexion LibérationFin de libération

DéconnexionRaccrochage

Déconnexion Libération

Libération

Raccrochage DéconnexionDéconnexion

Fin de libération

LibérationLibération

Usagerdemandeur

Usagerdemandé

(X)

Terminal d'abonné

demandé (X)

Terminal d'abonné

demandé (Y)

Terminal d'abonnédemandeur (A)

par chevauchement

Le terminaldu demandéraccroche en premier

Le terminaldu demandeur

raccrocheen premier

A.R. de connexion

Fin de libération

Fin de libération

Flux de données

35

Contention d'accès au canal D

terminal A

terminal B

terminal C

canal écho

terminal A abandonne terminal C abandonne

Exemple de résolution de conflit

Structure de trame HDLC

adresse commande données FCS

“1” “1” “1”

“1”

“1” “1”

“1”

“1”

“1”

“1”

“0” “0”

“0” “0” “0”

“0” “0” “0”

“0”

“0” “0” “0”“0”

36

Résultat des conflits d'accès au bus

Terminal A

Terminal B

Signal sur le BUS

Données reçuespar la TNR

Emission de polarités opposéesla loi ET n'est pas réalisée

37

Signalisation (réseau)

38

Signalisation « RESEAU »

AbonnéNuméris

CSN

C

5

Protocole D

(AbonnéNuméris

CSN

C

5

Protocole D

)

SS7 (Signaling System 7)

Signalisation sémaphore

39

Réseau de signalisation

C4

C4

C5

C5

C5

serveur

C5

C4

PSPS

PSPTS

PTS

PTS

PTSPS

Réseau de signalisation

Réseau de transport des infor mations

40

Une architecture en couche

• Modèle

TUP ISUPTCAP

SCCP

MTP Level 3

MTP Level 2

MTP Level 1

MTP: Message Transfert Partroutage mode datagramme

SSCP:Signaling Connection Control PartService: Connectionless/Connection oriented

TCAP: Transaction Capabilities Application PartApplicatif

TUP: Telephone User PartApplicatif

DUP: Data User PartApplicatif

INAP: IN application partMAP : Mobile Application Part...

MAP INAP

41

Les couches applicatives

• ISUP: définit le protocole et les procédures pour l ’établissement, la gestion des circuits destinés a u transport de la voix et des données sur PSTN.

– Exemple:établissement d ’appel

STPW

STPX

SSPA

SSPB

(1)

IAM

(5)

RE

L (6) REL(2) IAM (3)

AC

M(5

)AN

M(7

) R

LC

Liens ss7

(6) ANM

(8)RLC(4) ACM

(0) switch A analyse du n°doit envoyer vers B réservation d ’un circuit libre

IAM :initial adress messageREL: releaseRLC: release messageACM: adress complete messageANM: answer message

« voice trunk »

42

Les couches applicatives

• SCCP: – offre un service orienté "connexion" (pas d'établissement de connexion

mais assure sequencement, contrôle de flux…)

– identifie l ’application de niveau supérieur– fonction d ’appellation globale « global title representation »

STPW

STPX

SCPL

SCPMSSP

A

(1) « 800 » query

(2)

« 800 » query

(3) response

(4) response

43

La couche physique et liaison

• MTP L1= lien 2Mbs (« T2 »), 64 kbs (V35), 64 Kbs (S0), ATM…• MTP L2

Flag Bsn Bib Fsn Fib Li Spare Crc

Flag Bsn Bib Fsn Fib Li Spare CrcStatus

Flag Bsn Bib Fsn Fib Li Spare CrcSio Sif

MTP L3

Fill In Signal UnitFISU

Link Status SignalLSSU

Message Signal UnitMSU 8 bits 7 1 7 1 6 2 <=272oc. 16

8 ou 16

279 oc. Maxi

DonnéesDe

Contrôle

Donnéesd’info.

44

La couche réseau

• MTP L3: SIF (Signaling Info. Field)

Dpcmember

Dpccluster

Dpcnetwork

Opcmember

Opccluster

Opcnetwork

Sparebits

Sls.

Routing Label

1 oc. 3 bits 5 bits

Couches Sup.(ex. ISUP)

ANSI point code: 24 bitsITU-T point code: 14 bits

ex itu-t point code 5557 peut être codé 2-182-5 (010 10110110 101)

zone région Signaling point

Sls: signaling link selection: partage du trafic sur plusieurs liens

Mess.type

CIC

Circuit Identification codedans le cas des messages Isup

45

Signalisation: suite

• "courant continu" ("DC" signaling)– analogique– nombre d'états limité (tension, courant…)– ex: « Ear&Mouth », Accès RTC

• "binaire" ("digital " signaling ou Common Associated Si gnaling:C.A.S.)

– les 4 bits de l ’IT16 du Mic E1 (C.A.S. E1)– le 7éme bit d ’un IT voix (64->56Kbs)

• " dans la bande " ("in band »)– « diffserv (ip ) » : numérique– DTMF (usager/réseau 300<<3400Hz): analogique

• "hors bande" ("out of band "/Common Channel Sig. :CCS)– > bande 3.5 à 4 Khz (analogique)

– SS7, canal D (RNIS), « rsvp (IP ) »: numérique

46

Services Télécom.:

Signalisation IP

47

C4

STP

STP STP

STP

STP

STP

SSPSSP

SCP

SCP

Liens « TRUNKS »

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

C5

C3C3

C4 C4

C4

C5 C5C5C5C5

Réseau de signalisation

Réseau de transport

48

• Topologie hiérarchique--> adaptée au transport de la voix (p rotocoles orientés circuit) mais pas optimisés pour le transport 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, iden tifiant 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éveloppem ent et le déploiement rapide de nouveaux services

Services télécoms dans les réseaux « circuit »:Constats

49

• 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.SIP )

– architecture centralisée facilite la création et le déploiement de services # architecture distribuée du RTC

• Connectivité vers les réseaux existants (Mobile, Adsl, RI (SS7 ),…)– Media gateways

– Signaling gateways

• "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 device, Any N etwor k")

Services télécoms dans les réseaux « Paquet » (IP):Atouts

50

Architecture générale(architecture dite “Next Generation Network” )

«Circuit»«Paquet»

RGwRGw

MGwMGw

Internet +QoS(Diffserv/Intserv)

Serveurcontrôle d’appels

Serveurcontrôle d’appels

SCTP

(SIP

)

H.323/SIP

Flux media (RTP/RTCP/…)

RTP/RTCP

SGw

Sign

alisa

tion:

Meg

aco/

H.2

48

SS7 Megaco/H

.248 (SIP)

PSTN/SS7

SGw: signaling gatewayMGw: media gatewayRGw: residential gateway

Plate-forme (services API)

Remarque : circuit de sig. Indépendant du circuit de transpo rt (du flux)

51

BTS

BTS

BTS

BTS

BSC

BSC

HLRVLR

MTP1

MTP2

MTP3

SCCP

SSP SSP

SCP

STP STP

IPe

MG

SG

CO COSN

MSC

VoIPGateway

MGCSOFTSWITCH

IP MediaServer

MTP2MTP3

SCCPTCAP

MTP1

MTP2MTP3

SCCPTCAPINAP

MTP1

MTP2

MTP3

SCCP

TCAP ISUP

MTP1

MTP2

MTP3

MTP1

MTP2

MTP3

SCCP

TCAP

GSM MAPISUP

MTP1

IN (SS7 ou sémaphore)

Réseaux IpMobile

Fixe

Signalisation SS7 pour réseaux intelligents convergents

52

Cohabitation des protocoles « IP »

UDP TCP

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

CRTP/MLPP

Transport

Réseau

SAP

Liaison

Physique

RTCP

RSVP

Mcast Fiable

RTSP

RTP

SIP SMTPHTTP

SDPAppli. Audio/Video Appli.

partagées

Création et établissement de séssion.

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

H323

53

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

• RFC 2543/ 3261-3266 (IETF SIP WG depuis 1999)• Pour l ’établissement de session « téléphoniques » et n on

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

• Protocole de signalisation client/serveur, de niveau 7 .• 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 + Localisation : terminal serve ur, "user"• Protocole orienté Transactions:

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

• Permet de garder un nombre minimal d’états (info) au n iveau des proxys. (« scalabilité »)

54

Serveur

Redirect /Proxy

Serveur

Localisation

ServeurRegistrar

Passerelle SIP

SIP UA

Passerelle SIP

SIP UA

Passerelle SIP

SIP UA

Terminal SIP

SIP UA

Terminal SIP

SIP UA

Terminal SIP

Agent Utilisateur (AU)

SIP

SIP UA

RTC

Mobile

H.323

Réseau « IP »

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

Protocole SIP: Architecture

SIP

Serveur de média SIP

SIP UA

55

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

SIPServeur

SIP

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)

ACK ( Cseq1 ACK)

ACK(Cseq1 ACK) ACK(Cseq1 ACK)ou

Flux MEDIA (ex. Audio)

180 Ringing (Cseq1.)

ACK(Cseq1 ACK)

-Localization-Registration-Redirection…...

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

200 OK (Cseq2 BYE)

BYE(Cseq2 BYE)

Transaction 1

Etablissement

Transaction 2

Transaction 3Libération

DialogueSIP

Cancel (Cseq1 INVITE)

BYE(Cseq2 BYE)

200 OK (Cseq2 BYE)

Communication

100 Trying (Cseq1 INVITE)

56

Entités principales d’une architecture SIP 1

(Session Invitation/Initiation Protocol)

• Agent Utilisateur Client et Serveur– Points terminaux capables d’émettre (Uac) ou de recevo ir (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 de localisation– Offre des services pour obtenir et mettre à jour des in formations

sur le destinataire (adresse courante et multiple, droi t, mot depasse, disponibilité, ...)

– Entité utilisée par les serveurs proxy et serveurs de red irection• relayer ou rediriger les messages

57

Entités d’une architecture SIP 2

• Serveur proxy– Entité intermédiaire active, à la fois client et serv eur– 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

• Serveur de redirection– Reçoit des requêtes et renvoie à l’émetteur une ou p lusieurs

adresses pour contacter le destinataire (régulation de c harge)– A la différence du serveur proxy, ce serveur n’initie pa s de

requêtes

58

Entités d’une architecture SIP 3

• Back to Back User Agent (B2BUa)– Maintien en mémoire des états relatifs à l’appel (c all

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 »

PROXYUA UA

Dialogue XDialogue X

B2BUA UA

Dialogue XDialogue y

59

Messages Requêtes:INVITEACKBYECANCEL OPTIONREGISTER…..

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

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

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

Principaux messages SIP :

60

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 descrip tion

de la session (utilisation de SDP: type de média au dio, vidéo, data, format, codage en vigueur)

• Méthode ACK– Indique que l’appelant a reçu une réponse final à l’i nvitation– Le corps du message peut contenir la description final e de la

session (négociation des capacités)– Un corps vide indique que la description du message I nvite

sera utilisée

61

Méthodes de requête (suite)

• Méthode REGISTER– Gestion (ajout, maj, suppression) des liaisons (ident ifiant agent

utilisateur, adresse contact) enregistrées dans le servi ce de localisation

– Egalement utilisé pour interroger le service de liaison (serveurproxy, redirection)

– L’agent utilisateur doit indiquer la durée de vie de l a liaison (champ « expire »)

– 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 c ontenu, ..

– Peut être émis en dehors ou à l’intérieur d’une sessi on

62

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ép onse– Utilisé par les serveurs proxy lors d’appels parallèles.

• Méthode BYE– indique à l’autre participant la clôture de la sessi on

• Autres méthodes (pour le support de services évolués)– PRACK (RFC3262)– MESSAGE, PUBLISH,SUBSCRIBE & NOTIFY (RFC3265) - Servic e 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 batte ries (Pda, terminal mobile…)

• Pb: fiabilité des MESSAGES (SIP sur UDP)

63

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)– 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

64

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

– prévention des boucles, garantie le chemin de retour(billing,...)

• Contact : pour l’enregistrement d’informations (Register)• Content-type : type de média du corps (ex. application/sdp,

application/xml, texte/plain …)• ...

65

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

En-tête de message

corps de message(ex.format SDP)

Ligne de début (méthode URL SIP/2.0)

INVITE sip:pascal@int.fr SIP/2.0Via:SIP/2.0/UDP durer.enic.frFrom:Ahmed<sip:ahmed@enic.fr>To:Pascal<sip:pascal@int.fr>Call-ID: 1234567890@rodin.enic.frCseq:1 INVITEContact::<sip:ahmed@193.48.251.108>Content-Type:application/SDPContent-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

méthode URL SIP/2.0

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

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

66

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

Type réponse en-têtemessage

corpsmessage

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

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

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:ahmed@enic.fr>To:Pascal<sip:pascal@int.fr> :tag=2544Call-ID: 1234567890@rodin.enic.frCseq:1 INVITEContent-Type:application/SDPContent-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

67

Session Description Protocol

• SIP utilise le protocole SDP (session description protocol, RFC 2237)

• SDP est employ é pour d éfinir les attributs d ’unesession SIP avec une syntaxe standard.

• Les param ètres SDP sont plac és dans le corpsd’une requ ête SIP

• Les ent êtes SDP sont encod ées en format text etsont 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

68

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

z*= fuseau horaire k*= clef de crytpo.a*= attributs de session

c*= info. Sur la connexion

t= 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 de la session

Description « temporel »

Description « réseau »

Format SDP <type>=<valeur>Description

69

Adresse SIP

• SIP exploite des formats d’adresses de type e-mail : user/service_Id@domaine/host_name

– Adresse logique indépendante de l’@ « physique » (IP)– Identifie un utilisateur (user_Id peut être un individ u, un groupe)

ou un service (service Id) – Identifie l’adresse de contact (nom DNS, adresse IP…)

• Différents formes possibles– user@domain ahmed@tl1.fr– user@host ahmed@pc.tl1.fr ou ahmed@193.48.251.183– service@IP_adress AudioconfA45@mcu.tl1.fr– phone-number@gateway +33608923951@passerelle.tl1.fr

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

70

Les URI SIP

• Utilisé dans les requêtes (entêtes: From, To, Contac t)• Intégration dans des pages HTML, emails

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

Exemples : Ahmed@tl1.fr-> sip:meddahi@PC1.enic.fr;maddr=10.0.0.1;q=0.8Ahmed@tl1.fr -> sip:+33608923951@passerelle.tl1.fr;user=phone;q=0.8Ahmed@tl1.fr -> sip:voicemail@media-engine.tl1.fr;msgid=78;q=0.1

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

infos_utilisateur

host

paramètres

en-têtes

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

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

71

Serveur

Redirect /Proxy

Serveur

Localisation

ServeurRegistrar

Entité Administrative:SIP@tl1.fr (Serveur SIP du domaine « tl1.fr »)

BD

183.48.251.107

183.48.251.108

REGISTER sip:tl1.fr SIP/2.0

To: sip:ahmed@tl1.fr

From: sip:ahmed@tl1.fr

Contact: sip:ampc@183.48.251.107,

sip:amtel@183.48.251.108…

1

sip:ampc@183.48.251.107

sip:ahmed@tl1.fr sip:amtel@183.48.251.108

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

SIP/2.0 200 OKExpires: 3600…

3

Protocole SIP : processus d’enregistrement

72

term1

ahmed@tl1.frahmed@tl1.fr

term1.tl1.frterm1.tl1.fr

tl1.frtl1.fr

Sipproxy

term2

serveur de

localisation

serveur de

localisation

1

pasc

alpa

scal

2

Pas

cal@

term

2.in

t.fr

Pas

cal@

term

2.in

t.fr

3

INVITEpascal@term2.int.fr

INVITEpascal@term2.int.fr

4

pascal@term2.int.frpascal@term2.int.fr5

200 OK200 OK6200 OK200 OK

7

ACKACK8

ACKpascal@term2.int.fr

ACKpascal@term2.int.fr

9

Protocole SIP : Exemple "INVITATION" dans le cas du « Proxy »

int.frint.fr

DNS

Requête «

DN

S»:

@ S

IP du proxy IN

T?

INVITE sip:pascal@int.fr SIP/2.0

To: sip:pascal@int.fr

From: sip:am@enic.fr;tag=4711

Contact: sip:amtel@183.48.251.108

INVITEpascal@int.fr

INVITEpascal@int.fr

Flux média (ex. audio )

73

ahmed@tl1.frahmed@tl1.fr

term1.tl1.frterm1.tl1.fr

tl1.frtl1.fr

SipRedirect

term2.int.frterm2.int.fr

pascal@term2.int.frpascal@term2.int.fr

INVITE pascal@int.frINVITE pascal@int.fr1 pa

scal

pasc

al

2

Pas

cal@

term

2.in

t.fr

Pas

cal@

term

2.in

t.fr

3

SIP/2.0 302 Moved temporarilyContact : pascal@term2.int.frSIP/2.0 302 Moved temporarilyContact : pascal@term2.int.fr

4

INVITE pascal@term2.int.frINVITE pascal@term2.int.fr6

200 OK200 OK7

ACKACK8

Protocole SIP : Exemple "INVITATION" dans le cas d'une « redirection »

ACKACK5

Serveur de localisationServeur de localisation

int.frint.fr

74

Service « Click to dial » (utilisation du sip « B2Bua » )

Serveur web

sip « B2Bua »0. HTTP

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)

5. Ack(SDP B) 5. Ack

75

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

1’. Invite

(SDP Mixer)

1’. Invite

(SDP Mixer)

2’. Ok

(SDP A

)

2’. Ok

(SDP C)

AB

Mixer audio

sip:A@enic. fr

sip:confA45@enic.fr sip:B@int.fr

sip:C@enst. fr

c

3’. Ack

3’. Ack

1’. I

nvite

(SDP M

ixer

)

2’. O

k(S

DP B)

3’. A

ck

Media RTPAudio ->A<- B+C

Media RTPAudio ->A+C<- B

Media RTPAudio ->A+B<- C

MCU:Pont audioconférence

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

0. HTTPServeur

webConfA45@TL1.fr

sip «B2Bua»(Focus)

76

gilles@TL1.frgilles@TL1.gilles@TL1. frfr

SIP Serverint.fr

SIP ServerSIP Serverint.int.frfr

SIP Serverenst.fr

SIP ServerSIP Serverenstenst..frfr

ahmedahmed@lab.

@lab.enstenst..frfr

ahmedahmed@office.

@office.enstenst..frfr

INTERNETINTERNET BACKBONEBACKBONE

1

10116

14

28

12

13397

5

4

15

16

Mobilité (nomadisme) et SIP: exemple de scénario

Exercice: Détailler le schéma en précisant les méth odes/messages et les enregistrements contenus au niveau des serveurs « SI P ».

77

Scénario: description (suite)

– Ahmed est potentiellement joignable sur trois sites : l’INT (bureau) et l’ENST (bureau et labo.)

– Ahmed publie un seul identifiant d’appel: ahmed@i nt.fr

– Ahmed est en déplacement à l’ENST et enregistre sur le serveur SIP de l’INT l’adresse ahmed@enst.fr (1)

– Il enregistre aussi sur le serveur de l’ENST, ses d eux adresses de contact (2, 3)

• ahmed@office.enst.fr, ahmed@lab.e nst.fr

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

78

Scénario: description (suite)

– gilles@ tl1.fr appel ahmed@int.fr (4) (résolution DNS = Serveur SIP Lucent)

– Le serveur SIP de l’INT localise l’adresse courante de Ahmed (5)et retransmet donc l’appel à ahmed@enst.fr (6)

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

– Le poste du labo selon sa configuration redirige l’app el vers leserveur SIP de l’INT, qui détecte une boucle et retou rne un message d’erreur (10,11)

– L’erreur est propagée par le poste au serveur SIP de l’EN ST(12)– Dans le même temps, Ahmed a répondu à l’appel depui s son

bureau (13)

79

Scénario: description (suite)

– Le serveur SIP de l’ENST a maintenant les deux réponse s et peut retourné l’acceptation de l’appel au Serveur SIP d e l’INT (14) qui fait de même vers l’agent client « Gilles » (1 5)

– A ce stade, Les serveurs peuvent « détruire » les états l iés à l’appel. Ahmed et Gilles communiquent directement (f lux média) sans passer par les serveurs intermédiaires (16)

• Caractéristiques de SIP mises en évidence par ce scénario

– Forking– Mobilité (utilisateur)– Détection de boucle

80

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

• Sensibilité au contexte du terminal/utilisateur:• Localisation, disponibilité, « humeur » de l’utilisat eur

• Permettre le support des applications classiques ma is aussi nouvelles:

• Transfert d’appels, suivie d’appels… (classique)• messagerie instantanée, applications basées localis ation.

• Modèle IMPP:

81

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

200 OKEvent:presenceExpires:1800

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

200 OK

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

200 OKEvent:presenceExpires:1800

Serveur de présencePA serveur

SIP « Watcher » UAPDA

SUBSCRIBE (pres:B@TL1.fr)Event:presenceExpires:3600Accept: text/plain….

200 OK

202 ACCEPTEDEvent:presence

NOTIFYEvent:presenceExpires:1759Subscr-State:activeSip:PDA@tl1.fr….

SIP Presence UA

SIP et IMPP:

NOTIFYEvent:presenceSubscr-State:pending

82

<presence ... entity=" pres:B@TL1.fr ">

<tuple id=" mobile-im ">

<status>

<basic> open </basic>

</status>

<contact priority="0.8"> im:B@sms-gw.TL1.fr </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>

<tuple id=" interactive-mm ">

<status>

<basic> closed </basic>

</status>

<contact priority="1.0"> sip:B@TL1.fr </contact>

</tuple>

<note> je serai en déplacement la semaine prochaine </note>

</presence>

Données de présence au format PIDF: Pres. info. Data F ormat (XML)

Remarques: Pb: congestion (1 « subscribe/notify » et 1 « mes sage » par RTT, ex 1/ 5sec.) durée de vie des batteries (Pda, terminal mobile…); fiabilité des MESSAGES (SIP sur UDP)

83

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

• 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)

84

INVITEPréconditions

SIP UAS

SIP et la QoS (RFC 3312):

SIP UAC

rcv

snd

QoS

\/x

\/x

Des.Cur.

rcv

snd

QoS

\/x

\/x

Des.Cur.

183 Session ProgressPréconditionsconfirmation request

PRACK

200 OK (PRACK)

Réservation ressources (QoS)

UPDATEPréconditionsconfirmation response

200 OK (UPDATE)Préconditions

RINGING

rcv

snd

QoS

\/\/

\/x

Des.Cur.

rcv

snd

QoS

\/\/

\/x

Des.Cur.

rcv

snd

QoS

\/\/

\/\/

Des.Cur.

rcv

snd

QoS

\/\/

\/\/

Des.Cur.

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=a=a=a=currcurrcurrcurr::::qosqosqosqos e2e none e2e none e2e none e2e none a=des:a=des:a=des:a=des:qos mandatoryqos mandatoryqos mandatoryqos mandatory e2ee2ee2ee2e sendrecvsendrecvsendrecvsendrecv

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=a=a=a=currcurrcurrcurr::::qosqosqosqos e2e none e2e none e2e none e2e none a=des:a=des:a=des:a=des:qos mandatoryqos mandatoryqos mandatoryqos mandatory e2ee2ee2ee2e sendrecv sendrecv sendrecv sendrecv a=a=a=a=confconfconfconf::::qosqosqosqos e2ee2ee2ee2e recv recv recv recv

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=a=a=a=currcurrcurrcurr::::qosqosqosqos e2ee2ee2ee2e send send send send a=des:a=des:a=des:a=des:qos mandatoryqos mandatoryqos mandatoryqos mandatory e2ee2ee2ee2e sendrecv sendrecv sendrecv 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=a=a=a=currcurrcurrcurr::::qosqosqosqos e2ee2ee2ee2e sendrecv sendrecv sendrecv sendrecv a=des:a=des:a=des:a=des:qos mandatoryqos mandatoryqos mandatoryqos mandatory e2ee2ee2ee2e sendrecv sendrecv sendrecv sendrecv

85

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

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

Exemple de négociation de QoS:

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

Confirmation demandée (confirmation request)

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

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

-négociation d’un mécanisme pour traverser les firewall ou le s serveurs NAT. 86

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 sop histiqués)

• Transfert vers email, messagerie instantanée, page web…

• Gestion des capacités– configuration, négociation des paramètres de la sess ion,

hétérogénéité des terminaux

• Etablissement de la session– mise en relation des deux participants

• Gestion de la session – modification, terminaison

87

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:– 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)

88

« Traces » SIP (et H.323)

89

Trace de message SIP (texte)

90

Trace de message SIP (texte)

91

Format message de signalisation H.225 (éléments d ’info. de type « user-user » d ’un message Q931)• Les éléments d'informations sont en format TLV (Type/ Longueur/Valeur)

– Type• fonction de

l'élément d'information

– Longueur• de la partie

variable

– Variable• peut contenir

des éléments d'informationsimbriqués

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

longueurlongueur

Valeur (corps du message « H.323 »

codé en ASN.1)

Type de message (ex. « ALERTING »)

92

• 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 (BER, PER…)

Trace H225: ASN1 (Abstract Syntax Notation 1)

93

• 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.,

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

• structures (SEQUENCE),

• lists (SEQUENCE OF),

• choice between types (CHOICE),

• etc.

Trace H225 (suite) ASN.1 (Abstract SyntaxNotation 1)

94

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 (0..255),

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

...

} OPTIONAL,

...

}....

. suite

.

.

H323-UU-PDU ::= SEQUENCE

{

h323-message-body CHOICE

{

setup Setup-UUIE,alerting Alerting-UUIE,

callProceeding CallProceeding-UUIE,

connect Connect-UUIE,

}nonStandardData NonStandardParameter OPTIONAL,

...

}

Setup-UUIE ::= SEQUENCE

{…

activeMC BOOLEAN,

...

}

}

END

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

95

Trace de message H225 (ASN.1)

96

Trace de message H225 (ASN.1)

97

Trace de message H225 (ASN.1)

98

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 preuves• adopté par les industriels

99

• SIP (IETF)1.5 aller-retourSimple (format

«texte»)protocole ouvertdistribuéesupportésupportésupporté

Remarques sur SIP (et H323): suite

• H323 (ITU-T)6 à 7 aller-retourComplexe (compilateur)

ajout d ’extensions propriétaires

Centralisée avec le MCUH323 V2+H.450non supporté dans la V1non supporté

Nbre d'échangespour établir la com.

Maintenance du code

Evolution

Conférence

Services

Detection boucle

Multicast

www.sipcenter.com et www.openh323.org

100

Modèle de création de services SIP

REFER

Pile SIP

IMCall control

UDP TCP,SCTP, TLS

IP/IP Multicast/QoS

MESSAGe

SUBSC.

NOTIFy

PUBLISh

Telephonie 3G …..

PRACk

SeSSti

mer

OVERLAp

SECURITé

.

.

.

.

INFO

SIP

Services

SIP

(Applications)

API

APIINVITE

ExtensionsSIP

101

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

Couche signalisation

Couche Réseau

YX Z

Plate-forme services

« 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 »

102

Rés

eau

paq

uet

Rés

eau

paq

uet

Services télécoms: Services JAVA API

103

– JAIN TCAP – Java Call Control–JAIN MGCP– JAIN SIP– JAIN INAP– JAIN MEGACO– JAIN SIP Lite– JAIN SDP– JAIN ENUM– JAIN Presence– JAIN Instant Messaging– JAIN SIMPLE (Presence +IM)– OSS/QoS– OSS/Billing…...

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

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

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

104

Délai Connexion

0

5

10

15

20

25

30

35

40

S1 S2 S3ScenarioD

ela

i(s

ec.

)

LAN802.11bCable ModemModem 56 Kbs

Délai“pre-selection”

0

0,5

1

1,5

2

2,5

3

S11 S2( no TRYING ) S 3

ScenarioDe

lai

(se

c.)

LAN802.11bCable ModemModem 56 Kbs

Délai “post-selection”

0

5

10

15

20

25

30

S1 S2 S3ScenarioD

ela

i(s

ec.

)

LAN802.11bCable ModemModem 56 Kbs

ITU-t rec (E.721)Circuit network (charge “normale”)

Délai “post-selection”moyenne 95%

3 sec. 6sec.

8 sec. 11sec.“International” 1

1 8-10 noeuds

Appel“Local” 111-4 noeuds

Appel “Regional” 115-7 noeuds

5 sec. 8sec.

1S1:1 serveur SIP S2:1 serv. SIP (Redirect)S3:2 serveurs SIP

105

Performance du flux RTP

Delay(ms) 13.5 - 490

0.5 - 20Jitter(ms)

Loss (%) 0 - 9

150 - 400

20 - 80

5 - 10

Measures1(G.711)

ITU-t2 rec.

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

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

106

Conclusion

107

• Services Télécoms sur IP: Convergence Fixe/mobile et V oix-Vidéo-Données (multiServices):

– une seule infrastructure réseau pour la « voix » et l es données (et vidéo)

– Administration d ’une architecture uniqueréduction des coûts de communication?Administration plus simple et mois onéreuse?

• Developpement et déploiement rapide d'applications " nouvelles et plus riche" (web call center, « VoIP » contextuel, Appli. Basées localisation…)

– services de téléphonie existants sur IP?

• Qualité de Service?– Dépend essentiellement de la technologie réseau sous-jacent (QoS).

• Facilité et rapidité de création de services réseaux v ia une certaine « Abstraction » de la « couche réseau » (ex. A PI JAINxxx)

Conclusion

108

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 dynamiques et

variables.���� Impacte sur les performances.

���� Avant un déploiement total des services, les réseaux“paquets”doivent fournir le même niveau de Qualité de 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)

109

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)• Localisation géographique (applications basées local.)• Appels d’urgences• Interception d’appels• Performance de la signalisation (ex. SIP)• …

110

Quelques références (liste non exhaustive)

• Livres:

– « Understanding the Session Initiation Protocol », Ala n B. Johnson, Editions Artech House.

– « Codecs, H.323, SIP, MGCP, déploiement et dimension nement », Olivier Hersent, David Gurle et Jean-Pierre Petit - Ed itions Dunod

• Sites web:– www.sipcenter.com– http://java.sun.com/../jain/

111

ANNEXES

112

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

113

Exemple de flot « MGCP »

0 <- RQNTAck ->

(ready)

1 Off- NFTY ->

hook (off-hookrecorded)

Ack<-

2 (dialtone)

<- RQNTAck ->

3 digit

4 (nodialtone)

5 digit...

TerminaleRTC

PasserelleMG

Serveur Megaco (MGC)

Terminal « IP »(ex. H323)

Serveur d’appels(ex.H323)

Etape

Rq: en noir signalisation MGCP

114

Exemple de flot « MGCP »(suite) :

10 digit

->10a NFTY(match)Ack<-

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

- -11 ARQ ->

12 <- - - ACFMDCX<-12a

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

ARQ14 ->ACF15 <-

16 <- ALERTING(ringback)

17 <- RQNT+MDFY (SDP)

Ack ->

EtapeTerminale

RTCPasserelle

MGServeur

Megaco (MGC)Terminal « IP »

(ex. H323)Serveur d’appels

(ex.H323)

115

Exemple de flot « MGCP » (suite) :

18 CONNECT<-

19 (cut-through)

<- RQNT+MDFY

(fullduplexmediatransferrecorded)

->ACK

Etape TerminaleRTC

PasserelleMG

Serveur Megaco (MGC)

Terminal « IP »(ex. H323)

Serveur d’appels(ex.H323)

116

Exemple de flot « MGCP » (suite) :

<- Ack20 NTFY ->on-hook

21 RELEASE - - ->

<- RQNT+DLCX21a

Ack ->21b

<-22 - - RELEASECOMPLETE(Media

transfertstopped)

(Accounting) ->

Etape TerminaleRTC

PasserelleMG

Serveur Megaco (MGC)

Terminal « IP »(ex. H323)

Serveur d’appels(ex.H323)

Serveurtaxation« Acc »

117

Détail des messages MGCP:0)RQNT 1201 endpoint/1@rgw-2567.enic.fr MGCP 0.1 N: ca@ca1.enic.fr:5678 X: 0123456789AB R: hd 0)200 1201 OK

1)NTFY 2001 endpoint/1@rgw-2567.enic.fr MGCP 0.1 N: ca@ca1.enic.fr:5678 X: 0123456789AB O: hd1)200 2001 OK

2)RQNT 1202 endpoint/1@rgw-2567.enic.fr MGCP 0.1N: ca@ca1.enic.fr: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/1@rgw-2567.enic.fr MGCP 0.1N: ca@ca1.enic.fr:5678 X: 0123456789AC O: 2,3,4,5,6,7,8,T10a)200 2002 OK

10b)CRCX 1204 endpoint/1@rgw-2567.enic.fr 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

m=audio 3456 RTP/AVP 0

12a) MDCX 1205 endpoint/1@rgw-2567.enic.fr 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

118

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/1@rgw-2567.enic.fr MGCP 0.1C: 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

Détail des messages MGCP (suite):19)MDCX 1208 endpoint/1@rgw-2567.enic.fr MGCP 0.1

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

19)200 1208 OK

20)NTFY 2005 endpoint/1@rgw-2567.enic.fr 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: FDE234C1 X: 0123456789B0 R: hd

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

119

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

120

Megaco/h248

• MGCP• notion: « endpoint »,

connexions• 1 transaction=1 commande• 1type de reponse• commandes:

– EndpointConfiguration

– NotificationRequest– Notifications

– CreateConnection

– ModifyConnection– DeleteConnection

– AuditEndpoint

– AuditConnection– RestartinProgress

• TEXTE

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

(TransactionPending)• commandes:

– Add– Modify

– Subtract

– Move– AuditValue

– AuditCapabilities

– Notify– ServiceChange

• TEXTE, BINAIRE (asn.1)

121

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

Reply=50009{

Context=5000{subtract=A5555{

statistics{

nt/os=45123;

nt/dur=40}},subtract=A5556{ statistics{rtp/ps=1245,nt/os=62345,rtp/pr=780,nt/or=45123,

rtp/pl=10,rtp/jit=27,}}

122

• 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

• Définit les mécanismes ou protocoles de bout en bout afin d ’assurer un transport performant et robuste des messages transportés.

Protocole SCTP(Stream Control Transport Protocol, RFC 2960)

123

Protocole SCTP: Composantes

Module Adaptation (M2UA)

IP

Ce que doit assurer SCTP:

* fiabilité* faible latence* disponibilité•« multilink »•détection rapide de coupure•fonction « keep alive »* synchro des horloges* sécurité* ...

UDP-TCP

Couche Transport (SCTP)

124

Protocole SCTP: suite

ApplicationSpecificLayers ISUP

TCAPSCCP

MTP Level3

MTP Level2

MTP Level1

GSMMAP/IS-41

INAPTUP

Appli.orientés « Transaction »

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

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

Sig. orientée

« Transactions

MTP3

M2UAM3UA

SCTP

IP

TCAP

SUA

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

125

MGC

IP SCP

MG

SG

SS7/SCTP

MGCP

MGCP

SS7

MGC

[SG][MG]

Q931/Q921

media

(Q931/SCTP)MGCP

Architecture 1: Architecture 2:

Protocole SCTP:

Réseau IP

MGCP

T2

126

51

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

*0 t

Offset:11200

Offset: 4800=600ms6400=800ms

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

11600=1,45sec (paquet « RTP » envoyé)

timestamp:11200