NGN protocoles.pdf

(Formation NGN) - D1 - 08/06/2001

Le prsent document contient des informations qui sont la proprit de France Tlcom. L'acceptation de ce document par son destinataire implique, de la part de ce dernier, la reconnaissance du caractre confidentiel de son contenu et l'engagement de n'en faire aucune reproduction, aucune transmission des tiers, aucune divulgation et aucune utilisation commerciale sans l'accord pralable crit de France Tlcom R&D

Protocoles de commande du NGN

La communication de ce document est soumise autorisation de France TlcomR&D

(Formation NGN) - D2 - 08/06/2001

France Tlcom R&D

Introduction (1/2)

Nouvelle rpartition des fonctions de commande du rseau apparueavec les architectures NGN Serveur de commande externeRseau de transport paquet

Sparation des fonctions qui rsidaient traditionnellement dans la mme machine : distinction entre les fonctions de commande du support et les fonctions de commande d appel

Consquences :Augmentation du nombre d interfaces entre les entits de commande Introduction de nouveaux protocoles de commande entre ces entits


(Formation NGN) - D3 - 08/06/2001

France Tlcom R&D

Introduction (2/2)

Call

Server

Megaco/H.248 Megaco/H.248

BICC, H.323, SIP(T)

ISUP

CAA IWU

ISUP

CAAIWURseau ATM, IP

Call

Server

Principe de rpartition : Entit avec peu d intelligence charge de raliser une adaptation entre le rseau synchrone et

le rseau paquet l Entit baptise unit dinterfonctionnement (IWU) , Media Gateway (MG) ou BearerControl Function (BCF).

Entit concentrant l intelligence, traitant la signalisation de commande d appel et pilotant une ou plusieurs unit(s) d interfonctionnementl Entit baptise serveur d appel (CS) , Media Gateway Controller (MGC), Call Service Function (CSF) ou Softswitch.

Normalisation des protocoles associs ces nouvelles interfaces : condition essentielle pour garantir l interoprabilit entre des machines d industriels diffrents

(Formation NGN) - D4 - 08/06/2001


BICCBearer Independent Call

Control

Caroline Salahun DAC/ACE


(Formation NGN) - D5 - 08/06/2001

France Tlcom R&D

GnralitsHistorique :

Travaux lancs l UIT -T (Commission 11) en mars 1999 Fort engouement suscit par ces travaux mens en collaboration avec l ATM Forum, l ETSI et

l ANSIPremire version du protocole (BICC CS1) acheve en dcembre 1999 (approuve en juin 2000)

Objectif : dfinir un protocole de commande dappels capable de fournir, quel que soit le support utilis (ATM AAL1, ATM AAL2, IP), les mmes services que ceux actuellement offerts dans les rseaux tlphoniques traditionnels

Principes fondamentaux :Minimisation des impacts sur les rseaux actuels Prservation des fonctions et services existantsPossibilit de raliser une migration en douceur des rseaux tlphoniques classiques vers les

rseaux de nouvelle gnration

Caractristique principale : protocole bas sur l ISUPRutilisation de l existant (limitation cots et temps de dveloppement)Hritage des fonctions et services supplmentaires supports parl ISUP Interfonctionnement simple et quasiment transparent entre BICC et ISUP


(Formation NGN) - D6 - 08/06/2001

France Tlcom R&D

Architecture (1/2)Obit au principe de sparation entre les plans de commande d appel et de transfert

Utilisation conjointe :l d un protocole gnrique de commande d appel (BICC), etl d un protocole de commande du support propre au type de rseau paquet utilis (ex: UNI4.0, DSS2, PNNI, B-ISUP, AINI, IP BCP)

ISN

CSF

Me gac o/H .248 Megac o/H .248

TSN

BI CC

I SU P

CAA BCF Rseau ATM, IP

CSF

M egac o/H .248

ISN

I SUP

CAA

CSF"CSF"

CMN

Rseau ATM, IP

BI CC BI CC

BIWF

BCF

BIWF

BCF

BIWF

Le serveur d appel (CSF : Call Service Function) comporte les fonctions de traitement d appel. Il traite la signalisation BICC et commande un (ou plusieurs) BCF(s)

Le BCF (Bearer Control Function) traite la signalisation propre au support

Lunit dinterfonctionnement (BIWF : Bearer Interworking Function) contient la fois le BCF et les ressources physiques associes au support.


(Formation NGN) - D7 - 08/06/2001

France Tlcom R&D

Architecture (2/2)Plusieurs types de nuds sont dfinis dans larchitecture de rfrence :

Un SN (Serving Node) est compos d'un serveur d'appel (CSF) et d'une ou plusieurs unit(s) d'interfonctionnement (BIWF)

Trois types de SN sont dfinis :

lLISN (Interface Serving Node) = nud dinterfonctionnement entre un rseau BICC et un rseau dun autre type (ex : RTC, rseau daccs, rseau SIP, H.323)

lLe TSN (Transit Serving Node) = nud de transit lintrieur dun rseau BICC

lLe GSN (Gateway Serving Node) = nud de raccordement entre deux rseaux BICC (interconnexion entre oprateurs)

Le CMN (Call Mediation Node) est un nud comportant une fonction CSF et ne commandant aucune unit dinterfonctionnement .


(Formation NGN) - D8 - 08/06/2001

France Tlcom R&D

Le concept dindpendance (1/2)Indpendance vis vis du support

Protocole non spcifique un type de support particulier

Spcificits du support masques vis vis du serveur d appel

Serveur d appel idalement transparent vis vis des informations relatives au support

Objectifs :

l Permettre une volution indpendante des couches commande d appel et transfert

l Offrir la possibilit d utiliser un mme protocole de commande d appel au-dessus de

divers types de support

Obstacles :

l Difficile compromis entre :

le respect du concept d indpendance vis vis du support (rpartition des fonctions

conforme la dcoupe appel/support) et

la conception de passerelles aux fonctionnalits rduites (concentration de

l intelligence dans le serveur d appel)

l Risque d accroissement de la spcificit des passerelles vis vis du protocole de

commande d appel


(Formation NGN) - D9 - 08/06/2001

France Tlcom R&D

Le concept dindpendance (2/2)

Indpendance vis vis des couches de transport de signalisationUtilisation de Convertisseurs de Transport de Signalisation (STC)

l spcifiques la pile de protocole utilise pour le transport de la signalisation

l masquant les spcificits de la couche sous-jacente vis vis du protocole BICC

Les Convertisseurs de Transport de Signalisation dj dfinis permettent le dploiement du protocole BICC sur :

l MTP3/MTP3B, SSCOP, SSCOPMCE, SCTP ( venir)


(Formation NGN) - D10 - 08/06/2001

France Tlcom R&D

Un protocole bas sur l ISUP

Protocole construit partir de l ISUP 2000 (version ISUP UIT la plus rcente) auquel ont t apportes les adaptations ncessaires pour prendre en compte :

la sparation appel/supportl Exemples :

mcanisme de corrlation appel/support,

transport d informations relatives au support,

adaptation des procdures d tablissement et de libration d appel

la disparition de la notion de circuitl volution des procdures de gestion de circuit

Se positionne en tant que successeur de l ISUP


(Formation NGN) - D11 - 08/06/2001

France Tlcom R&D

BICC CS1

BICC CS1 : premire version du protocole BICC

Dfini dans la Recommandation Q.1901 approuve en juin 2000

crit en delta par rapport aux Recommandations ISUP (Q.761 Q.765)

Conu pour le trunking ATM (ATM/AAL1, ATM/AAL2)

Outre les procdures d appel de base adaptes au contexte NGN, BICC CS1 comporte deux procdures particulires :

Ngociation/modification de codecs

Rutilisation de connexions existantes (systme de cache de connexions ATM)


(Formation NGN) - D12 - 08/06/2001

France Tlcom R&D

Principales caractristiques de lappel de base (adaptation au contexte NGN) (1/2)

tablissement dappelDfinition de deux modes d tablissement :l tablissement dans le sens avant : connexion tablie dans le mme sens que l appel

l tablissement dans le sens arrire : connexion tablie dans le sens inverse par rapport

l appel

Transport dinformations relatives au supportExemples :l type de support (ex : AAL1, AAL2)

l adresse des passerelles

l codecs


(Formation NGN) - D13 - 08/06/2001

France Tlcom R&D

Principales caractristiques de lappel de base (adaptation au contexte NGN) (2/2)

Corrlation appel/supportNcessit de corrler les messages de commande d appel et les messages de commande du

support

Cration d un nouvel identifiant : BNC- IDl Unique au sein de la passerelle (BCF) qui le gnre

l Utilis pour :

corrler les messages de commande d appels et de commande du support

identifier la connexion associe l appel


(Formation NGN) - D14 - 08/06/2001

France Tlcom R&D

Exemple : tablissement d appel dans le sens arrire

CSF

BCF

CSF

BCF

IAM

IAM

IAM (BIWF-Add= x), (BNC-ID= x1), (CIC=a )

Add=x

BNC-ID=x1

Bearer Setup Request

Bearer Setup Connect

(BIWF-Add=x), (BNC-ID=x1)

SWN SWN

Bearer Setu p RequestBearer Setup Req uest

Bearer Setup Con nect

Bearer Setup Connect

Corrlation l 'aidedu BNC-ID

ACMACM (CIC=a)ACM


(Formation NGN) - D15 - 08/06/2001

France Tlcom R&D

BICC CS2Envoi en Dtermination l UIT-T en dcembre 2000 (Appel de base dfini dans les

Recommandations Q.1902.1 Q.1902.4)

Compatibilit arrire garantie avec BICC CS1

volutions principales par rapport BICC CS1Commande d appels sur dorsal IPExtension des procdures aux commutateurs locaux (CAA, MSC)Sparation physique entre CSF et BCF (serveur d appel/passerelle)

volutions fonctionnelles diversesExemples :l Nouveau type de support : multiplex AAL1 (option rseau)l Transport hors bande de la DTMF

l Amlioration des procdures de ngociation de codecsl Mcanisme de reroutage dans le plan transfert (bearer redirection)

l Spcification complte des procdures associes au CMNl Interfonctionnements avec d autres systmes de signalisation (ex : DSS1, H.323, INAP)


(Formation NGN) - D16 - 08/06/2001

France Tlcom R&D

BICC CS2 - Mcanisme de tunnellingDfini initialement pour la commande d appels sur dorsal IPtendu au transport de tout type de protocole de commande du support compatible avec

ce mcanismeTransport en transparent des informations de passerelle passerelle :

Seule utilisation actuellement dfinie du mcanisme de tunnelling : commande d appels sur dorsal IPTransport du protocole IP BCP (descriptions en SDP (Session Description Protocol) des

caractristiques de la connexion)

CCU

CSF

CCU

CSFBICC

CBCCBC

BIWF

BCF

BIWF

BCF

Tunnel


(Formation NGN) - D17 - 08/06/2001

France Tlcom R&D

Bearer redirectionMcanisme dfini dans le cadre de BICC CS2Offre la possibilit de racheminer la connexion en cas de modification de la configuration

d appel (ex : renvoi d appel)

Vise tirer avantage de la sparation appel/support : Dissociation des chemins suivis dans le plan de commande d appel et le plan transfert

Optimisation de l utilisation des ressources par l tablissement d un chemin plus direct dans le plan transfert

Av ant re-routage

BCF

CSFBCF

CSF

BCF

CSF

SN-A

SN-B

SN-C

Aprs re-routage

BCF

CS FBCF

CSF

BCF

CSF

SN-A SN-C

CMN-B


(Formation NGN) - D18 - 08/06/2001

France Tlcom R&D

Protocole CBCSparation physique entre serveur d appel et passerelle tudie dans le cadre de BICC

CS2

BCF

CSF

SwitchingFunction

Interface CBC

Interface BMC

Dfinition du profil H.248 associ l interface CBC : Recommandation Q.1950

Identification de deux interfaces :Interface CBC (Call & Bearer Control) entre CSF et BCF

Interface BMC (Bearer & Media Control) entre BCF et fonction d interconnexion physique


(Formation NGN) - D19 - 08/06/2001

France Tlcom R&D

BICC - Conclusion

BICC applicable la commande d appels sur dorsal ATM ou IP

Interfonctionnement simple avec l ISUPConu pour supporter les services supplmentaires ISUPAdapt une intgration au sein du RTC

Prochaine chance : BICC CS3 dici fin 2002Fonctions candidates :

l Commande d appels sur MPLS ?l Support du multimdia ?l Interfonctionnement avec SIP ?l ...

(Formation NGN) - D20 - 08/06/2001


H.323 & SIP pour le NGN

Tin Dao Trung (DAC/ACE) / Laurent Pos (DAC/ACE)


(Formation NGN) - D21 - 08/06/2001

France Tlcom R&D

Les normes associes H.323

T.Share T.126 T.127

T.124

T.122T.125T.123

Donnes

G.711G.711

G.722G.728G.723G.729

H.261

H.263

RTPRTPRTCPRTCP

TCP UDP

IP

LAN

Contrle etcommande Audio Vido

H.225 H.225 (Q.931)(Q.931)

H.245H.245RASRAS

H.225H.225

La Recommandation H.323 normalise les procdures d'tablissement et de gestion des appels. Pour cela elle s'appuie sur un ensemble de normes :

H.225.0 est la signalisation d'appel. C'est une version simplifie de la norme Q.931. Elle permet le contrle de l'appel.

H.245 est le protocole de commande. Il assure principalement l'tablissement du canal de transmission, la ngociation des capacits, le contrle de flux, la dtermination matre/esclave des terminaux.

RTP est le protocole de transmission temps rel. Il fournit des champs d'horodatage et de squencement des paquets.

RTCP fournit la source un retour sur les conditions de transmission, ainsi que de nombreuses indications sur les participants une visioconfrence.

G.711 est le codec audio obligatoire. D'autres codecs peuvent tre utiliss, mais tous les quipements doivent possder G.711.

Les normes suivantes sont optionnelles :

RAS, Registration Administration, Status est le protocole d'enregistrement des terminaux auprs des Gatekeepers.

T.120 est le canal de donnes. Cette norme permet les applications de type tableau blanc, de travailler distance sur un mme document.

H.261 ou H.263 sont les codecs vido utilisables.

H.235 est utilis pour la confidentialit des donnes changes, pour l'authentification des usagers.

Dans les versions 1 et 2 de H.323, H.225 et H.245 sont sur un transport fiable : TCP. UDP est utilis par RTP et par la voie RAS. Depuis la version 3, H.323 est capable d'utiliser UDP comme transport de signalisation, ce qui amliore le temps d'tablissement d'un appel.


(Formation NGN) - D22 - 08/06/2001France Tlcom R&D

Architecture H.323 : Les lments dfinis dans la norme

IP RTCGW

Terminaux H.323

Gatekeeper

CAA

MCU

H.225, H

.245

RTP

H.225, H.245H.225,H.245,RTP

H.225, H.245

H.225,H

.245,

RTP

Le GK: ses fonctions obligatoires: Traduction dadresse, Contrle de ladmission, Contrle de la bande passante, Gestion de zone

ses fonctions optionnelles: Gestion du contrle dappel, Gestion des autorisations, gestion de la bande passante,

Le MCU : Multipoint control unit: utilis pour les confrences.


(Formation NGN) - D23 - 08/06/2001

France Tlcom R&D

Premire vision "NGN" de H.323 :le "toll bypass"

GWRTCRTC

RTCRTC

IP

RAS RASGatekeeper

GW

ISUPOuQ.931

H.225

RTP ISUPOuQ.931

Concentration des fonctions de commande dappel et de commande des ressources dans les passerelles.

Premier protocole normalis de signalisation de commande d'appel sur IP, H.323 fut parmi les premiers proposer en 1996 une architecture phone-to-phone qui est lembryon de larchitecture NGN actuelle.

Cette premire gnration darchitecture pr-NGN fut le rsultat dun arbitrage tarifaire. Lide de base tait dacheminer lappel vers une passerelle H.323 au plus prs du demandeur et ensuite, aprs transit sur IP, de ressortir sur une passerelle au plus prs du demand. Le cot des communications internationales tant fortement allg pour lusager, larchitecture fut un rel succs auprs des nouveaux oprateurs proposant des prix casss, ainsi que des multinationales voulant relier faibles frais leurs filiales ltranger.

Dans cette architecture, la passerelle concentre les fonctions de traitement d'appel et de traitement des ressources. Le Gatekeeper nayant quun rle de traduction de numro tlphonique en adresse IP et de contrle daccs. La passerelle dentre de rseau traduit les messages de la signalisation reus du RTC (DSS1 ou ISUP) en messages H.225. Lappel est rout vers la passerelle de sortie qui fait la traduction inverse.

Cependant cette architecture n'est plus suivie par les instances de normalisation. Elle sadapte mal aux grands rseaux de tlphonie IP. La passerelle devient trs complexe alors que le rseau doit rester simple.


(Formation NGN) - D24 - 08/06/2001

France Tlcom R&D

H.323 entre serveurs d'appel

H.323MGC

MG MG

MGC

RTCRTC RTCRTC

MGCP, H248ISUP/MTPISUP/MTP

IP

SG

ISUP/IPSG

ISUP/IP

MGCP, H248

Gain en souplesse et volutivit.Les GW ne traitent plus la signalisation SS7.

Dans larchitecture NGN classique, la signalisation venant du RTC arrive sur un serveur dappel externe la passerelle. Dans la terminologie commerciale en H.323 ce serveur est appel un Softswitch ou MGC. Les passerelles retrouvent leur rle premier de conversion de la voix entre les rseaux de circuits et les rseaux IP. Ces passerelles sont commandes par le SoftSwitch via un protocole ddi (typiquement MGCP ou H.248/Megaco).

Dans l'architecture non distribue (voir transparent prcdent), la passerelle doit communiquer avec le Gatekeeper avant d'accepter ou de lancer chacun des appels. Cette mthode nest pas exploitable grande chelle du fait de lutilisation de TCP. Les serveurs sont incapables douvrir simultanment le millier de connexions TCP qui seraient ncessaires dans un rseau public.

L'avantage apporte par l'architecture distribue est de centraliser l'interprtation de la signalisation SS7 au niveau du MGC. Avec l'architecture H.323 prsente sur le transparent prcdent, chaque passerelle doit traiter la signalisation de commande dappel. A chaque nouvelle version de protocole c'est l'ensemble des passerelles qui est impact.


(Formation NGN) - D25 - 08/06/2001

France Tlcom R&D

Raccordement au RTC

Deux documents ont t produits par la commission 16 de l'UIT pour permettre d'interconnecter un rseau IP H.323 un rseau ISUP :

H.246 annexe C : interfonctionnement entre H.225 et ISUP,

H.323 (v4) annexe M.2 : mthode d'encapsulation de la signalisation ISUP dans H.225

H.225 tant bas sur le protocole d'accs Q.931, l'interfonctionnement entre l'ISUP et H.225 conduit une perte importante d'informations. Cette mthode nest donc pas bien adapte au cas du trunking IP (i.e. une configuration de transit par un rseau H.323 localis entre deux tronons ISUP). Cest pourquoi la commission 16 de lUIT a dfini, dans le cadre de ses travaux sur la quatrime version de H.323, un mcanisme d'encapsulation (ou de tunnelling) de l'ISUP dans H.225.

H.323 annexe M.2 spcifie la faon dont le contenu d'un message ISUP reu peut tre transmis en transparent de l'autre ct du rseau H.323 en tant vhicul l'intrieur d'un message H.225. Elle ne spcifie cependant pas les traitements raliser en entre ou en sortie du tunnel selon les informations ISUP reues. Les procdures de signalisation mettre en uvre au niveau des nuds dinterconnexion avec le RTC sont largement incompltes.


(Formation NGN) - D26 - 08/06/2001

France Tlcom R&D

Les principales lacunesPas de document dinterfonctionnement H.323/Q.931Un certain nombre d'informations vhicules par l'ISUP ne peuvent pas

tre retransmises (ex : compatibilit couche basse, compatibilit de couche haute, catgorie du demandeur, indicateur d'appel national/international, indicateur de prsence de satellite dans la connexion, informations sur l'insertion de suppresseur d'cho, indicateur de taxation, catgorie du demand), ce qui implique une perte d'informations en cas de transit sur IP. Pas de possibilit pour les terminaux de garantir la restriction de

prsentation de l'identit du demandeur. Jusqu' la version 3 de H.323 cette fonctionnalit n'existait pas. Trs peu d'quipements existants supportent cette fonctionnalit.



Session Initiation Protocol (SIP)the Internet Centric SignalingStatut03/1999 : Proposed Standard RFC 254309/1999 : cration du SIP WG, charg de poursuivre le dveloppement de SIPVersion actuelle : SIP 2.0, dfinie dans le RFC 2543bis-0312/2001 : devrait atteindre le statut de Draft Standard

Les ambitions de SIP

SIP sintgre dans larchitecture globale IETF multimedia temps relSIP peut initier, modifier et terminer des sessions interactives multimediaSIP entend fournir la pice manquante pour la convergence des rseaux et des servicesLe futur de SIPTrois WGs IETF consacrent leurs efforts lvolution de SIPFort engouement de la part de la communaut internet mondiale et de lindustrie des

telecomsMais encore beaucoup de travail effectuer avant que SIP natteigne ses objectifs



SIP is not @lone

SIPMedia RTSP

RSVPRTP / RTCP

TCP UDP

IP v4, IP v6

Link LayerPhysical Layer

Mmusic wgMmusic wg

Iptel wg

Dcs grSip wg

Sipping wg

Simple wgSipit

Impp wg

3 Gpp

Aaa wg

Midcom wg


(Formation NGN) - D29 - 08/06/2001

France Tlcom R&D

SIP3 niveaux de protocoles indpendants

Niveau 1 : Contrle de sessionl SIP

Niveau 2 : Description de session de service (adresse, type de flux,codec utilis)

l Protocole prconis : SDP

Niveau 3 : Description des mediasl Profile prconis : RTP/AVP

- Profils pour la description audio et video utiliss dans une session RTP

- Dfinition de types de codecs

SIP

SDP

RTP/AVP

invite sip:[email protected] SIP/2.0Via: SIP/2.0/UDP host1.lannion.cnet.fr:5060Date: Wed, 04 Oct 2000 07:14:34 GMTFrom sip:userA@francetelecom .frTo sip:[email protected]: 1 INVITECall-ID: [email protected] .frContact: [email protected]. cnet .frSubject: phone callContent-Type: application/SDPContent-Length: 148

v=0o=userA 562413 562413 IN IP4 194.240.47.217s=phone callc=IN IP4 194.240.47.217

m=audio 4710 RTP/AVP 4



SIP Exemple dtablissement dappel (mode Redirection)

Caller @ sip .com

Callee@ h o m e. com

Location Server

Proxy

ACK Cal lee@ h o m e. com#8

Cal

lee

# 2

INVITE Cal lee@ example .c o m#1

302 moved temporari lyContact : Cal lee@ h o m e.c o m#4

Callee@

home.com

# 3

INVITE Cal lee@ h o m e.c o m#6

ACK Cal lee@ example .com#5

OK 200# 7



LOCAL PROXY

NETWORK PROXY

LOCAL PROXY

PSTN

MOBILE

PBX

CALLER,

WATCHER

CALLED,

PRESENTITY

MEDIA, MESSAGES

INVITE

INVITE INVITE

INVITE

FORKING

NOTIFY

SUBSCRIBE

FRAME RELAY, ATM,

H.323, H.248

GATEWAYS

NON-SIP NETWORKS

SIP - Here, There and Everywhere

Focus ofSIP & SIMPLE WGs

Focus ofSIPPING WG

Courtesy : University of Columbia


(Formation NGN) - D32 - 08/06/2001

France Tlcom R&D

SIP-T L'Internet Draft SIP for Telephones (SIP-T) :Context and architectures est le

document de base produit par l'IETF qui dcrit l'utilisation du protocole SIP pour la tlphonie et l'interconnexion avec le RTCEncapsulation du message ISUP dans le corps du message SIP Transcodage de certaines informations ISUP dans l en-tte du message SIP

Plusieurs documents sont associs la description de mise en oeuvre du protocole SIP pour la tlphonie :

"ISUP to SIP mapping" dfinit la correspondance entre les messages ISUP et SIP.

"MIME media types for ISUP and QSIG Objects" spcifie le codage du champ dencapsulation transportant un message ISUP ou des informations QSIG.

"The SIP INFO Method" dfinit un nouveau message SIP pour le transport des messages ISUP transmis en cours d'appel (ex : CPG, FAC).

"SIP 183 Session progress message" dfinit un nouveau message SIP pour ouvrir de faon anticipe un canal mdia dans le sens arrire (pour diffusion dune annonce vocale par exemple)

"Mapping of ISUP parameters to SIP header" dfinit des rgles dinterfonctionnemententre l ISUP et l en-tte des messages SIP (document propos trs rcemment sur la liste SIP)


(Formation NGN) - D33 - 08/06/2001

France Tlcom R&D

SIP-T : des spcifications encore incompltes

Documents sattachant davantage la description de principes gnraux darchitecture et de transcodage ( mapping ) qu la spcification de procdures compltes d'interfonctionnement.

Pas dindication sur la faon dont le MGC doit traiter le message encapsul (ex: traitement ou non des informations non reconnues au niveau des nuds dinterconnexion ?)

Pas dindication sur le traitement des informations n'ayant qu'une signification tronon par tronon et ne pouvant donc pas tre transmises en transparent de bout en bout.

Choix dimplmentation risquant de varier dun industriel lautre en l absence de solution complte normalise.

A noter : lUIT a rcemment accept de prendre en charge la dfinition de linterfonctionnement entre SIP et le RTC ( Interfonctionnement SIP/SIP-T BICC/ISUP)

(Formation NGN) - D34 - 08/06/2001


Megaco/H.248

Jean-Emmanuel Chapron (DAC/ACE)


(Formation NGN) - D35 - 08/06/2001

France Tlcom R&D

Larchitecture de base

3 entits issues de la dcomposition de la passerelle monolithique : Signalling Gateway (SG)Media Gateway (MG)Media Gateway Controller (MGC)

Linterface MGC-MG ncessitait la cration dun nouveau protocole pour permettre au MGC le contrle du MG.

H.225, SIP, BICC, ...

RTC IP

SG

MEDIA

ISUPMGC

MG

Protocole de commande

CIRCUIT


(Formation NGN) - D36 - 08/06/2001

France Tlcom R&D

MEGACO/H.248 - GnralitsNom:

MEGACO: lIETF (nom du WG). RFC 3015H.248: dsignation lUIT

Historique:Premiers travaux en juin 1999, approuv en juin 2000Issu dun compromis men par Nortel. Viennent ensuite Marconi, Lucent et

Ericsson.Objectif: permettre le contrle dun MG par un (et un seul) MGC.

TechniqueUtilisable pour rseaux IP, ATM, Frame Relay (ct paquets)Codage texte (syntaxe ABNF) ou binaire (syntaxe ASN.1); tout MGC doit supporter

les deux.Transport par TCP/IP (obligatoire), UDP/IP , SCTP/IP ( venir) ou AAL5/ATM.Codage des paramtres de connexion en SDP (protocole IETF) ou en Type-Length-

Value


(Formation NGN) - D37 - 08/06/2001

France Tlcom R&D

MEGACO/H.248 - Modle

2 abstractionsLa Terminaison : reoit et/ou met du mdia. Le Contexte : associe les terminaisons qui doivent tre connectes

Le StreamSymbolise le flux mdia qui traverse le MG

RTC IP/ATM

MG

C1

T1 T2


(Formation NGN) - D38 - 08/06/2001

France Tlcom R&D

MEGACO/H.248 La Terminaison2 types de terminaisons:

Physique : existence permanente, reprsente linterface avec le RTCphmre : cre et dtruite explicitement par le MGC selon les besoins de

lappel. Exemple: Terminaison RTP, interface avec le rseau IP.

Contient un identifiant (TermID) et des descriptors (paramtres):Media

l Termination State: tat de la Terminaison: en service, hors service,l Stream Descriptor: proprits du flux traversant la Terminaison

Local Control: flux send only, send&receive, receive only,Local: (SDP) proprits locales du flux mdia: adresse IP, port RTP, codecRemote (SDP) proprits lautre bout du flux mdia: adresse IP,

Events : liste des vnements dtecter par la TerminaisonSignals: liste des signaux jouer par la TerminaisonDigit Map: schmas de dtection des DTMFPackages: liste des packages H.248 supports par la TerminaisonMultiplex: liste des multiplex utiliss par la TerminaisonStatistics: liste des proprits retourner au MGC (nombre de paquets envoys,..)


(Formation NGN) - D39 - 08/06/2001

France Tlcom R&D

MEGACO/H.248 - Commandes

Une commande sapplique une TerminaisonLe TerminationID est donc obligatoirement pass en paramtre de cette

commandeA toute commande est associe une rponse8 commandes:

Add: ajoute une Terminaison un contexteMove: bouge une Terminaison dun contexte un autreSubtract: retire une Terminaison dun contexteModify: modifie les proprits dune TerminaisonNotify: Notifie le MGC quun vnement sest produit au niveau dune TerminaisonAuditCapability: demande daudit des valeurs possibles de telle propritAuditValue: demande daudit des valeurs courantes de telle propritServiceChange: notifie le MGC ou le MG dune dfaillance; permet au MG de

senregistrer auprs de son MGC


(Formation NGN) - D40 - 08/06/2001

France Tlcom R&D

MEGACO/H.248 Packages

Toute implmentation de MEGACO/H.248 peut crer ses propres packages dfinissant:Une liste dvnements pouvant tre dtects par les TerminaisonsUne liste de signaux pouvant tre jous par les TerminaisonsUne srie de proprits spcifiques lenvironnement de la passerelle.

Par exemple, il est prvu de crer des packages pour lATM (MSForum), ou pour BICC (UIT SG11).De nouveaux codes derreur

Un package doit tre connu par le MGC et le MG pour pouvoir tre utilis.Risque important de voir se multiplier des versions de H.248 ne se

comprenant que trs partiellement, car ne pouvant pas utiliser les packages des autres.Tout package cr doit tre enregistr auprs de lIANA, pour essayer

de centraliser un peu ces diffrentes versions.


(Formation NGN) - D41 - 08/06/2001

France Tlcom R&D

Conclusion sur H.248

Permet la commande de passerellePlus largement, offre une interface de commande du plan mdia dans

le rseau paquet

Architectures trs intressantes, et vues comme telles par le monde VoIP

Applications de H.248Premires implmentations de H.248 proposes par les constructeurs mi-

2001.Protocole CBC: Profile de H.248 normalis lUIT SG11. Interface

verticale de larchitecture BICC.

Autres packages dvelopps lATM Forum, MSForum, 3GPP, TIPHON,


(Formation NGN) - D42 - 08/06/2001

France Tlcom R&D

Conclusion

Avances consquentes ces dernires annes en normalisation (BICC, H.323, SIP, Megaco/H.248)

Existence dune solution complte pour le trunking ATM ou IP avec BICC CS2

Intgration des protocoles H.323 et SIP dans les architectures rseau existantes encore mal dfinie

Convergence vers H.248 pour la commande des passerellesProlifration de nouveaux packages