RTP : protocole de transport - RFC

More documents

Recommendations

Info

RFC 3550 page - 44 - Schulzrinne & autresunsigned int version:2; /* version du protocole */unsigned int p:1; /* fanion de bourrage */unsigned int count:5; /* varie selon le type de paquet */unsigned int pt:8; /* type de paquet RTCP */u_int16 length; /* longueur de paquet en mots, w/o ce mot */} rtcp_common_t;/** gabarit gros boutien pour la version, paire bit de bourrage et type de paquet*/#define RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)#define RTCP_VALID_VALUE ((RTP_VERSION
RFC 3550 page - 45 - Schulzrinne & autres/* BYE */struct {u_int32 src[1]; /* liste des sources *//* on ne peut exprimer le texte de cause en queue */} bye;} r;} rtcp_t;typedef struct rtcp_sdes rtcp_sdes_t;/** informations d'état par source*/typedef struct {u_int16 max_seq; /* plus fort numéro de séquence rencontré */u_int32 cycles; /* compte glissant de cycles de numéros de séquence */u_int32 base_seq; /* numéro de séquence de base */u_int32 bad_seq; /* dernier 'mauvais' numéro de séquence + 1 */u_int32 probation; /* paquets en séquence depuis que la source est valide */u_int32 received; /* paquets reçus */u_int32 expected_prior; /* paquets attendus au dernier intervalle */u_int32 received_prior; /* paquets reçus au dernier intervalle */u_int32 transit; /* temps de transit relatif pour le paquet précédent */u_int32 jitter; /* gigue estimée *//* ... */} source;A.1 Vérifications de validité des en-têtes de données RTPUn receveur RTP devrait vérifier la validité de l'en-tête RTP sur les paquets entrants car ils pourraient être chiffrés oupourraient provenir d'une application différente après avoir été mal adressés. De même, si le chiffrement est activéconformément à la méthode décrite à la Section 9, la vérification de validité de l'en-tête est nécessaire pour vérifier que lespaquets entrants ont été correctement déchiffrés, bien qu'un échec de la vérification de validité de l'en-tête (par exemple, untype de charge utile inconnu) puisse ne pas indiquer nécessairement un échec du déchiffrement.Seules des vérifications de validité faibles sont possibles sur un paquet de données RTP provenant d'une source qui n'avaitpas été entendue auparavant :o le champ de version RTP doit être égal à 2 ;o le type de charge utile doit être connu, et en particulier il doit n'être pas égal à SR ou RR ;o si le bit P est mis, le dernier octet du paquet doit alors contenir un compte d'octets valide, en particulier, moins que lalongueur totale de paquet moins la taille d'en-tête ;o le bit X doit être à zéro si le profil ne spécifie pas que le mécanisme d'extension d'en-tête peut être utilisé. Autrement, lechamp Longueur d'extension doit être inférieur à la taille totale de paquet moins la longueur d'en-tête fixe et debourrage ;o la longueur du paquet doit être cohérente avec CC et type de charge utile (si la charge utile a une longueur connue).Les trois dernières vérifications sont un peu complexes et pas toujours possibles, ce qui ne laisse que les deux premières quine totalisent que peu de bits. Si l'identifiant de SSRC dans le paquet est un qui a été reçu auparavant, le paquet est alorsprobablement valide et vérifier si le type de charge utile est dans la gamme attendue donne une confirmation de validation.Si l'identifiant de SSRC n'a jamais été vu auparavant, les paquets de données qui portent cet identifiant peuvent alors êtreconsidérés comme invalides jusqu'à ce qu'un petit nombre d'entre eux arrivent avec des types de charge utile consécutifs.Ces paquets invalides PEUVENT être éliminés ou ils PEUVENT être mémorisés et délivrés une fois que la validation auraété réalisée si le délai résultant est acceptable.Le sous-programme update_seq indiqué ci-dessous assure qu'une source est déclarée valide seulement après queMIN_SEQUENTIAL paquets ont été reçus en séquence. Il valide aussi le type de charge utile seq d'un paquetnouvellement reçu et met à jour l'état de séquence pour la source du paquet dans la structure vers laquelle il pointe.Lorsque une nouvelle source est entendue pour la première fois, c'est-à-dire, lorsque l'identifiant de SSRC n'est pas dans letableau (voir au paragraphe 8.2) et que l'état par source est alloué pour lui, s->probation est mis au nombre de paquets
Page 1 and 2: RFC 3550 page - 1 - Schulzrinne & a
Page 11 and 12: RFC 3550 page - 11 - Schulzrinne &
Page 43: RFC 3550 page - 43 - Schulzrinne &

RTP : protocole de transport - RFC

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?