Udoskonaloną wersją WFQ jest PQWFQ (Priority Queuing WFQ). Poszerza on WFQ o kolejkę priorytetową, obsługiwaną przed wszystkimi pozostałymi. Program schedulera pobierze najpierw pakiet z kolejki priorytetowej, a następnie z kolejki WFQ.

Z kolei CBWFQ (Class Based WFQ) przypisuje kolejce oprócz wagi także klasę, która ma przyporządkowany udział w pasmie łącza. Bardziej złożony program schedulera umożliwi takie pobieranie pakietów, że pasmo przyporządkowane klasie nie zostanie przekroczone.

RTP i RTCP

Protokół RTP ma kilka nazw, jak Real Time Protocol czy Real-time Transport Protocol itp. Nazwa zgodna z RFC 1889 ma postać: A Transport Protocol for Real-Time Applications Internet. W RFC 1889 został również opisany protokół RTCP.

RTP (Real Time Protocol)

RTP jest przeznaczony do wsparcia ruchu przesyłanego w czasie rzeczywistym. Typowymi aplikacjami czasu rzeczywistego są audio- i wideokonerencje, transmisje radiowe i telewizyjne. RTP może obsługiwać aplikacje zarówno unicastowe, jak i multicastowe.

Pakiety RTP są przenoszone w datagramach UDP, dla których środkiem transportu jest IP. RTP zapewnia usługi przez łącza wirtualne Internetu lub intrasieci. Ten aspekt protokołu zostanie przedstawiony dalej. RTP był konstruowany w taki sposób, ażeby mógł dostarczać informacji wymaganej przez konkretną aplikację. Jest więc często integrowany z procesem aplikacji, a nie implementowany jako oddzielna warstwa. W przeciwieństwie do konwencjonalnych protokołów, w których dodatkowe funkcje mogłyby zostać lokowane przez dodanie opcji wymagających przeprowadzenia analizy składniowej, RTP jest tak zaprojektowany, aby mógł się dostosowywać do różnych formatów drogą modyfikacji lub poszerzania zawartości nagłówka, bądź modyfikacji i poszerzania.

Rysunek przedstawia dwa sposoby wspierania ruchu multimedialnego między nadawcami a odbiorcami. Urządzenia wideo po lewej stronie są przystosowane do przepływności 512 kb/s, a po prawej do 384 kb/s. Ponadto sieć transportowa może nie być w stanie przesłać strumienia 512 kb/s. W efekcie tych ograniczeń komunikacja multimedialna między urządzeniami z lewej i prawej strony (rysunku) nie będzie możliwa. Jednakże translator RTP umożliwi wzajemną interakcję. Jego praca polega w głównej mierze na przekształceniu jednej składni na inną, czyli - innymi słowy - na przystosowaniu ruchu do formatu, który uwzględni ograniczenia zarówno pasma transmisyjnego sieci tranzytowej, jak też stacji po prawej stronie.

Na tym samym rysunku widać też serwer RTP przeprowadzający operacje miksowania. Mikser łączy wiele źródeł w jeden strumień - po prostu łączy sygnały w spójny format. Zazwyczaj miksery uczestniczą w operacjach audio i nie pogarszają jakości sygnału. Operacje miksowania RTP są szczególnie polecane w audiokonferencjach, natomiast niezbyt dobrze radzą sobie z wideokonferencjami. Miksery RTP nie dokonują translacji każdego rodzaju, np. nie dokonują jej z każdego źródła na różne formaty. Miksery są już używane w audiokonferencjach, ale nie wideokonferencjach, ponieważ miksowanie strumieni wideo nie jest jeszcze rzeczywistością rynkową. Z drugiej strony, jeśli strumienie audio są nieskomplikowanym ruchem PCM (Pulse Code Modulation), jak z większości wielofunkcyjnych przełączników dostawców usług internetowych, to wtedy istnieje możliwość zsumowanie wartości każdego źródła ładunku i połączenia ich w jeden strumień.

Na rysunku obok widać, że RTP może wspierać różne typy ładunków, jak audio ITU-T G.722 czy rekomendację wideo JPEG. PDU (Protocol Data Unit) RTP jest transportowany w PDU UDP oraz w PDU IP. X - eXtension - wskazuje na obecność następnego nagłówka po RTP, ale nie jest jeszcze używany.

CC (CSRS Count) przenosi liczbę identyfikatorów CSRS. M (Marker) jest znacznikiem, którego interpretacja została zdefiniowana przez profil. Znacznik zwraca uwagę na pewne ważne zdarzenia, np. zaznaczanie w strumieniu ramek brzegowych. Stempel czasowy „odbija” chwilę próbkowania pierwszego bajta w pakiecie danych RTP.