Groupe de travail Réseau	R. Kumar & M. Mostafa	
Request for Comments : 3108	Cisco Systems	
Catégorie : En cours de normalisation		
Traduction Claude Brière de L’Isle	01/05/01	

Conventions pour l’utilisation du protocole de description de session (SDP) pour les connexions de support ATM

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2001). Tous droits réservés

Résumé
Le présent document décrit les conventions pour l’utilisation du protocole de description de session (SDP, Session Description Protocol) décrit dans la RFC2327 pour contrôler les connexions de porteuse ATM et toute couche d’adaptation ATM (AAL, ATM Adaptation Layer) associée. Les AAL visées sont de type 1, type 2 et type 5. Cette liste de conventions est destinée à être exhaustive. Les applications individuelles peuvent utiliser des sous ensembles de ces conventions. De plus, ces conventions sont destinées à se conformer strictement à la syntaxe de SDP telle que définie dans la RFC2327.
Table des Matières
1. Introduction	1
1.1 Mots clés pour indiquer les niveaux d’exigence	2
2. Représentation de certains champs dans les lignes de description de SDP	2
2.1 Représentation des attributs d’extension	3
2.2 Représentation des valeurs de paramètres	3
2.3 Convention de direction	3
2.4 Convention de casse	4
2.5 Utilisation de caractères spéciaux dans les valeurs de paramètres SDP	4
3. Capacités fournies par les conventions SDP	4
4. Format de description de la session ATM	5
5. Structure des lignes de description de session	6
5.1 Ligne d’origine	6
5.2 Ligne de nom de session	7
5.3 Ligne d’informations de connexion	7
5.4 Ligne d’horodatage	8
5.5 Ligne d’informations support des connexions ATM	9
5.6 Lignes d’attribut du support	14
6. Liste des paramètres avec représentations	43
7. Exemples de descriptions de session ATM utilisant SDP	46
8. Considérations sur la sécurité	47
8.1 Sécurité du support	47
8.2 Sécurité de la description SDP	47
9. Grammaire du SDP ATM	48
Références	54
Remerciements	56

1.	Introduction

SDP sera utilisé en conjonction avec un protocole de traitement de connexion / appareil de contrôle tel que Megaco (H.248) [26], SIP [18] ou MGCP [25] pour communiquer les informations nécessaires à l’établissement des connexions de support ATM et AAL2. Ces connexions incluent des connexions vocales, des connexions de données en bande vocale, des connexions d’émulations de circuit sur canal clair, des connexions vidéo et des connexions en bande de base (comme le relais de télécopie, le relais de modem, SSCOP, le relais de trame, etc.).

Ces conventions utilisent la syntaxe SDP standard comme défini dans la RFC2327 [1] pour décrire les connexions de niveau ATM et de niveau AAL, les adresses et d’autres paramètres. En général, les paramètres associés à des couches supérieures à la couche d’adaptation ATM ne sont incluses que si elles sont étroitement couplées aux couches ATM ou AAL. Comme la syntaxe se conforme à la RFC2327, les analyseurs SDP standard devraient réagir d’une manière bien définie et sûre à réception de descriptions de session fondées sur les conventions SDP du présent document. Cela est fait en étendant les valeurs des champs définies dans la RFC2327 plutôt qu’en définissant de nouveaux champs. Ceci est vrai pour toutes les lignes SDP sauf les lignes de l’attribut de support, auquel cas de nouveaux attributs sont définis. Le protocole SDP permet la définition de nouveaux attributs dans les lignes d’attribut de support qui sont de forme libre. Pour les lignes restantes, le fait que le champ <TypeDeRéseau> dans un descripteur SDP soit réglé à "ATM" devrait empêcher la mauvaise interprétation des valeurs de paramètre étendues par les analyseurs SDP conformes à la RFC2327.

Ces conventions sont destinées à s’adresser aus applications ATM suivantes :

1.	Applications dans lesquelles un nouvel SVC est établi pour chaque connexion de service. Ces SVC pourraient être des SVC AAL1 ou AAL5 ou des SVC AAL2 à un seul CID.
2.	Applications dans lesquelles les ressources de chemin existantes sont allouées aux connexions de service. Ces ressources pourraient être :
*	des PVC AAL1/AAL5, des SPVC ou des SVC en antémémoire,
*	des PVC AAL2 à un seul CID, des SPVC ou des SVC en antémémoire,
*	des CID au sein de /PVC/SPVC AAL2 qui multiplexent plusieurs CID.
*	des sous canaux (identifiés par les CID) au sein de SVC/PVC/SPVC AAL1 [8] ou AAL2 [11].

Noter que la différence entre les PVC et les SPVC est dans la façon dont la connexion de circuit virtuel support est établie. Les SPVC sont une classe de PVC qui utilise la signalisation du support, par opposition au provisionement nœud par nœud, pour l’établissement de la connexion.

Le présent document se limite au cas où le type de réseau est ATM. Cela inclut des encapsulations RTP brutes [45] ou l’encapsulation d’échantillons vocaux [46] sur AAL5 sans intervention de la couche IP. Il ne traite pas de l’utilisation de SDP pour IP, avec ou sans ATM comme couche inférieure.

Dans certains cas, l’établissement de la connexion IP est indépendant des couches inférieures, qui sont configurées avant elle. Par exemple, les PVC AAL5 qui se connectent aux routeurs IP peuvent être utilisés pour les appels VoIP. Dans d’autres cas, l’établissement de l’appel VoIP est étroitement lié à l’établissement de connexion de niveau ATM. Cela peut exiger un chaînage des descripteurs IP et ATM, comme décrit au paragraphe 5.6.4.1.

Le présent document ne fait pas d’hypothèse sur celui qui construit les descriptions de session (passerelle de support, commutateur intermédiaire ATM/AAL2, contrôleur de passerelle de supports, etc.). Cela sera différent dans des applications différentes. De plus, cela permet l’utilisation d’une description de session pour les deux directions d’une connexion (comme dans les applications SIP et MGCP) ou l’utilisation de descriptions de session différentes pour des directions différentes. Cela vise aussi les capacités ATM de diffusion groupée et d’envoi à la cantonade.

Le présent document ne fait pas d’hypothèse sur la façon dont la description SDP sera codée. Bien que les descriptions qu’on montre ici soient codées comme du texte, d’autres codages sont possibles :
-	un codage binaire comme ASN.1. C’est une option (en plus du codage en texte) dans le contexte Megaco.
-	l’utilisation de paramètres ISUP étendus [36] pour coder les informations dans les descripteurs SDP, avec conversion de/en codage SDP binaire/fondé sur le texte, lorsque nécessaire.

1.1	Mots clés pour indiquer les niveaux d’exigence

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la RFC2119 [62].

2.	Représentation de certains champs dans les lignes de description de SDP

Le présent document se conforme aux conventions syntaxiques du SDP standard définies dans la RFC 2327 [1].

2.1	Représentation des attributs d’extension

Le protocole SDP [1] exige que les attributs non standard et les noms de codec utilisent un préfixe "X-".

Dans le présent document Internet, le préfixe "X-" est utilisé de façon cohérente pour les noms de codec (Tableau 2) qui n’ont pas été enregistrés auprès de l’IANA. Les noms de codec enregistrés auprès de l’IANA énumérés dans [31] n’utilisent pas ce préfixe, sans considérer si ils sont des types de charge utile alloués statiquement ou dynamiquement.

Cependant, ce préfixe n’est pas utilisé pour les attributs d’extension SDP définis dans le présent document. Cela a été fait pour améliorer la lisibilité.

Le présent document suggère que les analyseurs soient souples dans l’utilisation de la convention de préfixe "X-". Ils devraient accepter les noms de codec et les noms d’attribut avec ou sans le préfixe "X-".

2.2	Représentation des valeurs de paramètres

Selon le format de leur représentation en SDP, les paramètres définis dans le présent document entrent dans les classes suivantes :
(1)	Paramètres toujours représentés en format décimal.
(2)	Paramètres toujours représentés en format hexadécimal.
(3)	Paramètres toujours représentés comme des chaînes de caractères.
(4)	Paramètres qui peuvent être représentés en format décimal ou  hexadécimal.

Aucun préfixe n’est nécessaire pour les classes 1 à 3, car le format est fixé. Pour la classe 4, un préfixe "0x" devra toujours être utilisé pour différencier le format hexadécimal du décimal.

Pour les deux représentations décimale et hexadécimale, si le champ binaire sous-jacent est plus petit ou plus grand que l’équivalent binaire de la représentation SDP, des bits 0 devraient alors être ajoutés ou retirés en tête selon le besoin. Donc, 3 et 0x3 se traduisent dans le schéma à cinq bits suivant : 0 0011. Les représentations SDP 0x12 et 18 se traduisent en le schéma à cinq bits suivant : 1 0010.

Des chiffres 0 en tête ne devront pas être utilisés dans les représentations décimales.
Généralement, ils ne sont pas aussi utilisés dans les représentations hexadécimales. Les exceptions sont lorsque un nombre exact de chiffres hexadécimaux est attendu, comme dans le cas des adresses NSAP. Les analyseurs ne devront pas rejeter les zéros en tête dans les valeurs hexadécimales.

Les valeurs des chaîne d’un seul caractère aussi bien que multi caractères sont incluses entre guillemets (c’est-à-dire, "). À l’opposé, une simple apostrophe (c’est-à-dire, ') est utilisée pour souligner les mots-clés plutôt que se référer aux caractères ou aux chaînes.

Dans la représentation textuelle des nombres décimaux et hexadécimaux, les chiffres de gauche ont un plus fort poids que ceux de droite.

2.3	Convention de direction
Ce paragraphe définit la signification des termes 'vers l’avant' et 'vers l’arrière' lorsque ils sont utilisés dans le présent document. Ceci est particulièrement applicable aux paramètres qui sont associés à une direction spécifique.

Dans le présent document, 'vers l’avant' se réfère à la direction qui s’éloigne du nœud ATM considéré, tandis que 'vers l’arrière' se réfère à la direction vers le nœud ATM. Cette convention doit être utilisée dans toutes les descriptions de session fondées sur SDP, sans considération de si le support sous-jacent est un SVC, un PVC/SPVC alloué dynamiquement ou un CID alloué dynamiquement. Ceci, quel que soit le côté qui a généré la connexion de service. Si une signalisation de SVC ATM ou de AAL2 Q.2630.1 est utilisée, la convention de direction est indépendante du côté qui a généré la connexion SVC ou AAL2.

Cela donne un moyen simple pour identifier la direction dans laquelle un paramètre est applicable, d’une manière indépendante du support ATM ou AAL2 sous-jacent. Cette simplicité a un prix que l’on va décrire ci-dessous.

La convention utilisée par toutes les spécifications de signalisation ATM/AAL2 (par exemple, au paragraphe 1.3.3 de Q.2931 et dans Q.2630.1) exige que vers l’avant soit de l’extrémité qui initie l’établissement via la signalisation de support vers l’extrémité qui reçoit la demande d’établissement. Vers l’arrière est dans la direction opposée. Dans certains cas, les directions 'vers l’avant' et 'vers l’arrière' de la convention de signalisation ATM peuvent être l’exact opposé de la convention SDP décrite ci-dessus, exigeant que la passerelle support effectue la traduction nécessaire. Un exemple dans lequel ceci est nécessaire est décrit ci-dessous.

Considérons une description SDP envoyée par un contrôleur de passerelle de supports à la passerelle qui a généré un appel de niveau service. Dans le modèle d’établissement d’appel SVC vers l’arrière, cette passerelle termine (plutôt qu’elle ne génère) un appel SVC. La passerelle de supports se réfère au descripteur de trafic (et donc au PCR) dans la direction qui s’éloigne de cette passerelle comme descripteur de trafic et PCR vers l’avant. Il est clair que ceci est à l’opposé de la direction de la signalisation de SVC ATM qui se réfère à ce même PCR comme le PCR vers l’arrière. La passerelle a besoin d’être capable d’effectuer l’échange de direction requis. Dans cet exemple, la passerelle de supports qui termine l’appel de niveau service (et donc qui génère l’appel SVC) n’a pas besoin d’effectuer cet échange.

Certains paramètres au sein d’attributs sont définis exclusivement vers l’avant ou vers l’arrière. Des exemples de vers l’avant sont le sous paramètre <fsssar> au sein de la ligne d’atttribut de support 'aal2sscs3661unassured', les sous paramètres <fsssar>, <fsscopsdu> et <fsscopuu> au sein de la ligne d’attribut de support 'aal2sscs3661assured', les sous paramètres <fsscopsdu> et <fsscopuu> au sein de la ligne d’attribut de support 'aal5sscop', et le paramère <fmaxFrame> au sein de la ligne d’attribut de support 'aal2sscs3662'. Des exemples de vers l’arrière sont le sous paramètre <bsssar> au sein de la ligne d’attribut de support 'aal2sscs3661unassured', les sous paramètres <bsssar>, <bsscopsdu> et <bsscopuu> au sein de la ligne d’attribut de support 'aal2sscs3661assured', les sous paramètres <bsscopsdu> et <bsscopuu> au sein de la ligne d’attribut de support 'aal5sscop', et le paramètre <bmaxFrame> au sein de la ligne d’attribut de support 'aal2sscs3662'.

2.4	Convention de casse
Comme défini dans la RFC 2327 [1], la syntaxe SDP est sensible à la casse. Comme ces conventions ATM se conforment strictement à la syntaxe SDP, elles sont sensibles à la casse. Les types de ligne SDP (par exemple, "c", "m", "o", "a") et les champs dans les lignes SDP devraient être construits conformément aux conventions de casse de [1] et du présent document. Il est suggéré mais pas exigé que les analyseurs SDP pour les applications ATM soient tolérants à la casse lorsque ignorer la casse ne résulte pas en une ambiguïté. Les noms de codage, qui sont définis en dehors du protocole SDP, sont insensibles à la casse.

2.5	Utilisation de caractères spéciaux dans les valeurs de paramètres SDP
En général, les valeurs de chaîne conformes à la RFC2327 des paramètres SDP [1] ne comportent pas de caractères spéciaux qui ne soient ni alphabétiques ni numériques. Une exception est le caractère "/" utilisé dans la valeur "RTP/AVP" du sous-champ Transport de la ligne 'm'.

Les valeurs de chaîne utilisées dans les descriptions SDP des connexions ATM conservent cette convention, tout en permettant l’utilisation du caractère spécial "/" d’une manière compatible avec [1]. De plus, les caractères spéciaux "$" et "-" sont utilisés de la manière suivante. Une valeur "$" est un caractère générique qui permet au receveur de la description SDP de choisir toute valeur permise du paramètre. Une valeur "-" indique qu’il n’est pas nécessaire de spécifier la valeur du paramètre dans la description SDP parcc que ce paramètre n’est pas pertinent dans cette application, ou parce que sa valeur peut être connue d’une autre source comme l’approvisionnement, une valeur par défaut, un autre protocole, un autre descripteur SDP ou une autre partie du même descripteur SDP. Si l’utilisation de ces caractères spéciaux est perçue comme unc violation de la syntaxe de la RFC2327 [1], on peut alors utiliser des valeurs de chaîne réservées. La chaîne "CHOOSE" peut être utilisée à la place de "$". La chaîne "OMIT" peut être utilisée à la place de "-" pour un paramètre omis.

3.	Capacités fournies par les conventions SDP

Pour prendre en charge les applications énumérées dans la section 1, les conventions SDP dans le présent document fournissent les capacités de contrôle de session suivantes :
*	Identification du type de réseau de support sous-jacent comme ATM.
*	Identification par un élément de réseau ATM de sa propre adresse, dans un des formats possibles. Un homologue de connexion peut initier l’établissement du SVC à cette adresse. Un agent d’appel ou un homologue de connexion peut choisir un chemin de support pré-établi vers cette adresse.
*	Identification de la connexion support ATM qui doit être liée à la connexion de niveau service. Selon l’application, c’est soit un VCC, soit un sous canal (identifié par un CID) au sein d’un VCC.
*	Identification du type de support : audio, vidéo, données.
*	Dans les applications AAL1/AAL5, la déclaration d’un ensemble de types de charges utiles qui peuvent être liées à la connexion support ATM. Les noms de codage et les types de charges utiles définies pour être utilisées dans le contexte RTP [31] sont réutilisés pour AAL1 et AAL5, si c’est applicable.
*	Dans les applications AAL2, la déclaration d’un ensemble de profils qui peuvent être liés à la connexion support ATM. Un mécanisme pour définir de façon dynamique les profils personnalisés au sein de la description de session SDP est inclus. Cela permet d’utiliser des profils personnalisés pour les connexions qui s’étendent sur plusieurs interfaces multi réseaux.
*	Un moyen de corréler les connexions de niveau service avec les connexions support ATM sous-jaccentes. L’identifiant de connexion de cœur de réseau ou le bnc-id spécifié dans la Recommandation UIT-T Q.1901 [36] est utilisé à cette fin. Pour fournir une base SDP commune pour les applications fondées sur Q.1901 et SIP/SIP+, le terme neutre 'eecid' est utilisé au lieu de 'bnc-id' dans le descripteur de session SDP.
*	Un moyen de transposer les types de codec et les périodes de mise en paquet en types de service (vocal, données en bande vocale et télécopie). Cela est utile pour déterminer le codage à utiliser lorsque la connexion est accélérée en réponse à des tonalités de modem ou de télécopie.
*	Un moyen de décrire le type d’adaptation, la classe de QS, la catégorie de capacité/service de transfert ATM, la classe de support haut débit, les paramètres de trafic, les paramètres de CPS et les paramètres de SSCS en rapport avec la connexion support sous-jacente.
*	Un moyen pour activer ou décrire des fonctions spéciales comme une jonction à l’initiative de l’extrémité, l’envoi à la cantonade et la mise en antémémoire de SVC.
*	Pour les applications de l’Annexe C à la Recommandation UIT-T H.323, un moyen de spécifier l’adresse IP et le numéro d’accès sur lesquels le nœud va recevoir les messages RTPC.
*	Un moyen pour chaîner des descripteurs SDP consécutifs afin qu’ils se réfèrent aux différentes couches de la même connexion.

4.	Format de description de la session ATM

La séquence des lignes dans les descriptions de session dans le présent document se conforme à la RFC2327 [1]. En général, une description de session consiste en une partie de niveau session suivie par zéro, une ou plusieurs parties de niveau support. Les descriptions de session ATM consistent en une partie de niveau session suivie par une ou deux parties de niveau support. Les deux seuls supports applicables sont le support de porteuse ATM et le contrôle RTCP (lorsque applicable).

La partie de niveau session comporte les lignes suivantes :
v=  (version du protocole, zéro ou une ligne)
o=  (origine, zéro ou une ligne)
s=  (nom de session, zéro ou une ligne)
c=  (informations de connexion, une ligne)
b=  (bande passante, zéro, une ou plusieurs lignes)
t=  (horodatage, zéro ou une ligne)
k=  (clé de chiffrement, zéro ou une ligne)

Dans les descriptions de session ATM, il n’y a pas de ligne d’attribut du support dans la partie de niveau session. Elles sont présentes dans les parties de niveau support.

La partie de niveau support pour la porteuse ATM consiste en les lignes suivantes :
m=  (informations sur le support et adresse de transport, une ligne)
b=  (bande passante, zéro, une ou plusieurs lignes)
k=  (clé de chiffrement, zéro, une ou plusieurs lignes)
a=  (attribut du support, zéro, une ou plusieurs lignes)

La partie de niveau support pour le contrôle RTCP consiste en les lignes suivantes :
m=  (informations sur le support et adresse de transport, une ligne)
c=  (informations de connexion pour le seul contrôle, une ligne)

En général, les lignes 'v', 'o', 's', et 't' sont obligatoires. Cependant, dans le contexte Megaco [26], ces lignes ont été rendues facultatives. Les lignes 'o', 's', et 't' sont omises dans la plupart des applications MGCP [25].

Noter que les descripteurs de session SDP pour ATM peuvent contenir des lignes de bande passante (b=) et de clé de chiffrement (k=). Comme toutes les autres lignes, ces lignes devraient se conformer strictement à la norme SDP [1].

La ligne bande passante (b=) n’est pas nécessairement redondante dans le contexte ATM car, dans certaines applications, elle peut être utilisée pour porter des informations de niveau application qui ne se transposent pas directement en la ligne d’attribut de support atmTrfcDesc. Par exemple, la ligne 'b' peut être utilisée dans les descripteurs SDP dans les commandes RTSP pour décrire la bande passante du contenu.

La ligne clé de chiffrement (k=) peut être utilisée pour indiquer une clé de chiffrement pour le support, et une méthode pour obtenir la clé. À présent, le chiffrement des supports ATM et AAL2 n’a pas encore été réglé par des conventions, à la différence du chiffrement des charges utiles de RTP. Non plus que l’authentification ou le chiffrement de la signalisation de support ATM ou AAL2. Dans les contextes d’ATM et de AAL2, le terme de 'support' peut inclure la 'signalisation de support' aussi bien que les 'charges utiles de support'.

L’ordre des lignes dans une description de session ATM est exactement l’ordre conforme à la RFC2327 décrit ci-dessus. Cependant, il n’y a pas d’ordre des lignes d’attribut de support ('a') par rapport aux autres lignes 'a'.

La version du protocole SDP pour les descriptions de session qui utilisent ces conventions est 0. En conformité avec le SDP standard, il est fortement recommandé que la ligne 'v' soit incluse au début de chaque description de session SDP. Dans certains contextes comme Megaco, la ligne 'v' est facultative et peut être omise sauf si plusieurs descriptions de session sont fournies à la suite, auquel cas la ligne 'v' sert de délimiteur. Selon l’application, les séquences de descriptions de session peuvent se référer à :
-	différentes connexions ou sessions,
-	d’autres façons de réaliser la même connexion ou session,
-	différentes couches de la même session (paragraphe 5.6.4.1).

Les lignes 'o', 's' et 't' sont incluses pour une stricte conformité avec la RFC2327. Il est possible que ces lignes ne portent pas d’informations utiles dans certaines applications fondées sur ATM. Donc, certaines applications peuvent omettre ces lignes, bien qu’il soit recommandé qu’elle ne le fassent pas. Pour maximiser l’interopérabilité, il est préférable que les analyseurs SDP ne rejettent pas les descriptions de session qui ne contiennent pas ces lignes.

5.	Structure des lignes de description de session
5.1	Ligne d’origine
La ligne d’origine pour une session fondée sur ATM est structurée comme suit :

o=<nomd’utilisateur> <sessionID> <version> <TypeDeRéseau> <Typed’Adresse> <Adresse>

Le <nomd’utilisateur> est réglé à "-".

Le <sessionID> peut être réglé à un des suivants :
*	un horodatage NTP se référant au moment de la création du descripteur de session SDP.
*	un identifiant d’appel, un identifiant de connexion ou un identifiant de contexte qui identifie de façon univoque la session dans la portée du nœud ATM. Comme les appels peuvent comprendre plusieurs connexions (sessions), les identifiants d’appel ne conviennent généralement pas pour cela.

Les horodatages NTP peuvent être représentés comme des entiers décimaux ou hexadécimaux. La partie de l’horodatage NTP qui se réfère à un nombre entier de secondes est suffisant. C’est un champ de 32 bits.

D’un autre côté, les identifiants d’appel, les identifiants de connexion, et les identifiants de contexte peuvent être de 32 chiffres hexadécimaux.

Le champ <sessionID> est représenté comme un nombre décimal ou hexadécimal de jusqu’à 32 chiffres. Un préfixe "0x" est utilisé avant la représentation hexadécimale. Le champ <version> se réfère à la version du descripteur de session SDP (pas à celle du protocole SDP). Il peut être réglé à une des valeurs suivantes :
*	0.
*	un horodatage NTP se référant au moment de la modification du descripteur de session SDP. Si le descripteur de session SDP n’a pas été modifié par une entité intermédiaire (comme un MGC) l’horodatage <version> sera alors le même que l’horodatage <sessionID>, si il en est. Comme avec le <sessionID>, seule la partie entière de l’horodatage NTP est utilisée.

Lorsque il a été réduit à la partie entière d’un horodatage NTP, le champ <version> fait 10 chiffres. Ceci est plus restrictif que [1], qui permet une taille illimitée. Comme dans [1], le chiffre de plus fort poids n’est pas à zéro quand un horodatage NTP est utilisé.

Le <TypeDeRéseau> dans les descriptions de session SDP pour les applications ATM devrait recevoir la valeur de chaîne "ATM" ou une valeur générique de "$" ou "-".

Les paramètres <TypeD’Adresse> et <Adresse> sont identiques à ceux des informations de connexion de la ligne ('c') (paragraphe  5.3). Chacun de ces paramètres peut être représenté par un caractère générique selon les conventions décrites pour la ligne 'c' au paragraphe 5.3. Ces paramètres ne devraient pas être omis car cela violerait la syntaxe SDP [1].

Comme avec la ligne 'c', les analyseurs SDP ne sont pas supposés vérifier la cohérence de <TypeDeRéseau> avec les paires <TypeD’Adresse>, <Adresse>. <TypeD’Adresse> et <Adresse> doivent être cohérents l’un avec l’aurtre.

5.2	Ligne de nom de session
En général, la ligne Nom de session est structurée comme suit :

s=<nomDeSession>

Pour les sessions fondées sur ATM, le paramètre <nomDeSession> est réglé à "-". la ligne résultante est :

s=-

5.3	Ligne d’informations de connexion
En général, la ligne d’informations de connexion [1] est structurée comme suit :

c=<TypeDeRéseau> <TypeD’Adresse> <Adresse>

Pour les réseaux ATM, des valeurs supplémentaires de <TypeDeRéseau>, <TypeD’Adresse> et de <Adresse> sont définies, en plus de celles énumérées dans [1]. La syntaxe ABNF (Section 9) pour SDP ATM ne limite pas les façons dont <TypeDeRéseau> peut être combiné avec les paires <TypeD’Adresse>, <Adresse>. Cependant, certaines combinaisons ne seront pas valides dans certaines applications, tandis que d’autres ne seront jamais valides. Les combinaisons invalides devraient être rejetées par des fonctions spécifiques de l’application, et non par des analyseurs génériques. La syntaxe ABNF ne limite pas les façons dont <TypeD’Adresse> et <Adresse> peuvent être appariés.

Pour les réseaux ATM, la valeur de <TypeDeRéseau> devrait être réglée à "ATM". De plus, cela peut être remplacé par un caractère générique de "$" ou "-". Si cela est fait, un nœud qui utilise ATM comme mécanisme de transport de base choisira une valeur de "ATM". Un nœud qui a des interfaces avec plusieurs types de réseaux ("IN", "ATM", etc.) qui incluent ATM peut aussi choisir une valeur de "ATM".

Lorsque la description SDP est construite par un nœud comme une passerelle de supports, le <Adresse> se réfère à l’adresse du nœud qui construit la description SDP. Lorsque cette description est transmise à un autre nœud, il contient encore l’adresse du nœud d’origine. Lorsque le contrôleur de la passerelle de supports construit une partie ou toute la description SDP, le descripteur local contient l’adresse du nœud local, tandis que le descripteur distant contient l’adresse du nœud distant. Si le <Adresse> et/ou <TypeD’Adresse> ne sont pas pertinents ou sont connus par d’autres moyens, ils peuvent être réglés à "$" ou a "-", comme décrit ci-dessous.

De plus, dans tous les contextes, la ligne 'm' peut avoir une adresse ATM dans le sous paramètre <virtualConnectionId> qui, s’il est présent, est l’adresse distante si l’adresse de ligne 'c' est locale, et vice versa.

Pour les réseaux ATM, le <TypeD’Adresse> peut être NSAP, E164 ou GWID (ALIAS). Pour les réseaux ATM, la syntaxe de <Adresse> dépend de la syntaxe de <TypeD’Adresse>. Les analyseurs SDP devraient vérifier la cohérence de <TypeD’Adresse> avec <Adresse>.

NSAP : si le type d’adresse est NSAP, l’adresse est exprimée sous la forme hexadécimale standard séparée par des points. C’est une chaîne de 40 chiffres héxadécimaux, avec un point après le 2ème, 6ème, 10ème, 14ème, 18ème, 22ème, 26ème, 30ème, 34ème et 38ème chiffre. Le dernier octet de l’adresse NSAP est le champ 'sélecteur' qui est disponible pour les utilisations non standard. Un exemple d’une ligne avec une adresse NSAP est :

c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00

Un préfixe "0x" ne devra pas être utilisé dans ce cas car c’est toujours en format hexadécimal.

E164 : si le type d’adresse est E164, l’adresse est exprimée comme un nombre décimal avec jusqu’à 15 chiffres. Par exemple :

c=ATM E164 9738294382

L’utilisation des numéros E.164 dans le contexte du RNIS-LB est défini dans la Recommandation UIT-T E.191. Il y a une disparité entre le Forum ATM et l’UIT pour l’utilisation des numéros E.164 pour l’adresssage ATM. Le Forum ATM (par exemple dans la signalisation UNI 4.0) ne permet que le format international des numéros E.164, tandis que l’UIT (par exemple, Q.2931) permet des plans de numérotage privés. Comme le but de la présente spécification SDP est d’interopérer avec tous les protocoles de signalisation, elle permet l’utilisation de numéros qui ne se conforment pas au format international E.164. Cependant, pour maximiser la cohérence globale, les administrateurs de réseaux peuvent restreindre l’approvisionnement des numéros au format international E.164.

GWID (ALIAS) : si le type d’adresse est GWID, cela signifie que l’adresse est un identifiant de passerelle ou un alias de nœud. Il peut être ou non unique au monde. Dans ce format, l’adresse est exprimée par une chaîne alphanumérique ("A"-"Z", "a"-"z", "0" - "9",".","-","_"). Par exemple :

c=ATM GWID officeABCmgx101vism12

Comme ces conventions SDP peuvent être utilisées pour plus que des passerelles, la chaîne "ALIAS" peut être utilisée à la place de "GWID" dans la ligne 'c'. Donc, l’exemple ci-dessus est équivalent à :

c=ATM ALIAS officeABCmgx101vism12

Un exemple de GWID (ALIAS) est le code CLLI utilisé pour les équipements de télécommunications. Du point de vue pratique, il devrait être adéquat que le GWID (ALIAS) soit une chaîne de longueur variable avec une taille maximum de 32  caractères.

La ligne d’informations de connexion est toujours présente dans un descripteur de session SDP. Cependant, chacun des paramètres de cette ligne peut être remplacé par un caractère générique "$" ou "-", indépendamment du fait que d’autres paramètres de cette ligne le sont aussi ou pas. Toutes les combinaisons syntaxiquement légales de caractères génériques ne sont pas significatives dans une application particulière.

Des exemples de combinations significatives de caractères génériques dans le contexte d’ATM sont :
c=- - -
c=$ $ $
c=ATM - -
c=ATM $ $
c=ATM <TypeD’Adresse> -
c=ATM <TypeD’Adresse> $

Spécifier le type d’adresse ATM sans spécifier l’adresse ATM est utile lorsque il est demandé au receveur de choisir une adresse ATM d’un certain type (NSAP, E.164, etc.).

Des exemples de combinaisons de caractères génériques syntaxiquement légales d’utilité douteuse sont :
c=- $ -
c=- $ $
c=- <TypeD’Adresse> -
c=$ <TypeD’Adresse> $
c=- <TypeD’Adresse> <Adresse>
c=$ <TypeD’Adresse> <Adresse>

Noter que <TypeD’Adresse> et/ou <Adresse> ne devraient pas être omis sans être réglés à "-" ou "$" car cela violerait la syntaxe de base SDP [1].

5.4	Ligne d’horodatage
La ligne Horodatage pour une descripteur de session SDP est structurée comme suit :

t= <heureDeDébut> <heureDeFin>

Selon la référence [49], l’horodatage NTP utilise une représentation sur 32 bits non signée des secondes, et une représentation sur 32 bits non signée des fractions de secondes. Pour les sessions fondées sur ATM, le paramètre <heureDeDébut>peut être rendu égal à l’horodatage NTP qui se réfère au moment où le descripteur de session SDP a été créé. Il peut aussi être réglé à 0 pour indiquer qu’il n’est pas pertinent. Si il a été mis égal à l’horodatage NTP en secondes, la partie fractionnaire de l’horodatage NTP est omise. Lorsque il est mis égal à la partie entière d’un horodatage NTP, le champ <heureDeDébut> fait 10  chiffres. Ceci est plus restrictif que [1], qui permet une taille illimitée. Comme dans [1], le chiffre de poids fort n’est pas zéro quand un horodatage NTP est utilisé.

Le paramètre <heureDeFin> est réglé à 0 pour les descripteurs SDP fondés sur ATM.

5.5	Ligne d’informations support des connexions ATM
Le format général de la ligne d’information de supports adaptée pour les applications AAL1 et AAL5 est :

m=<support> <virtualConnectionId> <transport> <liste de formats>

Le format général de la ligne d’information de supports adaptée pour les applications AAL2 est :

m=<support> <virtualConnectionId> <transport n°1> <liste de formats n°1> <transport n°2> <liste de formats n°2> ... <transport n°M> <liste de formats n°M>

Noter que <virtualConnectionId> est équivalent à <accès> dans [1].

Le sous paramètre <support> peut prendre toutes les valeurs définies dans [1]. Ce sont : "audio", "vidéo", "application", "données" et "contrôle".

Lorsque le paramètre <transport> a plus d’une valeur dans la ligne 'm', les paires <transport>, <liste de formats> peuvent être arrangées en ordre de préférence.

5.5.1	Identifiant de connexion virtuelle
Dans les applications dans lesquelles la partie niveau support d’un descripteur de session est limitée à un circuit virtuel ATM, le <virtualConnectionId> peut être d’un des formats suivants :
* <ex_vcci>
* <TypeD’Adresse>-<Adresse>/<ex_vcci>
* <Adresse>/<ex_vcci>
* <ex_bcg>/<ex_vcci>
* <ex_portId>/<ex_vpi>/<ex_vci>
* <ex_bcg>/<ex_vpi>/<ex_vci>
* <ex_vpci>/<ex_vci>
* <TypeD’Adresse>-<Adresse>/<ex_vpci>/<ex_vci>
* <Adresse>/<ex_vpci>/<ex_vci>

Dans les applications dans lesquelles la partie niveau support d’un descripteur de session se limite à un sous canal au sein d’un circuit virtuel ATM, le <virtualConnectionId> peut avoir un des formats suivants :
* <ex_vcci>/<ex_cid>
* <TypeD’Adresse>-<Adresse>/<ex_vcci>/<ex_cid>
* <Adresse>/<ex_vcci>/<ex_cid>
* <ex_bcg>/<ex_vcci>/<ex_cid>
* <ex_portId>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_bcg>/<ex_vpi>/<ex_vci>/<ex_cid>
* <ex_vpci>/<ex_vci>/<ex_cid>
* <TypeD’Adresse>-<Adresse>/<ex_vpci>/<ex_vci>/<ex_cid>
* <Adresse>/<ex_vpci>/<ex_vci>/<ex_cid>

Ici,
<ex_vcci> = VCCI-<vcci>
<ex_vpci> = VPCI-<vpci>
<ex_bcg> = BCG-<bcg>
<ex_portId> = PORT-<portId>
<ex_vpi> = VPI-<vpi>
<ex_vci> = VCI-<vci>
<ex_cid> = CID-<cid>

Les paramètres <vcci>, <vpi>, <vci>, <vpci> et <cid> sont des nombres décimaux ou hexadécimaux. Un préfixe "0x" est utilisé avant leur valeur lorsque ils sont en format hexadécimal.

Le <portId> est toujours un nombre hexadécimal. Il n’utilise pas le préfixe "0x".

Les <TypeD’Adresse> et <Adresse> sont identiques à leur définition ci-dessus pour la ligne d’informations de connexion avec pour différence que cette adresse se réfère à l’homologue distant dans la ligne d’informations support. Comme le <virtualConnectionId>, comme défini ici, est destiné à être utilisé dans les réseaux ATM, les valeurs de <TypeD’Adresse> et <Adresse> dans le <virtualConnectionId> sont limitées aux valeurs spécifiques d’ATM.

Le <vpi>, <vci> et <cid> sont respectivement l’identifiant de chemin virtuel, l’identifiant de circuit virtuel, et l’identifiant de canal. Le champ <vpi> fait 8 ou 12 bits. Le champ <vci> fait 16 bits. Le champ <cid> fait 8 bits ([8] et [11]). Pour les applications AAL1, il correspond au numéro de canal défini dans l’Annexe C de [8].

Le champ <vpci> fait 16 bits comme défini au paragraphe 4.5.16 de la Recommandation UIT-T Q.2931 [15]. Le champ <vpci> est similaire au <vpi>, excepté pour sa longueur et le fait qu’il conserve sa valeur à travers les interconnexions de VP. Dans certaines applications, la taille de <vpci> est la même que celle de <vpi> (8 ou 12 bits). Dans ce cas, les 8 ou 4 bits de poids fort sont ignorés.

Le <vcci> est un champ de 16 bits défini dans la Recommandation UIT-T Q.2941.2 [32]. Le <vcci> est similaire au <vci>, excepté le fait qu’il conserve sa valeur à travers les interconnexions de VP.

En général, les valeurs de <vpci> et de <vcci> sont uniques entre une paire de nœuds. Lorsque elles sont uniques entre une paire de nœuds mais pas uniques au sein d’un réseau, elles doivent être qualifiées, à l’un des nœuds, par l’adresse ATM du nœud distant. Ces paramètres peuvent être pré-provisionnés ou signalés. Lorsqu’il est signalé, le <vpci> est encapsulé dans l’élément d’information Identifiant de connexion des messages de signalisation SVC. Le <vcci> est encapsulé dans l’élément d’information, Transport d’informations génériques (GIT, Generic Information Transport) des messages de signalisation SVC. Dans une paire de nœuds ATM, l’un ou l’autre nœud peut allouer des valeurs de <vcci> et le signaler à l’autre extrémité via la signalisation SVC. Un schéma d’évitement de double prise est défini dans [32] et [44]. Ce mécanisme fonctionne dans les applications SVC. Une technique d’évitement de double prise différente est nécessaire lorsque un réservoir de PVC/SPVC existants est alloué dynamiquement aux appels. Un de ces schémas pour l’évitement de double prise est l’allocation de valeurs de <vcci> provenant de différentes extrémités de la gamme de <vcci>, en utilisant la plus faible ou la plus forte valeur disponible, selon le cas applicable.

Lorsque les valeurs de <vpci> et de <vcci> sont pré-provisionnées, les administrations ont le choix de les provisionner de façon univoque dans un réseau. Dans ce cas, l’adresse ATM de l’extrémité distante n’est pas nécessaire pour qualifier ces paramètres.

Dans le contexte AAL2, la définition d’un VCC implique qu’il n’y ait pas de commutation de niveau CID entre ses extrémités. Si l’une et l’autre extrémité peut allouer des valeurs de <cid>, un mécanisme de réduction de double prise est nécessaire. Un tel schéma de réduction de double prise est l’allocation de valeurs de <cid> provenant des différentes extrémités de la gamme de <cid>, en utilisant selon le cas applicable la plus forte ou la plus faible valeur disponible.

Le paramètre <portId> est utilisé pour identifier l’accès de circuit physique sur un module ATM. Il peut être représenté comme un nombre hexadécimal de jusqu’à 32 chiffres.

Dans certaines applications, il est significatif de grouper un ensemble de connexions entre une paire de nœuds ATM en un groupe de connexions porteuses. Le sous paramètre <bcg> est un champ de huit bits qui permet le groupage de jusqu’à 255 VPC ou VCC.

Dans certaines applications, il est nécessaire de remplacer par un caractère générique le paramètre <virtualConnectionId>, ou certains éléments de ce paramètre. Le caractère générique "$" peut être substitué au paramètre <virtualConnectionId> entier, ou à certains de ses termes. Dans ce dernier cas, la chaîne constante qui qualifie les termes dans le <virtualConnectionId> est conservée. L’enchaînement de <TypeD’Adresse>-<Adresse> peut être remplacé par un caractère générique de la façon suivante :
*	l’enchaînement entier, <TypeD’Adresse>-<Adresse>, est remplacé par un "$",
*	<Adresse> est remplacé par un "$", mais pas <TypeD’Adresse>.

Des exemples de remplacement de <virtualConnectionId> par un caractère générique dans le contexte de AAL1 et AAL5 sont  : $, VCCI-$, BCG-100/VPI-20/VCI-$.
Des exemples de remplacement de <virtualConnectionId> par un caractère générique dans le contexte de AAL2 sont : $, VCCI-40/CID-$, BCG-100/VPI-20/VCI-120/CID-$, NSAP-$/VCCI-$/CID-$, $/VCCI-$/CID-$.

On peut aussi permettre de régler le paramètre <virtualConnectionId> entier à "-" ce qui indique sa non pertinence.

5.5.2	Paramètre Transport
Le paramètre <transport> indique la méthode utilisée pour encapsuler la charge utile de service. Ces méthodes ne sont pas définies dans le présent document, qui se réfère aux normes existantes de l’ATMF et de l’UIT-T, qui à leur tour peuvent se référer à d’autres normes. Pour les applications ATM, les valeur de <transport> suivantes sont définies :

Tableau 1 : Liste des valeurs de paramètre Transport utilisées par SDP dans le contexte ATM

Transport	Document de contrôle pour l’encapsulation de la charge utile de service
AAL1/ATMF	af-vtoa-0078.000 [7]
AAL1/ITU	UIT-T H.222.1 [51]
AAL5/ATMF	af-vtoa-0083.000 [46]
AAL5/ITU	UIT-T H.222.1 [51]
AAL2/ATMF	af-vtoa-0113.000 [44] et af-vmoa-0145.000 [52]
AAL2/ITU	UIT-T I.366.2 [13]
AAL1/custom	document d’entreprise ou déclaration d’interopérabilité spécifique de l’application.
AAL2/custom	document d’entreprise ou déclaration d’interopérabilité spécifique de l’application.
AAL5/custom	document d’entreprise ou déclaration d’interopérabilité spécifique de l’application.
AAL1/<corporateName>	document d’entreprise
AAL2/<corporateName>	document d’entreprise
AAL5/<corporateName>	document d’entreprise
AAL1/IEEE:<oui>	document d’entreprise
AAL2/IEEE:<oui>	document d’entreprise
AAL5/IEEE:<oui>	document d’entreprise
RTP/AVP	Annexe C de H.323 [45]

Dans les applications de l’Annexe C à H.323 [45], le paramètre <transport> a une valeur de "RTP/AVP" parce que ces applications utilisent le protocole RTP [2] et un profil audio/vidéo [3]. Le fait que RTP soit porté directement sur AAL5 selon [45] peut être indiqué explicitement via l’attribut de support aalApp.

Une valeur de "AAL1/custom", "AAL2/custom" ou "AAL5/custom" pour le paramètre <transport> peut indiquer un schéma d’encapsulation non standard ou semi standard défini par une corporation ou un accord multi-entreprises. Comme il n’y a pas d’administration standard de cette convention, il faut veiller à empêcher les incohérences dans la portée du déploiement.

L’utilisation des valeurs de <transport> "AAL1/<corporateName>", "AAL2/<corporateName>", "AAL5/<corporateName>", "AAL1/IEEE:<oui>", "AAL2/IEEE:<oui>" et "AAL5/IEEE:<oui>" est similaire. Elles indiquent des mécanismes de transport non standard ou des profils AAL2 qui devraient être utilisés de façon cohérente dans la portée ou le déploiement d’une application. Le paramètre <corporateName> est le nom enregistré, unique au monde d’une entreprise (par exemple, Cisco, Telcordia, etc.). Le paramètre <oui> est la représentation hexadécimale d’un champ de trois octets identique au OUI tenu par l’IEEE. Comme il est toujours représenté en hexadécimal, le préfixe "0x" ne devra pas être utilisé. Les zéros en tête peuvent être omis. Par exemple, "IEEE:00000C" et "IEEE:C" se réfèrent tous deux à Cisco Systems, Inc.

5.5.3	Liste de formats pour applications AAL1 et AAL5
Dans les contextes AAL1 et AAL5, <format list> est une liste des types de charge utile :

<TypeDeChargeUtile n°1> <TypeDeChargeUtile n°2>...<TypeDeChargeUtile n°n>

Dans la plupart des applications AAL1 et AAL5, l’ordre des types de charge utile implique une préférence (les types de charge utile préférés avant les types de préférence moindre). Le type de charge utile peut être alloué de façon statique ou transposé de façon dynamique. Bien que le transport ne soit pas le même, SDP dans le contexte ATM reprend les noms des codages et les types de charge utile enregistrés auprès de l’IANA [31] pour RTP. Les noms des codages non cités dans [31] utilisent un préfixe "X-". Les codages qui ne sont pas transposés de façon statique en types de charge utile dans [31] sont à transposer de façon dynamique au moment de l’établissement de connexion en types de charge utile dans la gamme décimale 96-127. L’attribut SDP 'atmmap' (similaire à 'rtpmap') est utilisé à cette fin.

En plus de la liste des noms de codage enregistrée par l’IANA et des types de charge utile qu’on trouve dans [31], le Tableau  2 définit quelques noms de codages non standard (avec un préfixe "X-").

5.5.4	Liste de formats pour applications AAL2
Dans le contexte AAL2, <format list> est une liste de types de profil AAL2 :

<profil n° 1> <profil n° 2>...<profil n° n>

Dans la plupart des applications, l’ordre des profils implique une préférence (profils préférés avant les autres). Le paramètre <profile> est exprimé par un nombre décimal dans la gamme de 1 à 255.

5.5.5	Construction de la ligne d’informations sur le support
En utilisant les définitions de paramètres ci-dessus, la ligne 'm' pour les supports audio fondés sur AAL1 peut être construite comme suit :

m=audio <virtualConnectionId> AAL1/ATMF <TypeDeChargeUtile n°1> <TypeDeChargeUtile n°2> ... <TypeDeChargeUtile n°n>

Noter que seuls les types de charge utile, qu’ils soient transposés de façon statique ou alloués de façon dynamique, qui sont cohérents avec af-vtoa-78 [7] peuvent être utilisés dans cette construction.

Note : Pour la rétro compatibilité, la valeur de transport "AAL1/AVP" utilisée dans les précédentes versions du présent document devrait être considérée comme équivalente à la valeur "AAL1/ATMF" définie ci-dessus. "AAL1/AVP" ne convient pas parce que le profil AVP est étroitement lié à RTP.

Un exemple d’utilisation de la ligne 'm' pour le support audio sur AAL1 est :

m=audio VCCI-27 AAL1/ATMF 0

Ceci indique l’utilisation d’un VCC AAL1 avec VCCI=24 pour porter une PCMU audio qui est encapsulée conformément à af-vtoa-78 de l’ATMF [7].

Un autre exemple de l’utilisation de la ligne 'm' pour un support audio sur AAL1 est :

m=audio $  AAL1/ATMF 0 8

Ceci indique que tout VCC AAL1 peut être utilisé. Si il existe déjà, sa sélection est alors soumise aux règles de double prise. Le support audio sur ce VCC est encapsulé conformément au af-vtoa-78 de l’ATMF [7]. Les codages à utiliser sont soit MICu (PCMU), soit MICA (PCMA), dans cet ordre de préférence.

Le 'm' pour le support audio fondé sur AAL5 peut être construit comme suit :

m=audio <virtualConnectionId> AAL5/ATMF  <TypeDeChargeUtile n°1> <TypeDeChargeUtile n°2>...<TypeDeChargeUtile n°n>

Un exemple d’utilisation de ligne 'm' pour le support audio sur AAL5 est :

m=audio PORT-2/VPI-6/$  AAL5/ITU  9  15

qui implique que tout VCI sur VPI= 6 d’accès de circuit n° 2 peut être utilisé. Les identités des termes dans l’identifiant de connexion virtuelle sont implicites dans le contexte de l’application. Le support audio sur ce VCC est encapsulé conformément à la Recommandation UIT-T H.222.1 [51]. Les codages à utiliser sont soit UIT-T G.722, soit UIT-T G.728 (LD-CELP), dans cet ordre de préférence.

La ligne 'm' pour l’audio de l’Annexe C de H.323 fondé sur AAL5 [45] peut être construite comme suit :

m=audio <virtualConnectionId> RTP/AVP <TypeDeChargeUtile n°1> <TypeDeChargeUtile n°2> ... <TypeDeChargeUtile n°n>

Par exemple :
m=audio PORT-9/VPI-3/VCI-$  RTP/AVP 2 96
a=rtpmap:96 X-G727-32
a=aalType:AAL5
a=aalApp:itu_h323c - -
implique que tout VCI sur VPI= 3 d’accès de circuit n° 9 peut être utilisé. Ce VC encapsule des paquets RTP directement sur AAL5 conformément à [45]. L’attribut 'rtpmap' (plutôt que 'atmmap') est utilisé pour transposer de façon dynamique le type de charge utile de 96 en nom de codec X-G727-32 (Tableau 2). Ce nom représente un MIC EAD à 32 kbit/s.

La ligne 'm' pour le support de vidéo fondée sur AAL5 peut être construite comme suit :

m=video <virtualConnectionId> AAL5/ITU <payloadType#1> <payloadType#2>...<payloadType #n>

Dans ce cas, l’utilisation de AAL5/ITU comme transport pointe sur H.222.1 comme norme de contrôle [51]. Un exemple de ligne 'm' utilisée pour le support vidéo est :

m=video PORT-9/VPI-3/VCI-$  AAL5/ITU  33

Cela indique que tout VCI sur VPI= 3 d’accès de circuit n° 9 peut être utilisé. Le support vidéo sur ce VCC est encapsulé conformément à la Recommandation UIT-T H.222.1 [51]. Le schéma de codage est un flux de transport MPEG 2 ("MP2T" dans le Tableau 1). Ceci est transposé de façon statique selon [31] en un type de charge utile de 33.

En utilisant les définitions de paramètre des paragraphes précédents, la ligne d’informations de support pour l’audio fondé sur AAL2 peut être construite comme suit :

m=<media> <virtualConnectionId> <transport#1> <format list#1> <transport#2> <format list#2> ... <transport#M> <format list#M>

où <format list#i> est de la forme <profile#i_1>...<profile#i_N>. À la différence de la ligne 'm' pour les applications AAL1 ou AAL5, la ligne 'm' pour les applications AAL2 peut avoir plusieurs paramètres <transport>, chacun suivi par une <format list>. Cela parce qu’il est possible de prendre en compte des définitions provenant de plusieurs sources (documents ATMF, UIT et non standard) lors du choix d’un profil AAL2 pour le lier à une connexion.

Dans la plupart des applications, l’ordre des profils implique une préférence (les profils préférés avant ceux qui le sont moins). Donc, il peut y avoir plusieurs instances de la même valeur <transport> dans la même ligne 'm'.

Un exemple d’utilisation de ligne 'm' pour le support audio sur AAL2 est :

m=audio VCCI-27/CID-19 AAL2/ITU 7 AAL2/custom 100 AAL2/ITU 1

Cela indique l’utilisation du CID n° 19 sur le VCCI n° 27 pour porter de l’audio. Il donne une liste des profils préférés pour cette connexion : le profil AAL2/ITU 7 défini dans [13], AAL2/custom 100 défini dans un document spécifique de l’application ou d’interopérabilité, et le profil AAL2/ITU 1 défini dans [13].

Un autre exemple de l’utilisation de la ligne 'm' pour le support audio sur AAL2 est :

m=audio VCCI-$/CID-$  AAL2/ATMF 6 8

Cela indique que tout CID AAL2 peut être utilisé, sous réserve de toute règle applicable d’évitement/réduction de double prise. Les profils qui peuvent être liés à cette connexion sont AAL2/ATMF 6 défini dans af-vtoa-0113.000 [44] et AAL2/ATMF 8 défini dans af-vmoa-0145.000 [52]. Ces sources utilisent des gammes de numéros de profil qui ne se recouvrent pas. Les profils qu’elles définissent entrent dans la catégorie <transport> "AAL2/ATMF". Cette application ne range pas les profils par ordre de préférence. Cette règle est connue a priori. Elle n’est pas incorporée dans la ligne 'm'.

Un autre exemple de l’utilisation de la ligne 'm' pour le support audio sur AAL2 est :

m=audio VCCI-20/CID-$  AAL2/xyzCorporation 11

Les VCC AAL2 dans cette application sont des VCC à un seul CID. Donc, il est possible de remplacer le CID par un caractère générique. Le VCC à un seul CID avec VCCI=20 est choisi. Le profil AAL2 à utiliser est AAL2/xyzCorporation 11 défini par xyzCorporation.

Dans certaines applications, un "-" peut être utilisé au lieu de :
-	<format list>
-	<transport> et <format list>

Cela implique que ces paramètres sont non pertinents ou sont connus par d’autres moyens (comme par défaut). Par exemple :
m=audio VCCI-234 - -
a=aalType:AAL1
indique l’utilisation de VCCI=234 avec une adaptation AAL1 et un codage non spécifié.

Dans un autre exemple d’application, l’attribut 'aal2sscs3662' peut indiquer <faxDemod> = "on" et toute autre option concurrente comme "off", et l’attribut <aalType> peut indiquer AAL2. Donc :
m=audio VCCI-123/CID-5 - -
a=aalType:AAL2
a=aal2sscs3662:audio off off on off on off off off - - -

En plus d’indiquer un support audio, un VCCI de 123 et un CID de 5, la ligne 'm' indique un profil non spécifié. Les lignes d’attribut de support indiquent une couche d’adaptation de AAL2, et l’utilisation de SAP audio [13] pour porter de la télécopie démodulée.

La ligne d’informations sur le support pour le support "data" a un des formats suivants :
m=data <virtualConnectionId> - -
m=data - - -

Les données peuvent être des données d’émulation de circuit portées sur AAL1 ou AAL2, ou des données de paquet portées sur AAL5. Les lignes d’attribut de support, plutôt que la ligne 'm', sont utilisées pour indiquer le type d’adaptation pour le support de données. Des exemples de la représentation du support de données sont cités ci-dessous.

m=data  PORT-7/VPI-6/VCI-$  - -
a=aalApp:AAL5_SSCOP-                             -
implique que tout VCI sur VPI= 6 de l’accès de circuit n° 7 peut être utilisé. Ce VC utilise SSCOP sur AAL5 pour transporter des données.

m=data  PORT-7/VPI-6/VCI-50  - -
a=aalType:AAL1_SDT
a=sbc:6
implique que le VCI 50 sur VPI 6 à l’accès 7 utilise de l’AAL1 structuré pour transférer 6 x 64 kbit/s de données d’émulation de circuit. Cela peut aussi être représenté par :
m=data  PORT-7/VPI-6/VCI-50  - -
b=AS:384
a=aalType:AAL1_SDT

Les lignes suivantes :
m=data VCCI-123/CID-5 - -
a=aalType:AAL2
a=sbc:2
impliquent que CID 5 du VCCI 123 est utilisé pour transférer 2 x 64 kbit/s de données d’émulation de circuit.

Dans le contexte de AAL1, il est aussi permis de représenter des données en mode circuit comme un codec "audio". Si on le fait, les types de codec utilisés sont X-CCD ou X-CCD-CAS. Ces noms de codage sont transposés de façon dynamique en types de charge utile au moyen de l’atttribut 'atmmap'. Par exemple :
m=audio VCCI-27 AAL1/AVP 98
a=atmmap:98 X-CCD
a=sbc:6
implique que le VCCI=27 AAL1 est utilisé pour une transmission 6 x 64.

Dans le contexte AAL2, le codec X-CCD peut se voir allouer un type et un numéro de profil. Bien qu’il ne soit pas possible de construire un tableau de profils comme décrit dans [13] pour ce "codec", il est préférable d’adopter la convention commune de profil AAL2 dans ce cas. Un exemple de transposition de profil AAL2 pour le codec X-CCD pourrait être le suivant :

Type de profil	Numéro de profil	"CODEC" (un seul)
    "custom" 	200	X-CCD

Le profil n’identifie pas le numéro des sous canaux ('n' en nx64). Celui-ci est connu par d’autres moyens tels que la ligne d’attribut de support 'sbc'.

Par exemple, la ligne d’informations sur le support :
m=audio $ AAL2/custom 200
a=sbc:6
implique une émulation de circuit à 384 kbit/s utilisant l’adaptaion AAL2.

Il n’est pas nécessaire de définir un profil avec le codec X-CCD-CAS, car cette méthode de transport CAS [7] n’est pas utilisée dans les applications AAL2.

5.6	Lignes d’attribut du support
Dans une séquence de lignes SDP, la ligne d’informations sur le support 'm' est suivie par un ou plusieurs attributs de support ou des lignes 'a'. Les lignes d’attribut de support sont selon le format ci-dessous :

a=<attribut>:<valeur>
ou
a=<valeur>

En général, les lignes d’attribut du support sont facultatives sauf lorsque nécessaires pour qualifier la ligne d’informations sur le support. Cette qualification est nécessaire lorsque la ligne "m" pour une session AAL1 ou AAL5 spécifie un type de charge utile qui doit être transposé de façon dynamique. La ligne d’attribut de support 'atmmap' définie ci-dessous est utilisée à cette fin.

Dans les lignes d’attribut, les sous paramètres qui sont destinés à rester non spécifiés sont réglés à "-". Ils sont généralement inapplicables ou, si ils sont applicables, sont connus par d’autres moyens comme le provisionnement. Dans certains cas, une ligne d’attribut de support avec tous les paramètres réglés à "-" ne porte pas d’informations et devrait de préférence être omise. Dans d’autres cas, comme celui de la ligne d’attribut de support 'lij', la seule présence de la ligne d’attribut de support a une signification.

La RFC 2327 [1] ne fait aucune restriction sur l’ordre des lignes 'a' par rapport aux autres lignes 'a'. Cependant, ces lignes ne doivent pas se contredire les unes les autres ou avec d’autres lignes SDP. Les incohérences ne doivent pas être ignorées et devraient être marquées comme erreurs. Des lignes d’attribut du support répétées peuvent porter des informations supplémentaires. Elles ne devraient pas se contredire les une les autres.

Les applications vont utiliser de façon sélective les lignes d’attribut du support facultatives citées plus loin. Cette liste est destinée à être une description exhaustive des attributs généraux des réseaux supports d’ATM.

La spécification de base de SDP, la RFC 2327 [1], permet la définition de nouveaux attributs. Dans cet esprit, certains des attributs définis dans le présent document peuvent aussi être utilisés dans les descriptions SDP de IP et autres sessions non ATM. Par exemple, les attributs 'vsel', 'dsel' et 'fsel' définis ci-dessous se réfèrent de façon générique aux codecs. Ces attributs peuvent servir de base pour la négociation et l’allocation de codes spécifique d’un service dans des applications non ATM aussi bien qu’ATM.

Les attributs de support SDP définis dans le présent document pour être utilisés dans le contexte d’ATM sont classés en :
*	attributs de connexion de support ATM (paragraphe 5.6.1)
*	attributs AAL (paragraphe 5.6.2)
*	attributs de service (paragraphe 5.6.3).
*	attributs de support divers, qui ne peuvent pas être classés dans les attributs ATM, AAL ou de service (paragraphe 5.6.4).

En plus de ceux-ci, les attributs SDP définis dans [1] peuvent aussi être utilisés dans le contexte ATM. Des exemples sont :
*	Les attributs définis dans la RFC 2327 qui permettent d’indiquer la direction dans laquelle une session est active. Ce sont a=sendonly, a=recvonly, a=sendrecv, a=inactive.
*	L’attribut 'Ptime' défini dans la RFC 2327. Il indique la période du paquet. Il n’est pas recommandé que cet attribut soit utilisé dans les applications ATM car les informations de période de paquet sont fournies par d’autres paramètres (par exemple, le type et numéro de profil dans la ligne 'm', et les attributs 'vsel', 'dsel' et 'fsel'). Aussi, pour les applications AAL1, 'ptime' n’est pas applicable et devrait être marqué comme erreur. Si il est utilisé dans les applications AAL2 et AAL5, 'ptime' devrait être cohérent avec le reste de la description SDP.
*	L’attribut 'fmtp' utilisé pour désigner des paramètres spécifiques du format.

5.6.1	Attributs de connexion de support ATM
Voici une liste résumée des attributs de support SDP qui peuvent être utilisés pour décrire les connexions de support ATM. Ils sont détaillés dans les paragraphes qui suivent :
*	Attribut 'eecid'. Pour ‘identifiant de connexion de bout en bout’ (end-to-end connection identifier). Donne le moyen de corréler les connexions de niveau service avec les connexions de support ATM sous-jacentes. Dans le contexte Q.1901 [36], eecid est synonyme du bnc-id (identifiant de connexion de cœur de réseau).
*	Attribut 'aalType'. Il est utilisé pour indiquer la nature de la couche d’adaptation ATM (AAL, ATM adaptation layer).
*	Attribut 'capability', qui indique la capacité de transfert ATM (nomenclature UIT-T), synonyme de la catégorie de service ATM (nomenclature ATMF).
*	Attribut 'qosClass', qui indique la classe de QS de la connexion support ATM.
*	Attribut 'bcob', qui indique la classe de support en mode connexion haut débit, et si la synchronisation de bout en bout est requise.
*	Attribut 'stc' (susceptibility to clipping) qui indique la susceptibilité de coupure.
*	Attribut 'upcc' (user plane connection configuration) configuration de connexion de plan d’utilisateur.
*	Attribut 'atmQOSparms', qui est utilisé pour décrire certains paramètres clés de qualité de service ATM.
*	Attribut 'atmTrfcDesc', qui est utilisé pour décrire les paramètres ATM de descripteur de trafic.
*	Attribut 'abrParms', qui est utilisé pour décrire les paramètres spécifiques d’ABR. Ces paramètres sont décrits par la spécification de signalisation d’UNI 4.0 [5].
*	Attribut 'abrSetup', qui est utilisé pour indiquer les paramètres d’ABR nécessaires durant l’établissement d’appel/connexion.
*	Attribut 'bearerType', qui est utilisé pour indiquer si le support sous-jacent est un PVC/SPVC ATM, un SVC ATM, ou un sous canal au sein d’un SVC/PVC/SPVC ATM existant.
*	Attribut 'lij', qui est utilisé pour indiquer la présence d’une connexion qui utilise la capacité de jonction à l’initiative de l’extrémité (Leaf-initiated-join) décrite dans UNI 4.0 [5], et facultativement pour décrire les paramètres associés à cette capacité.
*	Attribut 'anycast', qui est utilisé pour indiquer l’applicabilité de la fonction d’envoi à la cantonade (anycast) décrite dans UNI 4.0 [5], et facultativement pour la qualifier avec certains paramètres.
*	Attribut 'cache', qui est utilisé pour permettre la mise en antémémoire de SVC et de spécifier un temporisateur d’inactivité pour la libération de SVC.
*	Attribut 'bearerSigIE', qui peut être utilisé pour représenter les éléments d’information de la série de Recommandations UIT-T Q. en format bit-map. Ceci est utile pour décrire les paramètres qui ne sont pas étroitement couplés aux couches ATM et AAL. Des exemples sont les éléments d’information B-HLI et B-LLI spécifiés dans la Recommandation UIT-T Q.2931 [15], et l’élément d’information d’utilisateur à utilisateur décrit dans la Recommandation UIT-T Q.2957 [48].

5.6.1.1	Attribut 'eecid'
L’attribut 'eecid' est synonyme du paramètre de 4 octets 'bnc-id' utilisé par T1SI, le forum ATM et l’UIT-T (Q.1901). Le terme de 'eecid' est l’abréviation de 'end-to-end connection identifier' (identifiant de connexion de bout en bout), tandis que 'bnc-id' signifie 'backbone network connection identifier' (identifiant de connexion de cœur de réseau). Le nom "cœur de réseau" est un peu trompeur car il se réfère au réseau ATM tout entier, y compris la bordure ATM et les réseaux de cœur ATM. Dans la terminologie de Q.1901, un "cœur de réseau" ATM connecte des bordures TDM ou analogiques.

Bien que le terme 'bnc-id' puisse être utilisé dans le plan de signalisation du support dans un plan de contrôle d’appel ISUP (Q.1901), les descripteurs de session SDP utilisent le terme neutre de 'eecid'. Cela donne une ligne de base commune SDP pour les applications qui utilisent ISUP (Q.1901) et les applications qui utilisent SIP/SIP+.

La paragraphe 5.6.6 décrit l’utilisation de eecid dans les procédures d’établissement d’appel. Dans ces procédures, le eecid est utilisé pour corréler les appels de niveau service avec les demandes d’établissement de SVC.

Dans le modèle d’établissement de SVC vers l’avant, la passerelle de terminaison d’appel choisit un eecid et le transmet via SDP à la passerelle d’origine de l’appel. La passerelle d’origine de l’appel transmet cet eecid à la passerelle de terminaison de l’appel via le message d’établissement du support (établissement de SVC ou demande d’établissement Q.2630.1).

Dans le modèle d’établissement de SVC vers l’arrière, la passerelle d’origine de l’appel choisit un eecid et le transmet via SDP à la passerelle de terminaison de l’appel. La passerelle de terminaison de l’appel transmet cet eecid à la passerelle d’origine de l’appel via le message d’établissement de support (établissement de SVC ou demande d’établissement Q.2630.1).

La valeur de l’attribut eecid doit être unique au sein du nœud qui termine l’établissement du SVC mais pas sur plusieurs nœuds. Donc, la passerelle de terminaison de SVC a le contrôle complet de l’utilisation et la libération des valeurs de ce paramètre. L’attribut eecid est utilisé pour corréler, une à une, les demandes d’établissement de support reçues avec la signalisation de contrôle d’appel de niveau service.

Au sein d’une description de session SDP, l’attribut eecid est utilisé comme suit :

a=eecid:<eecid>

où <eecid> consiste en huit chiffres hexadécimaux maximum (équivalent de 4 octets). Comme ceci est toujours représenté en hexadécimal, le préfixe "0x" ne devra pas être utilisé.

Dans la représentation textuelle du paramètre <eecid>, les chiffres hexadécimaux de gauche ont un plus fort poids que ceux de droite (paragraphe 2.2).

Le présent document de SDP ne spécifie pas comment le eecid (synonyme de bnc-id) va être communiqué à travers la signalisation du support (Q.931, UNI, PNNI, AINI, IISP, équivalent de signalisation propriétaire, Q.2630.1). C’est une tâche de ces protocoles de signalisation de support. Cependant, les déclarations informatives suivantes sont faites pour donner un sens à l’interopérabilité qui est un des buts des efforts de normalisation actuels :

-	La Recommandation UIT-T Q.2941.3 et l’ATMF recommandent chacun l’utilisation de l’élément d’information (IE) GIT pour porter le eecid (synonyme de bnc-id) dans le message d’établissement des protocoles de signalisation ATM (Q.2931, UNI 4.0, PNNI, AINI, IISP). Le codage pour porter le eecid (bnc-id) dans l’IE GIT est défini dans UIT-T Q.2941.3 et accepté par l’ATM forum.

-	Une autre méthode est d’utiliser l’IE Sous adresse de l’appelé. Dans certains réseaux, cela peut être considéré comme une violation du protocole et n’est pas le moyen recommandé pour porter le eecid (bnc-id). L’IE GIT est la méthode préférée pour transporter le eecid (bnc-id) dans les messages de signalisation ATM.

-	Le message ERQ (establish request) du protocole de signalisation Q.2630.1 [37] peut utiliser l’IE SUGR (Served User Generated Reference, référence générée par l’usager desservi) pour transporter le eecid (bnc-id).

Le nœud qui alloue le eecid peut le libérer et le réutiliser lorsque il reçoit un message d’établissement Q.2931 [15] ou un message de demande d’établissement Q.2630.1 [37] qui contient le eecid. Cependant, dans les deux cas (modèle vers l’arrière et modèle vers l’avant) il est recommandé que cet eecid soit conservé jusqu’à ce que la connexion se termine. Comme l’espace d’eecid est assez grand, il n’est pas nécessaire de le libérer aussitôt que possible.

5.6.1.2	Attribut 'aalType'
Lorsque présent, l’attribut 'aalType' est utilisé pour indiquer la couche d’adaptation ATM. Si cette information est redondante avec la ligne 'm', elle peut être omise. Le format de la ligne d’attribut de support 'aalType' est le suivant :

a=aalType: <aalType>

Ici, <aalType> peut prendre les valeurs de chaîne suivantes : "AAL1", "AAL1_SDT", "AAL1_UDT", "AAL2", "AAL3/4", "AAL5" et "USER_DEFINED_AAL". Noter que "AAL3/4" et "USER DEFINED AAL" ne sont pas traitées dans le présent document.

5.6.1.3	Attribut 'capability'
Lorsque présent, l’attribut 'capability' indique la capacité de transfert ATM décrite dans la Recommandation UIT-T I.371 [28], équivalente à la catégorie de service ATM décrite dans la spécification de gestion de trafic UNI 4.1 [6].

La ligne d’attribut de support 'capability' est structurée d’une des façons suivantes :

a=capability:<asc> <soustype>
a=capability:<atc> <soustype>

Les valeurs possibles pour <asc> sont :  "CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR"
Les valeurs possibles pour <atc> sont : "DBR", "SBR", "ABT/IT", "ABT/DT", "ABR"

Certaines applications pourraient utiliser des valeurs non standard de <atc> et <asc> non citées ci-dessus. Les concepteurs d’équipements devront se mettre d’accord sur la signification et les implications de capacités de transfert/service non standard.

Le champ <soustype> sert essentiellement d’indexation pour les champs <asc> et <atc>. En général, il peut prendre toute valeur d’entier, ou la valeur "-" qui indique qu’il ne s’applique pas ou que les données sous-jacentes doivent être connues par d’autres moyens, comme le provisionnement.

Pour une valeur <asc> de CBR et une valeur <atc> de DBR, des valeurs peuvent être allouées au champ <soustype> à partir du Tableau 4-6 de la Recommandation UIT-T Q.2931 [15]. ce sont :

<asc>/<atc>	<sous type>	Signification
"CBR"/"DBR"	1	Transport du signal dans la bande vocale (UIT-T G.711, G.722, I.363)
"CBR"/"DBR" 	2	Transport sur circuit (UIT-T I.363)
"CBR"/"DBR"	4	Transport de signal audio haute définition (UIT-T I.363)
"CBR"/"DBR"	5	Transport de signal vidéo (UIT-T I.363)

Noter que [15] ne définit pas une valeur de <soustype> de 3.

Pour les autres valeurs des paramètres <asc> et <atc>, les valeurs suivantes peuvent être allouées au champ <soustype>, sur la base de [6] et [28].

<asc>/<atc>	<sous type>	Signification
nrt-VBR	1	nrt-VBR.1
nrt-VBR	2	nrt-VBR.2
nrt-VBR	3	nrt-VBR.3
rt-VBR	1	rt-VBR.1
rt-VBR	2	rt-VBR.2
rt-VBR	3	rt-VBR.3
UBR	1	UBR.1
UBR	2	UBR.2
GFR	1	GFR.1
GFR	2	GRR.2
SBR	1	SBR1
SBR	2	SBR2
SBR	3	SBR3

Il sort du domaine d’application de la présente spécification d’examiner l’équivalence de certaines des définitions de l’ATMF et de l’UIT-T. Cela doit être reconnu à partir des spécifications source de l’ATMF et de l’UIT-T et exploité, autant que possible, pour simplifier la conception du nœud ATM.
Lorsque la connexion support est une seule connexion CID AAL2 au sein d’un VC AAL2 multiplexé, l’attribut 'capability' ne s’applique pas.

5.6.1.4	Attribut 'qosClass'
Lorsque il est présent, l’attribut 'qosClass' indique la classe de QS spécifiée dans la Recommandation UIT-T I.2965.1 [34].

La ligne d’attribut du support 'qosClass' est structurée comme suit :

a=qosClass:<qosClass>

Ici, <qosClass> est un entier dans la gamme 0 - 5.

<qosClass>	Signification
0	QS par défaut
1	strict
2	tolérant
3	bi-niveau
4	sans limite
5	strict bi-niveau

5.6.1.5	Attribut 'bcob'
Lorsque présent, l’attribut 'bcob' représente la classe de support en mode connexion haut débit définie dans [5], [15] et [33]. Il peut aussi être utilisé pour indiquer si la synchronisation de bout en bout est requise.

La ligne d’attribut de support 'bcob' est structurée comme suit :

a=bcob:<bcob> <eetim>

Ici, <bcob> est la représentation décimale ou hexadécimale d’un champ de 5 bits. Les valeurs suivantes sont actuellement définies :

<bcob>	Signification
0x01	BCOB-A
0x03	BCOB-C
0x05	service support en relais de trame
0x10	BCOB-X
0x18	BCOB-VP (service VP transparent)

Le paramètre <eetim> peut recevoir une valeur de "on ou "off" selon que la synchrisation de bout en bout est requise ou non (Tableau 4-8 de [15]).

L’un et l’autre de ces paramètres peenut être inspécifiés en les réglant à "-". Une ligne d’attribut de support de 'bcob' avec tous les paramètres réglés à "-" ne porte aucune information et devrait être omise.

5.6.1.6	Attribut 'stc'
Lorsque présent, l’attribut 'stc' représente la susceptibilité de coupure. La ligne d’attribut de support 'stc' est structurée comme suit :

a=stc:<stc>

Ici, <stc> est l’équivalent décimal d’un champ de 2 bits. Actuellement, toutes les valeurs sont inutilisées et réservées avec les exceptions suivantes :

Valeur de <stc>	Équivalent binaire	Signification
0	00	Non susceptible de coupure
1	01	Susceptible de coupure

5.6.1.7	Attribut 'upcc'
Lorsque présent, l’attribut 'upcc' représente la configuration de la connexion de plan d’utilisateur. La ligne d’attribut de support 'upcc' est structurée comme suit :

a=upcc:<upcc>

Ici, <upcc> est l’équivalent décimal d’un champ de 2 bits. Actuellement, toutes les valeurs sont inutilisées et réservées à l’exception des suivantes :

Valeur de <upcc>	Équivalent binaire	Signification
0	00	Point à point
1	01	Point à multipoint

5.6.1.8	Attribut 'atmQOSparms'
Lorsque présent, l’attribut 'atmQOSparms' est utilisé pour décrire certains paramètres clés de qualité de service ATM.
La ligne d’attribut de support 'atmQOSparms' est structurée comme suit :

a=atmQOSparms:<directionFlag><cdvType><acdv><ccdv><eetd><cmtd><aclr>

Les valeurs de chaîne suivantes peuvent être allouées à <directionFlag> : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrière. "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrières sont celles du paragraphe 2.3.

Le paramètre <cdvType> peut prendre les valeurs de chaîne de "PP" et "2P". Elles se réfèrent à la variation du temps de propagation de cellule (CDV, Cell Delay Variation) de crête à crête et entre deux points comme défini respectivement dans UNI 4.0 [5] et dans la Recommandation UIT-T Q.2965.2 [35].

Les paramètres de CDV, <acdv> et <ccdv>, se réfèrent respectivement aux CDV acceptables et cumulatives. Elles sont exprimées en microsecondes et représentées par l’équivalent décimal d’un champ de 24 bits. Ils utilisent le taux de perte de cellule, <aclr>, comme les quantiles "alpha" définis dans la spécification ATMF TM 4.1 [6] et dans la Recommandation UIT-T I.356 [47].

Les paramètres de délai de transit, <eetd> et <cmtd>, se réfèrent au délai de transit respectivement de bout en bout et cumulatif en millisecondes. Ils sont représentés par l’équivalent décimal de champs de 16 bits. Ces paramètres sont définis dans Q.2965.2 [35], UNI 4.0 [5] et Q.2931 [15].

Le paramètre <aclr> se réfère aux taux de perte de cellule vers l’avant et vers l’arrière acceptables. C’est le ratio entre le nombre de cellules perdues et le nombre de cellules transmises. Il est exprimé comme l’équivalent décimal d’un champ de 8  bits. Ce champ exprime un ordre de grandeur n, où n est un entier dans la gamme de 1 à 15. Le taux de perte de cellules prend la valeur 10 élevée à la puissance moins n.

Le fanion <directionFlag> est toujours spécifié. Sauf pour le <directionFlag>, les paramètres restants peuvent être réglés à "-" pour indiquer qu’ils ne sont pas spécifiés, inapplicables ou implicites. Cependant, il doit y avoir quelques paramètres spécifiés pour que la  ligne soit utile dans une description SDP.

Il peut y avoir plusieurs lignes 'atmQOSparms' dans une description SDP.
Un exemple d’utilisation de ces attributs pour un circuit virtuel vocal AAL2 rt-VBR, à un seul CID est :

a=atmQOSparms:f PP  8125 3455 32000 -  11
a=atmQOSparms:b PP  4675 2155 18000 -  12

Cela impliquee une CDV acceptable vers l’avant de crête à crête de 8,125 ms, une CDV acceptable de crête à crête vers l’arrière de 4,675 ms, une CDV vers l’avant cumulative de crête à crête de 3,455 ms, une CDV cumulative de crête à crête vers l’arrière de 2,155 ms, un délai de transit vers l’avant de bout en bout de 32 ms, et un délai de transit de bout en bout vers l’arrière de 18 ms, un délai de transit cumulatif vers l’avant non spécifié, un délai de transit cumulatif vers l’arrière non spécifié, un taux de perte de cellules vers l’avant de 10 puissance moins 11 et un taux de perte de cellules vers l’arrière de 10 puissance moins 12.

Un exemple de spécification des mêmes paramètres vers l’avant et vers l’arrière est :

a=atmQOSparms:fb PP  8125 3455 32000 -  11

Cela implique une CDV vers l’avant et vers l’arrière acceptable de crête à crête de 8,125 ms, une CDV vers l’avant et vers l’arrière cumulative de crête à crête de 3,455 ms, un délai de transit de bout en bout vers l’avant et vers l’arrière de 32 ms, un délai de transit cumulatif non spécifié vers l’avant et vers l’arrière, et un taux de perte de cellules de 10 puissance moins 11 vers l’avant et vers l’arrière.

5.6.1.9	Attribut 'atmTrfcDesc'
Lorsque présent, L’attribut 'atmTrfcDesc' est utilisé pour indiquer les paramètres ATM de descripteur de trafic. Il peut y avoir plusieurs lignes 'atmTrfcDesc' dans une description SDP.
La ligne d’attribut de support 'atmTrfcDesc' est structurée comme suit :

a=atmTrfcDesc:<directionFlag><clpLvl> <pcr><scr><mbs><cdvt><mcr><mfs><fd><te>

Les valeurs de chaîne suivantes peuvent être allouées au fanion <directionFlag> : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrière. "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrières sont données au paragraphe 2.3.

Le fanion <directionFlag> est toujours spécifié. Sauf pour le <directionFlag>, les paramètres restants peuvent être réglés à "-" pour indiquer qu’ils ne sont pas spécifiés, inapplicables ou implicites. Cependant, il faut que quelques paramètres soient spécifiés pour que la ligne soit utilisée dans une description SDP.

Le paramètre <clpLvl> (niveau de priorité de perte de cellule (CLP, Cell Loss Priority)) indique si les taux et les salves décrits dans ces lignes d’attribut du support s’appliquent aux valeurs de CLP de 0 ou (0+1). Il peut prendre les valeurs de chaîne suivantes : "0", "0+1" et "-". Si les taux et les salves pour les deux valeurs de <clpLvl> doivent être décrites, il est alors nécessaire d’utiliser deux lignes séparées d’attribut du support pour chaque direction dans le même descripteur de session. Si le paramètre <clpLvl> est réglé à "-", cela implique alors que le paramètre CLP est connu par d’autres moyens tels que par défaut, l’approvisionnement d’une MIB, etc..

La signification, les unités et l’applicabilité des paramètres restants sont celles de [6] et [28]:

Paramètre	Signification	Unités	Applicabilité
<pcr>	PCR	Cellule/s 	CBR, rt-VBR, nrt-VBR, ABR, UBR, GFR; CLP=0,0+1
<scr>	SCR	Cellule/s	rt-VBR, nrt-VBR; CLP=0,0+1
<mbs>	MBS	Cellules	rt-VBR, nrt-VBR, GFR; CLP=0,0+1
<cdvt>	CDVT	Microseconde	CBR, rt-VBR, nrt-VBR, ABR, UBR, GFR; CLP=0,0+1
<mcr>	MCR	Cellule/s	ABR,GFR; CLP=0+1
<mfs>	MFS	Cellules	GFR; CLP=0,0+1
<fd>	Élimination de trame	"on"/"off"	CBR, rt-VBR, nrt-VBR, ABR, UBR, GFR; CLP=0+1
<te>	Marquage CLP	"on"/"off"	CBR, rt-VBR, nrt-VBR, ABR, UBR, GFR; CLP=0

<fd> indique que l’élimination de trame est permise. Il peut prendre les valeurs de chaîne de "on" ou "off". Noter que, dans le cas de GFR, l’élimination de trame est toujours activée. Donc, ce sous paramètre peut être réglé à "-" dans le cas de GFR. Comme le <fd> est indépendant de la CLP, il est significatif dans le cas où <clpLvl> = "0+1". Il devrait être réglé à "-" dans le cas où <clpLvl> = "0".

<te> (tag enable, étiquette activée) indique que l’étiquetage de CLP est permis. Il peut prendre les valeurs de chaîne de "on" ou "off". Comme le paramètre <te> ne s’applique qu’avec une CLP de 0, il est significatif dans le cas où <clpLvl> = "0". Il devrait être réglé à "-" pour le cas où <clpLvl> = "0+1".

Un exemple d’utilisation de ces lignes d’attribut du support pour un circuit virtuel vocal AAL2 rt-VBR à un seul CID est :
a=atmTrfcDesc:f 0+1 200   100  20   - - - on  -
a=atmTrfcDesc:f 0   200   80   15   - - - -  off
a=atmTrfcDesc:b 0+1 200   100  20   - - - on -
a=atmTrfcDesc:b 0   200   80   15   - - - -  off

Cela implique un PCR vers l’avant et vers l’arrière de 200 cellules par seconde sans considération de la CLP, un PCR vers l’avant et vers l’arrière de 200 cellules par seconde pour les cellules de CLP=0, un débit de cellules soutenu (SCR, Sustained Cell Rate vers l’avant et vers l’arrière de 100 cellules par seconde pour toutes les cellules sans considération de leur CLP, un SCR vers l’avant et vers l’arrière de 80 cellules par seconde pour les cellules de CLP=0, une taille de salve maximum (MBS, Maximum Burst Size) vers l’avant et vers l’arrière de 20 cellules pour toutes les cellules sans considération de la CLP, une MBS vers l’avant et vers l’arrière de 15 cellules pour les cellules de CLP=0, une tolérance de variation de délai de cellule (CDVT, Cell Delay Variation Tolerance) non spécifiée qui peut être connue par d’autres moyens, et un débit de cellule minimum (MCR, Minimum Cell Rate) et un MFS qui sont inspécifiés parce qu’inapplicables. L’élimination de trame est activée dans les deux directions vers l’avant et vers l’arrière. L’étiquetage n’est activé dans aucune des deux directions.

Les paramètres <pcr>, <scr>, <mbs>, <cdvt>, <mcr> et <mfs> sont représentés par des entiers décimaux, dont la gamme est définie à la Section 6. Voir le paragraphe 2.2 sur l’omission des zéros en tête dans les représentations décimales.

5.6.1.10	Attribut 'abrParms'
Lorsque présent, l’attribut 'abrParms' est utilisé pour indiquer les paramètres de débit binaire disponible (ABR, Available Bit Rate) 'supplémentaires' spécifiés dans la spécification de signalisation UNI 4.0 [5]. Il peut y avoir plusieurs lignes 'abrParms' dans une description SDP.

La ligne d’attribut de support 'abrParms' est structurée comme suit :

a=abrParms:<directionFlag><nrm><trm><cdf><adtf>

Le fanion <directionFlag> peut recevoir les valeurs de chaîne suivantes : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrière. "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrière sont celles du paragraphe 2.3.

Le fanion <directionFlag> est toujours spécifié. Sauf pour le <directionFlag>, les paramètres restants peuvent être réglés à "-" pour indiquer qu’ils ne sont pas spécifiés, inapplicables ou implicites. Cependant, il doit y avoir quelques paramètres spécifiés pour que la ligne soit utile dans une description SDP.

Ces paramètres sont transposés en paramètre de service ABR dans [6] de la manière décrite ci-dessous. Ces paramètres peuvent être représentés dans SDP comme des entiers décimaux, avec des fractions permises pour certains. Les détails de la signification, des unités et de l’applicabilité de ces paramètres sont dans [5] et [6].
Dans SDP, ces paramètres sont représentés par l’équivalent décimal ou hexadécimal des champs binaires mentionnés ci-dessous.

Paramètre	Signification	Taille de champ
<nrm>	Nombre max. de cellules par cellule de gestion de ressource transmise	 3 bits
<trm>	Délai maximum entre cellules de gestion de ressource transmises	 3 bits
<cdf>	Facteur de diminution de coupure	 3 bits
<adtf>	Facteur de délai de diminution de taux de cellules admis	10 bits

5.6.1.11	Attribut 'abrSetup'
Lorsque présent, l’attribut 'abrSetup' est utilisé pour indiquer les paramètres ABR nécessaires durant l’établissement d’appl/connexion (paragraphe 10.1.2.2 de la spécification de signalisation UNI 4.0 [5]). Cette ligne est structurée comme suit :

a=abrSetup:<ficr><bicr><ftbe><btbe><crmrtt><frif><brif><frdf><brdf>

Ces paramètres sont définis comme suit :

Paramètre	Signification	Représentation
<ficr>	débit initial de cellule vers l’avant | (cellules par s)	équivalent décimal d’un champ de 24 bits
<bicr>	débit initial de cellule vers l’arrière (cellules par s) 	équivalent décimal d’un champ de 24 bits
<ftbe>	expos. de mémoire tampon transitoire vers l’avant (cell.) 	équivalent décimal d’un champ de 24 bits
<btbe>	expos. de mémoire tampon transitoire vers l’arrière (cell.)	équivalent décimal d’un champ de 24 bits
<crmrtt>	temps d’aller-retour RM cumulatif (microsecondes)	équivalent décimal d’un champ de 24 bits
<frif>	facteur d’augmentation du débit vers l’avant	entier décimal de 0 à 15
	(utilisé pour déduire le compte de cellules)
<brif>	facteur d’augmentation du débit vers l’arrière (idem)	entier décimal de 0 à 15
<frdf>	facteur de diminution du débit vers l’avant (idem)	entier décimal de 0 à 15
<brdf>	facteur de diminution du débit vers l’arrière (idem)	entier décimal de 0 à 15

Voir au paragraphe 2.3 la définition des termes 'vers l’avant' et 'vers l’arrière'.

Si un de ces paramètres n’est pas spécifié dans la ligne d’atttribut de support 'abrSetup', est inapplicable ou est implicite, il est alors réglé à h "- ".

5.6.1.12	Attribut 'bearerType'
Lorsque présent, l’attribut 'bearerType' (type de support) est utilisé pour indiquer si le support sous-jacent est un PVC/SPVC ATM, un SVC ATM, ou un sous canal au sein d’un SVC/PVC/SPVC ATM existant. De plus, pour les SVC ATM et les connexions CID AAL2, l’attribut 'bearerType' peut être utilisé pour indiquer si la passerelle de supports initie l’établissement de connexion via la signalisation du support (fondée sur Q.2931 ou fondée sur Q.2630.1). Le format de la ligne d’attribut de support 'bearerType' est le suivant :

a=bearerType: <Type de support> <localInitiation>

Le champ <bearerType> peut prendre les valeurs de chaîne suivantes : "PVC", "SVC", "CID", avec la sémantique définie ci-dessus. Ici, "PVC" inclut les deux cas PVC et SPVC.

Dans le cas où le support sous-jacent est un PVC/SPVC, ou un CID alloué par le MGC plutôt que par la signalisation du support, le fanion <localInitiation> peut être omis ou réglé à "-". Dans le cas où la signalisation du support est utilisée, ce fanion peut être omis lorsque il est connu par défaut ou par d’autres moyens si la passerelle de supports initie l’établissement de connexion via la signalisation du support. C’est seulement lorsque ceci doit être indiqué explicitement que le fanion <localInitiation> prend les valeurs de "on" ou "off". Une valeur "on" indique que la passerelle de supports est responsable de l’initiation de l’établissement de la connexion via la signalisation du support (signalisation de SVC ou signalisation Q.2630.1) une valeur de "off" indique qu’il en est autrement.

5.6.1.13	Attribut 'lij'
Lorsque présent, l’attribut 'lij' est utilisé pour indiquer la présence d’une connexion qui utilise la capacité Leaf-initiated-join décrite dans UNI 4.0 [5], et facultativement pour décrire les paramètres associés à cette capacité. Le format de la ligne d’attribut de support 'lij' est le suivant :

a=lij: <sci><lsn>

Le <sci> (indication d’affichage) est un champ de 4 bits exprimé comme un entier décimal ou hexadécimal. Il est défini dans la spécification de signalisation UNI 4.0 [5]. Il est possible que les valeurs de ce champ soient définies ultérieurement par l’ATMF et/ou l’UIT-T. Actuellement, toutes les valeurs sont réservées à l’exception de 0, qui indique une 'Jonction réseau sans notification de racine'.

Le <lsn> (numéro de séquence de feuille) est un champ de 32 bits exprimé comme un entier décimal ou hexadécimal. Selon la spécification de signalisation UNI 4.0 [5], il est utilisé par une feuille qui se joint pour associer des messages et des réponses durant les procédures de LIJ (jonction à l’initiative de la feuille).

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

5.6.1.14	Attribut 'anycast'
Lorsque présent, la ligne d’attribut 'anycast' (à la cantonade) est utilisée pour indiquer l’applicabilité de la fonction "à la cantonade" décrite dans UNI 4.0 [5]. Les paramètres facultatifs pour qualifier cette fonction sont fournis. Le format de l’attribut 'anycast' est :

a=anycast: <atmGroupAdresse> <cdStd> <conScpTyp> <conScpSel>

Le <atmGroupAdresse> est selon l’annexe 5 de UNI 4.0 [5]. Dans un descripteur SDP, il peut être représenté dans un de ces formats (NSAP, E.164, GWID/ALIAS) décrits ailleurs dans le présent document.

Les sous paramètres restants reflètent l’élément d’information de sélecteur de portée de connexion de UNI 4.0 [5]. Leur signification et leur représentation est donnée ci-dessous.

Paramètre	Signification	Représentation
<cdStd>	Norme de codage pour l’IE de choix de portée de connexion
Définition : UNI 4.0 [5]	équivalent décimal ou hexadécimal de 2 bits	
<conScpTyp>	Type de définition de portée de connexion : UNI 4.0 [5] 	équivalent décimal ou hexadécimal de 4 bits	
<conScpSel>	définition de choix de portée de connexion : UNI 4.0 [5]	équivalent décimal ou hexadécimal de 8 bits	

Actuellement, toutes les valeurs de <cdStd> et de <conScpTyp> sont réservées à l’exception de <cdStd> = 3 (codage ATMF standard) et de <conScpTyp> = 1 (type de portée de connexion de 'organisationnel').

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

5.6.1.15	Attribut 'cache'
Cet attribut est utilisé pour permettre la mise en antémémoire de SVC. Cet attribut a le format suivant :

a=cache:<cacheEnable><cacheTimer>

Le fanion <cacheEnable> indique si la mise en antémémoire est activée ou non, correspondant aux valeurs de chaîne de "on" et "off" respectivement.

Le <cacheTimer> indique la période d’inactivité à la suite de laquelle le SVC doit être libéré par l’envoi d’un message de libération de SVC dans le réseau. Ceci est spécifié comme l’équivalent décimal ou hexadécimal d’un champ de 32 bits, indiquant la temporisation en secondes. Comme d’habitude, les zéros en tête peuvent être omis. Par exemple,

a=cache:on 7200

implique que le SVC en antémémoire est à supprimer si il est inactif pendant 2 heures.

Le <cacheTimer> peut être réglé à "-" si il est inapplicable ou implicite.

5.6.1.16	Attribut 'bearerSigIE'
Les normes de signalisation ATM fournissent des 'mécanismes d’échappement' pour représenter, signaler et négocier des paramètres de couche supérieure. Des exemples en sont les IE B-HLI et B-LLI spécifiés dans la Recommandation UIT-T Q.2931 [15], et l’élément d’information d’usager à usager décrit dans UIT-T Q.2957 [48].

L’attribut 'bearerSigIE' (élément d’information signalisation du support) est défini pour permettre un mécanisme d’échappement similaire qui peut être utilisé avec ces conventions SDP d’ATM. Le format de cette ligne d’attribut de support est le suivant  :

a=bearerSigIE: <bearerSigIEType> <bearerSigIELng> <bearerSigIEVal>

Lorsque une ligne d’attribut de support 'bearerSigIE' est présente, tous ses sous paramètres sont obligatoires. Le préfixe "0x" n’est pas utilisé parce qu’ils sont toujours représentés en hexadécimal.

Le <bearerSigIEType> est représenté par exactement 2 chiffres hexadécimaux. Il est l’identifiant d’IE univoque tel que défini dans les Recommandations UIT-T de la série Q. Les zéros en tête ne sont pas omis. Certaines valeurs pertinentes sont 7E (IE usager à usager selon UIT-T Q.2957 [48]), 5F (IE B-LLI) et 5D (IE B-HLI). B-LLI et B-HLI, qui signifient respectivement informations de couche inférieure à haut débit (Broadband Low-layer Information) et informations de couche supérieure à haut débit (Broadband High-layer Information) sont définis dans la Recommandation UIT-T Q.2931 [15]. Tous deux se réfèrent aux couches au dessus de la couche d’adaptation ATM.

Le <bearerSigIELng> consiste en 1 à 4 chiffres hexadécimaux. C’est la longueur de l’élément d’information en octets. Les zéros en tête peuvent être omis.

Le <bearerSigIEVal> est la valeur de l’élément d’information, représenté comme une transposition binaire hexadécimale. Bien que la taille de cette transposition binaire dépende du réseau/service, établir une limite supérieure de 256 octets (512 chiffres hexadécimaux) est adéquat. Comme c’est une transposition binaire, les zéros en tête ne devraient pas être omis. Le nombre de chiffres hexadécimaux dans cette transposition binaire est pair.

5.6.2	Attributs de couche d’adaptation ATM (AAL)
Voici une liste sommaire des attributs de support SDP qui peuvent être utilisés pour décrire la couche d’adaptation ATM (AAL, ATM Adaptation Layer). Ils sont détaillés dans les paragraphes qui suivent :
*	l’attribut 'aalApp qui est utilisé pour pointer sur la norme de contrôle pour une couche d’application au dessus de la couche d’adaptation ATM  ;
*	l’attribut 'cbrRate', qui représente l’octet de débit CBR défini au tableau 4-6 de la Recommandation UIT-T Q.2931 [15]  ;
*	l’attribut 'sbc', qui note le compte de sous canaux dans le cas de communication en n x 64 canaux clairs  ;
*	l’attribut 'clkrec, qui indique la méthode de récupération d’horloge pour les transferts de données non structurées (UDT, unstructured data transfer) AAL1  ;
*	l’attribut 'fec', qui indique l’utilisation de la correction d’erreur directe  ;
*	l’attribut 'prtfl', qui indique le niveau de remplissage des cellules partiellement remplies  ;
*	l’attribut 'structure', qui est utilisé pour indiquer la présence ou l’absence de transfert de données structurées (SDT, structured data transfer) AAL1, et la taille des blocs SDT  ;
*	l’attribut 'cpsSDUsize', qui est utilisé pour indiquer la taille maximum de la charge utile de SDU CPCS  ;
*	l’attribut 'aal2CPS', qui est utilisé pour indiquer qu’une sous couche CPS AAL2, comme défini dans UIT-T I.363.2 [13], est associée au VCC auquel se réfère la ligne 'm'. Facultativement, il peut être utilisé pour indiquer les options de CPS choisies et les valeurs de paramètres pour ce VCC  ;
*	l’attribut 'aal2CPSSDUrate', qui est utilisé pour fixer une limite supérieure au débit binaire de SDU pour un CID AAL2  ;
*	l’attribut 'aal2sscs3661unassured', qui est utilisé pour indiquer la présence d’une sous couche SSCS AAL2 avec transmission non assurée comme défini dans UIT-T I.366.1 [12]. Facultativement, il peut être utilisé pour indiquer les valeurs d’option et de paramètre choisies pour cette SSCS  ;
*	l’attribut 'aal2sscs3661assured', qui est utilisé pour indiquer la présence d’une sous couche SSCS AAL2 qui a assuré la transmission comme défini dans UIT-T I.366.1 [12]. Facultativement, il peut être utilisé pour indiquer les valeurs d’option et de paramètre choisies pour cette SSCS  ;
*	l’attribut 'aal2sscs3662', qui est utilisé pour indiquer la présence d’une sous couche SSCS AAL2 comme défini dans UIT-T I.366.2. Facultativement, il peut être utilisé pour indiquer les valeurs d’option et de paramètre choisies pour cette SSCS  ;
*	l’attribut 'aal5sscop', qui est utilisé pour indiquer l’existence d’une couche de protocole SSCOP sur une couche CPS AAL5, et les paramètres qui relèvent de cette couche SSCOP.

5.6.2.1	Attribut 'aalApp'
Lorsque présent, l’attribut 'aalApp' est utilisé pour pointer sur la norme de contrôle pour une couche d’application au dessus de la couche d’adaptation ATM. Le format de la ligne d’attribut de support 'aalApp' est le suivant :

a=aalApp: <appClass> <oui> <appId>

Si un des sous paramètres, <appClass>, <oui> ou <appId>, doit rester non spécifié, il est réglé à "-". Cependant, une ligne d’attribut 'aalApp' avec tous les sous paramètres réglés à "-" ne porte pas d’informations et devrait être omise.

Le champ, ou classe d’application <appClass> peut prendre les valeurs de chaîne énumérées ci-dessous.

Cette liste n’est pas exhaustive. Un préfixe "X-" devrait être utilisé avec les valeurs de <appClass> qui ne sont pas citées ici.

<appClass>	Signification	
"itu_h323c"	Annexe C de H.323 qui spécifie RTP direct sur AAL5 [45].	
"af83"	af-vtoa-0083.001, qui spécifie des PDU AAL5 de taille variable avec MIC vocal et un SSCS nul [46].	
"AAL5_SSCOP"	SSCOP comme défini dans UIT-T Q.2110 [43] fonctionnant sur un CPS AAL5 [21]. Aucune information n’est fournie concernant les couches au dessus de SSCOP comme les couches de fonction de coordination spécifiques du service (SSCF, Service Specific Coordination Function).	
"itu_i3661_unassured"	SSCS avec transmission non assurée, selon UIT-T I.366.1 [12].	
"itu_i3661_assured"	SSCS avec transmission assurée, selon UIT-T I.366.1 [12]. Utilise SSCOP [43].	
"itu_i3662"	SSCS selon UIT-T I.366.2 [13].	
"itu_i3651"	Relais de trame SSCS selon UIT-T I.365.1 [39].	
"itu_i3652"	Fonction de coordination spécifique de service, comme défini dans UIT-T I.365.2, pour le service réseau en mode connexion (SSCF-CONS) [40]. Utilise SSCOP [43].	
"itu_i3653"	Fonction de coordination spécifique de service, comme défini dans UIT-T I.365.3, pour le service de transport en mode connexion (SSCF-COTS) [41]. Utilise SSCOP [43].	
"itu_i3654"	Fonction de coordination spécifique de service HDLC, comme défini dans UIT-T I.365.4 [42].	
"FRF5"	Utilise la norme de relais de trame FRF.5 [53], qui fait références à UIT-T I.365.1 [39].	
"FRF8"	Utilise la norme de relais de trame FRF.8.1 [54]. Cela implique un SSCS nul et la transposition de l’en-tête de relais de trame en en-tête ATM.	
"FRF11"	Utilise la norme de relais de trame FRF.11 [55].	
"itu_h2221"	Utilise la norme UIT-T H.222.1 pour communication audiovisuelle sur AAL5 [51].	

Le <oui>, ou identifiant unique d’organisation, se réfère à l’organisation responsable de la définition de <appId>, ou identifiant d’application. Le <oui> est tenu par l’IEEE. Une de ses utilisations est dans les adresses MAC 802. C’est un champ de trois octets représenté comme un à six chiffres hexadécimaux. Comme ceci est toujours représenté en hexadécimal, le préfixe "0x" n’est pas utilisé. Les zéros en tête peuvent être omis.

Le sous paramètre <appId> se réfère à l’identifiant d’application, un nombre hexadécimal comportant jusqu’à 8 chiffres. Les zéros en tête peuvent ête omis. Le préfixe "0x" n’est pas utilisé, car la représentation est toujours hexadécimale. Actuellement, la seule organisation qui a défini des identifiants d’application est le Forum ATM. Ils ont été définis dans le contexte de AAL2 ([44], [52], Section 5 de [61]). Dans SDP, ce peut être utilisé avec <appClass> = itu_i3662. La valeur <oui> pour le forum ATM est 0x00A03E.

Dans l’exemple qui suit, la ligne d’attribut de support aalApp est utilisée pour indiquer 'service d’émulation de boucle’ utilisant CAS (seulement pour les POTS) sans le protocole de contrôle d’émulation de boucle (ELCP, Emulated Loop Control Protocol) [52]. L’identifiant d’application est défini par le Forum ATM [61]. Le SSCS utilisé est selon UIT-T I.366.2 [13].

a=aalApp:itu_i3662 A03E A

Si les zéros en tête ne sont pas éliminés, cela peut être représenté comme :

a=aalApp:itu_i3662 00A03E 0000000A

Comme les identifiants d’application ont été spécifiés dans le seul contexte du SSCS AAL2 défini dans UIT-T I.366.2 [13], le <appClass> peut être réglé à '-' sans ambiguïté. La ligne d’attribut de support aalApp peut être réduite à :

a=aalApp:- A03E A
ou
a=aalApp:- 00A03E 0000000A

5.6.2.2	Attribut 'cbrRate'
Lorsque présent, l’attribut 'cbrRate' est utilisé pour représenter l’octet de débit CBR défini au Tableau 4-6 de UIT-T Q.2931 [15]. Le format de cette ligne d’attribut de support est :

a=cbrRate: <cbrRate>

Ici, <cbrRate> est représenté comme exactement deux chiffres hexadécimaux. Le préfixe "0x" est omis car ce paramètre est toujours représenté en hexadécimal. Les valeurs actuellement définies par l’UIT-T sont :

Valeur (hex)	Signification
01	   64 kbit/s
04	1544 kbit/s
05	6312 kbit/s
06	32  064 kbit/s
07	44  736 kbit/s
08	97  728 kbit/s
10	  2  048 kbit/s
11	  8  448 kbit/s
12	 34  368 kbit/s
13	139  264 kbit/s
40	n x 64 kbit/s
41	n x 8 kbit/s

Il est préférable que l’attribut cbrRate soit omis plutôt que réglé à la valeur inspécifiée de "-", car il ne porte aucune information dans ce dernier cas.

5.6.2.3	Attribut 'sbc'
La ligne d’attribut de support 'sbc' note le compte de sous canaux et n’est significative que dans le cas de communication à n x 64 canaux clairs. Un canal n x 64 clair peut utiliser l’adaptation AAL1 (Forum ATM af-vtoa-78) ou l’adaptation AAL2 (UIT-T I.366.2). Bien qu’il n’existe pas une telle définition standard, il est aussi possible d’utiliser AAL5 à cette fin. Un canal clair n  x  64 est représenté par les noms de codage de "X-CCD" et "X-CCD-CAS" dans le Tableau 2.

Le format de la ligne d’attribut de support 'sbc' est le suivant :

a=sbc:<sbc>

Ici, <sbc> peut être exprimé par un entier décimal ou hexédécimal. Cet attribut indique le nombre de DS0 dans une trame T1 ou E1 qui est agrégée pour transmettre des données de canal clair. Pour les applications fondées sur T1, il peut prendre des valeurs entières dans la gamme inclusive [1...24]. Pour les applications fondées sur E1, il peut prendre des valeurs entières dans la gamme inclusive [1...31]. Lorsque il est omis, d’autres moyens doivent être utilisés pour déterminer le compte de sous canux.

L’utilisation de l’attribut 'sbc' donne un moyen direct pour indiquer le nombre de sous canaus à 64 kbit/s mis en faisceau dans un canal clair n x 64. Un autre mécanisme pour indiquer cela existe dans les informations de bande passante SDP, ou ligne 'b' [1]. Dans ce cas, au lieu de spécifier le nombre de sous canaux, la bande passante agrégée est spécifiée en kbit/s. La syntaxe de la ligne 'b', copiée mot à mot de [1], est comme suit :

b=<modifier>:<valeur de bande passante>

Dans le cas de canaux clairs n x 64, le <modifier> reçoit une valeur de chaîne de texte de "AS", qui indique que la ligne 'b' est spécifique de l’application. Le paramètre <valeur de bande passante>, qui est un nombre décimal qui indique la bande passante en kbit/s, est limitée à une des valeurs suivantes dans le contexte d’application de canal clair n x 64 :

64, 128, 192, 256, 320, 384, 448, 512, 576, 640, 704, 768, 832, 896, 960, 1024, 1088, 1152, 1216, 1280, 1344, 1408, 1472, 1600, 1664, 1728, 1792, 1856, 1920, 1984

Donc, pour un service de données en mode circuit n x 64,
a=sbc:6
est équivalent à
b=AS:384

La ligne d’attribut de support
a=sbc:2
est équivalente à
b=AS:128

5.6.2.4	Attribut 'clkrec'
Lorsque présent, l’attribut 'clkrec' est utilisé pour indiquer la méthode de récupération d’horloge. Cet attribut est significatif dans le cas de transfert de données AAL1 non structurées (UDT, unstructured data transfer). Le format de la ligne d’attribut de support 'clkrec' est le suivant :

a=clkrec:<clkrec>

Le champ <clkrec> peut prendre les valeurs de chaîne suivantes : "NULL", "SRTS" ou "ADAPTIVE". Les récupérations d’horloge SRTS et adaptive sont définies dans UIT-T I.363.1 [10]. "NULL" indique que le flux (par exemple, T1/E1) encapsulé dans ATM est synchrone au réseau ATM ou est réinitialisé, avant l’encapsulation AAL1, via des mémoires tampon glissantes.

5.6.2.5	Attribut 'fec'
Lorsque présent, l’attribut 'fec' est utilisé pour indiquer l’utilisation de la correction d’erreur directe. Actuellement, il existe une méthode de correction d’erreur directe définie pour AAL1 dans UIT-T I.363.1 [10]. Le format de la ligne d’attribut de support 'fec' est le suivant :

a=fec:<fecEnable>

Le fanion <fecEnable> indique la présence ou l’absence de la correction d’erreur directe. Il peut prendre les valeurs de chaîne de "NULL", "LOSS_SENSITIVE" et "DELAY_SENSITIVE". Une valeur de "NULL" implique que cette capacité est désactivée. La FEC peut être activée différemment pour les connexions sensibles au retard et sensibles à la perte.

5.6.2.6	Attribut 'prtfl'
Lorsque présent, l’attribut 'prtfl' est utilisé pour indiquer le niveau de remplissage des cellules. Lorsque cet attribut est absent, d’autres moyens (tels que l’approvisionnement par défaut) sont utilisés pour déterminer la présence et le niveau de remplissage partiel.

Cet attribut indique le nombre d’octets de charge utile hors bourrage, non inclus tous octets de SAR AAL ou de sous couche de convergence. Par exemple, dans certaines applications AAL1 qui utilisent des celules partiellement remplies avec un bourrage à la fin, cet attribut indique le nombre d’octets de charge utile en tête, toute redondance AAL non incluse.

Le format de la ligne d’attribut de support 'prtfl' est le suivant :

a=prtfl:<remplissagePartiel>

Ici, <remplissagePartiel> peut être exprimé comme un entier décimal ou hexadécimal.

En général, les valeurs permises sont des entiers dans la gamme de 1 à 48 inclus. Cependant, cette limite supérieure est différente pour des adaptations différentes car la redondance AAL, s’il y en a, est différente. Si le remplissage partiel spécifié est supérieur ou égal au remplissage maximum, le remplissage complet est utilisé. Utiliser un remplissage 'partiel' de 48 désactive toujours le remplissage partiel.

Dans le contexte AAL1, cette ligne d’attribut de support s’applique uniformément aux cellules P et non P. Dans les applications AAL1 qui ne font pas la distinction entre cellules P et non P, une valeur de 47 indique le remplissage complet (c’est-à-dire, l’absence de remplissage partiel). Dans les applications AAL1 qui font la distinction entre cellules P et non P, une valeur de 46 indique qu’il n’y a pas de bourrage dans les cellules P et un bourrage de un dans les cellules non P.

Si le remplissage partiel est activé (c’est-à-dire qu’il y a du bourrage au moins sur quelques cellules) les structures AAL1 ne doivent pas dépasser les limites de cellules. Celles-ci doivent être respectées dans toutes les cellules. Donc, leur taille devra être inférieure ou égale à la taille de remplissage partiel. De plus, la taille de remplissage partiel est de préférence un multiple entier de la taille de la structure. Sinon, la taille de remplissage partiel déclarée dans la description SDP devra être tronquée à un multiple entier (par exemple, une taille de remplissage partiel de 40 est tronquée à 36 pour prendre en charge six canaux 6  x  64).

5.6.2.7	Attribut 'structure'
Cet attribut ne s’applique qu’aux connexions AAL1. Lorsque présent, l’attribut 'structure' est utilisé pour indiquer la présence ou l’absence de transfert de données structurées (SDT, structured data transfer) et la taille en octets des blocs de SDT. Le format de la ligne d’attribut de support 'structure' est le suivant :

a=structure: <structureEnable> <blksz>

où le fanion <structureEnable> indique la présence ou l’absence de SDT. Il peut prendre les valeurs de "on" ou "off". Une valeur de "on" implique le transfert de données AAL1 structurées, tandis qu’une valeur de "off" implique le transfert de données AAL1 non structurées (UDT, unstructured data transfer).

Le champ Taille de bloc, <blksz>, est un champ facultatif de 16 bits [15] qui peut être représenté en décimal ou hexadécimal. Il est réglé à "-" lorsque non applicable, comme dans le cas de transfert de données non structurées (UDT). Pour SDT, il peut être réglé à "-" lorsque <blksz> est connu par d’autres moyens. Par exemple, af-vtoa-78 [7] fixe la taille de la structure pour le service n x 64, avec ou sans CAS. La valeur théorique maximum de <blksz> est 65  535, bien que la plupart des services utilisent beaucoup moins.

5.6.2.8	Attribut 'cpsSDUsize'
Lorsque présent, l’attribut 'cpsSDUsize' est utilisé pour indiquer la taille maximum de la charge utile de la SDU CPCS. Il peut y avoir plusieurs lignes ' cpsSDUsize' dans une description SDP.

Le format de cette ligne d’attribut de support est le suivant :

a=cpsSDUsize:<directionFlag><cpcs>

Le <directionFlag> peut recevoir les valeurs de chaîne suivantes : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant (forward) et vers l’arrière (backward). "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrière sont celles du paragraphe 2.3.

Le champ <cpcs> est un entier de 16 bits qui peut être représenté en décimal ou hexadécimal. La signification et les valeurs de ces champs sont les suivantes :

Application	Champ	Signifcation	Valeurs
AAL5	<cpcs>	Taille maximum de CPCS-SDU	1 à 65  535
AAL2	<cpcs>	Taille maximum de CPCS-SDU	45 ou 64

5.6.2.9	Attribut 'aal2CPS'
Lorsque présent, l’attribut 'aal2CPS' est utilisé pour décrire les paramètres associés à la couche CPS AAL2.

Le format de la ligne d’attribut de support 'aal2CPS' est le suivant :

a=aal2CPS:<cidLowerLimit><cidUpperLimit><timerCU> <simplifiedCPS>

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

<cidLowerLimit> et <cidUpperLimit> peuvent recevoir des valeurs d’entier entre 8 et 255 [11], avec pour limitation que <cidUpperLimit> soit supérieur ou égal à <cidLowerLimit>. Par exemple, pour les applications POTS fondées sur [52], <cidLowerLimit> et <cidUpperLimit> peuvent avoir des valeurs de 16 et 223 respectivement.

L’entier <timerCU> représente le temporisateur CU "utilisation combinée" défini dans la Recommandation UIT-T I.363.2. Ce temporisateur est representé par un nombre entier de microsecondes. Il est représenté comme l’équivalent entier décimal de 32  bits.

Le paramètre <simplifiedCPS> peut recevoir les valeurs de "on" ou "off". Lorsque à "on", la simplification CPS AAL2 décrite dans [52] est adoptée. Avec cette simplification, chaque celluele ATM contient exactement un paquet AAL2. Si nécessaire, les octets à la fin de la cellule sont bourrés avec des zéros. Comme la valeur de <timerCU> dans ce contexte est toujours 0, elle peut être réglée à "-".

5.6.2.10	Attribut 'aal2CPSSDUrate'
Lorsque présent, l’attribut 'aal2CPSSDUrate' est utilisé pour fixer une limite supérieure au débit binaire de SDU pour un CID AAL2. C’est utile pour limiter la bande passante utilisée par un CID, en particulier si le CID est utilisé pour les données en mode trame défini dans [13], ou avec le SSSAR défini dans [12]. Le format de cette ligne d’attribut de support est le suivant :

a=aal2CPSSDUrate: <fSDUrate><bSDUrate>

fSDUrate et bSDUrate sont les débits de SDU maximum vers l’avant et vers l’arrière en bits/seconde. Ils sont représentés par des entiers décimaux, dont la gamme est comme défini dans la Section 6. Si un de ces paramètres dans ces lignes d’attribut du support n’est pas spécifié, est inapplicable ou est implicite, il est alors réglé à "-".

5.6.2.11	Attribut 'aal2sscs3661unassured'
Lorsque présent, l’attribut 'aal2sscs3661unassured' est utilisé pour indiquer les options qui relèvent de la transmission SSCS non assurée définie dans la Recommandation UIT-T I.366.1 [12]. Cette SSCS peut être choisie via l’attribut aalApp défini ci-dessous, où du fait de la présence de l’attribut 'aal2sscs3661unassured'. Le format de cette ligne d’attribut du support est le suivant :

a=aal2sscs3661unassured: <ted> <rastimer> <fsssar> <bsssar>

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

Le fanion <ted> indique la présence ou l’absence de la détection d’erreur de transmission comme défini dans I.366.1. On peut lui donner les valeurs de "on" ou "off". Une valeur de "on" indique la présence de la capacité.

Le sous paramètre <rastimer> indique le temporisateur SSSAR de réassemblage en microsecondes. Il est représenté comme équivalent décimal de 32 bits.

Les champs <fsssar> et <bsssar> sont des entiers de 24 bits qui peuvent être représentés en décimal ou hexadécimal. La signification et les valeurs des champs <fsssar> et <bsssar> sont les suivants :

Champ	Signification	Valeurs
<fsssar>	Taille maximum de SSSAR-SDU vers l’avant	1 à 65  568
<bsssar>	Taille maximum de SSSAR-SDU vers l’arrière	1 à 65  568

Si elle est présente, la sous couche de détection d’erreur de transmission spécifique du service (SSTED, Service-Specific Transmission Error Detection) est au dessus de la sous couche de segmentation et réassemblage spécifique du service (SSSAR, Service-Specific Segmentation and Reassembly) [12]. Comme la taille maximum des SDU SSTED peut être déduite de la taille maximum de SDU SSSAR, il n’est pas nécessaire de la spécifier séparément.

5.6.2.12	Attribut 'aal2sscs3661assured'
Lorsque présent, l’attribut 'aal2sscs3661assured' est utilisé pour indiquer les options qui relèvent de la SSCS de transmission assurée définie dans la Recommandation UIT-T I.366.1 [12] sur la base de la Recommandation UIT-T Q.2110 [43]. Cette SSCS peut être choisie via l’attribut aalApp défini ci-dessous, ou de la présence de l’attribut 'aal2sscs3661assured'. Le format de cette ligne d’attribut de support est le suivant :

a=aal2sscs3661assured: <rastimer> <fsssar> <bsssar> <fsscopsdu> <bsscopsdu><fsscopuu> <bsscopuu>

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

Le sous paramètre <rastimer> indique le temporisateur de réassemblage SSSAR en microsecondes. Il est représenté comme l’équivalent décimal de 32 bits.

Les champs <fsssar> et <bsssar> sont des entiers de 24 bits qui peuvent être représentés en décimal ou en hexadécimal. Les champs <fsscopsdu>, <bsscopsdu>, <fsscopuu> et <bsscopuu> sont des entiers de 16 bits qui peuvent être représentés en décimal ou en hexadécimal. la signification et la valeurs de ces champs est la suivante :

Champ	Signification	Valeurs
<fsssar>	Taille maximum de SSSAR-SDU vers l’avant	1 à 65  568
<bsssar>	Taille maximum de SSSAR-SDU vers l’arrière	1 à 65  568
<fsscopsdu>	Taille maximum de SSCOP-SDU vers l’avant	1 à 65  528
<bsscopsdu>	Taille maximum de SSCOP-SDU vers l’arrière	1 à 65  528
<fsscopuu>	Taille maximum de SSCOP-UU vers l’avant	1 à 65  524
<bsscopuu>	Taille maximum de SSCOP-UU vers l’arrière	1 à 65  524

La sous couche SSTED (détection d’erreur de transmission spécifique du service) est au dessus de la sous couche SSSAR (segmentation et réassemblage spécifique du service) [12]. La sous couche SSADT (transfert de données assuré spécifique du service) est au dessus de la sous couche SSTED. Comme la taille maximum des SDU de SSTED et de SSADT peut être déduite de la taille maximum de SDU SSSAR, il n’est pas nécessaire de les spécifier séparément.

Le protocole SSCOP défini dans [43] est utilisé par le service de transfert de données assuré défini dans [12]. Dans le contexte de la SSCS de la Recommandation UIT-T I.366.1, il est possible d’utiliser l’attribut 'aal2sscs3661assured' pour limiter les tailles maximum des champs de SDU et UU (utilisateur à utilisateur) SSCOP dans l’une et l’autre direction. Noter qu’il est nécessaire que les paramètres sur la ligne d’attribut de support 'aal2sscs3661assured' soient cohérents les uns avec les autres.

5.6.2.13	Attribut 'aal2sscs3662'
Lorsque présent, l’attribut 'aal2sscs3662' est utilisé pour indiquer les options qui relèvent de la SSCS définie dans la Recommandation UIT-T I.366.2 [13]. Cette SSCS peut être choisie via l’attribut aalApp défini ci-dessous, ou par la présence de l’attribut 'aal2sscs3662'.

Le format de cette ligne d’arribut du support est le suivant :

a=aal2sscs3662: <sap> <circuitMode> <frameMode> <faxDemod> <cas> <dtmf> <mfall> <mfr1> <mfr2> <PCMencoding> <fmaxFrame> <bmaxFrame>

Chacun de ces champs peut être réglé à "-" lorsque l’intention n’est pas de les spécifier dans un descripteur SDP. De plus, les valeurs de ces champs doivent être cohérentes les unes avec les autres. Les incohérences devraient être marquées comme erreurs.

Le champ <sap> peut prendre les valeurs de chaîne suivantes : "AUDIO" et "MULTIRATE". Elles correspondent aux points d’accès de service (SAP, Service Access Point) audio et multidébit définis dans la Recommandation UIT-T I.366.2.

Pour le SAP multidébit, les paramètres  <faxDemod>,<cas>, <dtmf>, <mfall>, <mfr1>,  <mfr2> et <PCMencoding> ne s’appliquent pas sur la ligne d’attribut aal2sscs3662. Ils sont réglés à "-" pour le SAP multidébit.

Le fanion <circuitMode> indique si le transport de données en mode circuit est activé ou désactivé, correspondant aux valeurs de chaîne de "on" et "off" respectivement. Pour le SAP multidébit, il ne peut pas avoir une valeur de "off". Pour le SAP audio, il peut recevoir une valeur de "on", "off" ou "-". Noter que l’attribut <sbc>, défini ailleurs dans le présent document, peut être utilisé pour spécifier le nombre de sous canaux de 64 kbit/s mis en faisceau dans un canal de données en mode circuit.

Le fanion <frameMode> indique si le transport de données en mode trame est activé ou désactivé, correspondant aux valeurs de chaîne de "on" et "off" respectivement.

Le fanion <faxDemod> indique si la démodulation et remodulation de télécopie sont activées ou désactivées, correspondant aux valeurs de chaîne de "on" et "off" respectivement.

Le fanion <cas> indique si le transport de bits de signalisation de canal associé (CAS, Channel Associated Signaling) dans les paquets de type 3 AAL2 est activée ou désactivée, correspondant respectivement aux valeurs de chaîne de "on" et "off".

Le fanion <dtmf> indique si le transport de chiffres DTMF composés dans les paquets de type 3 AAL2 est activé ou désactivé, correspondant respectivement aux valeurs de chaîne de "on" et "off".

Le fanion <mfall> indique si le transport de chiffres composés en MF dans les paquets de type 3 AAL2 est activé ou désactivé, correspondant respectivement aux valeurs de chaîne de "on" et "off". Ce fanion permet des chiffres composés en MF d’une manière générique, sans spécifier le type (par exemple, R1, R2 etc.).

Le fanion <mfr1> indique si le transport, dans les paquets de type 3 AAL2, de chiffres composés en MF pour le système de signalisation R1 est activé ou désactivé, correspondant respectivement aux valeurs de chaîne de "on" et "off".

Le fanion <mfr2> indique si le transport, dans les paquets de type 3 AAL2, de chiffres composés en MF pour le système de signalisation R2 est activé ou désactivé, correspondant respectivement aux valeurs de chaîne de "on" et "off".

Le champ <PCMencoding> indique si le codage MIC, si il est utilié, se fonde sur la loi A ou sur la loi mu. Cela peut être utilisé pour qualifier le codec 'MIC générique' déclaré dans certains des profils AAL2. Le champ <PCMencoding> peut prendre les valeurs de chaîne de "PCMA" et "PCMU".

Les champs <fmaxFrame> et <bmaxFrame> sont des entiers de 16 bits qui peuvent être représentés en décimal ou en hexadécimal. La signification et les valeurs des champs <fmaxFrame> et <bmaxFrame> sont les suivantes :

Champ	Signification	Valeurs
<fmaxFrame>	longueur maximum d’une unité de données en mode trame, vers l’avant	1 - 65  535
<bmaxFrame>	longueur maximum d’une unité de données en mode trame, vers l’arrière	1 - 65  535

5.6.2.14	Attribut 'aal5sscop'
Lorsque présent, l’attribut 'aal5sscop' est utilisé pour indiquer l’existence d’une couche de protocole SSCOP [43] par dessus une couche CPS AAL5 [21], et les paramètres qui relèvent de cette couche SSCOP. SSCOP sur AAL5 peut aussi être choisi via l'attribut aalApp défini ci-dessous. Le format de la ligne d’attribut de support 'aal5sscop' est le suivant :

a=aal5sscop: <fsscopsdu> <bsscopsdu> <fsscopuu> <bsscopuu>

Chacun de ces champs peut être réglé à "-" lorsque l’intention est de ne pas les spécifier dans un descripteur SDP.

La représentation, la signification et les valeurs des champs <fsscopsdu>, <bsscopsdu>, <fsscopuu> et <bsscopuu> sont identiques à celles pour la ligne d’attribut de support 'aal2sscs3661assured' (paragraphe 5.6.2.12). Noter qu’il est nécessaire que les paramètres sur la ligne d’attribut de support ' aal5sscop' soient cohérents les uns avec les autres.

5.6.3	Attributs de service
On donne une liste récapitulative des attributs de suppot SDP qui peuvent être utilisés pour décrire les services qui utilisent la couche d’adaptation ATM (AAL). Ces attributs sont détaillés dans les paragraphes suivants.

*	Attribut 'atmmap' : Dans les contextes AAL1 et AAL5, il est utilisé pour la transposition dynamique des types de charge en chaînes de codec.

*	Attribut 'silenceSupp' : utilisé pour indiquer l’utilisation de la détection d’activité vocale pour la suppression des silences, et pour paramétrer facultativement la fonction de suppression de silence.

*	Attribut 'ecan' : utilisé pour indiquer l’utilisation de l’annulation d’écho, et pour paramétrer cette fonction.

*	Attribut 'gc' : utilisé pour indiquer l’utilisation du contrôle de gain, et pour paramétrer cette fonction.

*	Attribut 'profileDesc' : il peut être utilisé pour décrire les profils AAL2. Bien que tout profil AAL2 puisse être décrit ainsi, cet attribut est utile pour décrire, au moment de l’établissement de la connexion, des profils personnalisés qui peuvent n’être pas connus de l’extrémité distante. Cet attribut ne s’applique que dans le contexte AAL2.

*	Attribut 'vsel' : il indique une liste rangée par priorité de triplets pour le service vocal. Chaque triplet indique un codec, une longueur de paquet facultative, et une période facultative de mise en paquets. Cela complète les informations de la ligne 'm' et devrait être cohérent avec elle.

*	Attribut 'dsel' : il indique une liste rangée par priorité de triplets pour le service de données en bande vocale.Chaque triplet indique un codec, une longueur de paquet facultative et une période de mise en paquet facultative. Cela complète les informations de la ligne 'm' et devrait être cohérent avec elle.

*	Attribut 'fsel' : il indique une liste rangée par priorité de triplets pour le service de télécopie. Chaque triplet indique un codec, une longueur de paquet facultative et une période de mise en paquet facultative. Cela complète les informations de la ligne 'm' et devrait être cohérent avec elle.

*	Attribut 'onewaySel' : il indique une liste rangée par priorité de triplets pour une direction d’une connexion asymétrique. Chaque triplet indique un codec, une longueur de paquet facultative et une période de mise en paquet facultative. Cela complète les informations de la ligne 'm' et devrait être cohérent avec elle.

*	Attribut 'codecconfig'  : il est utilisé pour représenter le contenu d’un seul élément d’information (IE) de codec défini dans la Recommandation UIT-T Q.765.5 [57].

*	Attribut 'isup_usi'  : il est utilisé pour représenter l’élément d’information Capacité du support défini au paragraphe 4.5.5 de la Recommandation UIT-T Q.931 [59], et est réitéré comme l’élément d’information (IE) Service d’utilisateur au paragraphe 3.57 de la Recommandation UIT-T Q.763 [60].

*	Attribut 'uiLayer1_Prot'  : il est utilisé pour représenter le champ 'Protocole d’informations d’utilisateur de couche 1' au sein de l’élément d’information Capacités du support défini au paragraphe 4.5.5 de la Recommandation UIT-T Q.931 [59].

5.6.3.1	Attribut 'atmmap'
L’attribut 'atmmap' est défini sur la base de l’attribut 'rtpmap' utilisé dans la RFC 2327.

a=atmmap:<typeDeChargeUtile> <nomDeCodage>

L’attribut 'atmmap' est utilisé pour transposer de façon dynamique les noms de codage en types de charge utile. Ceci est nécessaire pour les noms de codage qui n’ont pas été affectés à un type de charge utile statique par l’IANA [31]. Les types de charge utile et les techniques de codage enregistrées auprès de l’IANA pour RTP ont été retenus pour AAL1 et AAL5.

La gamme des types de charge utile définis de façon statique est dans la gamme 0-95. Toutes les allocations statiques des types de charge utile aux codecs sont énumérées dans [31]. La gamme des types de charge utile définis de façon dynamique via l’attribut 'atmmap' est de 96 à 127.

En plus de répéter les noms de types de charge utile et de codages de [31], le Tableau 2 définit des noms de codage non standard (avec des préfixes "X-"). Noter que [31], plutôt que le Tableau 2, est l’autorité pour la liste des noms de code standard et des types de charge dans le contexte ATM.

Tableau 2 : Noms de code et types de charge utile

Technique de codage	Nom de code	Type de charge utile	
MIC – loi mu	"PCMU"	0 (Transposition statique)	
MIC AD à 32 kbit/s	"G726-32"	2 (Transposition statique)	
Double débit 5,3/6,3 kbit/s	"G723" 	4 (Transposition statique)	
MIC - loi A	"PCMA"	8 (Transposition statique)	
Codage audio à 7 kHz en 64 kbit/s	"G722"	9 (Transposition statique)	
LD-CELP	"G728"	15 (Transposition statique)	
CS-ACELP (normal/faible complexité)	"G729"	18 (Transposition statique)	
CS-ACELP à faible complexité	"X-G729a"	Aucune, transpo.dynamique	
CS-ACELP normal à suppression de silence défini par l’UIT-T	"X-G729b"	Aucune, transpo.dynamique	
CS-ACELP faible compl. à suppression de silence défini UIT-T	"X-G729ab"	Aucune, transpo.dynamique	
MIC AD à 16 kbit/s	"X-G726-16"	Aucune, transpo.dynamique	
MIC AD à 24 kbit/s	"X-G726-24"	Aucune, transpo.dynamique	
MIC AD à 40 kbit/s	"X-G726-40"	Aucune, transpo.dynamique	
Double débit 5,3/6,3 kbit/s – haut débit	"X-G7231-H"	Aucune, transpo.dynamique	
Double débit 5,3/6,3 kbit/s – bas débit	"X-G7231-L"	Aucune, transpo.dynamique	
Double débit 5,3/6,3 kbit/s – haut débit w/supp. silence UIT-T	"X-G7231a-H"	Aucune, transpo.dynamique	
Double débit 5,3/6,3 kbit/s – haut débit w/supp. silence UIT-T	"X-G7231a-L" 	Aucune, transpo.dynamique	
MIC EAD 16 kbit/s	"X-G727-16"	Aucune, transpo.dynamique	
MIC EAD 24 kbit/s	"X-G727-24"	Aucune, transpo.dynamique	
MIC EAD 32 kbit/s	"X-G727-32"	Aucune, transpo.dynamique	
Canal clair n x 64 kbit/s sans CAS selon af-vtoa-78 [7]	"X-CCD"	Aucune, transpo.dynamique	
Canal clair n x 64 kbit/s avec CAS selon af-vtoa-78 [7]	"X-CCD-CAS"	Aucune, transpo.dynamique	
GSM plein débit	"GSM"	3 (Transposition statique)	
GSM demi débit	"GSM-HR"	Aucune, transpo.dynamique	
GSM plein débit amélioré	"GSM-EFR"	Aucune, transpo.dynamique	
GSM demi débit amélioré	"GSM-EHR"	Aucune, transpo.dynamique	
Télécopie groupe 3 démod.	"X-FXDMOD-3"	Aucune, transpo.dynamique	
CELP Federal Standard FED-STD 1016	"1016" 	1 (Transposition statique)	
DVI4, 8 kHz [3]	"DVI4"	5 (Transposition statique)	
DVI4, 16 kHz [3]	"DVI4"	6 (Transposition statique)	
Codage prédictif linéaire LPC [3]	"LPC"	7 (Transposition statique)	
MIC linéaire à seize bits L16 [3], , double canal	"L16"	10 (Transposition statique)	
MIC linéaire à seize bits L16 [3], canal unique	"L16"	11 (Transposition statique)	
QCELP [3]	"QCELP"	12 (Transposition statique)	
MPEG1/MPEG2 audio	"MPA"	14 (Transposition statique)	
DVI4, 11,025 kHz[3]	"DVI4"	16 (Transposition statique)	
DVI4, 22,05 kHz [3]	"DVI4" 	17 (Transposition statique)	
MPEG1/MPEG2 vidéo	"MPV"	32 (Transposition statique)	
Flux de transport MPEG 2 audio/vidéo	"MP2T"	33 (Transposition statique)	
vidéo UIT-T H.261	"H261"	31 (Transposition statique)	
vidéo UIT-T H.263	"H263"	33 (Transposition statique)	
vidéo UIT-T H.263 version 1998	"H263-1998"	Aucune, transpo.dynamique	
Flux système MPEG 1	"MP1S"	Aucune, transpo.dynamique	
Flux programme MPEG 2	"MP2P"	Aucune, transpo.dynamique	
Redondance 	"RED"	Aucune, transpo.dynamique	
DVI4 à débit variable	"VDVI"	Aucune, transpo.dynamique	
Cell-B	"CelB"	25	
JPEG 	"JPEG"	26	
nv	"nv"	28	
MIC linéaire à huit bits L8	"L8"	Aucune, transpo.dynamique	
Recommandation UIT-R BT.656-3 pour vidéo numérique	"BT656"	Aucune, transpo.dynamique	
Multidébit adaptif – plein débit (3GPP) [58]	"FR-AMR"	Aucune, transpo.dynamique	
Multidébit adaptif – demi débit (3GPP) [58]	"HR-AMR"	Aucune, transpo.dynamique	
Multidébit adaptif – UMTS (3GPP) [58]	"UMTS-AMR"	Aucune, transpo.dynamique	
Multidébit adaptif - générique [58]	"AMR"	Aucune, transpo.dynamique	

5.6.3.2	Attribut 'silenceSupp'
Lorsque présent, l’attribut 'silenceSupp' est utilisé pour indiquer l’usage ou le non usage de la suppression des silences. Le format de la ligne d’attribut de support 'silenceSupp' est le suivant :

a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse> <fxnslevel>

Si un des paramètres de la ligne d’attribut de support silenceSupp n’est pas spécifié, est inapplicable ou est implicite, il est alors réglé à "-".

<silenceSuppEnable> peut prendre les valeurs de "on" ou "off". Si il est "on", la suppression de silence est alors activée.

<silenceTimer> est un champ de 16 bits qui peut être représenté en décimal ou en hexadécimal. Chaque incrément (tic) de ce temporisateur représente une milliseconde. La valeur maximum de ce temporisateur est entre 1 et 3 minutes. Ce temporisateur représente l’espace de temps avant que commence la suppression de silence. Même si cela peut théoriquement être aussi peu qu’une ms, la plupart des algorithmes de DSP prennent plus que cela pour détecter le silence. Régler <silenceTimer> à une grande valeur (disons 1 minute> est équivalent à désactiver la suppression de silence dans un appel. Cependant, la suppression de canal inactif entre les appels sur la base de la suppression du silence est quand même fonctionnelle dans les applications de transport non commutées si <silenceSuppEnable> = "on" et si <silenceTimer> est une grande valeur.

<suppPref> spécifie la méthode de suppression de silence qui est préférée ou déjà choisie. Il peut prendre les valeurs de chaîne de "standard" et de "custom". Si sa valeur est "standard", une méthode standard (par exemple, définie par l’UIT-T) est préférée aux méthodes personnalisées si un tel standard est défini. Autrement, une méthode personnalisée peut être utilisée. Si <suppPref> est réglé à "custom", une méthode personnalisée, si il en est de disponible, est alors préférée à la méthode standard.

<sidUse> indique si les descripteurs d’insertion de silence (SID, Silence Insertion Descriptor) sont à utiliser, et si ils utilisent un bruit de comfort fixé ou un bruit de fond échantillonné. Il peut prendre les valeurs de chaîne de "No SID", "Fixed Noise", "Sampled Noise". Si la valeur de <sidUse> est "Fixed Noise", <fxnslevel> donne alors son niveau. Il peut prendre des valeurs d’entier dans la gamme de 0 à 127, comme suit :

Valeur de <fxnslevel>	Signification
0-29	réservé
30 	- 30 dBm0 
31	- 31 dBm0 
. . .	    . . .
77	- 77 dBm0
78	- 78 dBm0
79-126	réservé 
127	Code repos (pas de bruit)

En plus de la représentation décimale de <fxnslevel>, une représentation hexadécimale, précédée d’un préfixe "0x", est aussi permise.

5.6.3.3	Attribut 'ecan'
Lorsque présent, l’attribut 'ecan' est utilisé pour indiquer l’utilisation ou non de l’annulation d’écho. Il peut y avoir plusieurs lignes 'ecan' dans une description SDP.

Le format de la ligne d’attribut de support 'ecan' est la suivante :

a=ecan:<directionFlag><ecanEnable><ecanType>

<directionFlag> peut recevoir les valeurs de chaîne suivantes : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrières, "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrière sont celles du paragraphe 2.3.

Le fanion <directionFlag> est toujours spécifié. Sauf pour <directionFlag>, les paramètres restants peuvent être réglés à "-" pour indiquer qu’ils ne sont pas spécifiés, inapplicables ou implicites. Cependant, il doit y avoir quelques paramètres spécifiés pour que la ligne soit utile dans une description SDP.

Si les lignes d’attribut du support 'ecan' ne sont pas présentes, des moyens autres que le descripteur SDP doivent être utilisés pour déterminer l’applicabilité et la nature de l’annulation d’écho pour une direction de connexion. Des exemples de tels moyens sont le provisionnement d’une MIB, la structure des options de connexion locale dans MGCP, etc.

Le paramètre <ecanEnable> peut prendre les valeurs de "on" ou "off". Si il est à "on", l’annulation d’écho est alors activée. Si il est à "off", l’annulation d’écho est désactivée.

Le paramètre <ecanType> peut prendre les valeurs de chaîne "G165" et de "G168".

Lorsque SDP est utilisé avec des protocoles de contrôle de passerelle de support tels que MGCP et Megaco [26], il existe des moyens en dehors des descriptions de SDP pour spécifier les propriétés d’annulation d’écho d’une connexion. Néanmoins, cette ligne d’attribut de suppport est incluse dans un souci de complétude. Par suite, le SDP peut être utilisé pour décrire l’annulation d’écho dans des applications où ne sont pas disponibles des moyens de remplacement.

5.6.3.4	Attribut 'gc'
Lorsque présent, l’attribut 'gc' est utilisé pour indiquer l’utilisation ou non du contrôle de gain. Il peut y avoir plusieurs lignes 'gc' dans une description SDP.

Le format de la ligne d’attribut du support 'gc' est le suivant :

a=gc:<fanionDirection><gcEnable><gcLvl>

<fanionDirection> peut recevoir les valeurs de chaîne suivantes : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrière. "fb" se réfère aux deux directions (vers l’avant et vers l’arrière). Les conventions pour vers l’avant et vers l’arrière sont celles du paragraphe 2.3.

Le fanion <fanionDirection> est toujours spécifié. Sauf pour le <fanionDirection>, les paramètres restants peuvent être réglés à "-" pour indiquer qu’ils ne sont pas spécifiés, inapplicables ou implicites. Cependant, il doit y avoir quelques paramètres spécifiés pour que la ligne soit utile dans une description SDP.

Si les lignes d’attribut du support 'gc' ne sont pas présentes, des moyens autres que le descripteur SDP doivent alors être utilisés pour déterminer l’applicabilité et la nature du contrôle de gain pour une direction de connexion. Des exemples de tels moyens sont le provisionnement d’une MIB, la structure d’options de connexion locale dans MGCP, etc.

Le paramètre <gcEnable> peut prendre les valeurs de "on" ou "off". À "on", le contrôle de gain est activé, à "off", il est désactivé.

Le paramètre <gcLvl> est représenté comme équivalent décimal ou hexadécimal d’un champ binaire de 16 bits. Une valeur de 0xFFFF implique un contrôle de gain automatique. Autrement, ce nombre indique le nombre de décibels de perte insérés. La limite supérieure, 65  535 dB (0xFFFE) de perte inséree, est un grand nombre qui a été importé de Megaco [26]. Dans les applications pratiques, la perte insérée est bien inférieure.

Lorsque SDP est utilisé avec des protocoles de contrôle de passerelle de support tels que MGCP et Megaco [26], il existe des moyens autres que les descriptions de SDP pour spécifier les propriétés de contrôle de gain d’une connexion. Néanmoins, cette ligne d’attribut de support est incluse pour être complet. Par suite, le SDP peut être utilisé pour décrire le contrôle de gain dans des applications où d’autres moyens pour cela ne sont pas disponibles.

5.6.3.5	Attribut 'profileDesc'
Il y a une ligne d’attribut de support 'profileDesc' pour chaque profil AAL2 qu’on a l’intention de décrire. La ligne d’attribut de support 'profileDesc' est structurée comme suit :

a=profileDesc: <aal2transport> <profile> <uuiCodeRange#1> <encodingName#1> <packetLength#1> <packetTime#1> <uuiCodeRange#2> <encodingName#2> <packetLength#2> <packetTime#2>... <uuiCodeRange#N> <encodingName#N> <packetLength#N> <packetTime#N>

Ici, <aal2transport> peut avoir les valeurs de <transport> (Tableau 1) qui relèvent de AAL2. Ce sont :
AAL2/ATMF
AAL2/UIT-T
AAL2/custom
AAL2/<corporateName>
AAL2/IEEE:<oui>

Le paramètre <profile> est identique à celui défini pour la ligne 'm' (paragraphe 5.5.4).

Les éléments de profil (des rangées des tableaux de profil de UIT-T I.366.2 ou AF-VTOA-0113) sont représentés comme des quadruplets qui suivent le paramètre <profile> dans la ligne d’attribut de support 'profileDesc'. Si un membre d’un de ces quadruplets n’est pas spécifié ou est implicite, il est alors réglé à "-".

Le paramètre <uuiCodeRange> est représenté par D1-D2, où D1 et D2 sont des entiers décimaux dans la gamme de 0 à 15.

Le paramètre <encodingName> peut prendre une des valeurs de la colonne 2 du Tableau 2. De plus, il peut prendre les chaîne de descripteur suivantes : "PCMG", "SIDG" et "SID729" qui signifient respectivement MIC générique, SID générique, et SID G.729.

<packetLength> est une représentation en entier décimal de la longueur du paquet AAL2 en octets.

<packetTime> est une représentation en entier décimal de l’intervalle de mise en paquet AAL2 en microsecondes.

Par exemple, la ligne d’attribut du support 'profileDesc' ci-dessous définit le profil 100 AAL2/personnalisé. Ce profil est reproduit dans le Tableau 3 ci-dessous. Pour une description des paramètres dans ce profil tels que M et l’intervalle de numéro de séquence, voir la Recommandation UIT-T I.366.2 [13].

a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1 5000 8-15 G726-32 40 10000 8-15 SIDG 1 5000

Si le paramètre <packetTime> doit être omis ou implicite, le même profil peut alors être représenté comme suit :

a=profileDesc:AAL2/custom 100 0-7 PCMG 40 - 0-7 SIDG 1 - 8-15 G726-32 40 - 8-15 SIDG 1 -

Si une passerelle a une définition provisionnée ou incorporée d’un profil, toute définition fournie via la ligne 'profileDesc' l’outrepasse. L’exception à cette règle est à l’égard des profils standard tels que ceux définis par l’UIT-T et ceux définis par l’ATMF. En général, ceux-ci ne devraient pas être définis via une ligne d’attribut de support 'profileDesc'. Si ils le sont, la définition doit alors être cohérente avec la définition standard sinon le descripteur de session SDP devrait être rejeté avec un code d’erreur approprié.

Tableau 3 : Exemple d’un profil AAL2 personnlisé

Gamme de codet UUI	Longueur de paquet (octets)	Codage selon UIT I.366.2 version 2/99	Description de l’algorithme	M	Temps de paquet (ms)	Intervalle de n° de séq. (ms)	
0-7	40	Figure B-1	MIC, G.711-64, générique	1	5	5	
0-7	1	Figure I-1	SID générique	1	5	5	
8-15	40	Figure E-2	MIC AD G.726-32	2	10	5	
8-15	1	Figure I-1	SID générique	1	5	5	

5.6.3.6	Attribut 'vsel'
L’attribut 'vsel' indique une liste rangée par priorité de un ou plusieurs triplets pour le service vocal. Chaque triplet indique un codec, une longueur de paquet facultative et une période facultative de mise en paquets. Cela complète les informations de la ligne 'm' et devrait être cohérent avec elle.

L’attribut 'vsel' se réfère à toutes les directions d’une connexion. Pour une connexion bidirectionnelle, ce sont vers l’avant et vers l’arrières. Pour une connexion unidirectionnelle, ce peut être vers l’arrière ou vers l’avant.

L’attribut 'vsel' n’est pas destiné à être utilisé avec des connexions bidirectionnelles qui ont des configurations de codec asymétriques décrites dans un seul descripteur SDP. Pour ceux-ci, l’attribut 'onewaySel' (paragraphe 5.6.3.9) devrait être utilisé. Voir au paragraphe 5.6.3.9 l’exigence de ne pas utiliser les attributs 'vsel' et 'onewaySel' dans le même descripteur SDP.

La ligne 'vsel' est structurée comme suit :

a=vsel:<encodingName #1> <packetLength #1><packetTime #1> <encodingName #2> <packetLength #2><packetTime #2>  ... <encodingName #N> <packetLength #N><packetTime #N>

où le paramètre <encodingName> peut prendre une des valeurs de la colonne 2 du Tableau 2. <packetLength> est un entier décimal qui représente la longueur du paquet en octets. <packetTime> est un entier décimal qui représente l’intervalle de mise en paquets en microsecondes. Les paramètres <packetLength> et <packetTime> peuvent être réglés à "-" lorsque ils ne sont pas nécessaires. La ligne d’attribut du support 'vsel' entière peut aussi être omise lorsque elle n’est pas nécessaire.

Par exemple,

a=vsel:G729 10 10000 G726-32 40 10000

indique en première préference G.729 ou G.729a (tous deux sont interopérables) comme schéma de codage vocal. Une longueur de paquet de 10 octets et un intervalle de mise en paquet de 10 ms sont associés à ce codec. G726-32 est la seconde préférence déclarée dans cette ligne, avec une longueur de paquet associée de 40 octets et un intervalle de mise en paquet de 10  ms. Si on a l’intention d’omettre la longueur de paquet et l’intervalle de mise en paquet, cette ligne d’attribut du support devient alors 

a=vsel:G729 - - G726-32 - -

La ligne d’attribut du support

a=vsel:G726-32 40 10000

indique la préférence ou le choix de MIC AD à 32 kbit/s avec une longueur de paquet de 40 octets et un intervalle de mise en paquets de 10 ms.

Cette ligne d’attribut de support peut être utilisée dans ATM ainsi que dans des contextes non ATM. Dans le contexte ATM, elle peut être appliquée aux adaptations AAL1, AAL2 et AAL5. <packetLength> et <packetTime> n’ont pas de sens dans le cas de AAL1 et devraient être réglés à "-". Dans le cas d’AAL2, cette ligne détermine l’utilisation de certaines ou de toutes les rangées d’un tableau de profil. Si plusieurs triplets sont présents, ils peuvent indiquer une allocation hiérarchique de certaines rangées dans ce profil au service vocal (par exemple, la rangée A est préférée à la rangée B, etc.). Si plusieurs profils sont présents sur la ligne 'm', le profil qualifié par cet attribut est le premier profil. Si un seul profil qui a été choisi pour une connexion est indiqué dans la ligne 'm', l’attribut 'vsel' qualifie l’utilisation, pour le service vocal, de codecs dans ce profil.

Avec la plupart des noms de codage de la Figure 2, la longueur de paquet et la période de mise en paquet peuvent être déduites l’une de l’autre. L’une d’elles peut être réglée à "-" sans perte d’information. Il y a quelques exceptions telles que les noms de codage enregistrés auprès de l’IANA G723, DVI4 et L16 pour lesquels ce n’est pas vrai. Donc, il est nécessaire de conserver à la fois la longueur de paquet et la période de mise en paquet dans la définition de la ligne 'vsel'.

5.6.3.7	Attribut 'dsel'
L’attribut 'dsel' indique une liste rangée par ordre de priorité d’un ou plusieurs triplets pour le service de données en bande vocale. Le fanion <fxIncl> indique si cette définition des données en bande vocale inclut la télécopie (valeur "on") ou non (valeur "off"). Si <fxIncl> est "on", la ligne 'dsel' doit alors être cohérente avec toute ligne 'fsel' de la description de session. En cas d’incohérence, un événement d’erreur est généré. Chaque triplet indique un codec, une longueur de paquet facultative et une période facultative de mise en paquets. Cela complète les informations de la ligne ‘m’ et devrait être cohérent avec elle.

L’attribut 'dsel' se réfère à toutes les directions d’une connexion. Pour une connexion bidirectionnelle, ce sont vers l’avant et vers l’arrière. Pour une connexion unidirectionnelle, ce peut être soit vers l’arrière soit vers l’avant.

L’attribut 'dsel' n’est pas destiné à être utilisé avec des connexions bidirectionnelles qui ont des configurations de codec asymétrique décrites dans un seul descripteur SDP. Pour ceux-ci, l’attribut 'onewaySel' (paragraphe 5.6.3.9) devrait être utilisé. Voir au paragraphe 5.6.3.9 l’exigence de ne pas utiliser les attributs 'dsel' et 'onewaySel' dans le même descripteur SDP.

La ligne 'dsel' est structurée comme suit :

a=dsel:<fxIncl> <encodingName #1> <packetLength #1><packetTime #1> <encodingName #2> <packetLength  #2> <packetTime #2> ... <encodingName #N> <packetLength #N><packetTime #N>

où le paramètre <encodingName> peut prendre une desvaleurs de la colonne 2 du Tableau 2. Les paramètres <packetLength> et <packetTime> sont selon leur définition, ci-dessus, pour la ligne d’attribut de support 'vsel'. Les paramètres <packetLength> et <packetTime> peuvent être réglés à "-" lorsque ils ne sont pas nécessaires. Le fanion <fxIncl> est présumé être à "off" si il est réglé à "-". La ligne d’attribut de support 'dsel' peut aussi être omise quand elle n’est pas nécessaire.

Par exemple,

a=dsel:-  G726-32 20 5000 PCMU 40 5000

indique que cette ligne ne concerne pas la télécopie, et que la première préférence pour le codec de données en bande vocale est le MIC AD à 32 kbit/s, tandis que la seconde préférence est le MIV loi mu. La longueur de paquet et l’intervalle de mise en paquet associés au G726-32 sont respectivement 20 octets et 5 ms. Pour le MIC loi mu, ce sont respectivement 40 octets et 5  ms.

Cette ligne d’attribut de support peut être utilisée dans ATM aussi bien que dans des contextes non ATM. Dans le contexte ATM, elle peut être appliquée aux adaptations AAL1, AAL2 et AAL5. <packetLength> et <packetTime> n’ont pas de signification dans le cas de AAL1 et devraient être réglés à "-". Dans le cas d’AAL2 , cette ligne détermine l’utilisation de certaines ou toutes les rangées dans un certain tableau de profil. Si plusieurs triplets sont présents, ils peuvent indiquer une allocation hiérarchique de certaines rangées de ce profil au service de données en bande vocale (par exemple, la rangée A est préférée à la rangée B, etc.). Si plusieurs profils sont présents sur la ligne 'm', le profil qualifié par cet attribut  est le premier profil. Si un seul profil qui a été choisi pour une connexion est indiqué dans la ligne 'm', l’attribut 'dsel' qualifie l’utilisation, pour le service de données en bande vocale, de codecs au sein de ce profil.

Avec la plupart des noms de codage de la Figure 2, la longueur de paquet et la période de mise en paquet peuvent être déduites l’une de l’autre. L’une d’elles peut être réglée à "-" sans perte d’information. Il y a des exceptions comme les noms de codage enregistrés par l’IANA G723, DVI4 et L16 pour lesquels ceci n’est pas vrai. Donc, il est nécessaire de conserver la longueur de paquet et la période de mise en paquet dans la définition de la ligne 'dsel'.

5.6.3.8 	Attribut 'fsel'
L’attribut 'fsel' indique une liste rangée par ordre de priorité d’un ou plusieurs triplets pour le service de télécopie. Si une ligne 'fsel' est présente, toute ligne 'dsel' avec <fxIncl> réglé à "on" dans la description de session doit être cohérente avec elle. Un événement d’erreur est généré dans le cas d’incohérence. Chaque triplet indique un codec, une longueur de paquet facultative et une période facultative de mise en paquets. Cela complète les informations de la ligne ‘m’ et devrait être cohérent avec elle.

L’attribut 'fsel' se réfère à toutes les directions d’une connexion. Pour une connexion bidirectionnelle, ce sont vers l’avant et vers l’arrière. Pour une connexion unidirectionnelle, cela peut être soit vers l’arrière, soit vers l’avant.

L’attribut 'fsel' n’est pas destiné à être utilisé avec des connexions bidirectionnelles qui ont des configurations de codec asymétrique décrites dans un seul descripteur SDP. Pour celles-ci, l’attribut 'onewaySel' (paragraphe 5.6.3.9) devrait être utilisé. Voir au paragraphe 5.6.3.9 l’exigence de ne pas utiliser les attributs 'fsel' et 'onewaySel' dans le même descripteur SDP.

La ligne 'fsel' est structurée comme suit :

a=fsel:<encodingName #1> <packetLength #1><packetTime #1> <encodingName #2> <packetLength #2><packetTime #2> ... <encodingName #N> <packetLength #N><packetTime #N>

où le paramètre <encodingName> peut prendre une des  valeurs de la colonne 2 du Tableau 2. Les paramètres <packetLength> et <packetTime> sont selon leur définition, ci-dessus, pour la ligne d’attribut de support 'vsel'. Les paramètres <packetLength> et <packetTime> peuvent être réglés à "-" lorsque ils ne sont pas nécessaires. La ligne d’attribut de support 'fsel' toute entière peut aussi être omise lorsque elle n’est pas nécessaire.

Par exemple,

a=fsel:FXDMOD-3 - -

indique la démodulation et la remodulation de la télécopie groupe 3 de l’UIT-T à la passerelle.

a=fsel:PCMU 40 5000 G726-32 20 5000

indique une première et une seconde préférence du MIC loi mu et du MIC AD à 32 kbit/s comme schéma de codage de télécopie. La longueur de paquet et l’intervalle de mise en paquet associés à G726-32 sont respectivement 20 octets et 5 ms. Pour le MIC loi mu, ce sont 40 octets et 5 ms.

Cette ligne d’attribut de support peut être utilisée dans l’ATM ainsi que dans des contextes non ATM. Dans le contexte ATM, elle peut être appliquée aux adaptations AAL1, AAL2 et AAL5 adaptations. <packetLength> et <packetTime> n’ont pas de sens dans le cas d’AAL1 et devraient être réglés à "-". Dans le cas de AAL2, cette ligne détermine l’utilisation de certaines ou de toutes les rangées d’un certain tableau de profil. Si plusieurs triplets sont présents, ils peuvent indiquer une allocation hiérarchique de certaines rangées de ce profil au service de télécopie (par exemple, la rangée A est préférée à la rangée B, etc.). Si plusieurs profils sont présents sur la ligne 'm', le profil qualifié par cet attribut est le premier profil. Si un seul profil qui a été choisi pour une connexion est indiqué dans la ligne 'm', l’attribut 'fsel' qualifie l’utilisation pour le service de télécopie des codecs au sein de ce profil.

Avec la plupart des noms de codage de la Figure 2, la longueur de paquet et la période de mise en paquet peuvent être déduites l’une de l’autre. L’une d’elles peut être réglée à "-" sans perte d’information. Il y a quelques exceptions comme les noms de codage enregistrés par l’IANA G723, DVI4 et L16 pour lesquels ce n’est pas vrai. Donc, il est nécessaire de conserver la longueur de paquet et la période de mise en paquet dans la définition de la ligne 'fsel'.

5.6.3.9	Attribut 'onewaySel'
L’attribut 'onewaySel' (une seule direction choisie) peut être utilisé avec les connexions qui ont des configurations de codec asymétriques. Il peut y avoir plusieurs lignes 'onewaySel' dans une description SDP. La ligne 'onewaySel' est structurée comme suit :

a=onewaySel:<serviceType> <directionFlag> <encodingName #1> <packetLength #1><packetTime #1> <encodingName #2> <packetLength #2><packetTime #2>  ... <encodingName #N> <packetLength #N><packetTime #N>

Le paramètre <serviceType> peut être alloué aux valeurs de chaînes suivantes : "v", "d", "f", "df" et "all". Elles indiquent respectivement la voix, les données en bande vocale (télécopie non comprise), la télécopie, les données en bande vocale (télécopie comprise) et tous services.

Le fanion <directionFlag> peut recevoir les valeurs de chaîne suivantes : "f", "b" et "fb". "f" et "b" indiquent respectivement vers l’avant et vers l’arrière. "fb" se réfère aux deux directions (vers l’avant et vers l’arrière) et ne devra pas être utilisé avec la ligne 'onewaySel'. Les conventions pour vers l’avant et vers l’arrière sont celles du paragraphe 2.3.

À la suite de <directionFlag>, il y a une liste rangée par ordre de priorité d’un ou plusieurs triplets. Chaque tripler indique un codec, une longueur de paquet facultative et une période facultative de mise en paquets. Cela complète les informations de la ligne ‘m’ et devrait être cohérent avec elle.

Au sein de chaque triplet, le paramètre <encodingName> peut prendre une des valeurs de la colonne 2 du Tableau 2. <packetLength> est une représentation en entier décimal de la longueur du paquet en octets. <packetTime> est une représentation en entier décimal de l’intervalle de mise en paquet en microsecondes.

L’attribut 'onewaySel' ne doit pas être utilisé dans les descripteurs SDP qui ont un ou plusieurs des attributs suivants : 'vsel', 'dsel', 'fsel'. Si il y est présent, la commande contenant la description SDP peut être rejetée. Une autre manière de répondre à un tel descripteur SDP mal formé serait d’ignorer sélectivement certains attributs, ce qui doit être coordonné via une politique à l’échelle de l’application.

Les paramètres <serviceType>, <directionFlag> et <encodingName> ne peuvent pas être réglés à "-". Cependant, les paramètres <packetLength> et <packetTime> peuvent être réglés à "-" lorsque ils ne sont pas nécessaires.

Par exemple,

a=onewaySel:v f G729 10 10000
a=onewaySel:v b G726-32 40 10000

indique que pour le service vocal, le codec à utiliser vers l’avant est G.729 ou G.729a (qui sont tous deux interopérables), et que le codec à utiliser vers l’arrière est G726-32. Une longueur de paquet de 10 octets et un intervalle de mise en paquet de 10  ms sont associés au codec G.729/G.729a. Une longueur de paquet de 40 octets et un intervalle de mise en paquet de 10  ms sont associés au codec G726-32.

Par exemple,

a=onewaySel:d f G726-32 20 5000
a=onewaySel:d b PCMU 40 5000

indique que pour le service en bande vocale (télécopie non incluse) le codec à utiliser vers l’avant est G726-32), et le codec à utiliser vers l’arrière est le MIC loi mu. Une longueur de paquet de 20 octets et un intervalle de mise en paquet de 5 ms sont associés au codec G726-32. Une longueur de paquet de 40 octets et un intervalle de mise en paquet de 5 ms sont associés au codec MIC loi mu.

Cette ligne d’attribut de support peut être utilisée dans ATM aussi bien que dans des contextes non ATM. Dans le contexte ATM, elle peut s’appliquer aux adaptations AAL1, AAL2 et AAL5. <packetLength> et <packetTime> n’ont pas de sens dans le cas d’AAL1 et devraient être réglés à "-". Dans le cas d’AAL2, ces lignes déterminent l’utilisation de certaines ou de toutes les rangées d’un certain tableau de profil. Si plusieurs triplets sont présents, ils peuvent indiquer une allocation hiérarchique de certaines rangées de ce profil au service vocal (par exemple, la rangée A est préférée à la rangée B, etc.). Si plusieurs profils sont présents sur la ligne 'm', le profil qualifié par cet attribut est le premier profil.

Dans la plupart des noms de codage de la Figure 2, la longueur de paquet et la période de mise en paquet peuvent être déduites l’une de l’autre. L’une d’elles peut être réglée à "-" sans perte d’information. Il y a quelques exceptions comme les noms de codage enregistrés par l’IANA G723, DVI4 et L16 pour lesquels ce n’est pas vrai. Il est donc nécessaire de conserver la longueur de paquet et la période de mise en paquet dans la définition de la ligne 'onewaySel'.

5.6.3.10	Attribut 'codecconfig'
Lorsque présent, l’attribut 'codecconfig' est utilisé pour représenter le contenu du seul élément d’information (IE) codec défini dans [57]. Le contenu de cet IE est : un champ Identifiant d’organisation (OID) d’un seul octet, suivi par un champ Type de codec d’un seul octet, suivi par zéro, un, ou plusieurs octets de la configuration binaire du codec. La sémantique de la configuration binaire du codec est spécifique de l’organisation [57], [58]. L’attribut 'codecconfig' est représenté comme suit :

a=codecconfig:<q7655scc>

Le paramètre <q7655scc> (contenu d’IE d’un seul codec Q.765.5) est représenté par une chaîne de chiffres hexadécimaux. Le nombre de chiffres hexadécimaux est pair (gamme de 4 à 32). Le préfixe "0x" devra être omis car cette valeur est toujours hexadécimale. Comme avec les autres valeurs hexadécimales [paragraphe 2.2], les chiffres de gauche sont de plus fort poids que les chiffres de droite. Les zéros en tête ne devront pas être omis.

Un exemple de l’utilisation de cet attribut de support est :

a=codecconfig:01080C

Le premier octet indique un identifiant d’organisation de 0x01 (l’UIT-T). En utilisant la Recommandation UIT-T Q.765.5 [57], le second octet (0x08) indique un type de codec de G.726 (MIC AD). Le dernier octet, 0x0C, indique que les débits de 16  kbit/s et 24 kbit/s NE SONT PAS pris en charge, tandis que les débits de 32 kbit/s et 40 kbit/s sont pris en charge.

5.6.3.11	Attribut 'isup_usi'
Lorsque présent, l’attribut 'isup_usi' est utilisé pour représenter l’élément d’information Capacité du support défini au paragraphe 4.5.5 de UIT-T Q.931 [59] (excluant l’identifiant et la longueur de l’élément d’information). Cet élément d’information est répété de l’élément d’information Service d’utilisateur du paragraphe 3.57 de UIT-T Q.763 [60]. L’attribut 'isup_usi' est représenté comme suit :

a=isup_usi:<isupUsi>

Le paramètre <isupUsi> est représenté par une chaîne de chiffres hexadécimaux. Le nombre de chiffres hexadécimaux est pair (la gamme permise est de 4 à 24). Le préfixe "0x" devra être omis car cette valeur est toujours hexadécimale. Comme avec les autres valeurs hexadécimales (paragraphe 2.2), les chiffres de gauche sont de plus fort poids que les chiffres de droite. Les zéros en tête ne devront pas être omis.

5.6.3.12	Attribut 'uiLayer1_Prot'
Lorsque présent, l’attribut 'uiLayer1_Prot' est utilisé pour représenter le champ 'Protocole de couche 1 d’informations d’utilisateur' au sein de l’élément d’information Capacités du support défini au paragraphe 4.5.5 de [59], et est répété de l’élément d’information Service d’utilisateur du paragraphe 3.57 de [60]. Le champ 'Protocole de couche 1 d’informations d’utilisateur' comporte les cinq bits de moindre poids de l’octet 5 de cet élément d’information.

Dans SDP, l’attribut 'uiLayer1_Prot' est représenté comme suit :

a='uiLayer1_Prot':<uiLayer1Prot>

Le paramètre <uiLayer1Prot> est représenté comme une chaîne de deux chiffres hexadécimaux. Le préfixe "0x" devra être omis car cette valeur est toujours hexadécimale. Comme avec les autres valeurs hexadécimales (paragraphe 2.2), les chiffres de gauche sont de plus fort poids que ceux de droite. Ces chiffres hexadécimaux sont construits à partir d’un octet avec trois bits '0' en tête et au moins cinq bits égaux au champ 'Protocole de couche 1 d’informations d’utilisateur' décrit ci-dessus. Comme spécifié dans [59] et [26], le bit 5 de ce champ est le bit de poids fort. Les valeurs résultantes du paramètre <uiLayer1Prot> sont comme suit :

Valeur	Signification
0x01	Adaption de débit normalisé CCITT V.110 et X.30
0x02	Recommandation G.711 Loi mu
0x03	Recommandation G.711 Loi A
0x04	MIC AD à 32 kbit/s de la Recommandation G.721 et  I.460
0x05	Recommandations H.221 et.242
0x06	Recommandation  H.223 et.245
0x07	Adaptation de débit non normalisée par l’UIT-T
0x08	Adaptation de débit normalisée par l’UIT-T V.120
0x09	Adaption de débit normalisé CCITT X.31 avec fanion HDLC

5.6.4	Divers attributs de supports
La ligne d’attribut de support 'chain', qui est utilisée pour enchaîner des descriptions de SDP consécutives, ne peut pas être classée comme un attribut ATM, AAL ou de service. Elle est détaillée dans les paragraphes suivants.

5.6.4.1	Attribut 'chain'
Le début d’un descripteur SDP est marqué par une ligne 'v'. Dans certaines applications, les descriptions de SDP consécutives sont des descriptions de remplacement de la même session. Dans d’autres, elles décrivent des couches différentes de la même connexion (par exemple, IP, ATM, relais de trame). C’est utile lorsque la connexité à ces couches est établie au même moment (par exemple, une sesssion fondée sur IP sur un SVC ATM). Pour distinguer entre les solutions de remplacement et l’enchaînement des descriptions SDP, un attribut 'chain' peut être utilisé dans le cas d’enchaînement.

Lorsque présent, l’attribut 'chain' lie une description SDP à la prochaine description SDP ou à la précédente. La description précédente ou suivante est séparée de l’actuelle par une ligne 'v'. Il n’est pas nécessaire que cette description ait aussi une ligne d’attribut de support 'chain'.

Le chaînage avertit du besoin d’établir une seule description SDP pour une session qui est créée simultanément à plusieurs couches. Cela permet que les descripteurs SDP pour les différentes couches restent simples et propres. Le chaînage n’est pas nécessaire dans le contexte Megaco, où il est possible de créer des terminaisons séparées pour les différentes couches d’une connexion.

La ligne d’attribut de support 'chain' a le format suivant :

a=chain:<chainPointer>

Le champ <chainPointer> peut prendre les valeurs de chaîne suivantes : "NEXT", "PREVIOUS" et "NULL". La valeur "NULL" n’est pas équivalente à l’omission de l’attribut de chaîne d’une description car elle exclut expressément la possibilité du chaînage. Si l’attribut 'chain' est absent d’une description SDP, le chaînage peut quand même être réalisé par la présence d’une ligne d’attribut de support ‘chain’ dans la description précédente ou suivante.

5.6.5	Utilisation de la seconde partie de niveau support dans les applications de l’annexe C de H.323
La Section 4 mentionne que les applications de l’Annexe 4 de la Recommandation UIT-T H.323 ont une seconde partie de niveau support pour la description de session ATM. Elle est utilisée pour convoyer les informations sur le flux RTCP. Bien que le flux RTP soit encapsulé dans AAL5 sans intervention de la couche IP, le flux RTCP est envoyé à une adresse IP et un accès RTCP. Cette partie de niveau support a le format suivant :
m= control <rtcpPortNum> H323c -
c= IN IP4 <rtcpIPaddr>

La cohérence avec la RFC2327 est conservée dans la localisation et le format de ces lignes. Le <fmt list> dans la ligne 'm' est réglé à "-". La ligne 'c' dans la seconde partie de niveau support ne relève que de RTCP.

Les sous paramètres <rtcpPortNum> et <rtcpIPaddr> indiquent le numéro d’accès et l’adresse IP sur lesquels la passerelle de supports est prête à recevoir les paquets RTCP.

Tous les sous paramètres de ces lignes peuvent être réglés à "-" si ils sont connus par d’autres moyens.

La gamme et le format des sous paramètres <rtcpPortNum> et <rtcpIPaddr> sont ceux de [1]. Le <rtcpPortNum> est un nombre décimal entre 1024 et 65  535. C’est un nombre impair. Si un nombre pair dans cette gamme est spécifié, le nombre impair suivant est utilisé. Le <rtcpIPaddr> est exprimé dans la représentation usuelle des adresses IP en décimal séparé par des points, de 0.0.0.0 à 255.255.255.255.

5.6.6	Utilisation de l’attribut eecid dans les procédures d’établissement d’appel
Ce paragraphe pour information complète la définition de l’attribut eecid (paragraphe 5.6.1.1) par la description d’exemples de ses procédures d’utilisation. Ces procédures supposent un mécanisme de signalisation du support pour l’établissement de la connexion qui soit indépendant du contrôle d’appel de niveau service. Ces procédures sont indépendantes du protocole de contrôle de la passerelle de support (MGCP, Megaco, SIP, etc.) le protocole utilisé entre les contrôleurs de passerelle de support (UIT-T Q.1901, SIP, etc.) et le protocole utilisé pour l’établissement de la connexion du support (Q.2931, UNI, PNNI, AINI, IISP, Q.2630.1, etc.).

                            Protocole
               +---------+  inter MGC       +---------+
               |   MGC   |------------------|   MGC   |
               +---------+                  +---------+
                    |                            |
                    |Protocole de contrôle       |Protocole de contrôle
                    |de passerelle de supports   |de passerelle de supports
                    |                            |
                +------------+  (Réseau ATM)    +--------------+
                |Passerelle  |------------------|Passerelle    |
                |de supports |  Protocole       |de supports   |
                |d’origine   | d’établissement  |de terminaison|
                +------------+ du support       +--------------+

Dans le diagramme ci-dessus, la passerelle de supports d’origine génère l’appel de niveau service. La passerelle de supports de terminaison le termine. Dans le modèle d’établissement de connexion de supports vers l’avant, la passerelle de supports d’origine initie l’établissement de la connexion des supports. Dans le modèle d’établissement de connexion de supports vers l’arrière, la passerelle de terminaison initie l’établissement de la connexion des supports.

Exemple d’utilisation du modèle d’établissement de connexion des supports vers l’arrière :

(1)	Le contrôleur de passerelle de supports d’origine (OMGC, originating media gateway controller) initie l’établissement de l’appel de niveau service par l’envoi du message de contrôle approprié à la passerelle de supports d’origine (OMG, originating media gateway).

(2)	L’OMG fournit son adresse NSAP et une valeur d’eecid à l’OMGC, en utilisant la description SDP suivante :
v=0
o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0
m=audio $ AAL2/UIT-T 8
a=eecid:B3D58E32

(3)	L’OMGC signale au contrôleur de passerelle de supports de terminaison (TMGC, terminating media gateway controller) par le mécanisme approprié (ISUP avec extensions Q.1901, SIP, etc.). Il fournit au TMGC l’adresse NSAP et le eecid fournis par l’OMG.

(4)	Le TMGC envoie le message de contrôle approprié à la TMG. Cela inclut le descripteur de session reçu de l’OMG. Ce descripteur contient l’adresse NSAP de l’OMG et l’eecid alloué par l’OMG. De plus, le TMGC donne pour instruction à la TMG d’établir un SVC avec l’OMG. Il demande aussi à la TMG de notifier au TMGC quand l’établissement du SVC sera achevé. Selon le protocole de contrôle utilisé, cela peut être fait par divers moyens. Dans le contexte Megaco, la demande d’établir un SVC (pas la demande de notification de l’événement d’établissement du SVC) peut être faite au moyen du descripteur local suivant :
v=0
o=- 2873397497 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC on

L’attribut 'bearerType' indique qu’un SVC doit être utilisé et que le fanion <localInitiation> est mis, c’est-à-dire que le SVC est à établir par la TMG.

(5)	La TMG accuse réception du message de contrôle provenant du TMGC. Elle retourne le descripteur SDP suivant avec l’accusé de réception :
v=0
o=- 2873397498 0 ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/UIT-T 8
Les informations d’adresse NSAP fournies dans ce descripteur ne sont pas nécessaires. Elles peuvent être omises (en les réglant à "- -").

(6)	La TMG envoie un message d’établissement d’un SVC à l’OMG. Au sein de l’élément d’information GIT, elle inclut l’eecid (B3D58E32) reçu de l’OMG.

(7)	L’OMG utilise l’eecid pour corréler la demande d’établissement du SVC avec le message de contrôle de niveau service reçu auparavant de l’OMGC.

(8)	L’OMG retourne un message de connexion de SVC à la TMG. À réception de ce message, la TMG envoie une notification d’événement au TMGC indiquant la réussite de l’établissement du SVC.

Noter que pour cet exemple, les lignes "v=", "o=", "s=" et "t=" peuvent être omises dans le contexte Megaco.

Exemple d’utilisation du modèle d’établissement de connexion des supports vers l’avant :

(1)	L’OMGC initie l’établissement d’appel de niveau service par l’envoi du message de contrôle approprié à l’OMG.

(2)	L’OMG fournit son adresse NSAP à l’OMGC, en utilisant la description SDP suivante :
v=0
o=- 2873397496 0 ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3E64.FD01.0060.3E64.FD01.00
t=0 0 
m=audio $ AAL2/UIT-T 8

Les informations d’adresse NSAP fournies dans ce descripteur ne sont pas nécessaires. Elles peuvent être omises (en les réglant à "- -").

(3)	L’OMGC le signale au TMGC par le mécanisme approprié (ISUP avec extensions Q.1901, SIP, etc.). Bien que ce ne soit pas nécessaire, il peut fournir au TMGC l’adresse NSAP fournie par l’OMG.

(4)	Le TMGC envoie le message de contrôle approprié à la TMG. Cela inclut le descripteur de session reçu de l’OMG. Ce descripteur contient l’adresse NSAP de l’OMG.

(5)	La TMG accuse réception du message de contrôle provenant du TMGC. Avec cet accusé de réception, elle fournit un descripteur SDP avec un eecid alloué en local.
v=0
o=- 2873397714 0 ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
s=-
c=ATM NSAP 47.0091.8100.0000.0040.2A74.EB03.0020.4421.2A04.00
t=0 0
m=audio $ AAL2/UIT-T 8
a=eecid:B3D58E32

(6)	Le TMGC le signale à l’OMGC par le mécanisme approprié (ISUP avec extensions Q.1901, SIP, etc.). Il fournit à l’OMGC l’adresse NSAP et l’eecid fournis par le TMG.

(7)	L’OMGC envoie le message de contrôle approprié à l’OMG. Cela inclut le descripteur de session reçu de la TMG. Ce descripteur contient l’adresse NSAP de la TMG et l’eecid alloué par la TMG. De plus, l’OMGC donne pour instruction à l’OMG d’établir un SVC vers la TMG. Il demande aussi à l’OMG de notifier à l’OMGC l’achèvement de l’établissement du SVC. Selon le protocole de contrôle utilisé, cela peut être fait par divers moyens. Dans le contexte Megaco, la demande d’établissement d’un SVC (pas la demande de notification de l’événement d’établissement du SVC) peut être faite au moyen du descripteur local suivant :
v=0
o=- 2873397874 0 ATM - -
s=-
c=ATM - -
t=0 0
m=audio $ - -
a=bearerType:SVC on

L’attribut 'bearerType' indique qu’un SVC doit être utilisé et que le fanion <localInitiation> est mis, c’est-à-dire que le SVC doit être établi par la TMG.

(8)	L’OMG accuse réception du message de contrôle provenant de l’OMGC.

(9)	L’OMG envoie un mesage d’établissement de SVC à la TMG. Dans l’élément d’information GIT, il inclut l’eecid (B3D58E32) reçu de la TMG.

(10)	La TMG utilise l’eecid pour corréler la demande d’établissement de SVC avec le mesage de contrôle de niveau service reçu auparavant du TMGC.

(11)	La TMG retourne un message de connexion de SVC à l’OMG. À réception de ce message, l’OMG envoie une notification d’événement à l’OMGC pour indiquer l’établissement réussi du SVC.

Noter que pour cet exemple, les lignes "v=", "o=", "s=" et "t=" peuvent être omises dans le contexte Megaco.

6.	Liste des paramètres avec représentations

Cette section donne la liste des paramètres utilisés dans le présent document, et les formats utilisés pour les représenter dans les descriptions SDP. En général, une valeur "-" peut être utilisée pour tout champ qui n’est pas spécifié, est inapplicable ou est implicite.

Paramètre	Signification	Représentation	
<username>	Nom d’utilisateur	constante "-".	
<sessionID>	Identifiant de session	jusqu’à 32 chiffres décimaux ou hexadécimaux.	
<version>	Version de descripteur SDP	"0" ou 10 chiffres décimaux.	
<networkType>	Type de réseau	constante "ATM" pour transport ATM.	
<adressType>	Type d’adresse	valeurs de chaîne : "NSAP", "E164", "GWID", "ALIAS"	
<address>	Adresse	"NSAP" : 40 chiffres hexadécimaux,
"E164" à points : jusqu’à 15 chiffres décimaux
"GWID" : jusqu’à 32 caractères
"ALIAS" : jusqu’à 32 caractères.	
<sessionName>	Nom de session	constante "-".	
<startTime>	Heure de début de session	"0" ou 10 chiffres décimaux.	
<stopTime>	Heure de fin de session	constante "0".	
<vcci>	Identifiant de connexion de circuit virtuel	équivalent décimal ou hex de 16 bits.	
<ex_vcci>	Représentation explicite de <vcci>	"VCCI-" préfixé à <vcci>.	
<bcg>	Groupe de connexion support	équivalent décimal ou hex de 8 bits.	
<ex_bcg>	Représentation explicite de <bcg>	"BCG-" préfixé en <bcg>.	
<portId>	Identifiant d’accès	nombre hexadécimal jusqu’à 32 chiffres.	
<ex_portId>	Représentation explicite de <portId>	"PORT-" préfixé en <portId>.	
<vpi>	Identifiant de chemin virtuel	équivalent décimal ou hex de 8 ou 12 bits.	
<ex_vpi>	Représentation explicite de <vpi>	"VPI-" préfixé en <vpi>.	
<vci>	Identifiant de circuit virtuel	équivalent décimal ou hex de 16 bits.	
<ex_vci> 	Représentation explicite de <vci>	"VCI-" préfixé en <vci>.	
<vpci>	Identifiant de connexion de chemin de circuit virtuel	équivalent décimal ou hex de 16 bits.	
<ex_vpci>	Représentation explicite de <vpci>	"VPCI-" préfixé en <vpci>.	
<cid>	Identifiant de canal	équivalent décimal ou hex de 8 bits.	
<ex_cid>	Représentation explicite de <cid>	"CID-" préfixé en <cid>.	
<payloadType>	Type de charge utile	entier décimal 0-127.	
<transport>	Transport	valeurs données au Tableau 1.	
<profile>	Profil	entier décimal de 1 à 255.	
<eecid>	Identifiant de connexion de bout en bout	jusqu’à 8 chiffres hexadécimaux.	
<aalType>	Type AAL	valeurs de chaîne : "AAL1", "AAL1_SDT", "AAL1_UDT", "AAL2", "AAL3/4", "AAL5", "USER_DEFINED_AAL".	
<asc>	Catégorie de service ATM définie par l’ATMF	valeurs de chaîne : "CBR", "nrt-VBR", "rt-VBR", "UBR", "ABR", "GFR".	
<atc>	Capacité de transfert ATM définie par l’IUT	valeurs de chaîne : "DBR", "SBR", "ABT/IT", "ABT/DT", "ABR".	
<subtype>	Sous type <asc>/<atc>	entier décimal de 1 à 10.	
<qosClass>	Classe de QS	entier décimal de 0 à 5.	
<bcob>	Classe de support haut débit	représentation décimale/hex d’un champ de 5 bits.	
<eetim>	Temporisation de bout en bout exigée	valeurs de chaîne : "on", "off".	
<stc>	Susceptibilité à la coupure	équivalent décimal d’un champ de 2 bits.	
<upcc>	Configuration de connexion de plan d’usager	équivalent décimal d’un champ de 2 bits.	
<directionFlag>	Fanion de direction	valeurs de chaîne : "f", "b", "fb".	
<cdvType>	Type de CDV	valeurs de chaîne : "PP", "2P".	
<acdv>	CDV acceptable	équivalent décimal d’un champ de 24 bits.	
<ccdv>	CDV cumulative	équivalent décimal d’un champ de 24 bits.	
<eetd>	Délai de transit de bout en bout	équivalent décimal d’un champ de 16 bits.	
<cmtd> 	Délai de transit cumulatif	équivalent décimal d’un champ de 16 bits.	
<aclr>	Taux de perte de cellule acceptable	équivalent décimal d’un champ de 8 bits.	
<clpLvl>	Niveau de CLP	valeurs de chaîne : "0", "0+1".	
<pcr>	Débit de crête de cellules	équivalent décimal d’un champ de 24 bits.	
<scr>	Débit de cellules soutenu	équivalent décimal d’un champ de 24 bits.	
<mbs>	Taille de salve maximum	équivalent décimal d’un champ de 16 bits.	
<cdvt>	CDVT	équivalent décimal d’un champ de 24 bits.	
<mcr>	Débit de cellules minimum	équivalent décimal d’un champ de 24 bits.	
<mfs>	Taille de salve maximum	équivalent décimal d’un champ de 16 bits.	
<fd>	Élimination de trame permise	valeurs de chaîne : "on", "off".	
<te>	Étiquetage de CLP	valeurs de chaîne : "on", "off".	
<nrm>	NRM	équivalent décimal/hex d’un champ de 3 bits.	
<trm>	TRM	-idem-	
<cdf>	CDF	-idem-	
<adtf>	ADTF	équivalent décimal/hex d’un champ de 10 bits.	
<ficr>	Débit de cellules initial vers l’avant	équivalent décimal d’un champ de 24 bits.	
<bicr>	Débit de cellules initial vers l’arrière	équivalent décimal d’un champ de 24 bits.	
<ftbe>	Exposition de mémoire tampon temporaire vers l’avant	équivalent décimal d’un champ de 24 bits.	
<btbe>	Exposition de mémoire tampon temporaire vers l’arrière	équivalent décimal d’un champ de 24 bits.	
<crmrtt>	Délai d’aller-retour de RM cumulative (microsecondes)	équivalent décimal d’un champ de 24 bits.	
<frif>	Facteur d’augmentation de débit vers l’avant	entier décimal  0 – 15.	
<brif>	Facteur d’augmentation de débit vers l’arrière	entier décimal  0 – 15.	
<frdf>	Facteur de diminution de débit vers l’avant	entier décimal 0 – 15.	
<brdf>	Facteur de diminution de débit vers l’arrière	entier décimal 0 – 15.
	
<bearerType>	Type de support	valeurs de chaîne : "PVC", "SVC", "CID".	
<localInitiation> 	Initiation locale	valeurs de chaîne : "on", "off".	
<sci>	Indication de passage à l’écran	équivalent décimal ou hex de 4 bits.	
<lsn>	Numéro de séquence de feuille	équivalent décimal ou hex de 32 bits.	
<cdStd>	Norme de codage de définition de choix de portée de connexion : UNI 4.0 [5]	équivalent décimal ou hex de 2 bits.	
<conScpTyp>	Définition de type de portée de connexion : UNI 4.0 [5]	équivalent décimal ou hex de 4 bits.	
<conScpSel>	Définition de choix de portée de connexion : UNI 4.0 [5]	équivalent décimal ou hex de 8 bits.	
<cacheEnable>	Permettre la mise en mémoire de SVC	valeurs de chaîne : "on", "off".	
<cacheTimer>	Temporisateur de suppression de SVC en mémoire	équivalent décimal ou hex de champ de 32 bits.	
<bearerSigIEType>	Type d’IE Signalisation de support	2 chiffres hexadécimaux.	
<bearerSigIELng>	Longueur d’IE Signalisation de support	1-4 chiffres hexadécimaux.	
<bearerSigIEVal>	Valeur d’IE Signalisation de support	nombre pair de chiffres hexadécimaux, 2 à 512.	
<appClass> 	Spécification d’application	valeurs de chaîne : "itu_h323c", "af83", "AAL5_SSCOP", "itu_i3661_unassured", "itu_i3661_assured", "itu_i3662", "itu_i3651", "itu_i3652", "itu_i3653", "itu_i3654", "FRF5", "FRF8", "FRF11", "itu_h2221".	
<oui>	Identifiant d’organisation unique 	1 à 6 chiffres hexadécimaux.	
<appId>	Identifiant d’application 	1 à 8 chiffres.	
<cbrRate>	Débit de CBR	deux chiffres hexadécimaux.	
<sbc>	Compte de sous canaux	T1 : entier décimal de 1 à 24 ou équivalent hex.
E1 : entier décimal de 1 à 31 ou équivalent hex.	
<clkrec>	Méthode de récupération d’horloge	valeurs de chaîne : "NULL", "SRTS", "ADAPTIVE".	
<fecEnable>	Correction d’erreur directe activée	valeurs de chaîne : "NULL", "LOSS_SENSITIVE" "DELAY_SENSITIVE".	
<partialFill>	Remplissage partiel	entier décimal de 1 à 48 ou équivalent hex.	
<structureEnable>	Structure présente	valeurs de chaîne : "on", "off".	
<blksz>	Taille de bloc	équivalent décimal ou hex de 16 bits.	
<cpcs>	Taille maximum de SDU CPCS	AAL5 : équivalent décimal ou hex de 16 bits .
AAL2 : représentation décimale ou hex de 45 ou 64.	
<cidLowerLimit>	Limite inférieure de CID AAL2	entier décimal 8-255 ou équivalent hex.	
<cidUpperLimit>	Limite supérieure de CID AAL2	entier décimal 8-255 ou équivalent hex.	
<timerCU>	Temporisateur, utilisation combinée (µs)	entier décimal ; gamme déterminée par l’application  : utilise l’équivalent décimal de 32 bits.	
<simplifiedCPS> 	CPS simplifiée [52]	valeurs de chaîne : "on", "off"	
<fSDUrate>	Taux de SDU vers l’avant (bits/s)	équivalent décimal d’un champ de 24 bits	
<bSDUrate>	Taux de SDU vers l’arrière (bits/s)	équivalent décimal d’un champ de 24 bits	
<ted>	Detection d’erreur de transmission active	valeurs de chaîne : "on", "off"	
<rastimer>	Réassemblage de SSSAR (µs)	entier décimal ; gamme déterminée par l’application  ; utilise l’équivalent décimal de 32 bits.	
<fsssar> 	Taille maximum de SSSAR-SDU, vers l’avant	Décimal de 1 à 65  568 ou équivalent hex.	
<bsssar>	Taille maximum de SSSAR-SDU, vers l’arrière	Décimal de 1 à 65  568 ou équivalent hex.	
<fsscopsdu>	Taille maximum de SSCOP-SDU, vers l’avant	Décimal de 1 à 65  568 ou équivalent hex.	
<bsscopsdu>	Taille maximum de SSCOP-SDU, vers l’arrière	Décimal de 1 à 65  568 ou équivalent hex.	
<fsscopuu>	Taille maximum de SSCOP-UU, vers l’avant	Décimal de 1 à 65  568 ou équivalent hex.	
<bsscopuu>	Taille maximum de SSCOP-UU, vers l’arrière	Décimal de 1 à 65  568 ou équivalent hex.	
<sap> 	Point d’accès de service	valeurs de chaîne : "AUDIO", "MULTIRATE".	
<circuitMode>	Mode circuit activé	valeurs de chaîne : "on", "off".	
<frameMode>	Mode trame activé	valeurs de chaîne : "on", "off".	
<faxDemod>	Démodulation de télécopie activée	valeurs de chaîne : "on", "off".	
<cas>	Transport CAS permis via paquets de type 3	valeurs de chaîne : "on", "off".	
<dtmf>	Transport DTMF permis via paquets de type 3	valeurs de chaîne : "on", "off".	
<mfall>	Transport MF permis via paquets de type  3	valeurs de chaîne : "on", "off".	
<mfr1>	Transport MF (R1) permis via paquets de type 3	valeurs de chaîne : "on", "off".	
<mfr2>	Transport MF (R2) permis via paquets de type 3.	valeurs de chaîne : "on", "off".	
<PCMencoding>	Codage MIC	valeurs de chaîne : "PCMA", "PCMU".	
<fmaxFrame>	Longueur maximum d’unité de données en mode trame, vers l’avant	équivalent décimal ou hex d’un champ de 16 bits.	
<bmaxFrame>	Longueur maximum d’unité de données en mode trame, vers l’arrière	-idem-	
<silenceSuppEnable>	Suppression de silence activée	valeurs de chaîne : "on", "off".	
<silenceTimer>	Temporisateur de début de suppression de silence	représentation décimale/hex d’un champ de 16 bits.	
<suppPref>	Méthode préférée de suppression de silence	valeurs de chaîne : "standard", "custom".	
<sidUse>	Méthode d’utilisation de SID	valeurs de chaîne : "No SID", "Fixed Noise", "Sampled Noise".	
<fxnslevel>	Niveau de bruit fixeé	représentation décimale/hex d’un champ de 7 bits.	
<ecanEnable>	Annulation d’écho activée	valeurs de chaîne : "on", "off".	
<ecanType>	Type d’annulation d’écho	valeurs de chaîne : "G165", "G168".	
<gcEnable>	Contrôle de gain activé	valeurs de chaîne : "on", "off".	
<gcLvl>	Niveau de perte inserée	équivalent décimal ou hex de champ de 16  bits	
<aal2transport>	Transport AAL2	valeurs du Tableau 1 commençant par la chaîne "AAL2".	
<uuiCodeRange> 	Gamme de code UUI	entier décimal 0-15.	
<encodingName> 	Nom de codage	valeurs de chaîne : "PCMG", "SIDG", "SID729", toute valeur de la colonne 2 du Tableau 2.	
<packetLength>	Longueur de paquet	entier décimal 0-45.	
<packetTime>	Intervalle de mise en paquet en µs.	entier décimal 1-65  536.	
<fxIncl>	Télécopie incluse	valeurs de chaîne : "on", "off".	
<serviceType>	Type de service	valeurs de chaîne : "v", "d", "f", "df", "all".	
<q7655scc>	Contenu de l’IE Q.765.5 Single Codec	nombre pair de chiffres hexadécimaux (4-32).	
<isupUsi>	Informations de service d’utilisateur ISUP	nombre pair de chiffres hexadécimaux (4-24).	
<uiLayer1Prot>	Protocole d’informations d’utilisateur de couche 1	deux chiffres hexadécimaux.	
<chainPointer>	Pointeur de chaîne	valeurs de chaîne : "NEXT", "PREVIOUS", "NULL".	
<rtcpPortNum>	Numéro d’accès RTCP pour applications de l’Annexe C de H.323	décimal impair dans la gamme 1  024 à 65  535  ; préféré : impair dans la gamme 49  152 à 65  535.	
<rtcpIPaddr>	Adresse IP de réception des paquets RTCP	décimal séparé par des points, 7 à 15 caractères.	

7.	Exemples de descriptions de session ATM utilisant SDP

Voici un exemple d’une description de session AAL1 complète en SDP :
v=0
o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL1/AVP 18 0 96
a=atmmap:96 X-G727-32
a=eecid:B3D58E32

Exemple d’une description de session AAL2 complète en SDP :
v=0
o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/UIT-T 8 AAL2/custom 100 AAL2/UIT-T 1
a=eecid:B3E32

Le descripteur de session AAL2 ci-dessous est le même que celui de ci dessus sauf qu’il déclare une préférence explicite pour un codec vocal, un codec de données en bande vocale et un codec de télécopie en bande vocale. De plus, il définit le profil AAL2/custom 100 plutôt que de supposer que l’extrémité distante connaît les éléments de ce profil.
v=0
o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=audio $ AAL2/UIT-T 8 AAL2/custom 100 AAL2/UIT-T 1
a=eecid:B3E32
a=profileDesc:AAL2/custom 100 0-7 PCMG 40 5000 0-7 SIDG 1 5000 8-15 G726-32 40 10000 8-15 SIDG 1 5000
a=vsel:G726-32 40 10000
a=dsel:off PCMU - -
a=fsel:G726-32 40 10000

Exemple d’un descripteur de session SDP pour un circuit virtuel commuté AAL5 pour la livraison de vidéos MPEG-2 :
v=0
o=- A3C47F21456789F0 0 ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
s=-
c=ATM NSAP 47.0091.8100.0000.0060.3e64.fd01.0060.3e64.fd01.00
t=0 0
m=video $ AAL5/UIT-T 33
a=eecid:B3E32
a=aalType:AAL5
a=bearerType:SVC on
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -

Exemple d’un descripteur de session SDP pour un circuit virtuel permanent AAL5 pour livrer de la vidéo MPEG-2 :
v=0
o=- A3C47F21456789F0 0 ATM - -
s=-
c=ATM - -
t=0 0
m=video PORT-$/VPI-0/VCI-$ AAL5/UIT-T 33
a=bearerType:PVC -
a=atmTrfcDesc:f 0+1 7816 - - - - - off -
a=atmTrfcDesc:b 0+1 0 - - - - - on -
a=cpsSDUsize:f 20680
a=aalApp:itu_h2221 - -

8.	Considérations sur la sécurité
8.1	Sécurité du support
Pour l’instant, il n’y a pas d’accord sur des moyens standard de chiffrement des supports ATM et AAL2 comme il en existe sur les moyens de chiffrer les charges utiles RTP, non plus que sur l’authentification de la signalisation de support ATM ou AAL2.

La ligne SDP de clé de chiffrement (k=) définie dans la RFC 2327 peut être utilisée pour représenter la clé de chiffrement et la méthode d’obtention de la clé. Dans les contextes ATM et AAL2, le terme 'support' peut inclure 'signalisation du support' aussi bien que 'charges utiles du support'.

8.2	Sécurité de la description SDP
Les descriptions de session SDP peuvent être générées dans des zones qui ne sont pas de confiance comme des équipements qui sont la possession d’utilisateurs finaux ou situés dans des locaux d’abonnés. SDP s’appuie sur les mécanismes de sécurité du protocole encapsulant ou de la couche en dessous du protocole encapsulant. Des exemples de protocoles encapsulants sont le protocole d’initialisation de session (SIP), MGCP et le protocole de contrôle de passerelle multimédia (MEGACO, Multimedia Gateway Control Protocol). Aucun autre mécanisme de sécurité supplémentaire n’est nécessaire. SIP, MGCP et MEGACO peuvent utiliser l’authentification IPsec décrite dans la RFC1826 [27]. Le chiffrement IPsec peut facultativement être utilisé avec l’authentification pour fournir un niveau de sécurité supplémentaire, potentiellement plus coûteux. Les associations de sécurité IPsec peuvent être faites entre des équipements situés dans des zones qui ne sont pas de confiance et des équipements situés dans des zones de confiance par des secrets partagés configurés ou l’utilisation d’une autorité de certificat.

9.	Grammaire du SDP ATM

Le présent appendice fournit une grammaire de BNF augmenté (ABNF) pour les conventions d’ATM pour SDP. L’ABNF est défini dans la RFC2234. Ce n’est pas une description d’ABNF complet de SDP. Le lecteur se reportera à [1] pour une description du protocole de base ABNF du SDP, et à la RFC2848, la RFC2543, la RFC2045 et la RFC2326 pour les conventions spécifiques d’application pour l’utilisation dans SDP. Pour les conventions de casse, voir le paragraphe 2.4.

; Définitions des constantes

safe = alpha-numeric / "'" / "-" / "." / "/" / ":" / "?" / DQUOTE / "#" / "$" / "&" / "*" / ";" / "=" / "@" / "[" / "]" / "^" / "_" / "`" / "{" / "|" / "}" / "+" / "~"
DQUOTE = %x22	; guillemets
alpha-numeric = ALPHA / DIGIT
ALPHA = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
DIGIT = "0" / POS-DIGIT
POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
hex-prefix = "0" ("x"  /  "X")
HEXDIG = DIGIT  /  "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F"
space = %d32
EOL = (CR / LF / CRLF)	; conformément à la RFC Megaco
CR = %d13
LF = %d10

decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))

generic-U8  = (hex-prefix hex-U8) / decimal-uchar
generic-U12 = (hex-prefix hex-U12) / 1*4 (DIGIT)
generic-U16 = (hex-prefix hex-U16) / 1*5(DIGIT)
generic-U24 = (hex-prefix hex-U24) / 1*8(DIGIT)
generic-U32 = (hex-prefix hex-U32) / 1*10(DIGIT)
hex-U8  = 1*2(HEXDIG)
hex-U12 = 1*3(HEXDIG)
hex-U16 = 1*4(HEXDIG)
hex-U24 = 1*6(HEXDIG)
hex-U32 = 1*8(HEXDIG)
generic-U8-or-null  = generic-U8 / "-"
generic-U12-or-null = generic-U12 / "-"
generic-U16-or-null = generic-U16 / "-"
generic-U24-or-null = generic-U24 / "-"
generic-U32-or-null = generic-U32 / "-"
decimal-U8-or-null =  decimal-uchar / "-"
decimal-U12-or-null = 1*4(DIGIT) / "-"
decimal-U16-or-null = 1*5(DIGIT) / "-"
decimal-U24-or-null = 1*8 (DIGIT) / "-"
decimal-U32-or-null = 1*10(DIGIT) / "-"
on-off-or-null = "on" / "off" / "-"

; définition ABNF de SDP avec conventions ATM

SDP-infoset    =  1*(announcement)announcement  =  proto-version
origin-field   session-name-field   information-field   uri-field
email-fields   phone-fields   connection-field bandwidth-fields
time-fields key-field attribute-fields media-descriptions

proto-version = ["v=" 1*4(DIGIT) EOL]	; on utilise "v=0" pour le SDP ATM.

origin-field = ["o=" username space sess-id space sess-version space net-type-addr EOL]

username = 1* safe ; for ATM use "-"

sess-id = (1*32 DIGIT) / (hex-prefix 1*32 HEXDIG)
sess-version = (1*10 DIGIT) / (hex-prefix 1*8 HEXDIG)

net-type-addr= nettype space addrtype-addr

netttype = "ATM" / "IN" / "TN" / "-" / "$"

 ; D’autres valeurs de nettype peuvent être définies à l’avenir dans d’autres documents.
 ; La validité de la combinaison de nettype et de addrtype-addr est à vérifier au niveau application, non au niveau de la syntaxe du protocole.

addrtype-addr = atm-addrtype-addr / ip-addrtype-addr / tn-addrtype-addr
	; ip-addrtype-addr selon la RFC2327
	; tn-addrtype-addr selon la RFC2848

; Définition d’adresse ATM

atm-addrtype-addr =  atm-nsap-addr / atm-e164-addr / atm-alias-addr

atm-nsap-addr = ("NSAP" / "-" / "$")  space (nsap-addr / "-" / "$")
atm-e164-addr = ("E164" / "-" / "$") space (e164-addr / "-" / "$")
atm-alias-addr = ("GWID" / "ALIAS" / "-" / "$") space (alias-addr / "-" / "$")

nsap-addr = 2(HEXDIG) "." 9(4(HEXDIG) ".") 2(HEXDIG)

e164-addr = 1*15 (DIGIT)
alias-addr = 1*32(alpha-numeric / "-" / "." / "_")

session-name-field = ["s=" text EOL]	; pour l’usage d’ATM, "s=-"
text = byte-string
byte-string = 1*(byte-string-char) 	; définition selon la RFC2327
byte-string-char = %x01-09/ %x0B/ %x0C/ %x0E-FF	; Tous caractères ASCII sauf NUL, CR & LF.

; Les définitions de information-field, uri-field, email-fields, phone-fields sont selon la RFC2327. Ces champs sont omis dans
; les descriptions de SDP ATM. Si ils sont reçus, ils sont ignorés dans le contexte ATM.

connection-field = ["c=" c-net-type-addr]	; connection-field est exigé, et n’est pas facultatif dans ATM.

c-net-type-addr = nettype space c-addrtype-addr
c-addrtype-addr = atm-addrtype-addr / c-ip-addrtype-addr / tn-addrtype-addr
	; atm-addrtype-addr est défini plus haut.
	; c-ip-addrtype-addr selon la RFC2327
	; la différence d’usage de Adresse entre les lignes 'o' et 'c' selon la RFC2327
	; tn-addrtype-addr selon la RFC2848

bandwidth-fields = *("b=" bwtype ":" bandwidth EOL)

bwtype = 1*(alpha-numeric)
bandwidth = 1*(DIGIT)

time-fields = *( "t=" start-time space stop-time
              *(EOL repeat-fields) EOL)
              [zone-adjustments EOL]
start-time = time / "0"
stop-time = time / "0" 	; toujours "0" dans ATM.
time = POS-DIGIT 9*(DIGIT)	; même chose que la RFC2327
	; repeat-fields et zone-adjustments selon la RFC2327, non utilisé dans ATM.
	; la définition de key-field facultaiti selon la RFC2327

attribute-fields = *("a=" attribute EOL)

; Les descripteurs SDP pour ATM n’ont pas de ligne d’attribut du support au niveau session. Si il en est fourni, elles devraient
; être ignorées.

media-descriptions = *(media-description)
media-description  = media-field information-field *(connection-field) bandwidth-fields key-field attribute-fields

; La définition de information-field est selon la RFC2327. Ces champs sont omis dans les description SDP d’ATM. Si ils sont
; reçus, ils sont ignorés dans le contexte ATM.
; Dans ATM, connection-field est utilisé dans la description du support pour indiquerl’adresse IP associée au protocole de
; contrôle RTCP dans  les appliactions H.323.C. Dans ce cas, le champ Connection est selon la définition de la RFC2327 pour
; les connexions fondées sur IP v4. Autrement, il n’est pas utilisé dans la description du support. Si il est reçu au titre de la
; description du support,; il est ignoré.
; La définition des champs facultatifs de bande passante est donnée plus haut.
: La définition du champ facultatif key-field est celle de la RFC2327

media-field = rfc2327-media-field / rfc2848-media-field / atm-media-field
; Les champs rfc2327-media-field et rfc2848-media-field sont définis dans ces RFC.

atm-media-field = "m=" media space vcId space transport-fmts EOL
; surensemble de la définition de la RFC2327.

media = "audio" / "video" / "data" / "application" / "control" / 1*(alpha-numeric)

vcId = "$" / "-" / ex-vcci / (ex-vcci "/" ex-cid) / (atm-type-addr-m  "/" ex-vcci) /

     (atm-type-addr-m "/" ex-vcci "/" ex-cid) /
     (ex-bcg "/" ex-vcci) / (ex-bcg "/" ex-vcci "/" ex-cid)
     (ex-portid "/" ex-vpi "/" ex-vci) /
     (ex-portid "/" ex-vpi "/" ex-vci "/" ex-cid) /
     (ex-bcg "/" ex-vpi "/" ex-vci) /
     (ex-bcg "/" ex-vpi "/" ex-vci "/" ex-cid) /
     (ex-vpci "/" ex-vci) /
     (ex-vpci "/" ex-vci "/" ex-cid) /
     (atm-type-addr-m  "/" ex-vpci "/" ex-vci) /
     (atm-type-addr-m  "/" ex-vpci "/" ex-vci "/" ex-cid)

atm-type-addr-m = atm-nsap-addr-m / atm-e164-addr-m / atm-alias-addr-m
atm-nsap-addr-m =  ["NSAP-"] (nsap-addr / "$")
atm-e164-addr-m =  ["E164-"] (e164-addr / "$")
atm-alias-addr-m = ["GWID-" / "ALIAS-"] (alias-addr / "$")
; Le -m en fin indique l’utilisation dans le champ media.
; Les règles d’utilisation de caractères génériques diffèrent de celle de l’adresse ATM sur les lignes 'o' et 'c'.

ex-vcci    = "VCCI-"  vcci
ex-cid     = "CID-"   cid
ex-bcg     = "BCG-"   bcg
ex-portid  = "PORT-"  portid
ex-vpi     = "VPI-"   vpi
ex-vci     = "VCI-"   vci
ex-vpci    = "VPCI-"  vpci

vcci   = generic-U16
cid    = generic-U8
bcg    = generic-U8
portid = 1*32 (HEXDIG)
vpi    = generic-U12
vci    = generic-U16
vpci   = generic-U16

transport-fmts = generic-transport-fmts / known-transport-fmts / "- -"
generic-transport-fmts = generic-transport 1*(space fmt)
generic-transport = 1*(alpha-numeric / "/")
fmt = 1*(alpha-numeric)

known-transport-fmts = aal1-transport space aal1-fmt-list / aal2-transport space aal2-fmt-list                       *(space aal2-transport space aal2-fmt-list) / aal5-transport space aal5-fmt-list /
                       rtp-transport space rtp-fmt-list / tn-proto space tn-fmt-list / h323c-proto "-"
h323c-proto = "H323c"

; h323c-proto est utilisé pour les accès de contrôle RTCP dans les applications de l’Annexe C de H.323.
;  tn-proto et tn-fmt-list sont selon la RFC2848

aal1-transport = "AAL1" "/" aal1-transport-list
aal1-transport-list = "ATMF" / "UIT-T" / "custom" / "IEEE:" oui / corporate-name
corporate-name = 1*(safe)
aal2-transport = "AAL2" "/" aal2-transport-list
aal2-transport-list = aal1-transport-list
aal5-transport = "AAL5" "/" aal5-transport-list
aal5-transport-list = aal1-transport-list
rtp-transport = "RTP" "/" rtp-transport-list
rtp-transport-list = "AVP"

aal1-fmt-list = (payload-type *(space payload-type)) / "-"
payload-type = decimal-uchar
aal5-fmt-list = aal1-fmt-list
rtp-fmt-list = aal1-fmt-list
aal2-fmt-list = (profile *(space profile)) / "-"
profile = decimal-uchar
attribute-fields = *("a=" attribute EOL)
attribute = known-attribute / (generic-att-field ":" att-value) / generic-att-field
generic-att-field = 1*(alpha-numeric)
att-value = byte-string
known-attribute = atm-attribute / PINT-attribute / rfc2327-attribute
         ; PINT-attribute comme défini dans la RFC2848.
         ; rfc2327-attribute comme défini dans cette RFC.

atm-attribute =
      "eecid" ":" eecid /
      "aalType" ":" aalType /
      "capability" ":" (asc / atc) space subtype /
      "qosclass" ":" qosclass /
      "bcob" ":" bcob space eetim /
      "stc" ":" stc /
      "upcc" ":" upcc /
      "atmQOSparms" ":" directionFlag space cdvType space acdv space ccdv space eetd space cmtd space aclr /
      "atmTrfcDesc" ":" directionFlag space clpLvl space pcr space scr space mbs space cdvt space mcr space mfs space fd space te /
      "abrParms" ":" directionFlag  space nrm space trm space cdf space adtf /
      "abrSetup" ":" ficr space bicr space ftbe space btbe space crmrtt space frif space brif space frdf space brdf /
      "bearertype" ":" bearerType space localInitiation  /
      "lij" ":" sci space lsn /
      "anycast" ":" atmGroupAdresse space cdStd space conScpTyp space conScpSel /
      "cache" ":" cacheEnable space cacheTimer /
      "bearerSigIE" ":" bearerSigIEType space bearerSigIELng space bearerSigIEVal /
      "aalApp" ":" appClass space oui space appId /
      "cbrRate" ":" cbrRate /
      "sbc" ":" sbc /
      "clkrec" ":" clkrec /
      "fec" ":" fecEnable /
      "prtfl" ":" partialFill /
      "structure" ":" structureEnable space blksz /
      "cpsSDUsize" ":" directionFlag space cpcs /
      "aal2CPS" ":" cidLowerLimit space cidUpperLimit space timerCU space simplifiedCPS /
      "aal2CPSSDUrate" ":" fSDUrate space bSDUrate /
      "aal2sscs3661unassured" ":" ted space rastimer space fsssar space bsssar /
      "aal2sscs3661assured" ":" rastimer space fsssar space bsssar
           space fsscopsdu space bsscopsdu space fsscopuu space bsscopuu  /
      "aal2sscs3662" ":" sap space circuitMode space frameMode
           space faxDemod space cas space dtmf space mfall space mfr1
           space mfr2 space PCMencoding space fmaxFrame space bmaxFrame /
      "aal5sscop" ":" fsscopsdu space bsscopsdu space fsscopuu space bsscopuu  /
      "atmmap" ":" payload-type space encoding-name /
      "silenceSupp" ":" silenceSuppEnable space silenceTimer space suppPref space sidUse space fxnslevel /
      "ecan" ":" directionFlag space ecanEnable space ecanType /
      "gc" ":" directionFlag space gcEnable space gcLvl /
      "profileDesc" ":" aal2-transport space profile space 1*(profile-row) /
      "vsel" ":" 1*(encoding-name space packet-length space packet-time space) /
      "dsel" ":" fxIncl space 1*(encoding-name space packet-length space packet-time space) /
      "fsel" ":" 1*(encoding-name space packet-length space packet-time space) /
      "onewaySel" ":" serviceType space directionFlag space
                 1*(encoding-name space packet-length space packet-time space) /
      "codecconfig" ":" q7655scc /
      "isup_usi" ":" isupUsi /
      "uiLayer1_Prot" ":" uiLayer1Prot /
      "chain" ":" chainPointer

eecid =  8 (HEXDIG)
aalType = "AAL1" / "AAL2" / "AAL3/4" / "AAL5" / "USER_DEFINED_AAL"
asc = "CBR" / "nrt-VBR" / "rt-VBR" / "UBR" / "ABR" / "GFR"
atc = "DBR" / "SBR" / "ABT/IT" / "ABT/DT" / "ABR"
subtype = decimal-U8-or-null
qosclass = decimal-U8-or-null
bcob = generic-U8
eetim = on-off-or-null
stc = decimal-uchar
upcc = decimal-uchar
directionFlag = "f" / "b" / "fb"cdvType = "PP" / "2P" / "-"
acdv = decimal-U32-or-null
ccdv = decimal-U32-or-null
eetd = decimal-U16-or-null
cmtd = decimal-U16-or-null
aclr = decimal-U8-or-null
clpLvl = "0" / "0+1" / "-"
pcr = decimal-U24-or-null
scr = decimal-U24-or-null
mbs = decimal-U16-or-null
cdvt = decimal-U24-or-null
mcr = decimal-U24-or-null
mfs = decimal-U16-or-null
fd = on-off-or-null
te = on-off-or-null
nrm = generic-U8-or-null
trm = generic-U8-or-null
cdf = generic-U8-or-null
adtf = generic-U16-or-null
ficr = decimal-U24-or-null
bicr = decimal-U24-or-null
ftbe = decimal-U24-or-null
btbe = decimal-U24-or-null
crmrtt = decimal-U24-or-null
frif = 1*2 (DIGIT)
brif = 1*2 (DIGIT)
frdf = 1*2 (DIGIT)
brdf = 1*2 (DIGIT)
bearerType =  "PVC" / "SVC" / "CID"
localInitiation = on-off-or-null
sci = generic-U8-or-null
lsn = generic-U32-or-null
atmGroupAdresse = atm-type-addr
cdStd = generic-U8-or-null
conScpTyp = generic-U8-or-null
conScpSel = generic-U8-or-null
cacheEnable = on-off-or-null
cacheTimer = generic-U32-or-null
bearerSigIEType = 2 * (HEXDIG)
bearerSigIELng = 1*4 (HEXDIG)
bearerSigIEVal = 2*512 (HEXDIG)
appClass =  "-" / "itu_h323c" / "af83" / "AAL5_SSCOP" / "itu_i3661_unassured" / "itu_ i3661_assured"/ "itu_i3662"/ "itu_i3651" / "itu_i3652" / "itu_i3653" / "itu_i3654" / "FRF11" / "FRF5" / "FRF8" / "itu_h2221"
oui = "-" / 1*6 (HEXDIG)
appId = "-" / 1*8 (HEXDIG)
cbrRate = 2 (HEXDIG)
sbc = generic-U8
clkrec = "NULL" / "SRTS" / "ADAPTIVE"
fecEnable = "NULL" / "LOSS_SENSITIVE"  / "DELAY_SENSITIVE"
partialFill = generic-U8
structureEnable = on-off-or-null
blksz = generic-U16-or-null
cpcs = generic-U16
cidLowerLimit = generic-U8-or-null
cidUpperLimit = generic-U8-or-null
timerCU = decimal-U32-or-null
simplifiedCPS = on-off-or-null
fSDUrate = decimal-U24-or-null
bSDUrate = decimal-U24-or-null
ted = on-off-or-null
rastimer = decimal-U32-or-null
fsssar = generic-U24-or-null
bsssar = generic-U24-or-null
fsscopsdu = generic-U16-or-null
bsscopsdu = generic-U16-or-null
fsscopuu = generic-U16-or-null
bsscopuu = generic-U16-or-null
sap = "AUDIO" / "MULTIRATE" / "-"
circuitMode = on-off-or-null
frameMode = on-off-or-null
faxDemod = on-off-or-null
cas = on-off-or-null
dtmf = on-off-or-null
mfall = on-off-or-null
mfr1 = on-off-or-null
mfr2 = on-off-or-null
PCMencoding = "PCMA" / "PCMU" / "-"
fmaxframe = generic-U16-or-null
bmaxframe = generic-U16-or-null
silenceSuppEnable = on-off-or-null
silenceTimer = generic-U16-or-null
suppPref = "standard" / "custom" / "-"
sidUse = "No SID" / "Fixed Noise" / "Sampled Noise" / "-"
fxnslevel = generic-U8-or-null
ecanEnable = on-off-or-null
ecanType = "G165" / "G168" / "-"
gcEnable = on-off-or-null
gcLvl = generic-U16-or-null

profile-row  = uuiCodeRange space encoding-name space packet-length space packet-time space
uuiCodeRange = decimal-uchar "-" decimal-uchar / "-"
encoding-name = "-" / "PCMG" / "SIDG" / "SID729" / "PCMU" / "G726-32" / "G723" / "PCMA" / "G722" / "G728" /
                "G729" / "X-G729a" / "X-G729b" / "X-G729ab" / "X-G726-16" / "X-G726-24" / "X-G726-40" / "X-G7231-H" /
                "X-G7231-L" / "X-G7231a-H" / "X-G7231a-L" / "X-G727-16" / "X-G727-24" / "X-G727-32" / "X-CCD" / 
                "X-CCD-CAS" / "GSM" / "GSM-HR" / "GSM-EFR" / "GSM-EHR" / "X-FXDMOD-3" / "1016" / "DVI4" / 
                "L16" / "LPC" / "MPA" / "QCELP" / "H263" / "H263-1998" / "JPEG" / "H261" / "MPV" / "MP2T" / "nv" / 
                "RED" / "CelB" / "L8" / "VDVI" / "MP1S" / "MP2P" / "BT656" / "FR-AMR" / "HR-AMR" / "UMTS-AMR" / "AMR"
packet-length = decimal-U8-or-null
packet-time = decimal-U16-or-null
fxIncl = on-off-or-null
serviceType = "v" / "d" / "f" / "df" / "all"
q7655scc = 4*32 (HEXDIG)
isupUsi = 4*24 (HEXDIG)
uiLayer1Prot = 2 (HEXDIG)

chainPointer = "NEXT" / "PREVIOUS" / "NULL"

Références

[1]	[RFC2327] M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)

[2]	[RFC1889] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64) 

[3]	[RFC1890] H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", janvier 1996. (Obsolète, voir RFC3551) (P.S.)

[4]	"ATMF UNI 3.1 Specification",  af-uni-0010.002. Le paragraphe 5.4.5.5 de ce document, "ATM Adaptation Layer Parameters" est d’un intérêt particulier pour le présent document.

[5]	"ATMF UNI 4.0 Signaling Specification", af-sig-0061.000.

[6]	"ATMF Traffic Management Specification", Version 4.1, af-tm-0121.000.

[7]	"ATMF Circuit Emulation Service (CES) Interoperability Specification", version 2.0, af-vtoa-0078.000, janvier 97.

[8]	"ATMF Voice and Telephony over ATM - ATM Trunking using AAL1 for Narrowband Services", version 1.0, af-vtoa-0089.000, juillet 1997.

[9]	ATMF Specifications of (DBCES) Dynamic Bandwidth Utilization - in 64kbit/s Timeslot Trunking over ATM  - using CES, af-vtoa-0085.000, juillet 1997.

[10]	Recommandation UIT-T I.363.1, "B-ISDN ATM Adaptation Layer Specification: Type 1 AAL", août 1996.

[11]	Recommandation UIT-T I.363.2, "B-ISDN ATM Adaptation Layer Specification: Type 2 AAL", septembre 1997.

[12]	Recommandation UIT-T I.366.1, "Segmentation and Reassembly Service Specific Convergence Sublayer  for AAL Type 2", juin 1998.

[13]	Recommandation UIT-T I.366.2, "AAL Type 2 Reassembly Service Specific Convergence Sublayer for Trunking", février 1999.

[14]	[RFC2833] H. Schulzrinne, S. Petrack, "Charge utile RTP pour chiffres DTMF, tonalités téléphoniques et signaux téléphoniques", mai 2000. (Obsolète, voir RFC4733, RFC4734) (P.S.)

[15]	Recommandation UIT-T Q.2931, "B-ISDN Application Protocol for Access Signaling".

[16]	Amendements 1, 2, 3 et 4 à la Recommandation UIT-T Q.2931, "B-ISDN Application Protocol for Access Signaling".

[17]	[RFC2974] M. Handley, C. Perkins, E. Whelan, "Protocole d'annonce de session (SAP)", octobre 2000. (Expérimentale)

[18]	[RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP : protocole d'initialisation de session", mars  1999. (Obsolète, voir RFC3261, RFC3262, RFC3263, RFC3264, RFC3265) (P.S.)

[19]	[RFC1349] P. Almquist, "Type de service dans la suite de protocole Internet", juillet 1992. (Obsolète, voir RFC2474)

[20]	[RFC2474] K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ par RFC3168, RFC3260) (P.S.)

[21]	Recommandation UIT-T I.363.5, "B-ISDN ATM Adaptation Layer Specification: Type 5 AAL", août 1996.

[22]	ATMF PNNI 1.0, af-pnni-0055.000, mars 1996.

[23]	[RFC3550] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160)

[24]	[RFC3551] H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003.

[25]	[RFC2705] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Protocole de contrôle de passerelle support (MGCP) version 1.0", octobre 1999. (Obsolète, voir RFC3435) (MàJ par RFC3660) (Information)

[26]	[RFC3015] F. Cuervo et autres, "Protocole Megaco version 1.0", novembre 2000. (Obsolète, voir RFC3525) (P.S.)

[27]	[RFC1826] R. Atkinson, "En-tête d'authentification IP", août 1995. (Obsolète, voir la RFC2402)

[28]	Recommandation UIT-T I.371, "Traffic Control and Congestion Control in the BISDN".

[29]	Recommandation UIT-T E.191, "BISDN Numbering and Adresseing".

[30]	ATM Forum "Adresseing: Reference Guide", af-ra-0106.000.

[31]	http://www.iana.org/assignments/rtp-parameters donne la liste des codecs avec les types de charge utile statiques.

[32]	Recommandation UIT-T Q.2941-2, "Digital Subscriber Signalling System No. 2 (DSS 2): Generic identifier transport extensions".

[33]	Recommandation UIT-T Q.2961, "Digital subscriber signalling system no.2 (DSS 2) - additional traffic parameters". Aussi, Amendement 2 à la Recommandation UIT-T Q.2961.

[34]	Recommandation UIT-T Q. 2965.1, "Digital subscriber signalling system no.2 (DSS 2) - Support of Quality of Service classes".

[35]	Recommandation UIT-T Q. 2965.2, "Digital subscriber signalling system no.2 (DSS 2) - Signalling of individual Quality of Service parameters".

[36]	Recommandation UIT-T Q.1901, "Bearer Independent Call Control Protocol".

[37]	Recommandation UIT-T Q.2630.1, "AAL type 2 signaling protocol - capability set 1".

[38]	Recommandation UIT-T I.363.5, "B-ISDN ATM Adaptation Layer specification: Type 5 AAL".

[39]	Recommandation UIT-T I.365.1, "Frame relaying service specific convergence sublayer (FR-SSCS)".

[40]	Recommandation UIT-T I.365.2, "B-ISDN ATM adaptation layer sublayers: service specific  coordination function to provide the connection oriented network service".

[41]	Recommandation UIT-T I.365.3, "B-ISDN ATM adaptation layer sublayers: service specific coordination function to provide the connection-oriented transport service".

[42]	Recommandation UIT-T I.365.4, "B-ISDN ATM adaptation layer sublayers: Service specific convergence sublayer for HDLC applications".

[43]	Recommandation UIT-T Q.2110, "B-ISDN ATM adaptation layer - service specific connection oriented protocol (SSCOP)".

[44]	af-vtoa-0113.000, "ATM trunking using AAL2 for narrowband services".

[45]	Recommandation UIT-T H.323-2, "Packet-based multimedia communications systems".

[46]	af-vtoa-0083.000, "Voice and Telephony Over ATM to the Desktop".

[47]	Recommandation UIT-T I.356, "BISDN ATM layer cell transfer performance".

[48]	Recommandation UIT-T Q.2957, "Digital Subscriber Signaling System No. 2, User to user signaling".

[49]	[RFC1305] D. Mills, "Protocole de l'heure du réseau, version 3, spécification, mise en œuvre et analyse", STD 12, mars  1992. (Remplacée par RFC5905)

[50]	TIA/EIA/IS-J-STD-025-A, "Lawfully Authorized Electronic Surveillance", mai 2000.

[51]	Recommandation UIT-T H.222.1, "Multimedia multiplex and synchronization for audiovisual communication in ATM environments".

[52]	af-vmoa-0145.000, "Voice and Multimedia over ATM, Loop Emulation Service using AAL2".

[53]	FRF.5, "Frame Relay/ATM PVC Network Interworking Implementation Agreement".

[54]	FRF.8.1, "Frame Relay/ATM PVC Service Interworking Implementation Agreement".

[55]	FRF.11, "Voice over Frame Relay Implementation Agreement".

[56]	[RFC2234] D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[57]	Recommandation UIT-T Q.765.5, "Application Transport Mechanism - Bearer Independent Call Control".

[58]	http://www.3gpp.org/ftp/Specs pour les spécifications relatives au 3GPP, y compris les codecs AMR.

[59]	Recommandation UIT-T Q.931, "Digital Subscriber Signaling System No. 1: Network Layer".

[60]	Recommandation UIT-T Q.763, "SS7 - ISUP formats and codes"

[61]	ATM Forum, "Well-known Adressees and assigned codes". http://www.atmforum.com/atmforum/specs/specs.html

[62]	[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

Remerciements

Les auteurs tiennent à remercier plusieurs collègues de Cisco et de l’industrie qui ont contribué au développement des présentes conventions SDP, et qui ont révisé, mis en œuvre et essayé ces constructions. Des idées techniques précieuses qui ont été incorporées dans ce document Internet ont été fournies par Hisham Abdelhamid, Flemming Andreasen, David Auerbach, Robert Biskner, Bruce Buffam, Steve Casner, Alex Clemm, Bill Foster, Snehal Karia, Raghu Thirumalai Rajan, Joe Stone, Bruce Thompson, Dan Wing et Ken Young de Cisco, Michael Brown, Rade Gvozdanovic, Graeme Gibbs, Tom-PT Taylor, Mark Watson et Sophia Scoggins de Nortel Networks, Brian Rosen, Tim Dwight et Michael Mackey de Marconi, Ed Guy et Petros Mouchtaris de Telcordia, Christian Groves de Ericsson, Charles Eckel de Vovida Networks, Tom Jepsen, Dal Chohan, Sagar Gordhan et Chris Gallon de Fujitsu, Mahamood Hussain de Hughes Software Systems et Sean Sheedy de nCUBE Corporation, Narendra Tulpule de Intel, Albrecht Schwarz de Alcatel, et Jonathan Rosenberg de Dynamicsoft. Les auteurs souhaitent aussi remercier le groupe de contrôle des appareils ISC, et les sous-groupes MMUSIC et MEGACO de l’IETF, en particulier Bill Foster, Joerg Ott, Sean Sheedy et Brian Rosen pour leur aide à la préparation de ce document. Finalement, des remerciements sont dus à Narendra Tulpule de Intel dont la grammaire ABNF a été adaptée pour ce document.

Adresse des auteurs

Rajesh Kumar	Mohamed Mostafa	
Cisco Systems, Inc.	Cisco Systems, Inc.	
M/S SJC01/3	M/S SJC01/3	
170 West Tasman Drive	170 West Tasman Drive	
San Jose, CA 95134-1706	San Jose, CA 95134-1706	
téléphone : 1-800-250-4800	téléphone : 1-800-250-4800	
mél : rkumar@cisco.com	mél : mmostafa@cisco.com 	

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2001). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.