Types de supports MIME pour les objets ISUP et QSIG

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 types MIME pour les objets application/ISUP et application/QSIG à utiliser dans les applications SIP, conformément aux règles définies dans la RFC 2048. Ces types peuvent être utilisés pour identifier les objets ISUP et QSIG au sein d’un message SIP tel que INVITE ou INFO, qui pourraient être mis en œuvre lorsque on utilise SIP dans un environnement où une partie de l’appel implique un interfonctionnement avec le RTPC.

1. Introduction

Le sous-système utilisateur RNIS (ISUP, ISDN User part) défini dans la Recommandation UIT-T Q.761-4 est un protocole de signalisation utilisé entre les commutateurs téléphoniques. Il y a des configurations dans lesquelles des informations de signalisation codées en ISUP doivent être transportées entre des entités SIP au titre de la charge utile des messages SIP, lorsque la préservation des données ISUP est nécessaire pour le bon fonctionnement des caractéristiques du RTPC.

QSIG est le protocole de signalisation analogue utilisé entre les commutateurs privés pour prendre en charge les appels au sein des réseaux de téléphonie privés. Il y a un besoin similaire de transporter les informations de signalisation codées en QSIG entre les entités SIP dans certains environnements.

Le présent document est spécifique de cet usage et ne s’appliquerait pas au transport des messages ISUP ou QSIG dans d’autres applications. Ces types de supports sont destinés aux informations d’applications ISUP ou QSIG qui sont utilisées au sein du contexte d’une session SIP, et non comme transport général de signalisation SCN.

La définition des types de support pour les informations d’application ISUP et QSIG ne concerne pas comment les entités non SIP et les entités SIP qui échangent des messages déterminent ou négocient la compatibilité. On suppose que ceci est traité par d’autres moyens comme la configuration des fonctions d’interfonctionnement.

Ceci est destiné à être un type MIME approuvé par l’IETF, et à être défini par une RFC.

Note : l’usage de QSIG au sein de SIP n’est ni approuvé ni recommandé par suite de cet enregistrement MIME.

3. Nouveaux types de support proposés

Les messages ISUP et QSIG sont composés de données binaires arbitraires qui sont transparentes pour le traitement SIP. La meilleure façon de les coder est d’utiliser le codage binaire. Ceci est conforme aux restrictions imposées à l’utilisation de données binaires pour MIME ([RFC2045]). On notera que les règles mentionnées dans la RFC2045 s’appliquent aux messages Internet et non aux messages SIP. Le codage binaire a été préféré au Base64 parce que ce dernier résulterait seulement à ajouter de la longueur aux messages codés et serait éventuellement plus coûteux en termes de puissance de calcul.

3.1 Type de support ISUP

Ce type de support est défini par les informations suivantes :

Nom du type de support : application

Nom de sous-type de support : ISUP

Paramètres exigés : version

Paramètres facultatifs : base

Schéma de codage : binary

Considérations pour la sécurité : Voir la section 5.

Le message ISUP est encapsulé en commençant par le code de type de message (c’est-à-dire, en omettant l’étiquette d’acheminement et le code d’identifiant de circuit).

L’utilisation du paramètre 'version' permet aux administrateurs de réseau d’identifier les versions spécifiques d’ISUP qui vont être échangées sur une base bilatérale. Cela permet à un client particulier comme un commutateur logiciel ou un contrôleur de passerelle de supports de reconnaître et analyser correctement le message, ou (éventuellement) de rejeter le message si la version ISUP spécifiée n’est pas acceptée. La présente spécification ne fait peser aucune contrainte sur les valeurs qui peuvent être utilisées dans 'version' ; elles sont laissées à la discrétion de l’administrateur de réseau.

Cette 'version' pourrait, par exemple, être utilisée pour identifier une mise en œuvre d’ISUP spécifique du réseau, par exemple, X-NetxProprietaryISUPv3, ou pour identifier une version standard bien connue d’ISUP, par exemple, itu-t ou ansi.

Un paramètre 'base' peut facultativement être inclus dans certains cas (par exemple, si le receveur pourrait ne pas reconnaître la chaîne 'version') pour spécifier que l’ISUP encapsulé peut aussi être traité en utilisant la spécification 'base' identifiée. Le Tableau 1 donne une liste des valeurs de 'base' acceptées par le type de support 'application/ISUP', incluant si le mécanisme de compatibilité de transmission défini dans l’ISUP UIT-T 1992 est pris en charge.

Tableau 1 : Valeurs de 'base' ISUP

base protocole compatibilité

itu-t88 ITU-T Q.761-4 (1988) non

itu-t92+ ITU-T Q.761-4 (1992) oui

ansi88 ANSI T1.113-1988 non

ansi00 ANSI T1.113-2000 oui

etsi121 ETS 300 121 non

etsi356 ES 300 356 oui

gr317 BELLCORE GR-317 non

ttc87 JT-Q761-4(1987-1992) non

ttc93+ JT-Q761-4(1993-) oui

L’en-tête Content-Disposition [RFC2183] peut être inclus pour décrire comment l’ISUP encapsulé doit être traité, et en particulier ce que devrait être le traitement si le type de contenu reçu n’est pas reconnu. Le type de disposition par défaut pour un corps de message ISUP est "signal". Ce type indique que la partie de corps contient des informations de signalisation associées à la session, mais ne décrit pas la session.

Le BNF suivant complète la description de l’en-tête Content-Disposition de la [RFC2183], ainsi que la caractérisation de l’en-tête Content-Disposition dans la norme SIP, décrivant les types de disposition et les paramètres de disposition qui peuvent être utilisés dans l’en-tête des corps MIME ISUP et QSIG.

Content-Disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-param )

disposition-type = "signal" | disp-extension-token

disposition-param = "handling" "=" ( "optional" | "required" | other-handling ) | generic-param

other-handling = jeton

disp-extension-token = jeton

Une définition complète de l’utilisation du paramètre "handling" est données dans la section 6, Considérations relatives à l’IANA. Voici comment un en-tête normal serait constitué ('base' peut être omis):

Content-Type: application/ISUP; version=nxv3; base=etsi121

Content-Disposition: signal; handling=optional

3.2 Type de support QSIG

Le type de support application/QSIG est défini par les informations suivantes :

Nom de type de support : application

Nom de sous-type de support : QSIG

Paramètres exigés : aucun

Paramètres facultatifs : version

Schéma de codage : binary

Considérations pour la sécurité : Voir la section 5.

L’utilisation du paramètre 'version' permet l’identification des différentes variantes de QSIG. Cela permet au serveur de terminaison de connexion de reconnaître et analyser correctement le message, ou (éventuellement) de le rejeter si la variante QSIG particulière n’est pas prise en charge.

Le Tableau 2 est une liste des versions de protocole acceptées par le type de support 'application/QSIG'.

Tableau 2 : versions QSIG

version protocole

iso ISO/IEC 11572 (Appel de base) et ISO/IEC 11582 (Protocole fonctionnel générique)

Voici à quoi devrait normalement ressembler un en-tête (Content-Disposition n’est pas inclus dans cette instance) :

Content-Type: application/QSIG; version=iso

Le type de disposition de Content-Disposition par défaut est "signal" comme dans une partie de corps ISUP. Le paramètre "handling" décrit plus haut peut aussi être utilisé pour les corps QSIG.

4. Illustration par un exemple

4.1 ISUP

Le format de message SIP exige une ligne Request, suivie de lignes d’en-tête, suivies par un séparateur CRLF, suivi par le corps du message. Pour illustrer l’utilisation du type de support 'application/ISUP', on propose ci-dessous un message INVITE qui a les informations du SDP d’origine et un IAM ISUP encapsulé.

Noter que les deux charges utiles sont démarquées par le paramètre boundary (spécifié dans la [RFC2046]) qui dans l’exemple a la valeur "unique-boundary-1". Ceci fait partie de la spécification de MIME multipart et ne se rapporte pas au type de support 'application/ISUP'.

INVITE sip:13039263142@Den1.level3.com SIP/2.0

Via: SIP/2.0/UDP den3.level3.com

From: sip:13034513355@den3.level3.com

To: sip:13039263142@Den1.level3.com

Call-ID: DEN1231999021712095500999@Den1.level3.com

CSeq: 8348 INVITE

Contact: <sip:jpeterson@level3.com>

Content-Length: 436

Content-Type: multipart/mixed; boundary=unique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=ISO-10646

v=0

o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4

s=SDP seminar

c=IN IP4 MG122.level3.com

t= 2873397496 2873404696

m=audio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-Type: application/ISUP; version=nxv3;

base=etsi121

Content-Disposition: signal; handling=optional

01 00 49 00 00 03 02 00 07 04 10 00 33 63 21

43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63

53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b

0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00

--unique-boundary-1--

Note : Comme le codage binary est utilisé pour la charge utile ISUP, chaque octet est codé comme un octet, et non comme une représentation hexadécimale sur deux caractères. Les chiffres Hex ont été utilisés dans le document parce qu’un codage littéral de ces octets aurait été perturbant et illisible.

4.2 QSIG

Pour illustrer l’utilisation du type de support 'application/QSIG', voici un message INVITE qui a les informations de SDP d’origine et un messages QSIG SETUP encapsulé.

Noter que les deux charges utiles sont démarquées par le paramètre boundary (spécifié dans la [RFC2046]) qui dans l’exemple a la valeur "unique-boundary-1". Cela fait partie de la spécification de MIME multipart et ne se rapporte pas au type de support 'application/QSIG'.

INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=unique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=ISO-10646

v=0

o=audet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=SDP seminar

c=IN IP4 MG141.nortelnetworks.com

t= 2873397496 2873404696

m=audio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=iso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

5. Considérations sur la sécurité

Les informations contenues dans les corps ISUP et QSIG peuvent inclure des informations d’utilisateur sensibles, exigeant éventuellement l’utilisation du chiffrement.

Les mécanismes de sécurité sont exposés dans la [RFC2543] (protocole d’initialisation de session SIP) et devraient être utilisées comme approprié aussi bien pour le message SIP que le corps ISUP ou QSIG encapsulé.

6. Considérations relatives à l’IANA

Le présent document enregistre les types de support MIME "application/ISUP" et "application/QSIG".

Les enregistrements pour les symboles 'version' utilisés dans les types MIME ISUP et QSIG doivent spécifier une référence de spécification définitive, identifiant une question particulière de la spécification, à laquelle le nouveau symbole devra se référer. Identifier une référence de spécification définie exige un processus de revue ; les auteurs recommandent qu’un expert de la question soit désigné comme décrit dans la [RFC2434] sous la rubrique révision par un expert.

Noter que si une spécification est pleinement rétro compatible avec une question précédente (c’est-à-dire, si le mécanisme de compatibilité est pris en charge par les deux) il n’y a alors pas besoin d’enregistrer des symboles séparés. Le symbole pour la spécification d’origine devrait être utilisé pour identifier aussi les mises à jour rétro compatibles de cette spécification.

Les symboles qui commencent par le caractère 'X-' sont réservés pour un usage non standard (par exemple, les cas dans lesquels un jeton autre qu’une chaîne représentant une question d’une spécification ISUP est approprié pour caractériser ISUP au sein d’un domaine administratif). Une telle version non standard peut seulement être transmise entre des domaines administratifs conformément à un accord bilatéral. Ces symboles devraient être administrés dans le cadre de la politique d’utilisation privée décrite dans la [RFC2434].

Le présent document enregistre un nouveau type de disposition pour l’en-tête Content-Disposition, 'signal', à utiliser lorsque un corps MIME contient des informations de signalisation supplémentaires (ISUP et QSIG comme corps MIME en étant des exemples).

Le présent document définit aussi un paramètre de Content Disposition, "handling". Le paramètre de traitement, handling-parm, décrit comment l’UAS devrait réagir si il reçoit un corps de message dont il ne comprend pas le type de contenu ou le type de disposition. Si le paramètre a la valeur "optional", l’UAS DOIT ignorer le corps de message ; si il a la valeur "required", l’UAS DOIT retourner 415 (Type de support non pris en charge). Si le paramètre de traitement manque, la valeur "required" doit être supposée.

7. Adresse des auteurs

M. Watson

Nortel Networks

Maidenhead, UK

mél : mwatson@nortelnetworks.com

8. Références

[RFC2045] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 1 : Format des corps de message Internet", novembre 1996. (D. S., MàJ par 2184, 2231, 5335.)

[RFC2046] N. Freed et N. Borenstein, "Extensions de messagerie Internet multi-objets (MIME) Partie 2 : Types de support", novembre 1996. (D. S., MàJ par 2646, 3798, 5147, 6657.)

[RFC2048] N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)

[RFC2183] R. Troost, S. Dorner, K. Moore, éd., "Communication des informations de présentation dans les messages Internet : le champ d'en-tête Contenu-disposition", août 1997. (MàJ par RFC2184, RFC2231) (P.S.)

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[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.)

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 y 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 violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

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