Le protocole INAP

(Intelligent Network Application Part)

Mamadou Alpha BARRY

www.esmt.sn

1
 Rappel sur SS7 (SSCS)
Les capacités d’acheminement de la couche SSTM3 sont limitées à router les
messages jusqu’au point sémaphore adéquat à partir du code du point de destination
(CPD), et une fois les messages délivrés, à les relayer au sous-système utilisateur
dans le point sémaphore à partir de la valeur du champ octet de service (SER) de
chaque message. Le SSCS (Sous système de connexion sémaphore) fournit une
fonction supplémentaire de traduction d’adresse dénommée Global Title (GT).

Une fonction GT est une adresse telle qu’un numéro vert, un numéro de téléphone
mobile, un numéro RNIS, etc., qui ne peut être routé directement. Le SSCS traduit
cette fonction GT en un CPD et un Numéro de Sous-Système (NSS ou SSN, Sub-
System Number).

2
 Rappel sur SS7 (SSCS)
MTP + SSCS = NSP ou Network Service Part

Le SSCS est créé pour supporter les échanges d’informations entre nœuds sans
nécessairement en rapport avec un établissement de circuits.
IL fournit 2 catégories de services réseau au dessus de MTP3:

 Service réseau avec connexion : type circuits virtuels pour interfonctionnement

avec des réseaux paquets conformes au standard OSI X23.

 Service réseau sans connexion : transport de bout en bout via plusieurs réseaux
MTP)

3
 Rappel sur SS7 (SSCS)
 Domaine d'utilisation du gestionnaire de transactions

Dans un réseau du système de signalisation SS7, le gestionnaire de transactions

devrait être considéré pour des utilisations entre:

1) Commutateurs;
2) Un commutateur et un centre de gestion de services du réseau (base de
données, centre spécialisé de services, centre OA&M);
3) Centres de gestion de services du réseau.

Les applications suivantes ont été reconnues comme des utilisateurs du gestionnaire
de transactions:

– application pour le service mobile (par exemple localisation de l'abonné en

déplacement);

4
 Rappel sur SS7 (SSCS)
 Domaine d'utilisation du gestionnaire de transactions

– Enregistrement, activation et invocation de compléments de service impliquant

des centres spécialisés de services (service de libre appel, service carte de crédit,
etc.);

– Echanges d'informations de signalisation non relatives à la commande de circuit

(groupe fermé d'utilisateurs, procédure de test préalable, etc.);

– Applications pour l'exploitation et la maintenance (par exemple question/réponse).

Les Systèmes Utilisateurs qui sont identifiés par un SSN (Sub System Number) à 8
bits (ex:ISUP, HLR du GSM, MAP…)

MTP3 fournit un adressage à partir des CP, SSCS fournit un adressage à partir de
SSN (Sub System Number : 256 possible)

5
 Rappel sur SS7 (SSCS)
SSN normalisés

00000000 SSN non connu ou non-utilisé

00000001 Gestion SCCP
00000010 Réservé
00000011 ISUP
00000100 OMAP
00000101 MAP (Mobile Application Part)
00000110 HLR (Home Location Register)
00000111 VLR (Visitor Location Register)
00001000 MSC (Mobile Switching Center)
00001001 EIR (Equipment Identity Register)
00001010 AC (Authentication Center)
Reste Réservé

6
 Rappel sur SS7 (SSCS)
Exemple : utilisation du Global Title 4 – traduction GT en
CP CAA + SSN
3 – @SS7 CTI B +
2 – traduction GT en CP passerelle A + GT
CP passerelle A + GT
5 – @CP CAA + SSN
2 4
1 5
3

1 - @ SS7 demandée:
6
CP CTI A + GT 6 – OCP est « devenu » le DCP

7
 Rappel sur SS7 (TCAP)
le TCAP Transaction Application Part (Sous Système de Gestion des Transactions),
son objectif global est de fournir des moyens de transfert d'informations entre
points sémaphores ainsi qu'un ensemble de fonctions communes aux diverses
applications, tout en étant indépendant de celles-ci.

Il est créé pour les besoins RI (exemple : échanges entre le SSP et le SCP ( Service
Switching Point et le Service Command Point) et GSM

 Messages en nombre limité

 Faible volume de données et contrainte temps réel

Les applications suivantes ont été reconnues comme des utilisateurs du gestionnaire
de transactions:

– application pour le service mobile (par exemple localisation de l'abonné en

déplacement);
– enregistrement, activation et invocation de compléments de service
impliquant des centres spécialisés de services (service de libre appel,
service carte de crédit, etc.);

8
 Rappel sur SS7 (TCAP)
– échanges d'informations de signalisation non relatives à la commande de
circuit (groupe fermé d'utilisateurs, procédure de test préalable, etc.);
– applications pour l'exploitation et la maintenance (par exemple
question/réponse).
Cette liste n'est pas restrictive.

Du point de vue d'un utilisateur terminal, le gestionnaire de transactions se situe au

dessus de la couche Réseau du modèle de référence (OSI). La fourniture de services
de couche Réseau aux utilisateurs terminaux nécessite la communication entre
utilisateurs du TC dans différents nœuds du réseau; ces communications intraréseau
peuvent à leur tour être modélisées en utilisant le modèle de référence OSI de 7
couches

9
 Rappel sur SS7 (TCAP)
structure en 2 sous couches

 Sous couche « transaction » gère l’établissement de relations de bout en bout par

échanges de primitives appelées « transactions » .

Exemples de types de transactions : Begin/Continue/End/Abort/Cancel

TCAP peut contrôler plusieurs dialogues actifs au même instant : Transaction ID

(Originating Transaction ID et Destination Transaction ID)

10
 Rappel sur SS7 (TCAP)
structure en 2 sous couches
 sous couche « component » : traite des composants qui sont des unités de
données du protocole d'application (APDU, application protocol data unit) qui
véhiculent les demandes d'opérations distantes et leurs réponses et,
facultativement, le protocole de la partie dialogue pour l'acheminement des
informations liées au contexte d'application ou l'information d'utilisateur;

les composants échangés entre 2 utilisateurs TCAP constituent un dialogue

Exemple de composant : Invoke (nouvelle opération demandée – comprend

Invoke ID), Return_Result_Last/Not_Last

11
 Rappel sur SS7 (TCAP)
structure en 2 sous couches

Sous couche « Transaction » : Les types de transactions

12
 Rappel sur SS7 (TCAP)
structure en 2 sous couches

Sous couche « Component » : Les types de composants

13
 Rappel sur SS7 (TCAP)
Exemple de dialogue entre 2 CP (cas du service carte Téléphonique)

Début transaction Q1: Demande d’intrusions (Begin/Query)

R1: continue (Continue/Conversation)

Q2 : envoyez le N° demandé

R2 : numéro demandé
Q : Question
R : Réponse Q3 : envoyez N° Carte + PIN
D : Demande
unidirectionnelle R3 : numéros

Conversation !!!! … Conversation !!!

14
 Rappel sur SS7 (TCAP)
Exemple de dialogue entre 2 CP (cas du service carte Téléphonique)

D1 : connecter l ’appel

Q4 : envoyez heure début appel

Q5: envoyez heure fin appel

Q : Question
R4 : heure
R : Réponse
D : Demande R5 : heure
unidirectionnelle
D2 :Libérez l ’appel

Fin transaction

15
 Protocole INAP
Le protocole INAP (Intelligent Network Application Part) permet au deux partenaires
SCF et SSF d’invoquer des opérations dans l’entité distante. La référence qui fait foi
actuellement pour l’INAP et la norme de l’INAP produite par l’ETSI (European
Telecommunications Standards Institute), souvent appelé ETSI Core INAP. Cette
norme définit INAP pour le CS1.

Il y a 29 opérations ETSI Core INAP: dont nous donnons maintenant la liste et une
brève description. Cette liste est très intéressante parce qu’au fond, c’est la liste des
29 choses qu’un commutateur sait faire. En comparaison, un routeur du réseau
internet, ne sait rien faire de tout cela et par conséquent l’internet ne peut pas être un
réseau intelligent.

La norme les classes par ordre alphabétique, nous préférons ici les classer par types
de fonctionnalités.

16
 Protocole INAP
Débranchement du service normal et retour au service normal:

1. Initial DP procedure : C’est l’opération qui déclenche tout , cette opération est
envoyer vers la SSF lorsque les critères d’armement sont vérifiés et qu’il faut faire
appel à la SCF.

2. Continue procedure : C’est l’opération qui normalement termine le service. Elle

demande à la SSF de reprendre le traitement d’appel normal au point où elle avait
suspendu ce traitement pour attendre les instructions de la SCF.

3. Cancel procedure : Cette opération permet d’annuler une demande de service à

un SCF.

Demande de supervisions d’événement et notifications d’occurrences de ces

services:

4. Resquest Report BCSM Event: La SCF demande à la SSF de superviser le

passage par un DP détermine. Ce passage constitue un événement.

17
 Protocole INAP
5. Event Report BSCM procedure : Lorsque le traitement d’appel passé par un DP
indiquant un événement dont la supervision a été demandé par un opération
Request Report BCSM Event la SSF transmet la notification de l’événement à la
SCF.

Appels vers des destinations finales:

6. Collect information procedure : Cette opération demande au commutateur de

récupérer les informations de traitement d’appel composées par l’abonné. Elle ne
fait pas appel à une SRF.

7. Conncet procedure : Cette opération permet de demander à la SSF de

connecter l’appel à une destination déterminée.

8. Initiate call Attempt procedure : La SCF demande à la SSF de créer un nouvel

appel vers une nouvelle destination.

9. Call information Request procedure : La SCF demande à la SSF des

informations sur un appel en cours.

18
 Protocole INAP
10. Call Information Report procedure : La SSF répond à la SCF suite à une
demande d’information sur un appel en cours

11. Release Call procedure : Cette opération permet à la SCF de demander à la

SSF le relâchement d’un appel à n’importe quel moment de l’appel et pour tous
les partenaires de l’appel.

Connexions à des serveurs vocaux, pilotage des serveurs vocaux:

12. Connect To Ressource procedure : Connexion d’un utilisateur à une SRF.

13. Establish Temporary connection procedure : Cette opération permet de

demander à la SSF de connecter l’appel à une SRF ( serveur vocal) dans le où la
SRF est adressable séparément de la SSF.

14. Play Announcement procedure : Envoi de tonalité ou d’annonces vocales à un

utilisateur analogique ou d’informations alphabetiques à un utilisateur RNIS.

19
 Protocole INAP
15. Prompt And Collect User Information procedure : Interaction entre un serveur
vocal et un utilisateur pour récupérer des informations.

16. Disconnect Forward Connection procedure : Cette opération permet de

demander à la SSF de déconnecter l’appel d’une SRF (Serveur vocal ) qui aurait
été connecté précédemment.

17. Specialized ressource Report procedure : Réponse de la SRF à la SCF pour

indiquer qu’une annonce demandée est terminée.

Mise en place de taxations:

18. Apply charging procedure : La SCF demande la mise en place d’une taxation
dans la SSF.

19. Apply ChargingReport procedure : La SSF renvoie à la SCF les informations

de la taxation demandées.

20
 Protocole INAP
20. Request Notification Charging Event procedure : Demande de supervision
d’un événement en vue de la tarification.

21. Event Notification Charging procedure : Notification d’un événement en vue de

la tarification.

22. Send charging Information procedure : La SCF demande à la SSF d’envoyer

des signaux de taxes, par exemple des impulsions de taxe sur la ligne d’abonné.

23. Furnish Charging Information procedure : La SCF demande à la SSF de

générer un ticket de taxe pour tarification off-line ultérieur.

Contrôle de service :

24. Activity Test procedure: Opération utilisée par une SSF pour verifier que sa
relation avec une SSF donnée est bien toujours active.

25. Active Service Filtering procedure : La SCF donne des instructions à la SSF
pour traiter certains appels d’une mainere specifiques.

21
 Protocole INAP
26. Service Filtering Response procedure : Dans le cas où un filtrage de service a
été demande par la SCF, cette opération permet de renvoyer le contenu de
compteurs spécifiés dans la demande de filtrage à la SCF.

27. Assist Request Intruction procedure : Une SCF qui se rend compte qu’il n’y a
pas de serveurs vocaux (ressources spéciales) joignables directement depuis le
commutateur d’initiation du service redirige l’appel vers un autre commutateur
duquel on peut se connecter au serveur vocal. La SSF de cet autre commutateur
(Assist SSF) demande des instructions à la SCF avec cette opération.

28. Reset Timer procedure : Il existe une temporisation dans la SSF pour limiter la
durée d’une instance de service. Par cette opération, la SCF peut relancer la
temporisation si elle s’aperçoit qu’elle risque de déclencher.

29. Call Gap procedure : Cette opération institue un contrôle de flux entre la SCF et
la SSF, la SCF demande à la SSF de diminuer le taux de demande de service par
unité de temps.

22
 Exemple de déroulement d’un service IN-CS1
Pour illustrer les mécanismes que nous venons de décrire nous prenons l’exemple du
service libre appel. Le but de ce service est rendre l’appel gratuit pour l’appelant et de
faire supporter la taxation de l’appel au demandé, abonné au service.

Service libre d’appel: Description dans le plan fonctionnel global

23
 Exemple de déroulement d’un service IN-CS1
La figure précédente donne la description du service dans le plan fonctionnel global.
Les SIB utilisés sont la SIB traduction (pour traduire le numéro en un numéro
routable) et la SIB taxation (charger de la tarification de l’appel).

La SIB taxation : Elle reçoit en CID (Call instance Data) le numéro de l’appelant et le
numéro de l’appelé 0800PQMDCU (Il n’a pas signification routable). En SSD (Service
Support Data), elle reçoit des données à caractères permanent pour ce service, il
s’agit ici de la correspondance 0800PQMCDU en numéro routable.

La SIB taxation: Elle reçoit en CID des consignes pour savoir qui s’occupe de la
tarification. cela peut être le commutateur lui-même ou éventuellement la SCF, selon
les types d’équipement en places. D’autre par la SIB reçoit en SSD le tarif à appliquer
et le numéro de l’abonné.

24
Exemple de déroulement d’un service IN-CS1

25
Exemple de déroulement d’un service IN-CS1

26
 Exemple de déroulement d’un service IN-CS1

Remarque:

En même temps que l’envoi du Connect dans la traduction du numéro, la SCF peut
envoyer un Request Report BCSM Event pour mettre en place la supervision de
la réponse du demandé et de la libération, dans le cas où la taxation est effectuée
par la SCF.

27
 IN-CS2
Dés le début du processus de normalisation il était entendu que le CS1 n’offrait
qu’un nombre assez restreint de possibilité, même si ces possibilités étaient déjà
un énormes progrès dans les possibilités de fournir des services par un autre
téléphonique.

En effet les spécifications CS1 ne traitent que services de type A concernant des
appels téléphoniques point à point sans offrir de mécanismes pour les appels multi-
parties ou le multimédia, elles n’offrent que des possibilités très limitées pour la
mobilité, en particulier une interaction entre l’utilisateur et le service qui ne peut
avoir lieu que durant un appel.

La gestion des services et des équipements RI reste propriétaire, les interfaces

pour l’interconnections entre RI ne sont pas normalisées et l’architecture RI-CS1 ne
peut être déployée que sur le RTC.

Par ailleurs, les industries firent vite état de difficultés avec la notion de SIB, ils
mirent en cause la possibilité de réutiliser la même SIB dans plusieurs services
différents et déclarèrent trop limité le jeu de SIB normalisé du CS1.

28
 IN-CS2
En effet les SIB dans les standards ne s’intéressent pas aux fonctions de gestion
des services, qui représentent en moyenne prés de 70% des fonctions et elles
n’offrent aucune possibilité de parallèle ou synchronisation pour pouvoir composer
des services élémentaires en services plus sophistiqués.

Dans ces conditions, les objectifs des normes UIT-T Q.122x ont été les suivants:

 Enrichir les services d’appels:

- Permettre le déclenchement de service un fois l’appel établi (Mid Call
Interruptions).
- Permettre des appels multiparties (entre plusieurs correspondant) et
multiples (plusieurs appels liés comme le double appel).

 Permettre la composition de service en enrichissant les SIB et en introduisant

une possibilité de composer des SIB et de permettre le parallélisme et la
synchronisation de plusieurs services.

29
 IN-CS2
 Assurer l’interfonctionnement entre réseaux Intelligent pour permettre la
fourniture des services internationaux (exemple : Réseau privé Virtuel
International).

 Introduire en dehors des services d’appels, des fonctionnalités de gestion et de

création de service et notamment permettre une interaction avec l’utilisateur
hors du contexte d’un appel.

Les innovations majeurs de l’IN CS2 sont donc les services d’interfonctionnement
de réseau, les services multiparties et les services de mobilité personnelle.

Nous donnons ci-dessous des exemples de services permis par l’IN CS2:

Services d’interfonctionnement de réseaux:

- Libre appel inter-réseaux
- Réseaux virtuel mondial
- Kiosque téléphonique inter-réseau
- Télévote inter-réseau
- Carte de taxation des télécommuincation internationnales

30
 IN-CS2
Services Multiparties :
- Rappel automatique sur occupation
- Communication conférence
- Mise en garde
- Transfert d’appel
- Indication d’appel en attente

Service de mobilité personnelle

- Authentification de l’utilisateur
- Enregistrement de l’utilisateur
- Sécurité de réponse
- Suivi.

Pour atteindre ces objectifs l’IN CS2 a introduit de nouvelles possibilité dans le
plan global pour enrichir les SIB: en IN CS1, l’appel de base était représenté par un
SIB spéciale le BCP (Basic Call Process) dont on débrancherait pour entrer dans le
traitement substitutif

31
 IN-CS2
L’IN CS2 prévoit deux nouvelles SIB de base, en plus du BCP:

 Le Basic Call Unrelted Process BCUP qui est mis en œuvre dans une sessions
d’accès, quand un abonné allume un terminal mobile (se logue sur le réseau).

 Le Basic Service Management Process BSMP mis en œuvre quand une action
de gestion de service est réalisé.

Ensuite l’IN CS2 introduit une notion de compositions de SIB: on peut composer
des SIB en unités plus complexes appelées modules SIB de haut niveau (HLSIB :
High Level SIB). Les HLSIB peuvent être constitués d’une combinaison de module
SIB contenant elles mêmes plusieurs opérations de SIB (opSIB). HLSIB peuvent
également être combinaison afin de créer des modules SIB de niveau encore plus
élevé.

32
 IN-CS2

POS : Point of Synchronization

IN CS2 Composition des SIB et parallélisation des processus de service

33
 IN-CS2
Des nouvelles opérations de SIB sont destinées à assurer le parallélisme de
plusieurs processus de services simultanés.

 Initiate service process : Demarrer un service en paralléle à un service déjà

en cours

 Send : envoie un signal à un processus de service paralléle. Le signal peut

contenir des données interprocessus.

 Wait : attente d’un signal de synchronisation

 End : termine un processus de service

 Service Filter : exerce un filtrage sur le nombre d’appel à une fonctionnalité de

service.

34
 IN-CS2
Des nouvelles SIB ont été introduites pour décrire les appels multiples et multi-
parties:

 Attach : Rattache un correspondant du groupe d’appels en cours au groupe

d’appels spécifié, dans le cadre du même appel (conférence).

 Detcach : Détache un correspondant de l’appel en cours et rattache les

correspondants indiqués à un nouvel appel ou à un appel existant (conférence).

 Join : Réalise une continuité media entre 2 partenaires

 Split : Coupe une continuité de media entre 2 partenaires

35
 IN-CS2
L’architecture fonctionnelle d’exécution de service de l’IN CS2 est indiquée sur la
figure ci-dessous. Du fait que IN CS2 prend en compte la mobilité, des fonctions
non apparentées appel (Call unrelated Functions) sont nécessaire pour réaliser des
services au moment de la session d’accès de la SSF. Il y a aussi une SCUAF
(Service Control User Agent Fonction) qui est une fonction de signalisation entre
terminal de l’abonné et le commutateur qui embarque la CUSF.

IN CS2 prévoit que des communication de SCF à SCF sont prévus pour mettre en
œuvre plusieurs plate formes de service.

Nous notons qu’une nouvelle fonction est prévue : l’IAF (Intelligent Acces Function),
pour permettre de dialoguer avec les entités d’un réseau non intelligent (comme
internet).

36
 IN-CS2

IN CS2 les fonctions du plan fonctionnel réparti

37
 IN-CS2
Il y a beaucoup plus de commandes INAP en IN-CS2.

Le modèle d’appel est considérablement modifié. Ils contiennent beaucoup plus de

PIC et de DP, ce qui donne beaucoup d’occasion de déclanchement de services.

Notons que en particulier que pendant la phase stable de l’appel (où l’appel établi)
des DP Mid_Call permettent de réaliser des « mid call interruptions ». Ces DP sont
très intéressant pour les conférences pour les lesquelles sont déjà établis (call
centers). Ces DP sont également intéressant pour les conférences pour lesquelles
il faut contacter tous les participants alors que les BCSM des différents appelés
seront dans cet état intermédiaire.

38
 IN-CS2
Le protocole INAP : un aperçu des commandes du CS2

 PROVIDE INSTRUCTION : SSF vers SCF

 CREATE : SSF vers CAS Établissement d’un appel sortant sur un
numéro indiqué
 JOIN : SCF vers SSF Connexion de deux circuits
 SPLIT : SCF vers SSF Déconnexion de deux circuits
 SEND & RECEIVE : SCF vers SSF Envoi de film ou tonalité sur un circuit;
réception des informations venant de l’abonné via ce circuit et retransmission au
SCF
 EVENT : SSF vers SCF Transfert au SCF d’une information de
signalisation sur un circuit
 GENERATE SIGNAL : SCF vers SSF Envoi par le SSF d’une information de
signalisation sur un circuit
 RETRIEVE : SCF vers SSF Demande par le SCF d’une information au
CAS; l’information est transmise dans la réponse à l’opération.
 ATTACH : SCF vers SSF Permet d’attacher un circuit à une transaction
 DETACH : SCF vers SSF Permet de détacher un circuit d’une transaction
 MONITOR : SCF vers SSF Pour associer un type de gestion
(transparent, en copie,…) à un type de message de SIG

39
 IN-CS3 et IN-CS4
Apres 1998, l’intérêt des constructeurs s’est déplacé en faveur des normes de
réseau intelligent CAMEL (Customised Application Mobile Enhanced Logic)
produite par l’ETSI, puis maintenant pour les nouvelles solutions de services au
dessus de la téléphonie sur IP (Application serveurs SIP). Néanmoins l’UIT a
continué un certain effort de normalisation et produit encore 2ensemble de
capacités: l’IN-CS3 puis l’IN-CS4. Ces ensembles de capacités ne donneront pas
lieu à des réalisation conformes à ces normes et nous ne ferons ici qu’indiquer
quels étaient leur objectifs.

 Pouvoir mettre en œuvre plusieurs Points de contrôle de Services, permettre

l’interaction entre éléments de services.

 Permettre la portabilité des numéros

 Prendre en compte la mobilité bande étroite.

 Assurer la compatibilité du réseau intelligent et du réseau RNIS à large bande

(RNIS-LB).

40
 IN-CS3 et IN-CS4
 L’intégration du RI et du réseau de gestion TMN (Télécommunication
management Network) tel que définie par l’UIT.

La norme IN-CS3 ne diffère pas beaucoup de IN-CS2. Comme l’indique le tableau

ci-dessous les spécifications du plan service, u plan fonctionnel global physique
sont les reprises à l’identique des spécifications de l’IN-CS2.

Spécification de IN-CS3
Q.1231 Introduction au CS3
Q.1222 Plan de service du CS2
Q.1223 Plan fonctionnel global du CS2
Q.1225 Plan physique du CS2
Q.1236 Spécification et méthodologie du modèle d’information de
gestion du CS3
Q.1237 Extension du CS3 pour la prise en charge du RNIS-LB
Q.1238 Interface pour le CS3

41
 IN-CS3 et IN-CS4
En mai 2001, l’UIT propose de nouveau un ensemble de capacités
supplémentaires: l’IN-CS4. Les objectifs de ce nouvel ensemble de capacités sont
essentiellement l’inter-fonctionnement du réseau intelligent téléphonique et de
l’internet. Il s’agit d’assurer la compatibilité du réseau RI avec de nouvelles normes
de proposées par l’IETF (Internet Inginering Task Force) : PINT (PSTN and
InteNetworking for telephony) et SPIRIT (serves in the PSTN/IN Requesting
Internet).

Les services PINT sont des services initialisés dans le réseau internet et se
terminant dans le réseau téléphonique. Les plus connus sont : Click to Talk, Click
To Talk Back, Click To Fax, Click To Fax back par lesquels un abonné peut
déclencher un appel téléphonique ou l’envoi d’un Fax, en cliquant sur une page
Web.

Les services SPIRIT sont des services initialisés dans le réseau téléphoniques et
se terminant dans le réseau internet. Le plus connu est l’Internet Call Waiting qui
permet à un abonné surfant sur le net avec un modem dans la bande, de recevoir
une notification sur son écran lui indiquant qu’un appel était en cours vers sa ligne.

42
 IN-CS3 et IN-CS4
Les spécifications propres à l’IN-CS4 sont données par le tableau suivant:

Spécification de IN-CS4
Q.1241 Introduction au CS4
Q.1244 Plan fonctionnel reparti du IN-CS4
Q.1248.1-7 Interface pour le CS4

43