Protocoles de

commande du NGN

Le prsent document contient des informations qui sont la propri t 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

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

Introduction (1/2)
Nouvelle rpartition des fonctions de commande du rseau apparue
avec les architectures NGN
Serveur de commande externe
Rseau 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

France Tlcom R&D

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

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

Introduction (2/2)

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 Bearer
Control Function (BCF).
Entit concentrant l intelligence, traitant la signalisation de commande d appel et pilotant une
ou plusieurs unit(s) d interfonctionnement
l Entit baptise serveur d appel (CS) , Media Gateway Controller (MGC), Call Service
Function (CSF) ou Softswitch.

ISU P

CAA

Call

B ICC, H.323, SIP( T)

Call

S erver

Server

ISUP
Megaco/H.248

Megaco/H.248

IW U

Rseau AT M, IP

IWU

CAA

Normalisation des protocoles associs ces nouvelles interfaces : condition

essentielle pour garantir l interoprabilit entre des machines d industriels diffrents
France Tlcom R&D

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

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

BICC

Bearer Independent Call

Control
Caroline Salahun DAC/ACE

Le prsent document contient des informations qui sont la propri t 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

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

Gnralits
Historique :
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 ANSI

Premire 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 existants
Possibilit de raliser une migration en douceur des rseaux tlphoniques classiques vers les
rseaux de nouvelle gnration

Caractristique principale : protocole bas sur l ISUP

Rutilisation 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

France Tlcom R&D

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

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

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), et
l 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
BI CC

CSF
I SU P

C AA

C MN

TSN
CSF

BI CC

"CSF"

ISN
BI CC

CSF
I SUP

Megac o/H .2 4 8

Me gac o/H .2 4 8

BCF

Rseau ATM, IP

BIW F

BCF

M egac o/H .2 4 8

Rseau ATM, IP

BCF

BIW F

CAA

BIW F

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.
France Tlcom R&D

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

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

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 .

France Tlcom R&D

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

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

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 relativ es 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 (conc entration de
l intelligence dans le serveur d appel)
l Risque d accroissement de la spcificit des passerelles vis vis du pr otocole de
commande d appel
France Tlcom R&D

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

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

Le concept dindpendance (2/2)

Indpendance vis vis des couches de transport de signalisation
Utilisation 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)

France Tlcom R&D

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

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

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/support
l 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 circuit

l volution des procdures de gestion de circuit

Se positionne en tant que successeur de l ISUP

France Tlcom R&D

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

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

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)

France Tlcom R&D

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

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

Principales caractristiques de lappel de

base (adaptation au contexte NGN) (1/2)
tablissement dappel
Dfinition 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 s ens inverse par rapport
l appel

Transport dinformations relatives au support

Exemples :
l type de support (ex : AAL1, AAL2)
l adresse des passerelles
l codecs

France Tlcom R&D

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

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

Principales caractristiques de lappel de

base (adaptation au contexte NGN) (2/2)
Corrlation appel/support
Ncessit de corrler les messages de commande d appel et les messages de commande du
support

Cration d un nouvel identifiant : BNC- ID

l 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

France Tlcom R&D

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

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

Exemple : tablissement d appel dans le

sens arrire
CSF

CSF

BCF

IAM

SWN

Add=x

BCF

SWN

BNC-ID=x1

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

Bearer Setup Request (BIWF-Add=x), (BN C-ID=x1)
Corrlation l 'aide
du BNC-ID

Bearer Setup Req uest

Bearer Setup Con nect

Beare r Setu p Request

Be arer Se tup Co nnect

Bearer Setup Conne ct

IAM
ACM

France Tlcom R&D

ACM (CIC=a)

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

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

BICC CS2

Envoi 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 CS1
Commande d appels sur dorsal IP
Extension des procdures aux commutateurs locaux (CAA, MSC)
Sparation physique entre CSF et BCF (serveur d appel/passerelle)

volutions fonctionnelles diverses

Exemples :
l Nouveau type de support : multiplex AAL1 (option rseau)
l Transport hors bande de la DTMF
l Amlioration des procdures de ngociation de codecs
l Mcanisme de reroutage dans le plan transfert (bearer redirection)
l Spcification complte des procdures associes au CMN
l Interfonctionnements avec d autres systmes de signalisation (ex : DSS1, H.323, INAP)
France Tlcom R&D

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

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

BICC CS2 - Mcanisme de tunnelling

Dfini initialement pour la commande d appels sur dorsal IP
tendu au transport de tout type de protocole de commande du support compatible avec
ce mcanisme

Transport en transparent des informations de passerelle passerelle :

BICC
CSF

CSF

CCU

CCU
Tunnel

CBC

CBC
BCF

BIWF

BCF

BIWF

Seule utilisation actuellement dfinie du mcanisme de tunnelling : commande d appels

sur dorsal IP
Transport du protocole IP BCP (descriptions en SDP (Session Description Protocol) des
caractristiques de la connexion)
France Tlcom R&D

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

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

Bearer redirection
Mcanisme dfini dans le cadre de BICC CS2
Offre 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
CMN-B

Av ant re-routage

Aprs re-routage

CSF

CSF

CSF
BCF

BCF
SN-A

France Tlcom R&D

SN-B

CSF

CS F

CSF
BCF

BCF
S N-C

BCF

BCF

S N-A

S N-C

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

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

Protocole CBC
Sparation physique entre serveur d appel et passerelle tudie dans le cadre de BICC
CS2

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

CSF
Interface CBC

Dfinition du profil H.248 associ

l interface CBC : Recommandation Q.1950
Interface BMC

BCF

Switching
Function
France Tlcom R&D

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

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

BICC - Conclusion
BICC applicable la commande d appels sur dorsal ATM ou IP
Interfonctionnement simple avec l ISUP
Conu pour supporter les services supplmentaires ISUP
Adapt une intgration au sein du RTC

Prochaine chance : BICC CS3 dici fin 2002

Fonctions candidates :
l
l
l
l

Commande d appels sur MPLS ?

Support du multimdia ?
Interfonctionnement avec SIP ?
...

France Tlcom R&D

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

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

H.323 & SIP pour le

NGN

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

Le prsent document contient des informations qui sont la propri t 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

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

Les normes associes H.323

Donnes

Contrle et
commande

Audio Vido
G.711

T .Share T.126 T.127

T.124
T.122
T.125
T.123

G.722
G.728
H.245
G.723
H.225
RAS G.729
(Q.931)

H.261
H.263

RTP
RTCP

H.225
TCP

UDP
IP
LAN

France Tlcom R&D

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

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

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.

Architecture H.323 : Les

lments dfinis dans la norme

Gatekeeper
H.225,H.245,RTP

H.225, H.245

MCU

.245
H.225, H

Terminaux H.323
5,
,H.24
H.225 TP
R

45
H.2
25,
H.2

IP

GW

RTC
CAA

RTP

France Tlcom R&D

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

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

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.

Premire vision "NGN" de H.323 :

le "toll bypass"

RAS

Gatekeeper

RAS

H.225

RTC
RTC

GW

ISUP
Ou
Q.931

RTC
RTC

GW
RTP

IP

ISUP
Ou
Q.931

Concentration des fonctions de commande dappel et de commande

des ressources dans les passerelles.

France Tlcom R&D

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

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

Premier protocole normalis de signalisation de commande d'appel sur IP,

H.323 fut parmi les premiers proposer en 1996 une architecture phone-tophone 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.

H.323 entre serveurs d'appel

ISUP/IP

ISUP/IP

MGC

S
G
ISUP/MTP

H.323

MGCP, H248

MG

MGC

MGCP, H248

IP

S
G
ISUP/MTP

MG

RTC
RTC

RTC
RTC

Gain en souplesse et volutivit.

Les GW ne traitent plus la signalisation SS7.

France Tlcom R&D

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

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

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.

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

France Tlcom R&D

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

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

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.

Les principales lacunes

Pas de document dinterfonctionnement H.323/Q.931
Un 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, cat gorie 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.

France Tlcom R&D

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

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

Session Initiation Protocol (SIP)

the Internet Centric Signaling
Statut
03/1999 : Proposed Standard RFC 2543

09/1999 : cration du SIP WG, charg de poursuivre le dveloppement de SIP

Version actuelle : SIP 2.0, dfinie dans le RFC 2543bis -03
12/2001 : devrait atteindre le statut de Draft Standard
Les ambitions de SIP

SIP sintgre dans larchitecture globale IETF multimedia temps rel

SIP peut initier, modifier et terminer des sessions interactives multimedia
SIP entend fournir la pice manquante pour la convergence des rseaux et des services
Le futur de SIP
Trois WGs IETF consacrent leurs efforts lvolution de SIP

Fort engouement de la part de la communaut internet mondiale et de lindustrie des

telecoms

Mais encore beaucoup de travail effectuer avant que SIP natte igne ses objectifs

France Tlcom R&D

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

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

SIP is not @lone

Mmusic
Mmusicwg
wg
Iptel wg

Dcs gr

Sip wg

Sipping wg

3 Gpp
Sipit

Impp wg
Midcom wg

Aaa wg

Simple wg

SIP
Media

RTSP

RTP / RTCP
TCP

RSVP

UDP
IP v4, IP v6
Link Layer
Physical Layer

France Tlcom R&D

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

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

SIP
3 niveaux de protocoles indpendants
Niveau 1 : Contrle de session
l SIP

Niveau 2 : Description de session de

service (adresse, type de flux,codec utilis)
l Protocole prconis : SDP

Niveau 3 : Description des medias

l Profile prconis : RTP/AVP
- Profils pour la description audio et
video utiliss dans une session RTP

invite sip:userB@globalone.net SIP/2.0

Via: SIP/2.0/UDP
SIP host1.lannion.cnet.fr:5060
Date: Wed, 04 Oct 2000 07:14:34 GMT
From sip:userA@francetelecom .fr
To sip:userB@globalone.net
Cseq: 1 INVITE
Call-ID: 124325617@host1.lannion.cnet .fr
Contact: userA@host1.lannion. cnet .fr
Subject: phone call
Content-Type:
application/SDP
SDP
Content-Length: 148
v=0
RTP/AVP
o=userA 562413
562413 IN IP4 194.240.47.217
s=phone call
c=IN IP4 194.240.47.217
m=audio 4710 RTP/AVP 4

- Dfinition de types de codecs

France Tlcom R&D

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

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

SIP Exemple dtablissement dappel (mode

Redirection)

Location Server
Callee

Caller @ sip .com

#1 I N V I T E C a l l e e @ e x a m p l e .c o m

#4

Callee@home.com

#2

#3

302 moved temporarily

Contact: Callee@ h o m e.c o m

Proxy
#5 A C K C a l l e e @ example .c o m

Callee@ h o m e. c o m
#6 I N V I T E C a l l e e@ h o m e.c o m
#7

OK 200

#8 A C K C a l l e e @ h o m e. com

France Tlcom R&D

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

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

SIP - Here, There and Everywhere

FORKING

Focus of
SIP & SIMPLE WGs

Focus of
SIPPING WG

NETWORK
PROXY

INVITE

LOCAL
PROXY

GATEWAYS

INVITE

PSTN

MOBILE

LOCAL
PROXY

PBX
INVITE

SUBSCRIBE

INVITE
FRAME RELAY, ATM,

MEDIA, MESSAGES

H.323, H.248

NOTIFY
CALLER,

CALLED,

WATCHER

PRESENTITY

France Tlcom R&D

Courtesy : University of Columbia

NON-SIP NETWORKS

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

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

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 RTC
Encapsulation du message ISUP dans le corps du message SIP
Transcodage de certaines informations ISUP dans len-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 dinterfonctionnement

entre lISUP et l en-tte des messages SIP (document propos trs rcemment sur la
liste SIP)

France Tlcom R&D

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

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

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 n uds
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)

France Tlcom R&D

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

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

Megaco/H.248

Jean-Emmanuel Chapron (DAC/ACE)

Le prsent document contient des informations qui sont la propri t 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

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

Larchitecture de base
MGC
ISUP

SG

H.225, SIP,
BICC, ...
Protocole de commande

RTC

IP

CIRCUIT

MG

MEDIA

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.

France Tlcom R&D

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

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

MEGACO/H.248 - Gnralits
Nom:
MEGACO: lIETF (nom du WG). RFC 3015
H.248: dsignation lUIT
Historique:
Premiers travaux en juin 1999, approuv en juin 2000
Issu dun compromis men par Nortel. Viennent ensuite Marconi, Lucent et
Ericsson.

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

Technique
Utilisable 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-LengthValue

France Tlcom R&D

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

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

MEGACO/H.248 - Modle
2 abstractions
La Terminaison : reoit et/ou met du mdia.
Le Contexte : associe les terminaisons qui doivent tre connectes

Le Stream
Symbolise le flux mdia qui traverse le MG

RTC

IP/ATM

C1

T1

T2
MG

France Tlcom R&D

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

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

MEGACO/H.248 La Terminaison
2 types de terminaisons:
Physique: existence permanente, reprsente linterface avec le RTC
phmre : 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, codec
Remote (SDP) proprits lautre bout du flux mdia: adresse IP,
Events :
liste des vnements dtecter par la Terminaison
Signals:
liste des signaux jouer par la Terminaison
Digit Map: schmas de dtection des DTMF
Packages: liste des packages H.248 supports par la Terminaison
Multiplex: liste des multiplex utiliss par la Terminaison
Statistics: liste des proprits retourner au MGC (nombre de paquets envoys,..)

France Tlcom R&D

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

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

MEGACO/H.248 - Commandes
Une commande sapplique une Terminaison
Le TerminationID est donc obligatoirement pass en paramtre de cette
commande

A toute commande est associe une rponse

8 commandes:
Add: ajoute une Terminaison un contexte
Move: bouge une Terminaison dun contexte un autre
Subtract: retire une Terminaison dun contexte
Modify: modifie les proprits dune Terminaison
Notify: Notifie le MGC quun vnement sest produit au niveau dune Terminaison
AuditCapability: demande daudit des valeurs possibles de telle proprit
AuditValue: demande daudit des valeurs courantes de telle proprit
ServiceChange: notifie le MGC ou le MG dune dfaillance; permet au MG de
senregistrer auprs de son MGC

France Tlcom R&D

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

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

MEGACO/H.248 Packages
Toute implmentation de MEGACO/H.248 peut crer ses propres
packages dfinissant:
Une liste dvnements pouvant tre dtects par les Terminaisons
Une liste de signaux pouvant tre jous par les Terminaisons
Une 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.

France Tlcom R&D

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

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

Conclusion sur H.248

Permet la commande de passerelle
Plus 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.248
Premires implmentations de H.248 proposes par les constructeurs mi2001.

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

verticale de larchitecture BICC.

Autres packages dvelopps lATM Forum, MSForum, 3GPP,

TIPHON,

France Tlcom R&D

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

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

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 passerelles

Prolifration de nouveaux packages

France Tlcom R&D

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

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