Audio-via-IP - MAYAH Communications

Audio-via-IP Kompendium
Audio-via-IP
Grundlagen, Praxis und
Anwendungen
The MAYAH range –
Professional Audio & Video Encoding/Decoding, Recording,
Mixing and Transmission Products
CENTAURI®II
Multichannel Audio Gateway Codec
Sporty
Portable Reporter Codec
MERK II
Portable Audio Codec Mixer
IO [io]
Audio Video Encoder/Decoder
ganymed
IP Audio Encoder/Decoder
Flashman II
Portable Audio Recorder/Codec
MAYAH Communications
Am Soeldnermoos 17
85399 Hallbergmoos, Germany
Tel.: +49 8115517-0, Fax: -55
E-Mail: [email protected]
www.mayah.com
AUDIOVIAIPEXPERTS
AUDIOVIAIPEXPERTSGROUP
GROUP
Impressum
Herausgeber: MAYAH Communications GmbH, Copyright 2007,
Redaktion: Daniel Adasinsky
Autoren: Hans-Heinrich Hansen, Christian Diehl, Uwe Andersen,
Jan Simon, Werner Ludwig, Jörg Rimkus, Detlef Wiese
1. Auflage
Flashman, Centauri, Mayah sind eingetragene Warenzeichen
Layer 2 licensed from Audio MPEG, Coding Technologies
Layer 3/mp3Pro licensed from Thomson/Fraunhofer Institute
AAC / AAC HE licensed from VIA, Coding Technologies
*working name of MPEG 4, implementation from Coding Technologies
© Copyright MAYAH Communications GmbH, 2007. All rights reserved. CENTAURI®,
FLASHMAN® and MAYAH are registered trademarks. Patents pending.
Product information and technical specifications are subject to change without notice.
Audio-via-IP Kompendium
Audio-via-IP
Grundlagen, Praxis und Anwendungen
Professionell aber einfach
Zusammenfassung
Audio-over-IP nimmt einen wachsenden Stellenwert im Bereich des Rundfunkleitungsnetzwerks ein. Die Verfügbarkeit und Bandbreite von IP-Netzwerken steigen während gleichzeitig die Kosten nahezu kontinuierlich sinken. Das Angebot
an Festverbindungen und ISDN ist weltweit rückläufig und damit zu rechnen,
dass es bestimmte Angebote der Telekommunikationskonzerne früher oder später nicht mehr geben wird. Zum Beispiel werden schon heute ISDN Übertragungen in Europa teilweise über den IP Backbone geführt.
Dieses Kompendium nimmt sich dieser wichtigen Thematik an, und zwar von
den Grundlagen bis zu den Anwendungen ohne Anspruch auf Vollständigkeit.
Vielmehr sollen dem Neueinsteiger, Quereinsteiger und Fortgeschrittenen Anregungen gegeben werden.
Bevor auf alle Punkte sehr detailliert eingegangen wird soll das Kapitel „IP Audio
Kompakt“ die wesentlichen Punkte in kurzer Form übersichtlich darstellen.
1
IP Audio Kompakt
UDP, RTP, SIP… – IP Protokolle, welches wofür?
HE AACv2 usw. - Audio Codier Formate, wann brauche ich welches?
Das gewählte IP Protokoll bestimmt maßgeblich die Art und Weise wie das Audiosignal über ein Netzwerk transportiert wird. Da an ein Rundfunksignal höchste
Anforderungen bezüglich Qualität und Sicherheit gestellt werden, muß das Protokoll entsprechend ausgewählt sein. Während RTP/UDP in Corporate Networks
mit VPNs und festen Kommunikationspartnern verwendet wird, kommt zusätzlich
SIP im öffentlichen Internet zum Zug und ist insbesondere durch VoIP-Anwendungen bekannt geworden.
Die Vielzahl an Audio Codier Formaten kann durchaus manchmal Verwirrung stiften. Die Auswahl geschieht nach Kriterien wie Kompatibilität, Qualität und Verzögerungszeit. Während HE AACv2 aufgrund der hohen Qualität und niedrigen
Bitrate von deutlich unter 48kbps stereo immer mehr zur Anwendung kommt,
wird bei Netzen mit größerer Bandbreite auch gerne die verlustfreie transparente
AES/EBU Übertragung mit bis zu 3 MBit/s verwendet.
SIP Session Initiation Protocol
Für den Übergang der bestehenden ISDN- in die neue IP-Infrastruktur wird eine
Migrationszeit benötigt. Es muß Gerätetechnik mit beiden Schnittstellen geben,
sowie Transcodiermöglichkeiten, sogenannte Gateways geschaffen werden.
SIP ist ein textbasiertes Verhandlungsprotokoll, mit dem Verbindungen auf Basis
des Internet Protokolls (IP) verhandelt werden können. SIP wird lediglich genutzt,
um die Signalisierung zwischen den Partnern abzuwickeln. Der Transport der
Mediendaten erfolgt - wie im klassischen ISDN auch – getrennt von der Verhandlung. Meist werden die Nutzdaten über eine andere Route und mit einem anderen Transportprotokoll übermittelt. Während für die Verhandlung TCP oder UDP
zur Wahl stehen, geschieht der Transport der Nutzdaten meist mit RTP.
SIP-Wählverbindungen als ISDN Ersatz
Die neuen SIP Wählverbindugnen im öffentlichen Internet sind dann als gleichwertig zu den bekannten ISDN Verbindugnen zu betrachten, wenn eine verlustfreie Übertragung der Daten möglich und eine kurze Verzögerungszeit zu erreichen ist. Dies funktioniert mit garantierter Bandbreite, z.B. durch Verwendung
von RSVP und FEC. Mehr in Kapitel
VPNs mit garantierter Bandbreite als Ersatz für E1 und X.21 Verbindungen
Virtual Private Networks, die sogennanten VPNs können die heute genutzten E1
oder X.21 Strecken dann ersetzen, wenn für eine entsprechende stabile Bandbreite gesorgt wird.
Verwendung von IP über vorhandene E1 oder ATM Netze
Über bestehende E1- oder ATM-Strecken kann ein IP-Protokoll gelegt werden.
Damit ist z.B. die gleichzeitige Nutzung für Audio/Video- und Datensignale möglich. Bei den verwendeten Router wird eine Bandbreitenreservierung entsprechend eingerichtet.
2
Der Übergang von ISDN zu IP und umgekehrt
FEC – Fehlerschutz wie eingesetzt
Vorwärtsfehlerkorrektur oder Forward Error Correction (FEC) bietet die Möglichkeit, durch das Hinzufügen redundanter Daten, Übertragungsfehler aufzuspüren
und/oder zu korrigieren. So können in der Regel erneute Übertragungen oder
Datenverluste, die entsprechend höhere Kosten der Verbindung oder höhere
Verzögerungszeiten verursachen, vermieden werden.
IP Overhead
Bei IP-Übertragungen besteht der Datenstrom grundsätzlich aus zwei Teilen:
Nutzdaten (english Payload), z.B. ein oder mehrere MPEG-Frames, und Zusatzdaten (english Overhead). Beim UDP-Protokoll ist der absolute IP-Overhead 46
Bytes lang, und er setzt sich folgendermaßen zusammen: 8 Bytes UDP-Header,
20 Bytes IP-Header, 18 Bytes IEEE802.3 (Ethernet). Der relative IP Overhead
wird prozentual von dem Original-Payload berechnet.
MPEG TS über ASI, MPEG TS über IP
Der MPEG Transportstream, kurz MPEG TS wird überwiegend in DVB und ipTV
Umgebungen eingesetzt. Es handelt sich um eine Formatierung von einem oder
mehreren Audio- und/oder Videosignalen mit typischerweise Setop-Boxen als
Empfänger.
3
Gibt es schon Standards?
Um einheitliche Implementierungen voranzutreiben und zu unterstützen, wurde
die N/ACIP Arbeitsgruppe der EBU gegründet. Im September 2007 soll der erste
Entwurf einer Empfehlung offiziell herausgegeben werden.
RTP (Realtime Transport Protocol)
ist ein Protokoll zur kontinuierlichen Übertragung von audiovisuellen Daten über
IP-basierte Netzwerke. Es benutzt UDP (User Datagram Protocol), aber im Gegensatz zur reinen UDP-Implementation garantiert RTP die richtige Reihenfolge
der Pakete auf der Empfängerseite.
RTCP (RTP Control Protocol)
basiert auf dem periodischen Austausch von Kontrollpaketen unter den Sitzungsteilnehmern. Durch RTCP wird der Multimedia Datenstrom nicht gestört. Informationen wie die Zahl der gesendeten und verlorenen Pakete, Round Trip Delay,
Jitter usw. dienen dazu, das Streaming an die aktuellen Netzwerkbedingungen
anzupassen.
SDP (Session Description Protocol)
dient dazu, Multimedia-Sitzungen zu beschreiben. Diese Beschreibung kann
verwendet werden, die Sitzung anzukündigen, Teilnehmer zu dieser Sitzung
einzuladen oder auf andere Weise eine Verbindung zu initiieren.
SAP (Session Announcement Protocol)
dient dazu, eine SDP Information an einer Multicast-Adresse bekannt zu machen. Somit kann ein potentieller Empfänger sich einen Gesamtüberblick aller im
(Sub-) Netz angebotenen Inhalte verschaffen und sich dann den gewünschten
auswählen. MAYAH unterstützt, entgegen der Norm, auch SAP-Unicast.
RTSP (Real Time Streaming Protocol)
ist ein Anwendungsprotokoll, das die Auslieferung, Kontrolle und Steuerung von
Multimedia-Daten auf Basis von Unicast und Multicast unterstützt. Damit kann
man einen Streaming Server mit den typischen Befehlen wie zum Beispiel „Wiedergabe“ oder „Pause“ steuern.
4
5
Inhaltsverzeichnis
1
Audio und der Einstieg in IP
Praktische Voraussetzungen für SIP und
Audio-via-IP
1.1
IP Grundlagen
1.2
Packet Switching versus digitaler Festverbindung
5.1
Voraussetzungen für SIP-basierte Verbindungen
über öffentliches Internet
Audio Codierung für IP:
Verzögerungszeit versus Bitrate
5.2
Voraussetzungen für sonstige IP-basierte Verbindungen –
Unicast vs. Multicast
2
2.1
G.711
2.2
G.722
2.3
MPEG Layer 2
2.4
MPEG Layer 3
2.5
MPEG 4 HE AAC
2.6
apt-X und Enhanced apt-X
2.7
Lineares Audio und AES/EBU transparent
3
3.1
4
6
5
6
Typische IP oder gemischte IP/ISDN Anwendungen
7
Referenzen
7.1
R. Wagner, „Das neue Verteilnetz von Telekom Austria
und ORF“, FKT, Nr. 56, 7 / 2002, S. 387 – 390
7.2
G. Stoll, F. Kozamernik, „EBU subjective listening tests
on low-bitrate audio codecs“, EBU, 2003
7.3
IP als Plattform moderner Media- und Telekom
Netze
“Too many audio codecs“, Detlef Wiese,
Tonmeistertagung, 2002
7.4
Voraussetzungen für Mediatransport / Echtzeit
Fähigkeiten nachgerüstet
White Paper „Diskussion von Codierverfahren“,
Detlef Wiese, 2002
7.5
White Paper „NAT Traversal for Multimedia over IP“,
Newport Networks, 2005
Wählverbindungen im Public Internet
7.6
White Paper „Understanding SIP“, D. Sisale, J. Kutan,
GMD Fokus, 2000
7.7
CENTAURI II Handbuch, Werner Ludwig, 2006
4.1
ISDN – SIP ein Vergleich
4.2
SIP – und wie es funktioniert
4.3
Betriebssicherheit
4.4
SIP für hochqualitative Medialinks
4.5
Ausblick
7
1
Audio und der Einstieg in IP
1.1
IP Grundlagen
In Anlehnung an OSI Schichtenmodell wurde für das Internet Protokoll auch ein
Referenzmodell definiert. Es beschreibt den Aufbau und die Wechselwirkung der
verschiedenen Netzwerkprotokolle in vier Schichten: Netzwerkschicht, Vermittlungsschicht, Transportschicht und Anwendungsschicht.
Die Anwendungsschicht enthält aufgabenbezogene Protokolle, wie z.B. Telnet
oder FTP, s. Abbildung 1.
Abb. 1
)3//3)REFERENCEMODEL
Layer 7
Application Layer
Defining application protocols
(e.g. FTP, TELNET, mail...)
Layer 6
Presentation Layer
Describing the data presentation
(e.g. ASCII, Unicode)
Layer 5
Session Layer
Connecting and disconnecting interlinks, login, logout,
handshake for non duplex connects ...
Layer 4
Transport Layer
Data transport between communication partners or applications
(e.g. TCP, UDP)
Layer 3
Network Layer
Interconnecting network stations or segments (IP)
Layer 2
Datalink Layer
Transfer protocol for data framing and secure transfer
(e.g. HDLC, SLIP, PPP)
Layer 1
Physical Layer
Specifying the bit transportation on the link media
(e.g. modulation, pin assignment of the connector...)
)3//3)REFERENCEMODELTO4#0)0REFERENCEMODEL
Application Layer
&40(440
Transport Layer
Transport Layer
2405$0FOR
-EDIA4RANSPORT
Network Layer
Internet Layer
)NTERNET0ROTOCOL
Network Layer
)%%%ON%THERNET
OR)%%%ONW,AN
Application Layer
Presentation Layer
Session Layer
Datalink Layer
Physical Layer
9
Um Informationen von Anwendung zu Anwendung zwischen verschiedenen
Netzteilnehmern zu übertragen, sind mindestens drei Adressen erforderlich. Die
einzelnen Teilnehmer eines physikalischen Netzsegments (Ethernet IEEE802.3)
werden über ihre 6 Byte lange MAC Adresse (Media Access Control) identifiziert.
Diese Adresse muss innerhalb eines Segments eindeutig sein. MAC Adressen
werden vielfach bereits von den Herstellern vergeben, wobei die ersten drei Byte
den Hersteller identifizieren.
Um im Internet einen Teilnehmer eindeutig erkennen zu können, wird die vier
(IPv4) bzw. 16 (IPv6) Byte lange Internetadresse verwendet.
Der Bezug zwischen physikalischer MAC und logischer IP Adresse wird über
das Address Resolution Protocol (ARP), ein Protokoll der Vermittlungsschicht,
hergestellt. Die IP Adressen des Senders als auch des Empfängers werden im IP
Protocol Header beschrieben.
Die dritte Adresse ist die so genannte Port- oder Socket-Nummer. Sie identifiziert
eine bestimmte Anwendung des Teilnehmers. Die Portnummer (16 Bit) befindet
sich innerhalb der Transportschicht, wobei eine Reihe an Portnummern bereits
bestimmten Anwendungen fest zugeordnet sind, so verwendet z.B. FTP grundsätzlich den Port 20/TCP für Daten und 21/TCP für Steuerinformationen. Telnet
verwendet Port 23 und für SMTP wird immer Port 25 genutzt. Die vollständige
Liste der Portdefinitionen ist unter www.iana.org/assignments/port-numbers zu
finden. Die IANA (Internet Assigned Numbers Authority) ist auch zuständig für
die Vergabe registrierter Portnummern.
1.2
Packet Switching versus digitaler Festverbindung
Heute werden für den Weitverkehrtransport von Mediadaten im Rundfunk meistens digitale Festverbindungen, Frame Relay oder Satellitenverbindungen verwendet: Leitungsarten mit in der Regel hoher Verfügbarkeit, konstanter Laufzeit
und vernachlässigbarem Jitter. Sequenzfehler oder Paketverluste treten artbedingt gar nicht auf.
Für den Dateitransfer und zunehmend auch für die Echtzeitübertragung im Bereich der Distribution und Contribution werden Internet-Dienste herangezogen.
Der ORF begann mit der Realisierung des L-NETs bereits im Jahr 2001, also vor
über sechs Jahren. Während auch danach der Schwerpunkt für die Echtzeit-
10
übertragung so genannte Corporate Networks waren, die vollständig kontrolliert
werden konnten, soll heute mehr und mehr auch das öffentliche Internet genutzt
werden. Insbesondere durch die abnehmende Verfügbarkeit von ISDN müssen
im Audiobereich vermehrt paketvermittelte Verbindungen genutzt werden, obwohl dies ursprünglich so nicht geplant war. Die Väter des Internet haben mit
dem 1981 festgeschriebenen Internet Protocol einige Möglichkeiten hinzugefügt,
die eine eingeschränkte Nutzung in Echtzeit ermöglichen, allerdings werden
diese Eigenschaften heute auf Standardanschlüssen nicht unterstützt. So verfügt
der IP Header über ein Type-of-Service Flag, welches zur Kennzeichnung der
Priorität der enthaltenen Daten dient, allerdings werden diese Flags entweder
von den Routern im Internet ignoriert oder gar zurückgesetzt. Der Grund dafür
ist klar, würde das Type-of-Service Flag tatsächlich Wirkung zeigen, kann man
sicher davon ausgehen, dass z.B. die „Internet Gamer Community“ dies sehr
schnell herausgefunden hätte und dann alle Internet Spiele mit priorisierten
Datagrammen arbeiten würden.
Um Mediadaten zuverlässig über ein paketvermitteltes Netz übertragen zu
können, sind bestimmte Voraussetzungen zu erfüllen: Latenz, Jitter und Verfügbarkeit des Netzes müssen sich in einem bekannten und der Anwendung
entsprechenden Rahmen bewegen. Die für die Signalübertragung erforderliche
Bandbreite muss zu jedem Zeitpunkt zur Verfügung stehen, außerdem muss
bekannt sein, ob Sequenzfehler, also Fehler in der Reihenfolge der eintreffenden
Datagramme auftreten können.
Es sind für einen gesicherten Betrieb geeignete Hilfsmittel einzusetzen; der maximale Jitter legt die Größe eines Kompensationspuffers auf der Empfangsseite
fest. Mögliche Paketverluste können durch den Einsatz eines Forward Error Correction Verfahrens (FEC) ausgeglichen werden. Sequenzfehlern wird durch den
Einsatz eines geeigneten Protokolls auf der Transportschicht entgegengewirkt
(RTP, Realtime Transport Protocol), s. Abbildung 2.
Der Einsatz all dieser Massnahmen hat allerdings eine teilweise erhebliche Auswirkung auf die Latenz der Übertragungsstrecke.
Ein weiterer wesentlicher Unterschied zu digitalen Direktverbindungen stellt der
durch die verschiedenen Protokoll-Header bedingte Overhead einer paketvermittelten Verbindung dar.
11
So werden pro Datagramm in
einem Ethernet 18 Byte für den
IEEE802.3 Header plus 8 Byte
für dessen Präambel benötigt.
Ethernet
IP
TCP/UPD Application
Der IP Header belegt 20 Byte,
RTP
Application
Layer
der UDP Header weitere 8 Byte
Data
Transport
und ein ggfs. verwendeter RTP
$ATA
Layer
Header
Header nochmals 12 Byte.
Internet
$ATA
Header
Header
Layer
Insgesamt werden 66 Byte
Network
Header Daten pro RTP Data$ATA
Header
Header
(EADER
Layer
gramm übertragen. Wird nun
z.B. in einem RTP Datagramm
jeweils genau ein MPEG 2 Layer 3 Audioframe mit 16 kHz Samplerate und einer
Bitrate von 24 kBit/sec transportiert (48 Byte), wird für den Transport eines 24
kBit/s Signals eine Bandbreite von 57 kBit/s benötigt.
Wird statt des MPEG2 Layer 3 jetzt MPEG4 AAC verwendet ist eine genaue
Berechnung der tatsächlich benötigten Transport Bandbreite aufgrund der signalbedingt wechselnden Länge der Audioframes nicht mehr möglich, da nicht
vorherzusehen ist, in welchem Verhältnis Nutzdaten zu Header Overhead stehen.
Segments hinaus, z.B. über ein Gateway ist nicht möglich, da keine logische
Adresse vorhanden ist. Auch, wenn die MAC-Adresse des anderen Teilnehmers
in einem anderen Netzwerk Segment bekannt wäre, so können die Router keinen
Pfad dorthin ermitteln, da zumindest die logische Adresse des fernen Netzwerksegments fehlt.
0ROTOCOLSTRUCTURES
Data Encapsulation
Abb. 3
IP Overhead in %
25%
12
19,7%
19,17%
15,97%
15%
15,97%
13,69%
11,98%
9,58%
7,99%
MPEG L3 UDP
6,85%
fs=48 kHz
5,99%
Bit rate = 256 Kbit/s
4,79%
Frame length = 256 (bit rate) /48 (sample rate) * 144 (Byte) = 768 Byte
IP Overhead = ((768 Byte + 46 Byte)/768 Byte –1) * 100 % = approx. 6 %
13,69%
10%
5%
Bitrate in Kbit/s
Um die Auswirkungen des Protokoll Overheads zu verringern, können ggfs. mehrere Audioframes pro Datagramm zu Lasten der Latenz übertragen werden, da
auf der Senderseite die notwendige Menge an Audioframes zuerst gesammelt
werden muss.
32
40
48
IP Overhead in %
25%
23,96%
56
64
80
96
112
128
160
192
224
256
320
e.g. apt-X (16 bit only) / Eapt-X, UDP
23,96%
23,96%
23,00%
23,96%
19,17%
20%
IP Overhead
Eine andere Möglichkeit, den Protokoll Overhead zu reduzieren, ist es, IP, UDP
und RTP Header einfach wegzulassen, ein Verfahren, dass sich Techniken wie
Ethersound und Cobranet zu Nutze machen. Hier werden die Mediadaten als
Payload der IEEE802.3 Pakete übermittelt. Da aber die IP-Adressen fehlen,
können nur Netzteilnehmer innerhalb des eigenen Netzwerksegments über die
MAC-Adressen identifiziert werden. Eine Übertragung über die Grenzen des
23,96%
23,7%
20%
0%
Für das oben erwähnte MPEG 2 Layer 3 Signal würde dies bedeuten, dass bei
optimal genutzter Payload insgesamt 30 komplette Audioframes pro Datagramm
transportiert werden würden. Jeder Audioframe enthält 576 Sample und damit
bei einer Abtastrate von 16 kHz 36 mSec Audio. Somit entsteht eine zusätzliche
Latenz 1044 mSec, s. Abbildung 3.
e.g. (MPEG Layer3, 48 KHz. packet size = 180 Bytes)
30%
IP Overhead
Abb. 2
15%
11,06%
10,27%
11,50%
11,50%
10,65%
10%
5%
0%
4,49%
16 bit
Mono
4,49%
16 bit
Stereo
4,42%
20 bit
Mono
4,42%
20 bit
Stereo
4,36%
24 bit
Mono
9,58%
4,36%
24 bit
Stereo
at packet size 180
at packet size 390
at packet size 1024
apt-X /Eapt-X,fixed block size, Resolution = 20 Bit Stereo
Payload = (180 [packet size] / 80 [block size] rounded up to the next integer) * 80 = 240 Byte
IP Overhead = ((240 Byte + 46 Byte)/240 Byte –1) * 100 % = approx. 19,7 %
13
2
Audio Codierung für IP: Verzögerungszeit versus Bitrate
Im Rundfunk wurden während der letzten fünfundzwanzig Jahre verschiedene
Codierverfahren eingeführt, wie z.B. J.41, J.57, MPEG Layer 2 und 3, sowie auch
nicht standardisierte Verfahren wie z.B. apt-X, Eapt-X oder ADPCM4SB (Micda).
Aufgrund unterschiedlicher Anforderungen wird dem Betreiber die Wahl der
korrekten Bitrate, Betriebsart und Abtastrate nicht leicht gemacht wird. Erschwerend ist, dass viele weitere Verfahren in den letzten Jahren hinzugekommen sind.
Neben den oben genannten Formaten werden die aus der Telefonie bekannten
G.711 und G.722 im Rundfunk ebenso eingesetzt wie die sich seit ca. 5 Jahren
sehr erfolgreich verbreitenden AAC Varianten, wie MPEG 2 und 4 AAC, HE AAC
(früher aacPlus), HE AACv2, AAC ELD*, sowie auch lineares Audio oder AES/
EBU transparent zur Anwendung; alles Formate mit vielen möglichen Abtastund Bitraten, manche nur mono und stereo, manche per Definition auch in dual
mono, joint stereo oder in 5.1/7.1 Technik.
Im Rahmen der Entwicklung von Codierverfahren wird auf die Optimierung der
Parameter Bitrate, Qualität, auch nach mehrfacher En-/Decodierung (Kaskadierbarkeit), Verzögerungszeit und Kompatibilität Wert gelegt.
Die hier beschriebenen Verfahren lassen sich auch dahingehend klassifizieren.
Während zum Beispiel HE AACv2 ausschließlich zur Reduktion der Bitrate bei
gleichzeitiger sehr guter Tonqualität entwickelt wurde, so stand bei apt‑X die
möglichst geringe Verzögerungszeit im Vordergrund.
Zunehmend kommen aufgrund der mehr und mehr zur Verfügung stehenden
Bandbreite auch lineare Übertragungsverfahren, wie 16, 20 oder 24 Bit lineares Audio oder sogar gleich die transparente Übertragung des gesamten 3,072
MBit/s AES/EBU Signals in Betracht. Hier steht die Qualität und die Verzögerungszeit im Vordergrund, was natürlich zu Lasten der Bandbreite geht.
Genaue Untersuchungen zum Marktanteil der verschiedenen Codierverfahren im
Rundfunk gibt es nicht. Man geht jedoch allgemein immer noch von einer Dominanz des MPEG Layer 2 und G.722 aus, wobei Verfahren, wie lineares Audio, das
4SB ADPCM Verfahren, apt-X und Enhanced apt-X, sowie der MPEG 4 Standard
HE AAC und HE AACv2 bei entsprechenden Anwendungen zunehmen, letzterer
sehr deutlich.
14
*work item of MPEG
15
Eine ausführliche Diskussion muss eine Darstellung der Verfahren hinsichtlich
Qualität, Flexibilität, Bandbreite, Verzögerungszeiten, Kompatibilität, Standardisierung, Marktanteil und –aussichten beinhalten. Tatsächlich gibt es für nahezu
jedes Verfahren eine optimale Anwendung.
2.1
Es gibt zwei verschiedenen Methoden, um Audiocodecs mit G.722 zu synchronisieren.
G.722 mit H.221 Inband-Signalisierung (G.722/H.221):
Bei G.722/H.221 werden 1,6 kbit/s des 64 kbit/s B-Kanals für das Versenden
von Inbandinformation verwendet. Diese Inbandinformation wird zur Synchronisation des Audiodatenstroms verwendet.
G.722 mit statistischer Synchronisation (G.722/SRT):
Bei G.722/SRT (SRT = Statistical Recovery Timing) wird durch statische Untersuchung der Byteanfang gefunden. Hierbei ist zu beachten, dass dies nur bei
wirklichen statistische Signalen wie Musik oder Sprache funktioniert, nicht aber
bei Sinustönen.
16
MPEG Layer 2 erlaubt die Datenraten von 8 bis 384 Kbit/s, Zielbitrate für Stereo
ist 256 Kbit/s
2.4
MPEG Layer 3
Viel mehr als mp3 bekannt, wird dieses Format auch verwendet. Zum Beispiel
wenn kleinere Datenraten gefordert sind, als die, die mit MPEG Layer 2 bei einer
gewünschten Audioqualität erreichbar sind.
G.722
Ein weiterer Standard der ITU-T. Im Vergleich zu G.711 bietet G.722 eine höhere
Audioqualität, indem das Signal mit 16 kHz abgetastet wird. Dennoch wird es mit
64 Kbit/s (z.B. über ein ISDN B-Kanal) übertragen. Ähnlich wie bei G.711 entsteht bei der G.722 Codierung keine bedeutende Verzögerung.
MPEG Layer 2
Bis jetzt bleibt der Anfang 1990-er Jahre standardisierte Algorithmus ein sehr
verbreitetes Codierverfahren für qualitative Audioübertragung über verschiedene
Netzwerke im Rundfunkbereich. Im wesentlichen tragen zur Popularität des
Formats seine für ein verlustbehaftetes (psychoakustisches) Codierverfahren
relativ hohe Kaskadierbarkeit und die breite Unterstützung in diversen Soft- und
Hardware Audiocodecs der früheren Generationen bei.
G.711
Ein der grundlegenden Standards der ITU-T. G.711 erlaubt Digitalisierung von
Audio in Mono mit einer Abtastrate von 8 kHz. Damit wird der Bereich zwischen
300 und 3400 Hz codiert. Übertragen wird mit 64 Kbit/s in Europa und mit 56
Kbit/s in Nordamerika. G.711 wird vor allem in der klassischen Telefonie verwendet. Bei IP-Übertragungen kann das Format, dann zum Einsatz kommen, wenn
ein herkömmliches Telefon über VoIP erreicht werden muss. Bei der Codierung
ins G.711 entsteht keine bemerkbare Verzögerungszeit.
2.2
2.3
MPEG Layer 3 erlaubt die Datenraten von 8 bis 320 Kbit/s. Zielbitrate für Stereo
liegt zwischen 128 und 192 Kbit/s
2.5
MPEG 4 HE AAC
HE AAC ist eine Weiterentwicklung von AAC unter Verwendung der SBR-Technologie von Coding Technologies ( www.codingtechnologies.com ). AAC, das
innerhalb MPEG2 und 4 standardisierte Verfahren zählt zu den qualitativ hochwertigsten Codieralgorithmen mit der Zieldatenrate von 128kBit/s.
Viele Anwendungen benötigen so geringe Bitraten, die von AAC nicht mehr mit
hoher Qualität encodiert werden können. Deshalb hat man bei Coding Technologies, einer schwedisch-deutschen Kooperation, eine Technologie namens SBR,
der so genannten Spectral Band Replication entwickelt, die genau hier entgegenwirkt und nun erlaubt, AAC auch bei niedrigen Bitraten, z.B. 32, oder 48kBit/s
joint stereo zu verwenden.
Dabei werden über 90% der verwendeten Bitrate weiterhin für die klassische
AAC-Codierung und nur ein sehr kleiner Teil (<4kBit/s) für die SBR-Information
verwendet. Der konventionell codierte AAC-Teil der Codierung wird mit halber
Abtastrate, also 16, 22.05 oder 24kHZ durchgeführt. Dies resultiert in einer Erhöhung der Codiereffizienz,
17
Schlüsselfunktionen sind:
Die Verbindung von SBR und AAC ist ein qualitativ hochwertiges Format. Man
verabschiedet sich zwar vom Anspruch der Transparenz, da die Frequenzen
oberhalb 7, bzw. 8 kHz nicht mehr transparent übertragen werden, man erreicht
jedoch mit wesentlich niedrigeren Bitraten eine CD-ähnliche Qualität. CD-ähnlich
heißt im Fall von HE AAC sehr gut, was sich insbesondere durch die mittlerweile
sehr weite Verbreitung dieses Formats im Rundfunk, aber auch bei Übertragungssystemen zeigt.
Da SBR die Bitrate generell um ca. 30-50% optimiert hat HE AAC eine Zieldatenrate von 48 kBit/s für Stereosignale. In Verbindung mit einer sogenannten
„parametric stereo“ Codierung heißt das Verfahren HE AACv2 und es werden
auch die für das stereofone Bild notwendigen Daten parametrisiert übertragen.
Die Zieldatenraten gehen damit sogar auf 16, 20 und 24 kBit/s.
2.6
2.7
4:1:4 Datenreduktion
■■
Mono/stereo audio encoder/decoder
■■
Flexible Abtastrate bis zu 96kHz
■■
Zusatzdaten bis zu 12kbit/s
Lineares Audio und AES/EBU transparent
Mit zunehmender Verfügbarkeit an Bandbreite kommen auch die Übertragung
von linearem Audio und „AES/EBU Transparent“ in Betracht. Unter linearem
Audio versteht man ein PCM Signal mit einer bestimmten Wortbreite von 16, 20
oder 24 Bit sowie einer festgelegten Abtastrate von im Rundfunk stets 48 oder
96kHz. Die resultierende Bitrate beträgt bei einem Stereosignal demnach zwischen 1,5 bis 4,5 MBit/s.
apt-X und Enhanced apt-X
Bei der Übertragung von AES/EBU Transparent geht es darum, dass im AES/
EBU Signal auch encodierte Datensignale wie Dolby E oder DTS, etc. enthalten
sein können und dieses Signal keiner Abtastratenkonvertierung unterzogen wird,
da ansonsten die encodierte Datensignale irreversible manipuliert wären. Die
Datenrate des AES/EBU Signals beträgt 3,072 MBit/s.
Apt-X wurde erstmalig 1990 als Tonübertragungsverfahren mit sehr kurzer Verzögerungszeit bekannt und hat sich seit dem als de-facto Industriestandard insbesondere in privaten Produktionsstudios hervorgetan. Die Stärken liegen in der
hohen Tonqualität verbunden mit sehr kurzen Verzögerungszeiten.
Es kommt die ADPCM (Adaptive Differential Pulse Code Modulation) zum Einsatz, die bei den verwendeten Datenraten selbst bei mehreren En-/DecodierProzessen, der so genannten Kaskadierung noch eine sehr gute Qualität hat. Die
theoretische Verzögerungszeit liegt bei 3ms mit eine Abtastrate von 48kHz.
Der Algorithmus ist bei vielen Abtastraten einsetzbar und wurde erst kürzlich
um den sogenannten Enhanced apt-X Algorithmus erweitert. Enhanced apt-X™
bringt eine signifikante Verbesserung, speziell bei der Verzögerungszeit und dem
Dynamikumfang, da hier Abtastwerte mit einer Wortbreite von bis zu 24 Bit verarbeitet werden.
■■
Sollen Mehrkanalsignale, z.B. 5.1 oder 7.1 übertragen werden erhöhen sich die
Bitraten entsprechend.
2.8 Mehrkanalton
Die Encodierung von 5.1 oder 7.1 Mehrkanalsignalen wird von vielen Audioformaten unterstützt. Hervorzuheben sind HE AAC mit sehr effizienter Codierung
und geringen Bitraten bis 128 kbps, Eapt-X mit diskret encodierten Signalen und
Bitraten von 1-2 Mbit/s sowie linearen Formaten mit Bitraten bis zu 18 MBit/s.
apt-X ist heute eines der weltweit verbreitetsten Systeme für kurze Verzögerungszeiten. 18
19
!UDIO#ODIER&ORMATE!BTASTRATENINK(Z
!UDIO#ODIER&ORMATE1UALITÊTUND,ATENZ
'
'
SG
'
'
SEHRGERING
-0%',AYER
-0%',AYER
-0%',AYER
-0%',AYER
-0%',AYER
-0%',AYER
-0%',AYER
-0%',AYER
-0%'
,AYER
-0%'
,AYER
MS
VARIABELBISK(Z
MP02/
MP02/
MS
VARIABELBISK(Z
-0%'!!#
-0%'!!#
-0%'!!#,$
-0%'!!#,$
-0%'!!#(%V
-0%'!!#(%V
*
*
SEHRGERING
K(Z
!$0#-3"-)#$!
!$0#-3"-)#$!
SEHRGERING
K(Z
%APT8APT8
%APT8APT8
SEHRGERING
*
*
SEHRGERING
,INEAR!UDIO
,INEAR!UDIO
SEHRGERING
!%3%"54RANSPARENT
!%3%"54RANSPARENT
!!#UND!!#(%V
!!#UND!!#(%V
+ANALLINEAR!UDIO
+ANALLINEAR!UDIO
SEHRGERING
VARIABELK(ZMÚGLICH
+ANALAPT8%APT8
+ANALAPT8%APT8
SEHRGERING
VARIABELK(ZMÚGLICH
PROPRIETÊRE%RWEITERUNGVON&RAUNHOFER
K(Z
K(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
MS
VARIABELBISK(Z
VARIABELK(ZMÚGLICH
K(Z
VARIABELK(ZMÚGLICH
MS
VARIABELBISK(Z
PROPRIETÊRE%RWEITERUNGVON&RAUNHOFER
Audio Codier Formate: Bitraten in kBit/s
*proprietäre Erweiterung von Fraunhofer
20
21
3
IP als Plattform moderner Media- und Telekom Netze
3.1
Voraussetzungen für Mediatransport / Echtzeit Fähigkeiten nachgerüstet
Während klassische Broadcasting-Angebote aus ökonomischer Sicht eine möglichst
große Reichweite anstreben, werden Streaming-Media-Angebote mit wachsender
Teilnehmerzahl teurer, denn die Daten müssen an jeden Empfänger einzeln versendet werden. In der Netzwerktechnik ist zwar der Multicast-Modus bekannt, bei
dem ein vom Streaming-Server ausgehender Datenstrom bei geringer Netzbelastung
gleichzeitig an verschiedene Empfänger gesendet werden kann; dieser wird jedoch
bis heute praktisch nicht benutzt, weil ihn viele Router im Internet nicht unterstützen. Statt dessen werden für Streaming-Angebote mit einem Massenpublikum (z.
B. Übertragungen der Fußballbundesliga, grosse Events, etc.), so genannte OverlayNetze genutzt, welche die zu übertragenden Daten netztopologisch betrachtet an
vielen Orten gleichzeitig zur Verfügung stellen.
Hochqualitatives Streaming setzt als Transportprotokoll das RTP/RTCP- Protokoll
voraus. Dieses Protokoll ist die Grundlage für alle echtzeitfähige Übertragungen. Zur
Steuerung von Streaming- Inhalten existieren die Protokolle SIP, SAP, RTSP, HTTP.
Diese Protokolle werden über unterschiedliche Ports angesprochen und stellen
entsprechende Steuerungsfunktionen zur Verfügung, greifen aber wiederum gemeinsam auf das RTP-Protokoll zum Austausch von Informationsinhalten zurück.
Abb. 5
RTP/TCP: Protokoll-Architektur
Applikation (Sender)
RTCP
Encoder
22
RTP
Applikation (Empfänger)
Feedback
RTCP
Data
RTP
Decoder
23
4
Wählverbindungen im Public Internet
4.1
ISDN – SIP ein Vergleich
Beim Verbindungsaufbau in einem verbindungsorientierten Netz (z.B. ISDN)
wählt der Initiator seinen Kommunikationspartner an, woraufhin dem Netz der
Verbindungswunsch angezeigt wird. Das Netz akzeptiert diesen Wunsch, falls es
über genügend Kanäle oder entsprechende Bandbreite verfügt, indem es eine
Belegungsquittung zurücksendet und reserviert den Kanal bzw. die Bandbreite.
Da ein solches Netz klassischerweise in mehrere Netzabschnitte unterteilt ist,
wird ein Belegungswunsch und die Quittung zwischen jedem Netzabschnitt
mit dem darauffolgenden ausgetauscht. So kann der Verbindungswunsch aus
einem Lokalnetz in Regionalnetze und das Weitverkehrsnetz gelangen oder wird
sogar zwischen nationalen Weitverkehrsnetzen ausgetauscht. Wird der angerufene Kommunikationspartner gefunden und ist er in der Lage die Verbindung
anzunehmen, so werden die Kommunikationspartner direkt über die reservierten
Kanäle verbunden. Das Telekommunikationsnetz ist, um diesen Mechanismus
effizient umzusetzen, in zwei Netze unterteilt: das Zeichengabe- (Signalisierungs-)Netz und das Nutzkanalnetz. Während über das Signalisierungsnetz alle
zum Kommunikationsaufbau notwendigen Nachrichten geschickt werden, besteht das Nutzkanalnetz aus frei schaltbaren (Nutz-) Datenkanälen, die bei ISDN
eine Übertragungsgeschwindigkeit von 64 kbit/s haben.
Mit der flächendeckenden Verbreitung von paketbasierten Netzen in höherer
Bandbreite entstehen nun für viele Dienste Möglichkeiten auf diese Netze überzusiedeln. Ein Netz, das mit reiner Datenübertragung und Nachrichtenaustausch
wie z.B. über Email angefangen hat, ermöglicht jetzt dank hinreichender Kapazitäten auch Dienstleistungen wie Fernsehen, Radio und Telefonie. „Voice over IP“
ist der designierte Nachfolger des heutigen Telefonnetzes.
Im Gegensatz zu ISDN werden in paketorientierten Netzen Datenpakete von den
Endstellen mit Ursprungs- und Zieladresse versehen und spontan, d.h. ohne
vorherigen Verbindungsaufbau versendet. Um in einem solchen nicht verbindungsorientierten Netzwerk ein Wählverbindungen zu ermöglichen, wurde das
Session Initiation Protocol (IP) entwickelt. Obwohl die Verbindungssteuerung von
SIP sehr an das D-Kanal Protokoll bei ISDN erinnert, wurde es nicht von einer
Telekommunikationsbehörde, sondern von der Internet Engineering Task Force
24
25
(IETF) erarbeitet und in einem Request For Comments (RFC 3261) festgehalten.
Die Arbeitsgruppe der IETF hat hierbei auf bewährte Protokollbausteine zurückgegriffen, so ist es nicht verwunderlich, dass viele Elemente des SIP an HTTP
oder SMTP erinnern.
Abb. 6
SIP - simple session establishment
1: INVITE fritz
2: 100 / Trying
4.2
SIP – und wie es funktioniert
2: 180 / Ringing
Das Session Initiation Protocol (SIP) ist also ein textbasiertes Verhandlungsprotokoll, mit dem Verbindungen auf Basis des Internet Protokolls (IP) verhandelt
werden können. Das SIP wird hierbei lediglich genutzt, um die Signalisierung
zwischen den einzelnen Verhandlungsstellen abzuwickeln. Der Transport der
Mediendaten erfolgt - wie bei ISDN auch – getrennt von der Verhandlung. Meist
werden die Nutzdaten über eine andere Route und mit einem anderen Transportprotokoll übermittelt. Während für die Verhandlung TCP oder UDP zur Wahl
stehen, geschieht der Transport der Nutzdaten meist mit RTP.
3: 200 / OK
SIP ist ein sogenanntes Peer-to–Peer Protokoll, mit dem einzelne Komponenten
im einfachsten Fall direkt miteinander verbunden werden können ohne eine
zentrale Einheit. Die Instanzen eines Peers innerhalb einer Session werden UserAgents (UAs) genannt. Ein UA kann zwei unterschiedliche Rollen übernehmen:
■■
Der User-Agent-Client (UAC) initiiert eine Session, und
■■
Der User-Agent-Server (UAS) beantwortet die Anfragen eines Clients.
Ein SIP-Gerät kann beide Rollen übernehmen. Im einfachsten Fall können also
zwei Endgeräte direkt miteinander kommunizieren.
Um eine solche Verhandlung zu starten wird vom Anrufer eine INVITE-Nachricht
an die SIP-Adresse des Empfängers geschickt. Das Schlüsselwort INVITE ist eine
der sogenannten Methoden, die ein UA beherrschen muss. Andere Methoden
sind z.B. ACK, BYE oder REGISTER. Möchte der Angerufene das Gespräch entgegennehmen, so kann er im einfachsten Falle direkt mit einer „OK“-Nachricht
antworten, die dann vom Anrufer mit einer „ACK“-Nachricht quittiert wird. Diese
drei Nachrichten reichen im einfachsten Fall aus, um eine Nutzdatenverbindung
aufbauen zu können. Die Besonderheit der drei oben beschriebenen Nachrichten ist, dass sie meist einen speziellen, zusätzlichen Inhalt im sogenannten Body
haben. Dieser Body enthält die Beschreibung der aufzubauenden Nutzdatenverbindung. Hier wird u.a. festgelegt, welche Audio- und Video-Codecs zum Einsatz
26
User
Agent 1
4: ACK
Media Connection (RTP)
User
Agent 2
1: BYE
2: 200 / OK
kommen, welche Parameter diese benutzen sollen und welche IP-Adressen und
Ports die Endpunkte der Nutzdatenverbindung haben. Zur Beschreibung der
Mediendatenverbindung nutzt man das Session Description Protocol (SDP); ein
Protokoll, das in vielen anderen Verhandlungs- und Übertragungsmechanismen
bereits erfolgreich eingesetzt wird und sich seit langem etabliert hat.
Eine der Stärken von SIP liegt darin, dass durch den oben beschriebenen Nachrichtenaustausch auch Eigenschaften der Nutzdatenverbindung verhandelt und
nicht etwa nur von der Anruferseite festgelegt werden können. Es ist durchaus
erlaubt, anstelle eines einzelnen gewünschten Audiocodecs eine Prioritätsliste
auszutauschen, die von der Gegenstelle verändert oder gar ersetzt werden darf.
Da der Nachrichtenaustausch beim Verbindungsaufbau aus mindestens drei
Nachrichten besteht, hat der Anrufer das letzte Wort und kann über den wirklich
zu nutzenden Audiocodec bestimmen.
Ein weiterer Vorteil von SIP offenbart sich, wenn man den Verbindungsaufbau
unter Zuhilfenahme von SIP-Servern genauer betrachtet.
Die Adressen der SIP-Teilnehmer sind durch ein vorgestelltes „sip:“ gekennzeichnet und meist in der Form „sip:user@host“, „sip:user@domain“ oder
„sip:<user>@<ip_address>“. Im einfachsten Fall, also bei einer direkten Verbin27
dung zwischen zwei Endgeräten, ist hier Host und Domain (bzw. IP-Adresse) des
Endgerätes gemeint, d.h. die IP-Adresse des Empfangsgerätes muss bekannt
sein, bzw. der Host- oder Domainname muss über übliche Mechanismen (z.B.
Domain Name Service DNS) auflösbar sein. Da dies in der Praxis jedoch selten
der Fall sein wird, gibt es die Möglichkeit ein Endgerät mit Hilfe von SIP-Servern
zu ermitteln.
Wie aus der Illustration ersichtlich wird, verhandeln die Endgeräte mit Ausnahme
der „ACK“ Nachricht nie direkt miteinander, sondern kommunizieren stets nur
mit dem SIP-Proxy. Trotzdem läuft die Verhandlung aus Sicht der Endgeräte
exakt so ab, wie eine direkte Verhandlung ohne Proxy – der SIP-Proxy ist also
transparent.
Abb. 7
SIP - Call Flow
1: INVITE
Location Service
3: [email protected]?
4: [email protected]
[email protected]
5: INVITE
2: 100 / Trying
User
Agent 1
[email protected]
SIP Proxy
6: 100 / Trying
8: 100/ Ringing
7: 100/ Ringing
10: 200/ OK
9: 200/ OK
User
Agent 2
11: ACK [email protected]
Betrachten wir ein Beispielszenario, in dem Endgerät 1 eine Verbindung zu
einem mobilen Endgerät 2 aufbauen möchte. Die IP-Adresse der Geräte sei
hierbei der jeweiligen Gegenstelle unbekannt. Es könnte sich z.B. um mobile
Geräte handeln, die sich über UMTS oder ADSL in ein Netz einwählen. Um
dennoch eine Verbindung aufbauen zu können, melden sich beide Endgeräte
bei einem SIP-Server mittels spezieller SIP-Nachrichten an. Hierzu identifiziert
sich der Benutzer anhand einer zuvor zugeteilten SIP-Adresse der Form user@
service-provider und meist auch einem Passwort. Der SIP-Server legt die Information unter welcher IP-Adresse der angemeldete Benutzer zu erreichen ist bei
einem Location-Server ab. Bei einem Verbindungswunsch von Endgerät 1 wird
als Ziel die registrierte Adresse des Endgerätes 2, also beispielsweise geraet2@
service-provider, angegeben. Die „INVITE” SIP-Nachricht wird deshalb an einen
SIP-Proxy geschickt, der seinerseits beim Location-Server die IP-Adresse des
angerufenen Endgerätes erfragt und dann die Nachricht in leicht veränderter
28
Form an Endgerät 2 weiterleitet. Endgerät 2 antwortet mit SIP-Nachrichten an
den SIP-Proxy, der diese wieder an Endgerät 1 weiterleitet. Die in Abbildung
gezeigten Nachrichten „100/Trying“ sind optional und dienen der Quittierung
einer Anfrage. Ebenfalls optional sind die gezeigten „180/Ringing“ Nachrichten,
die in der klassischen Telefonie das Ertönen eines Wecksignales beim Empfänger
an den Anrufer signalisieren.
Der Einfachheit halber wird in diesem Beispiel darauf verzichtet die Teilnehmer
an verschiedenen SIP-Servern anzumelden. Dies ist jedoch durchaus üblich und
natürlich problemlos möglich, da Verbindungsanfragen einfach von einem an
andere SIP-Proxies weitergeleitet werden können. Somit kann statt eines einzigen
Proxies auch eine Kette mehrerer Proxy-Server zwischen den Endgeräten liegen.
Proxy-Server müssen auch nicht gezwungenermaßen bei einem Provider stehen.
Dank Open-Source-Lösungen wie Asterisk oder Routern mit eingebauter SIPServer Funktionalität ist es einfach, eine solche Netzstruktur selbst aufzubauen.
Natürlich bringt ein neues Protokoll auch neue potentielle Probleme mit sich. Wie
bei jedem Peer-to-Peer Protokoll können Firewalls auch bei SIP-Verbindungen
eine gewünschte Kommunikation unterbinden. Eine Firewall definiert alle Pakete,
die zu einer Verbindung, die von außerhalb (d.h. meistens aus dem Internet) initiiert wird, gehören, als nicht erwünscht und verwirft diese. Sind also beide Endgeräte hinter einer Firewall, so kann von keiner Seite eine Verbindung aufgebaut
werden, da die Firewall der Gegenseite eingehende Verbindungsversuche immer
als unerwünscht interpretiert und somit unterbindet.
29
ressen im Header geändert; der Inhalt eines Paketes (also z.B. die Beschreibung
der Nutzdatenverbindung im SDP-Teil bei SIP) bleibt unverändert. Es existieren
unterschiedliche Möglichkeiten, wie diese Adressübersetzung geschieht. Diese
verschiedenen Mechanismen können zu unterschiedlichen Adressen oder Ports
im Absender eines übersetzten Paketes führen. Je nach Art der NAT scheinen
die übersetzten Pakete (also die Pakete, die in das öffentliche Netz gelangen)
von unterschiedlichen Adressen oder Ports zu kommen und sind nicht eindeutig vorhersehbar. Es ist also schwierig, im Inhalt (Body) einer SIP-Nachricht die
richtige IP-Adresse und den richtigen Port anzugeben, da diese je nach eingesetztem NAT-Mechanismus unterschiedlich sein können.
Abb. 8
3)0.!4&IREWALLS
4HEh&IREWALL0ROBLEMv
1.
1.
2.
4.
3.
Dieses Problem läßt sich jedoch durch entsprechende Firewalleinstellungen (z.B.
Port-Forwarding) umgehen.
Ein weiteres Problem entsteht dadurch, dass im Inhalt (Body) einer Nachricht,
genauer gesagt im SDP-Teil, eine IP-Adresse für die Nutzdatenverbindung angegeben werden muss. Das ist im Normalfall die IP-Adresse des Endgerätes. Sollte
im Netzwerk zwischen den Endgeräten jedoch Network Address Translation
(NAT) eingesetzt werden, wie es häufig in nichtöffentlichen Netzen der Fall ist,
so kann die in der Nachricht angegeben Adresse nicht von einem anderen Netz
erreicht werden und ist somit falsch.
Nichtöffentliche Netze nutzen nämlich meist IP-Adressen aus einem speziellen
Adressraum, der nur in privaten Netzen genutzt werden darf. Beispiele hierfür
sind Adressen, nach dem Schema 192.168.X.X oder 10.X.X.X. Gelangt ein solches Paket in ein öffentliches Netz wie das Internet, so wird es sofort verworfen.
NAT sorgt deshalb dafür, dass beim Übergang zwischen einem nichtöffentlichen
und dem öffentlichen Netz die Absenderadresse eines IP-Paketes aus dem
privaten Netz in eine des öffentlichen Netzes umgeschrieben wird. Bei einem
hereinkommenden Paket wird entsprechend die Zieladresse von der öffentlichen
in die private Adresse umgeschrieben. Wohlgemerkt werden hier nur die IP-Ad-
30
Lösung bietet hier das STUN (Simple Traversal of UDP over NATs) Protokoll, das
ermöglicht herauszufinden, welche Art von NAT vom Netzwerk verwendet wird
und wie die zu verwendende IP-Adresse und der zu verwendende Port lautet.
Hierzu werden einige Testpakete mit einem STUN-Server (z.B. stunserver.org)
gewechselt, anhand derer die gewünschte Information ermittelt wird.
2.
4.3
Betriebssicherheit
Grundsätzlich gibt es zwei Aspekte der Sicherheit bei solchen Verbindungen:
■■
Die Sicherheit der Übermittlung von Informationen
■■
Die Sicherheit gegenüber Angriffen von außen
Bei einer SIP-gestützten Verbindung werden über zwei Kanäle Informationen
ausgetauscht. Zum einen werden Registrierungs- und Signalisierungsdaten über
das SIP ausgetauscht und zum anderen Nutzdaten (z.B. über RTP). Beide Verbindungen könnten geheime, schützenswerte Informationen preisgeben.
Um die SIP Signalisierung zu schützen, definiert der SIP-Standard (RFC 3261)
das SIPS Protokoll, bei dem anhand von Schlüsselwörtern signalisiert wird, dass
eine Verschlüsselung der SIP Verhandlung gewünscht ist. Eine solche Verschlüsselung wird mit dem TLS Verfahren, das z.B. auch bei HTTPS eingesetzt wird,
vorgenommen. Um eine Transparenz der Nachrichten zu gewährleisten, wird hier
jedoch nur der Inhalt (Body) einer Nachricht, also im Regelfall die Information
über verwendete Audio- und Video-Codecs etc., geschützt.
Gerade bei der Übertragung von Mediendaten in hoher Qualität ist der Inhalt
der Nutzdaten meist besonders schützenswert. Einen Mechanismus für einen
31
darauffolgender Übertragung ermöglicht es auf einfache Weise die Nutzung von
beliebigen Audio- und Video-Codecs auszuhandeln – sofern sie von allen Endteilnehmern unterstützt werden.
solchen Schutz bietet der SIP Standard jedoch nicht, da hier Mechanismen eingesetzt werden können, die auch bei anderen IP-Verbindungen genutzt werden.
Beispiele hierfür sind:
■■
■■
■■
ATM oder MPLS: Dienste im darunter liegenden Transportnetz, basierend
auf Adressierungsmechanismen
IPSec: Tunnel basierend auf dem Internetprotokoll
Ein nicht zu unterschätzendes Sicherheitsrisiko stellen Angriffe von außen dar.
Solche aus Fremdnetzen initiierte Angriffe haben meist zum Ziel, den angegriffenen Dienst zu stören oder ganz zu blockieren (Denial of Service / DoS). Es wäre
z.B. denkbar, dass ein Angreifer versucht, einen RTP-Nutzdatenstrom auf ein
neues Ziel umzulenken und sich so Zugang zu enthaltenen Informationen schafft
und/oder den Dienst blockiert. Umgekehrt könnte ein Angreifer auch RTPNutzdatenströme durch eigene ersetzen und somit falsche oder unerwünschte
Information verbreiten. Solche Attacken lassen sich nicht allein mit den oben
beschriebenen Mitteln vereiteln, sondern erfordern vielmehr Netzstrukturen und
Sicherheitsanwendungen, wie Firewalls und Application Layer Gateways (ALG).
Jedoch ist das Erstellen solcher Netzwerkstrukturen alleine wirkungslos, solange
das Netz nicht kontinuierlich und fachgerecht überwacht und gewartet wird.
4.4
SIP für hochqualitative Medialinks
SIP hat bis dato hauptsächlich in Telefonieanwendungen Verbreitung gefunden.
In solchen VoIP Anwendungen hat es heute seinen festen Platz und ist als Standard für das kommende Next Generation Network (NGN) fest eingeplant.
Man kann also fest damit rechnen, dass die für einen problemlosen Betrieb notwendigen Netzstrukturen und -ressourcen durch die weite Verbreitung von SIP
als VoIP-Lösung von allen wichtigen Netzbetreibern zur Verfügung stehen.
Wie bereits erwähnt ist SIP auch eine sehr gute Grundlage für Medialinks in
professioneller Qualität. Vor allem die saubere Trennung von Verhandlung und
32
Das hierzu benutzte SDP wird ohnehin bereits in anderen Übertragungsmechanismen eingesetzt und wird von Codec-Herstellern die Audio-Over-IP ernsthaft
betreiben, bereits verwendet. Es handelt sich bei SIP also lediglich um eine neue
Art der Signalisierung.
VPN: Teilnehmer eines VPN können Daten wie in einem internen LAN austauschen. Die einzelnen Teilnehmer selbst müssen hierzu nicht direkt verbunden sein. Die Verbindung über das öffentliche Netz wird üblicherweise
verschlüsselt.
4.5
SIP Ausblick
Um SIP für einen reibungslosen Ablauf der Kommunikation zwischen Audio- und
Video-Codecs nutzen zu können, sind jedoch einige Festlegungen und Erweiterungen wünschenswert. Bei einem normalen SIP Verbindungsaufbau kann
höchstens dreimal eine Beschreibung der aufzubauenden Verbindung gesendet
werden – zweimal vom Anrufer und einmal vom Angerufenen. Für die klassische
Telefonieanwendung, für die SIP geschaffen wurde, ist dies sicher ausreichend,
denn hier kommen vorwiegend Algorithmen mit wenigen oder gar keinen Parametern (G.711, G.722, G.723, G.728, G.729a,...) zum Einsatz. In dieser sehr
knappen Verhandlung müssen die Kommunikationspartner für hochqualitative
Medialinks sich jedoch nicht nur auf den zu verwendenden Algorithmus einigen,
sondern auch unter anderem auf die Anzahl der Kanäle, die Sample- und Datenraten und ob die Verbindungen bi- oder unidirektional aufgebaut werden sollen.
Abhilfe könnte man hier beispielweise schaffen, indem man die Anzahl und
Parameter der über SIP verhandelbaren Audio- und Video-Codecs limitiert und
festlegt. Eine andere Möglichkeit wäre die Ausdehnung der Verhandlungsphase
auf mehr als drei Schritte. Hier wird sicher die von der EBU ins Leben gerufene
Arbeitsgruppe N/ACIP eine normative Rolle spielen.
Das große Interesse an SIP als Verhandlungsprotokoll für hochqualitative Medialinks haben wir den zuletzt in verschiedenen Ländern und durch verschiedene
Telekommunikationsanbieter verbreiteten Meldungen ISDN demnächst abschalten zu wollen, zu verdanken. Deutschland wird sicher für diese Umstellung noch
einige Jahre Zeit haben, da hier ISDN auch bei Privatanwendern weit verbreitet
ist. Dass eine innerdeutsche ISDN-Verbindung jedoch ab der Vermittlungsstelle
über eine IP-Strecke läuft, ist jedoch bereits heute durchaus üblich. Die bei der
Umsetzung entstehende Latenz und der Verlust eventuell mitgesendeter Zu33
Beim erstmaligen Arbeiten mit SIP, sollte man sich als SIP-user registrieren.
Alle anderen Einstellungen werden direkt beim Client (z.B. CENTAURI II) vorgenommen. Es ist ferner zu berücksichtigen, daß man an Stelle des eigenen auch
öffentliche SIP-registrars verwenden kann. Dabei ist zu berücksichtigen, daß alle
notwendigen Features unterstützt werden.
satzinformationen wäre durch eine Umstellung auf IP-basierte Übertragungen
vermeidbar. Natürlich ist auch eine IP-Strecke - teils mit erheblicher – Latenz
behaftet, die stark von der Qualität des darunterliegenden Netzes abhängt.
Die von der EBU eingesetzte Arbeitsgruppe N/ACIP beschäftigt sich mit dem
Thema Audio-Over-IP und versucht zusammen mit Herstellern, Netzbetreibern
und Anwendern Empfehlungen für die Kompatibilität zwischen Audio Codecs
bei IP Verbindungen auszusprechen. Auch hier wird SIP als ein obligatorisch zu
unterstützendes Protokoll aufgeführt.
Bei der Anpassung von SIP an die Anforderungen hochqualitativer Mediaverbindungen wird diese Arbeitsgruppe sicher das wichtigste Forum sein. Glücklicherweise sind sich alle an dieser Arbeitsgruppe Beteiligten einig darüber, dass
ein langwieriger und hindernisreicher Weg wie er bei der Einführung von ISDN
gegangen wurde, bei der Einführung von SIP verhindert werden muss.
5
Praktische Voraussetzungen für SIP und Audio-via-IP
5.1
Voraussetzungen für SIP-basierte Verbindungen über öffentliches Internet
Die erste Maßnahme für eine erfolgreiche SIP Verbindung ist die Auswahl einer
geeigneten IP-Verbindung. Z.B. gibt es in Deutschland viele verschiedene regionale und recht große Service Provider, die S-DSL Angebot mit 2 MBit/s und mehr
anbieten. Bei Kontaktaufnahme zu einem solchen Provider müssen folgende
Punkte abgeklärt werden:
■■
Kosten für die S-DSL Verbindung
■■
Minimum an Kapazität von 2 Mbit/s
■■
mindestens 3, besser 16 öffentliche IP-Adressen
■■
Auskunft über möglichen Quality-of-Service erhalten
Alle SIP-clients müssen sich bei einem speziellen SIP-registrar registrieren. Dies
kann im selben Netzwerk oder auch irgendeine IP-Adresse im öffentlichen Internet sein. Der SIP-registrar ist der Schlüssel für SIP-Verbindungen, da er wie eine
Art Telefonbuch oder Datenback mit allenverfügbaren SIP-clients funktioniert.
Es wird für SIP-Verbindungstests empfohlen sich seinen eigenen SIP registrar zu
besorgen. Dafür gibt es verschiedene Modelle, z.B. von LANCOM den 1722 VoIP,
mit dem bereits viele erfolgreiche Tests durchgeführt wurden.
34
5.2 Voraussetzungen für sonstige IP-basierte Verbindungen – Unicast versus
Multicast
Die IP Punkt-zu-Punktverbindungen werden Unicast genannt während man Multicast als Begriff für Punkt-zu-Mehrpunkt-Verbindungen verwendet. Unicast nutzt
UDP und TCP Als Transportprotokoll. Bei der Verwendung von Audio Codecs,
z.B. CENTAURI II können diese UDP Unicast Verbindungen uni- oder auch bidirektional sein. CENTAURI II TCP Verbindungen sind stets bi-direktional. Multicast verwendet UDP als Transportprotokoll. Multicast Übertragungen sind stets
uni-direktional.
Multicasting ist der richtige Weg zur Verbreitung von Multimediadaten zu den
Empfängern, da diese sich jederzeit zu- oder abschalten können. Während
Unicast für ein Kommunikationsmuster steht, welches Daten von einem zum
anderen Teilnehmer schickt, bedeutet Broadcast der Versand von einem zu allen
anderen innerhalb eines Netzwerks.
Multicast hingegen bedeutet die Bereitstellung von Daten für eine sich ändernde
Zahl an Teilnehmern, wobei diese Teilnehmer die Möglichkeit haben sich durch
Versand einer speziellen Multicastadresse in eine bestehende Multicastverbindung zu schalten.
Die Probleme mit Multicast entstehen bei der Wahl der Route vom Sender zum
Empfänger. Während normales Radio oder Fernsehen einfach Signale ausstrahlt
und diese abhängig von der Reichweite überall im Versorgungsgebiet empfangen
werden können, gibt es im Internet einige Restriktionen, wie Bandbreite und
Netzwerkauslastung. Ein richtiger Broadcast würde das Internet lahmlegen. Ein
anderes Problem ist es, die Router entsprechend richtig über die Teilnehmer an
einer Multicastverbindung zu informieren.
Die Idee des Multicast ist es möglichst wenig Bandbreite zu verwenden und
somit die Netzbelastung so gering als möglich zu halten. Anstelle Bandbreite
35
zu verbrauchen, wird das Signal nur an die Teilnehmer geschickt, die es auch
tatsächlich hören bzw. sehen wollen, diese Teilnehmer dann auf dem effizientesten und kürzesten Weg zu erreichen. Der Sender verschickt das Signal nur
einmal und es wird erst bei einem dem Empfänger nahen Router dupliziert. Das
dafür verantwortliche Protokoll nennt sich IGMP (Internet Group Management
Protocol), mit dem ein Teilnehmer mitteilt Mitglied einer Multicastgruppe werden
zu wollen. Die Multicastgruppe ist eine Anzahl an Sendern/Empfängern, die
bei deren Router für eine bestimmte Multicast-IP registriert sind. Es gibt einen
bestimmten Adressbereich der sogenannten Class-D Adressen für Multicast.
Die vier wichtigsten Bits der Class-D Adressen werden auf 1 1 1 0 gesetzt. Die
folgenden 28-bit werden „multicast group ID“ genannt und gehen von 224.0.0.0
bis 239.255.255.255.
6
Typische IP oder gemischte IP/ISDN Anwendungen
UMTS/3G/3.5G
2x Head2x
phones Line Out
MPEG-4 HE AACv2, 48 kbps
*/5&3/&5
SPORTY
stereo analogue or
digital AES/EBU
CENTAURI II
CENTAURI II
2x Mic
2x Line In
CENTAURI II
Request for Multicast
Receiving Multicast
Abb. 10
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Sender
Receiver
Receiver
Head- Line
phones Out
Sender
Sender
Sender
Übertragung vom Reporter zu mehreren Studios mit IP Multicast über UMTS/3G
Receiver
Receiver
Receiver
WLAN
Hotspot
Receiver
Eapt-X
192 kbps
stereo analogue or
digital AES/EBU
*/5&3/&5
CENTAURI II
CENTAURI II
FLASHMAN II
Abb. 9
Jedes Multicast Datensignal wird durch eine Multicast group ID definiert. Falls
ein Teilnehmer zum Senden/Empfangen bestimmter Daten einer bestimmten Multicastgruppe beitreten möchte, muß er den nächsten Router darüber
informieren, und zwar durch Versant der bestimmten Multicast ID über ein
IGMP-Telegramm. Diese ID wird dann von Router zu Router weitergereicht, um
festzustellen, ob noch andere Multicastgruppenteilnehmer(s. Abb. 9: Request
for Multicast) existieren. Natürlich kann derselbe Teilnehmer auch als Sender
agieren. In diesem Fall wird der nächte Router die Daten an alle Teilnehmer der
Multicastgruppe verschicken.
36
CENTAURI II
2x Mic Line In
Abb. 11
Übertragung vom Reporter zu mehreren Studios mit IP Multicast über einen
Hotspot/ WLAN Zugang
37
stereo digital
AES/EBU
IP
MPEG 1/2, Layer 2
384 kbps
CENTAURI II
Backup Line
Abb. 12
ganymed 1002
DAB/DRM
FM/AM
stereo digital
AES/EBU
ganymed 1002
Abb. 15
*1
stereo digital
AES/EBU
CENTAURI II
CENTAURI II
*4%/
#1
CENTAURI II
SPORTY
#2
*1
*/5&3/&5
e.g. MPEG Layer 2
192 kbps
SIP
SIP
SIP<->ISDN
Gateway 2250
up to 8x
64 kbps
e.g. MPEG-4
HE AACv2
64 kbps
*4%/
CENTAURI II
CENTAURI II
Audio Codec
#8
Audio
CENTAURI II
Abb. 16
5.1/7.1 Multichannel
4x AES/EBU
Audio
e.g. Layer 3, 128 kbps
Audio Codec
*4%/
8 Audiokanäle werden im AES/EBU Transparent Modus über IP übertragen.
Bitrate netto 12 Bit/s.
2
8
SIP<->ISDN
Gateway 2250
SIP
CENTAURI II
1
Multipoint SIP/ISDN Gateway Anwendung mit Audio kodierung Konvertierung
e.g. Eapt-X
192 kbps
5.1/7.1 Multichannel
4x AES/EBU
38
CENTAURI II
SIP
*1
Abb. 14
#n
Audio
CENTAURI II
Point-to-Multipoint Backup an bis zu 8 Gegenstellen mit einem CENTAURI mit integrierten
4 BRI Schnittstellen und HE AACv2 mit 64kbps stereo
AES Transparent
12,288 mbps
#2
SIP
MPEG-4 HE AACv2, 64 kbps
Backup Line
#1
Multicast Anwendung, Senderzuführung an viele IP Decoder
FLASHMAN II
Abb. 13
ganymed 1002
*4%/
apt-X / Eapt-X
up to 24 Bit/96 kHz, 448 kbps
stereo digital
AES/EBU
*1
CENTAURI II
Backup einer IP-via-Satellite-Strecke über ISDN mit automatischer Rückkehr zu IP
CENTAURI II
stereo digital
AES/EBU
CENTAURI II
MPEG-4 HE AACv2
64 kbps
stereo digital
AES/EBU
MPEG 2 AAC
128 kbps
CENTAURI II
Audio analogue or
digital AES/EBU
Abb. 17
ISDN/SIP Gateway Anwendung mit Audio Format Konvertierung
39
40
7
Referenzen
7.1
R. Wagner, „Das neue Verteilnetz von Telekom Austria und ORF“, FKT, Nr. 56, 7 / 2002, S. 387 – 390
7.2
G. Stoll, F. Kozamernik, “EBU subjective listening tests on low-bitrate audio codecs”, EBU, 2003
7.3
“Too many audio codecs”, Detlef Wiese, Tonmeistertagung, 2002
7.4
White Paper „Diskussion von Codierverfahren“, Detlef Wiese, 2002
7.5
White Paper “NAT Traversal for Multimedia over IP”, Newport Networks, 2005
7.6
White Paper „Understanding SIP“, D. Sisale, J. Kutan, GMD Fokus, 2000
7.7
CENTAURI II Handbuch, Werner Ludwig, 2006
Impressum
Herausgeber: MAYAH Communications GmbH, Copyright 2007,
Redaktion: Daniel Adasinsky
Autoren: Hans-Heinrich Hansen, Christian Diehl, Uwe Andersen,
Jan Simon, Werner Ludwig, Jörg Rimkus, Detlef Wiese
1. Auflage
Flashman, Centauri, Mayah sind eingetragene Warenzeichen
Layer 2 licensed from Audio MPEG, Coding Technologies
Layer 3/mp3Pro licensed from Thomson/Fraunhofer Institute
AAC / AAC HE licensed from VIA, Coding Technologies
*working name of MPEG 4, implementation from Coding Technologies
© Copyright MAYAH Communications GmbH, 2007. All rights reserved. CENTAURI®,
FLASHMAN® and MAYAH are registered trademarks. Patents pending.
Product information and technical specifications are subject to change without notice.
Audio-via-IP Kompendium
Audio-via-IP
Grundlagen, Praxis und
Anwendungen
The MAYAH range –
Professional Audio & Video Encoding/Decoding, Recording,
Mixing and Transmission Products
CENTAURI®II
Multichannel Audio Gateway Codec
Sporty
Portable Reporter Codec
MERK II
Portable Audio Codec Mixer
IO [io]
Audio Video Encoder/Decoder
ganymed
IP Audio Encoder/Decoder
Flashman II
Portable Audio Recorder/Codec
MAYAH Communications
Am Soeldnermoos 17
85399 Hallbergmoos, Germany
Tel.: +49 8115517-0, Fax: -55
E-Mail: [email protected]
www.mayah.com
AUDIOVIAIPEXPERTS
AUDIOVIAIPEXPERTSGROUP
GROUP