5. Uso di RTCP da parte di endpoint che inviano flussi di media multipli

RTCP è definito nella Sezione 6 di [RFC3550]. La descrizione del protocollo è formulata in termini del comportamento dei "partecipanti" in una sessione RTP, partendo dall'assunzione che ogni endpoint sia un partecipante con un singolo SSRC. Tuttavia, per un funzionamento corretto nei casi in cui gli endpoint hanno più valori SSRC, le implementazioni DEVONO (MUST) trattare ciascun SSRC come un partecipante separato nella sessione RTP, cosicché un endpoint che ha più SSRC conti come più partecipanti.

5.1. Requisito di reportistica RTCP

Un endpoint RTP che ha più SSRC DEVE (MUST) trattare ciascun SSRC come un partecipante separato nella sessione RTP. Ogni SSRC manterrà le proprie informazioni di stato relative a RTCP e, quindi, avrà il proprio intervallo di reportistica RTCP che determina quando invia i report RTCP. Se il meccanismo di [MULTI-STREAM-OPT] non viene utilizzato, allora ciascun SSRC invierà report RTCP per tutti gli altri SSRC, compresi quelli co-locati presso lo stesso endpoint.

Se l'endpoint ha alcuni SSRC che inviano dati e altri che sono solo ricevitori, allora essi riceveranno quote diverse della larghezza di banda RTCP e calcoleranno intervalli di reportistica RTCP di base diversi. Altrimenti, tutti gli SSRC presso un endpoint calcoleranno lo stesso intervallo di reportistica RTCP di base. Gli intervalli di reportistica effettivi per ciascun SSRC sono randomizzati nel modo usuale, ma i report possono essere aggregati come descritto nella Sezione 5.3.

5.2. Intervallo di reportistica iniziale

Quando un partecipante si unisce a una sessione unicast, il testo seguente dalla Sezione 6.2 di [RFC3550] è rilevante: "Per le sessioni unicast... il ritardo prima dell'invio del pacchetto RTCP composto iniziale PUÒ (MAY) essere zero." L'assunzione di base è che ciò debba valere anche nel caso di SSRC multipli. Occorre tuttavia prestare attenzione quando un endpoint (o middlebox) con un numero elevato di SSRC si unisce a una sessione unicast, poiché la trasmissione immediata di molti report RTCP può creare una raffica significativa di traffico, portando a congestione transitoria e perdita di pacchetti a causa di overflow delle code.

Per garantire che la raffica iniziale di traffico generata da un endpoint RTP non sia più grande di quella che verrebbe generata da una connessione TCP, un endpoint RTP NON DEVE (MUST NOT) inviare più di quattro pacchetti RTCP composti con ritardo iniziale zero quando si unisce a una sessione RTP, indipendentemente dal numero di SSRC utilizzati dall'endpoint. Ciascuno di questi pacchetti RTCP composti iniziali PUÒ (MAY) includere report aggregati da più SSRC, purché la dimensione totale del pacchetto RTCP composto non superi l'MTU e l'avg_rtcp_size sia mantenuto come nella Sezione 5.3.1. L'aggregazione di report da diversi SSRC nei pacchetti RTCP composti iniziali consente a un numero sostanziale di SSRC di inviare report immediatamente. Gli endpoint DOVREBBERO (SHOULD) dare priorità ai report sugli SSRC che è probabile siano più immediatamente utili, ad esempio per gli SSRC che sono inizialmente mittenti.

Un endpoint che deve inviare report su più SSRC di quanti ne possano stare nei quattro report RTCP composti che possono essere inviati immediatamente DEVE (MUST) inviare gli altri report in seguito, seguendo le usuali regole di temporizzazione RTCP, inclusa la riconsiderazione del timer. Tali report POSSONO (MAY) essere aggregati come descritto nella Sezione 5.3.

Nota: Quanto sopra è scelto per corrispondere alla finestra iniziale massima di TCP di quattro pacchetti [RFC3390], non alle finestre iniziali TCP più grandi per cui è in corso un esperimento [RFC6928]. La ragione di ciò è il desiderio di essere conservativi, poiché un endpoint RTP in molti casi inizierà anche a inviare pacchetti di dati RTP nello stesso momento in cui vengono inviati questi pacchetti RTCP iniziali.

5.3. Aggregazione dei report in pacchetti RTCP composti

Come delineato nella Sezione 5.1, un endpoint con SSRC multipli deve trattare ciascun SSRC come un partecipante separato quando si tratta di inviare report RTCP. Ciò porterà ciascun SSRC a inviare un pacchetto RTCP composto in ogni intervallo di reportistica. Poiché questi pacchetti provengono dallo stesso endpoint, si potrebbe ragionevolmente attendersi che possano essere aggregati per ridurre i costi di overhead. In effetti, la Sezione 6.1 di [RFC3550] consente ai traduttori e ai mixer RTP di aggregare pacchetti in circostanze simili:

Si RACCOMANDA (RECOMMENDED) che i traduttori e i mixer combinino i singoli pacchetti RTCP provenienti dalle molteplici sorgenti che stanno inoltrando in un unico pacchetto composto ogni volta che ciò sia fattibile, al fine di ammortizzare l'overhead dei pacchetti (si veda la Sezione 7). Un esempio di pacchetto RTCP composto come potrebbe essere prodotto da un mixer è mostrato nella Fig. 1. Se la lunghezza complessiva di un pacchetto composto superasse l'MTU del percorso di rete, esso DOVREBBE (SHOULD) essere segmentato in più pacchetti composti più brevi da trasmettere in pacchetti separati del protocollo sottostante. Ciò non pregiudica la stima della larghezza di banda RTCP, poiché ogni pacchetto composto rappresenta almeno un partecipante distinto. Si noti che ciascuno dei pacchetti composti DEVE (MUST) iniziare con un pacchetto SR o RR.

Ciò consente ai traduttori e ai mixer RTP di generare pacchetti RTCP composti che contengono più pacchetti Sender Report (SR) o Receiver Report (RR) da SSRC diversi, nonché qualsiasi altro tipo di pacchetto. Non vi sono restrizioni sull'ordine in cui i pacchetti RTCP possono comparire all'interno del pacchetto composto, salvo la regola abituale secondo cui il pacchetto RTCP composto inizia con un pacchetto SR o RR. A causa di questa regola, gli endpoint RTP implementati correttamente saranno in grado di gestire pacchetti RTCP composti che contengono pacchetti RTCP relativi a più SSRC.

Di conseguenza, gli endpoint che usano SSRC multipli possono aggregare i pacchetti RTCP inviati dai loro diversi SSRC in pacchetti RTCP composti, a condizione che 1) i pacchetti RTCP composti risultanti inizino con un pacchetto SR o RR, 2) mantengano la dimensione media del pacchetto RTCP come descritto nella Sezione 5.3.1 e 3) pianifichino la trasmissione dei pacchetti e gestiscano l'aggregazione come descritto nella Sezione 5.3.2.

5.3.1. Mantenimento di AVG_RTCP_SIZE

L'algoritmo di pianificazione RTCP in [RFC3550] funziona su base per-SSRC. Ciascun SSRC invia un singolo pacchetto RTCP composto in ogni intervallo di reportistica RTCP. Quando un endpoint usa SSRC multipli, è auspicabile aggregare i pacchetti RTCP composti inviati dai suoi SSRC, riducendo l'overhead formando un pacchetto RTCP composto più grande. Questa aggregazione può essere effettuata come descritto nella Sezione 5.3.2, purché il calcolo della dimensione media del pacchetto RTCP sia aggiornato come segue.

I partecipanti a una sessione RTP aggiornano la loro stima della dimensione media del pacchetto RTCP (avg_rtcp_size) ogni volta che inviano o ricevono un pacchetto RTCP (si veda la Sezione 6.3.3 di [RFC3550]). Quando un pacchetto RTCP composto che contiene pacchetti RTCP di diversi SSRC viene inviato o ricevuto, la stima avg_rtcp_size per ciascun SSRC su cui si riporta viene aggiornata usando div_packet_size invece della dimensione effettiva del pacchetto:

avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size

dove div_packet_size è packet_size diviso per il numero di SSRC che inviano report in quel pacchetto composto. Il numero di SSRC che inviano report in un pacchetto composto è determinato contando il numero di SSRC diversi che sono la sorgente dei pacchetti RTCP SR o RR all'interno del pacchetto RTCP composto. I pacchetti RTCP non composti (ossia i pacchetti RTCP che non contengono un pacchetto SR o RR [RFC5506]) sono considerati come riportanti su un singolo SSRC.

Un partecipante che non segue la regola precedente e usa invece la dimensione completa del pacchetto RTCP composto per calcolare avg_rtcp_size ricaverà un intervallo di reportistica RTCP eccessivamente grande di un fattore proporzionale al numero di SSRC aggregati nei pacchetti RTCP composti e alla dimensione dell'insieme di SSRC che vengono aggregati rispetto al numero totale di partecipanti. Questo intervallo di reportistica RTCP aumentato può causare timeout prematuri se è più di cinque volte l'intervallo scelto dagli SSRC che comprendono il pacchetto RTCP composto e che aggregano report da molti SSRC. Un MTU di 1500 ottetti può contenere cinque report di dimensione tipica in un pacchetto RTCP composto, quindi questa è una preoccupazione reale se gli endpoint aggregano report RTCP da SSRC multipli.

Il problema sollevato nel paragrafo precedente è mitigato dalla modifica del comportamento di timeout specificata nella Sezione 7.1.2 di questo memo. Questa mitigazione è in atto nei casi in cui la larghezza di banda RTCP è sufficientemente elevata che un endpoint, usando avg_rtcp_size calcolato senza tenere conto del numero di SSRC che inviano report, può trasmettere con frequenza superiore a circa ogni 5 secondi. Si noti, tuttavia, che la reportistica RTCP dell'endpoint non aggiornato è comunque influenzata negativamente anche se i timeout prematuri dei suoi SSRC vengono evitati. Se la compatibilità con endpoint non aggiornati è una preoccupazione, il numero di report da SSRC diversi aggregati in un singolo pacchetto RTCP composto DOVREBBE (SHOULD) essere limitato a due report oppure non si dovrebbe usare affatto l'aggregazione. Ciò limiterà l'intervallo di reportistica RTCP dell'endpoint non aggiornato a non più del doppio dell'intervallo di reportistica RTCP che sarebbe scelto da un endpoint che segue questa specifica.

5.3.2. Pianificazione di RTCP durante l'aggregazione di SSRC multipli

Questa sezione rivede ed estende il comportamento definito nella Sezione 6.3 di [RFC3550] e nella Sezione 3.5.3 di [RFC4585] se viene usato il profilo RTP/AVPF o il profilo RTP/SAVPF, riguardo alle azioni da intraprendere quando si pianifica e si inviano pacchetti RTCP in cui più SSRC che inviano report aggregano i loro pacchetti RTCP nello stesso pacchetto RTCP composto. Queste modifiche alle regole di pianificazione RTCP sono necessarie per mantenere importanti proprietà di temporizzazione di RTCP, inclusa la distribuzione tra i pacchetti e il comportamento durante le flash join e altre variazioni nella composizione della sessione.

Le variabili tn, tp, tc, T e Td usate nel seguito sono definite nella Sezione 6.3 di [RFC3550]. Le variabili T_rr_interval e T_rr_last sono definite in [RFC4585].

Ciascun endpoint DEVE (MUST) pianificare la trasmissione RTCP in modo indipendente per ciascuno dei suoi SSRC usando il calcolo regolare di tn per il profilo RTP utilizzato. Ogni volta che il timer tn scade per un SSRC, l'endpoint DEVE (MUST) eseguire la riconsiderazione del timer RTCP e, se applicabile, la soppressione basata su T_rr_interval. Se il risultato indica che un pacchetto RTCP composto deve essere inviato da quell'SSRC, e la trasmissione non è un pacchetto RTCP anticipato [RFC4585], allora l'endpoint DOVREBBE (SHOULD) cercare di aggregare nel pacchetto RTCP composto i pacchetti RTCP di ulteriori SSRC pianificati in futuro, prima che venga inviato. La ragione per limitare o non aggregare per motivi di compatibilità all'indietro è discussa nella Sezione 5.3.1.

L'aggregazione procede come segue. L'endpoint seleziona l'SSRC che ha il valore tn più piccolo dopo il tempo corrente, tc, e prepara i pacchetti RTCP che quell'SSRC invierebbe se il suo timer tn scadesse a tc. Se tali pacchetti RTCP entrano nel pacchetto RTCP composto che viene generato, tenendo conto del path MTU e dei pacchetti RTCP aggiunti in precedenza, allora vengono aggiunti al pacchetto RTCP composto; altrimenti vengono scartati. Questo processo viene ripetuto per ciascun SSRC, in ordine di tn crescente, finché il pacchetto RTCP composto è pieno o tutti gli SSRC sono stati aggregati. A quel punto, il pacchetto RTCP composto viene inviato.

Quando il pacchetto RTCP composto viene inviato, l'endpoint DEVE (MUST) aggiornare tp, tn e T_rr_last (se applicabile) per ciascun SSRC incluso. Queste variabili vengono aggiornate come segue:

1. Per il primo SSRC che ha inviato report nel pacchetto RTCP composto, impostare il tempo di trasmissione effettivo, tt, di quell'SSRC a tc.
2. Per ciascun SSRC aggiuntivo che ha inviato report nel pacchetto RTCP composto, calcolare il tempo di trasmissione che quell'SSRC avrebbe avuto se non fosse stato aggregato nel pacchetto RTCP composto. Ciò si ricava prendendo tn per quell'SSRC, quindi eseguendo la riconsiderazione e aggiornando tn finché tp + T <= tn. Fatto ciò, impostare il tempo di trasmissione effettivo, tt, per quell'SSRC al valore calcolato di tn. Se si sta usando il profilo RTP/AVPF o il profilo RTP/SAVPF, allora la soppressione basata su T_rr_interval NON DEVE (MUST NOT) essere usata in questo calcolo.
3. Calcolare il tempo di trasmissione effettivo medio, tt_avg, per il pacchetto RTCP composto in base ai valori tt di tutti gli SSRC inviati nel pacchetto RTCP composto. Impostare tp per ciascuno degli SSRC inviati nel pacchetto RTCP composto a tt_avg. Se si sta usando il profilo RTP/AVPF o il profilo RTP/SAVPF, impostare T_tt_last per ciascun SSRC inviato nel pacchetto RTCP composto a tt_avg.
4. Per ciascuno degli SSRC inviati nel pacchetto RTCP composto, calcolare i nuovi valori tn in base ai parametri aggiornati e alle usuali regole di temporizzazione RTCP e ripianificare i timer.

Quando si usa il profilo RTP/AVPF o il profilo RTP/SAVPF, il meccanismo precedente tenta di aggregare i pacchetti RTCP solo quando il pacchetto RTCP composto da inviare non è un pacchetto RTCP anticipato, e quindi l'algoritmo nella Sezione 3.5.3 di [RFC4585] controllerà la pianificazione RTCP. Se T_rr_interval == 0, oppure se T_rr_interval != 0 e vengono scelte l'opzione 1, 2a o 2b dell'algoritmo, allora il meccanismo precedente aggiorna le variabili necessarie. Tuttavia, se la trasmissione viene soppressa secondo l'opzione 2c dell'algoritmo, allora tp viene aggiornato a tc poiché l'aggregazione non ha avuto luogo.

La riconsiderazione inversa DEVE (MUST) essere eseguita seguendo la Sezione 6.3.4 di [RFC3550]. In alcuni casi, ciò può portare il valore di tp dopo la riconsiderazione inversa a essere maggiore di tc. Questo non è un problema, e ha l'effetto desiderato di avvicinare proporzionalmente il valore tp a tc (così come tn) man mano che l'intervallo di reportistica si riduce in proporzione diretta alla dimensione ridotta del gruppo.

È stato dimostrato in simulazioni [Sim88] [Sim92] che l'algoritmo precedente mantiene la distribuzione del tempo di trasmissione tra pacchetti RTCP per ciascun SSRC e consuma la stessa quantità di larghezza di banda dei pacchetti RTCP non aggregati. Con questo algoritmo, l'intervallo di trasmissione effettivo per un SSRC che innesca una trasmissione di pacchetti RTCP composti segue le regole di trasmissione regolari. Il valore tp è impostato in un punto dell'intervallo [0, 1.5/1.21828*Td] davanti a tc. Il valore effettivo è la media di una istanza di tc e dei tempi di trasmissione randomizzati degli SSRC aggiuntivi; quindi, la parte inferiore dell'intervallo è più probabile. Ciò compensa il bias che altrimenti verrebbe introdotto scegliendo il valore tn più breve tra gli N SSRC inclusi nell'aggregato.

L'algoritmo gestisce anche i casi in cui il numero di SSRC che possono essere inclusi in un pacchetto aggregato varia. Un SSRC che in precedenza era aggregato e non entra in un pacchetto ha comunque la propria trasmissione pianificata secondo le regole normali. Quindi, innesterà una trasmissione a tempo debito, oppure l'SSRC sarà incluso in un altro aggregato. Il comportamento dell'algoritmo al variare della dimensione del gruppo di SSRC è il seguente:

Sessioni RTP in cui il numero di SSRC cresce: Quando la dimensione del gruppo cresce, Td cresce in proporzione al numero di nuovi SSRC nel gruppo. Quando la riconsiderazione viene eseguita a causa della scadenza del timer tn, quell'SSRC riconsidererà la trasmissione e, con una certa probabilità, ripianificherà il timer tn. Questa parte dell'algoritmo di riconsiderazione è influenzata dall'algoritmo precedente solo per il fatto di avere valori tp che erano nel futuro invece che impostati al momento dell'ultima trasmissione effettiva al momento dell'aggiornamento di tp.

Sessioni RTP in cui il numero di SSRC si riduce: Quando il gruppo si riduce, la riconsiderazione inversa sposta i valori tp e tn verso tc in proporzione al numero di SSRC che lasciano la sessione rispetto al numero totale di partecipanti quando l'hanno lasciata. Si potrebbe credere che l'impostazione del valore tp in avanti nel tempo rispetto a tc abbia un effetto negativo. Tuttavia, la ragione di questa impostazione è compensare il bias causato dalla scelta del tn più breve tra gli N aggregati. Questo bias permane anche in caso di riduzione del numero di SSRC. La riconsiderazione inversa compensa la riduzione indipendentemente dal fatto che l'aggregazione sia usata o meno. L'effetto negativo che può verificarsi rimuovendo un SSRC è che il tn più favorevole apparteneva all'SSRC rimosso. L'impatto di ciò è limitato a ritardare la trasmissione, nel caso peggiore, di un intervallo di reportistica.

In conclusione, le indagini svolte non hanno riscontrato alcun impatto negativo significativo sull'algoritmo di pianificazione.

5.4. Uso del feedback RTP/AVPF o RTP/SAVPF

Questa sezione discute la trasmissione dei pacchetti di feedback RTP/AVPF quando l'endpoint trasmittente ha SSRC multipli. Le linee guida di questa sezione si applicano anche agli endpoint che usano il profilo RTP/SAVPF.

5.4.1. Scelta dell'SSRC per i pacchetti di feedback

Quando un endpoint RTP/AVPF ha SSRC multipli, può scegliere quale SSRC usare come sorgente per i pacchetti di feedback RTCP che invia. Diversi fattori possono influenzare tale scelta:

• I pacchetti di feedback RTCP relativi a un particolare tipo di media DOVREBBERO (SHOULD) essere inviati da un SSRC che riceve quel tipo di media. Per esempio, quando audio e video sono multiplati su una singola sessione RTP, gli endpoint useranno il loro SSRC audio per inviare feedback sull'audio ricevuto da altri partecipanti.
• I pacchetti di feedback RTCP e i messaggi di controllo del codec RTCP che sono notifiche o indicazioni riguardanti dati RTP elaborati da un endpoint DEVONO (MUST) essere inviati dall'SSRC usato per quei dati RTP. Ciò include le notifiche relative a una richiesta o a un comando ricevuti in precedenza [RFC4585][RFC5104].
• Se SSRC separati sono usati per inviare e ricevere media, allora l'SSRC corrispondente DOVREBBE (SHOULD) essere usato per il feedback, poiché hanno frazioni di larghezza di banda RTCP diverse. Ciò può anche influenzare la considerazione se l'SSRC possa essere usato in modalità immediata.
• Alcuni tipi di pacchetto di feedback RTCP richiedono coerenza nell'SSRC usato. Per esempio, se una limitazione Temporary Maximum Media Stream Bit Rate Request (TMMBR) [RFC5104] è impostata da un SSRC, lo stesso SSRC deve essere usato per rimuovere la limitazione.
• Se diversi SSRC sono adatti per inviare feedback, potrebbe essere auspicabile usare un SSRC che consenta l'invio del feedback come pacchetto RTCP anticipato.

Quando un pacchetto di feedback RTCP viene inviato come parte di un pacchetto RTCP composto che aggrega report da SSRC multipli, non vi è alcun requisito che il pacchetto composto contenga un pacchetto SR o RR generato dal mittente del pacchetto di feedback RTCP. Per i pacchetti RTCP a dimensione ridotta, l'aggregazione dei pacchetti di feedback RTCP da più sorgenti non è limitata ulteriormente rispetto alla Sezione 4.2.2 di [RFC5506].

5.4.2. Pianificazione di un pacchetto di feedback RTCP

Quando un SSRC ha la necessità di trasmettere un pacchetto di feedback in modalità anticipata, DEVE (MUST) pianificare quel pacchetto seguendo l'algoritmo nella Sezione 3.5 di [RFC4585] modificato come segue:

• Per determinare se una sessione RTP è considerata una sessione punto-punto o una sessione multipartecipante, un endpoint DEVE (MUST) contare il numero di valori distinti di RTCP SDES CNAME usati dagli SSRC elencati nel campo SSRC dei pacchetti di dati RTP che riceve e nel campo "SSRC of sender" dei pacchetti RTCP SR, RR, RTPFB o PSFB che riceve. Una sessione RTP è considerata una sessione multipartecipante se più di un CNAME è usato da quegli SSRC, a meno che la segnalazione indichi che la sessione deve essere gestita come punto-punto oppure siano usati gruppi di reportistica RTCP [MULTI-STREAM-OPT]. Se vengono usati gruppi di reportistica RTCP, una sessione RTP è considerata una sessione punto-punto se l'endpoint riceve un solo gruppo di reportistica ed è considerata una sessione multipartecipante se vengono ricevuti più gruppi di reportistica o una combinazione di gruppi di reportistica e SSRC che non fanno parte di un gruppo di reportistica. Gli endpoint NON DEVONO (MUST NOT) determinare se una sessione RTP è multipartecipante o punto-punto in base al tipo di connessione (unicast o multicast) utilizzata, né al numero di SSRC ricevuti.
• Quando si verifica se esiste già un pacchetto RTCP composto pianificato contenente messaggi di feedback (Passo 2 nella Sezione 3.5.2 di [RFC4585]), tale verifica DEVE (MUST) essere effettuata considerando tutti gli SSRC locali.
• Se a un SSRC non è consentito inviare un pacchetto RTCP anticipato, allora il messaggio di feedback PUÒ (MAY) essere messo in coda per la trasmissione come parte di qualsiasi trasmissione anticipata o pianificata regolarmente che possa verificarsi entro la durata utile massima del messaggio di feedback (T_max_fb_delay). Ciò modifica il comportamento del punto 4a nella Sezione 3.5.2 di [RFC4585].

Il primo punto elenco sopra specifica una regola per determinare se una sessione RTP deve essere considerata una sessione punto-punto o una sessione multipartecipante. Questa regola è semplice da implementare, ma è nota per classificare erroneamente alcune sessioni come sessioni multipartecipante. I problemi noti sono i seguenti:

Endpoint con più contesti di sincronizzazione: Un endpoint che fa parte di una sessione punto-punto può avere più contesti di sincronizzazione, ad esempio a causa dell'inoltro di una sorgente di media esterna in una conversazione interattiva in tempo reale. In questo caso, la classificazione considererà il peer come due endpoint, mentre la trasmissione RTP/RTCP effettiva sarà sotto il controllo di un solo endpoint.

Middlebox di inoltro selettivo: Il Selective Forwarding Middlebox (SFM) come definito nella Sezione 3.7 di [RFC7667] ha il controllo sulla trasmissione e sulle configurazioni tra sé e ciascun endpoint peer individualmente. Controlla inoltre completamente i pacchetti RTCP che vengono inoltrati tra i singoli segmenti. Pertanto, questo tipo di middlebox può essere paragonato al mixer RTP, che usa i propri SSRC per mixare o selezionare i media che inoltra, e che sarà classificato come sessione RTP punto-punto dalla regola precedente.

Nei casi precedenti, è molto ragionevole usare i gruppi di reportistica RTCP [MULTI-STREAM-OPT]. Se viene usata tale estensione, un endpoint può indicare che la moltitudine di CNAME è in realtà sotto il controllo di un singolo endpoint o middlebox usando un solo gruppo di reportistica.

Le regole precedenti classificheranno anche alcune sessioni in cui l'endpoint è connesso a un mixer RTP come punto-punto. Per esempio, il mixer potrebbe agire come gateway verso una sessione RTP basata su Any Source Multicast per l'endpoint in questione. Tuttavia, nella maggior parte dei casi questo andrà bene, poiché il mixer RTP fornisce una separazione tra le due parti della sessione. La responsabilità ricade sul mixer di agire di conseguenza in ciascun dominio.

Infine, notiamo che potrebbero essere definiti meccanismi di segnalazione per prevalere sulle regole quando esse porterebbero a una classificazione errata.