RTP : protocole de transport - RFC

RFC 3550 page - 26 - Schulzrinne & autresLes éléments de SDES actuellement définis sont décrits dans les paragraphes suivants. Seul l'élément CNAME estobligatoire. Certains éléments présentés ici peuvent n'être utiles que pour des profils particuliers, mais les types d'élémentssont tous alloués à partir d'un espace commun pour favoriser l'utilisation partagée et pour simplifier les applicationsindépendantes du profil. Des éléments supplémentaires peuvent être définis dans un profil en enregistrant les numéros detype auprès de l'IANA comme décrit à la Section 15.6.5.1 CNAME : Élément SDES d'identifiant de point d'extrémité canonique0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1CNAME=1 longueur nom d'utilisateur et de domaineL'identifiant de CNAME a les propriétés suivantes :ooooComme l'identifiant de SSRC alloué de façon aléatoire peut changer si un conflit est découvert ou si un programme estredémarré, l'élément CNAME DOIT être inclus pour fournir le lien de l'identifiant de SSRC à un identifiant pour lasource (d'envoyeur ou de receveur) qui reste constant.Comme l'identifiant de SSRC, l'identifiant de CNAME DEVRAIT aussi être unique parmi tous les participants au seind'une session RTP.Pour fournir un lien à travers plusieurs outils de support utilisés par un participant dans un ensemble de sessions RTP enrapport, le CNAME DEVRAIT être fixe pour ce participant.Pour faciliter la surveillance par un tiers, le CNAME DEVRAIT convenir aussi bien pour qu'un programme ou qu'unepersonne localise la source.Donc, le CNAME DEVRAIT être déduit par un algorithme et non entré manuellement, lorsque possible. Pour satisfaire cesexigences, le format suivant DEVRAIT être utilisé sauf si un profil spécifie une autre syntaxe ou sémantique. L'élémentCNAME DEVRAIT avoir le format "user@host" ou "host" si un nom d'utilisateur n'est pas disponible comme sur lessystèmes à un seul utilisateur. Pour les deux formats, "host" est soit le nom de domaine pleinement qualifié de l'hôte d'oùproviennent les données en temps réel, formaté conformément aux règles spécifiées dans les RFC 1034 [6], RFC 1035 [7]et au paragraphe 2.1 de la RFC 1123 [8] ; ou la représentation standard ASCII de l'adresse numérique de l'hôte surl'interface utilisée pour la communication RTP. Par exemple, la représentation standard ASCII d'une adresse IP version 4est en "décimal séparé par des points", et pour IP version 6, les adresses sont textuellement représentées comme desgroupes de chiffres en hexadécimal séparés par deux points (avec les variations détaillées dans la RFC 3513 [23]). D'autrestypes d'adresses sont prévus pour avoir des représentations ASCII qui sont mutuellement uniques. Le nom de domainepleinement qualifié est plus pratique pour un observateur humain et peut éviter d'avoir besoin d'envoyer en plus un élémentNAME, mais il peut être difficile voire impossible de l'obtenir de façon fiable dans certains environnements defonctionnement. Les applications qui pourraient fonctionner dans de tels environnements DEVRAIENT utiliser à la place lareprésentation ASCII de l'adresse.Pour un système multi utilisateurs, des exemples sont "doe@sleepy.example.com", "doe@192.0.2.89" ou"doe@2201:056D::112E:144A:1E24". Sur un système sans nom d'utilisateur, des exemples seraient "sleepy.example.com","192.0.2.89" ou "2201:056D::112E:144A:1E24".Le nom d'utilisateur DEVRAIT être sous une forme qu'un programme tel que "finger" ou "talk" puisse utiliser, c'est-à-dire,c'est normalement le nom de connexion plutôt qu'un nom de famille. Le nom de l'hôte n'est pas nécessairement identique àcelui de l'adresse de messagerie électronique du participant.Cette syntaxe ne va pas fournir des identifiants univoques pour chaque source si une application permet à un utilisateur degénérer plusieurs sources à partir d'un hôte. Une telle application devrait s'appuyer sur le SSRC pour identifier la source, oule profil pour cette application devrait spécifier une syntaxe supplémentaire pour l'identifiant de CNAME.Si chaque application crée indépendamment son CNAME, les CNAME résultants peuvent n'être pas identiques comme ilserait exigé pour fournir un lien à travers plusieurs outils de supports appartenant à un participant dans un ensemble desession RTP s'y rapportant. Si un lien inter-supports est exigé, il peut être nécessaire que le CNAME de chaque outil soitconfiguré en externe avec la même valeur par un outil de coordination.Les auteurs d'applications devraient être conscients que les allocations d'adresse de réseau privé telles que les allocations deNet-10 proposées dans la RFC 1918 [24] peuvent créer des adresses réseau qui ne sont pas uniques au monde. Cela