A+ A A-

VoIP/RTP

Zur Diskussion von Anforderungen an Transportprotokolle aus Sicht von Streaming-Anwendungen steht im Labor C055 folgende Voice-over-IP-Infrastruktur zur Verfügung:

labor voip

Vier Rechner im Labor sind als VoIP-Clienten, sogenannte User Agents (UA), unter Ubuntu konfiguriert. Als Telefonie-Anwendung ist das Programm Linphone installiert. Jeder dieser Rechner verfügt über eine Kurzwahlnummer. Die VoIP-Kommunikation ist lediglich im Repeater angebundenen Netzwerk verfügbar. Die Registrierung der User Agents und die Vermittlung der VoIP-Kommunikation erfolgt über den im Labor befindlichen Asterisk-Server (Registrar und SIP-Proxy). Eine Anbindung der VoIP-Infrastruktur an das Internet ist zurzeit nicht gegeben. Alle weiteren Rechner des Labors dienen zum Mitschnitt der VoIP-Kommunikation.

Ablauf der Kommunikation
Grundlage von Voice-over-IP ist die Übertragung der Telefonie-Daten über das IP-Protokoll. Im Folgenden soll ein möglicher Kommunikationsablauf für VoIP vorgestellt werden. Möchte ein User Agent mit einem anderem User Agent telefonieren, muss zunächst eine Sitzung (Session) zwischen ihnen aufgebaut werden. Hierbei verständigen sich die User Agents über die Regeln, nach denen die Sprachübermittlung stattfinden soll. Der Sitzungsaufbau erfolgt über den Asterisk-Server nach dem Muster UA1 <-> Proxy (Asterisk) <-> UA2. Zum Aufbau der Sitzung wird das Signalisierungsprotokoll Session Initial Protocol (SIP) eingesetzt. Ein Bestandteil von SIP ist das Session Description Protocol (SDP) mit dessen Hilfe die Vereinbarungen zur Sitzung an die nachfolgende Sprachübermittlung übergeben werden. Nachdem eine Sitzung über das SIP erfolgreich aufgebaut wurde, schließt sich die Phase der Sprachübermittlung an. Zur Übermittlung der Sprachdaten wird das Real-Time Transport Protocol (RTP) eingesetzt. Die Sprachdaten werden direkt zwischen den UAs ausgetauscht, also nach dem Muster UA1 <-> UA2. Um den Verlauf der Kommunikation zu kontrollieren, werden ständig Statusberichte zwischen den User Agents ausgetauscht. Dieser Austausch erfolgt über das Protokoll Real-Time Control Protocol (RTCP). Ist das Telefonat beendet, wird die vormals eingerichtete Sitzung über das Protokoll SIP abgebaut. Nachfolgende Abbildung angelehnt [BSI05] stellt den beschriebenen Ablauf dar.

voip ablauf voip

Möchte UA1 mit UA2 telefonieren, so sendet UA1 zunächst einen INVITE-Request an den Proxy. Der Proxy antwortet mit einem TRYING und signalisiert UA1 damit, dass seine Anfrage bearbeitet und an den gewünschten Teilnehmer weitergeleitet wird. Bei UA2 klingelt es. Das wird UA1 über ein RINGING signalisiert. Nimmt UA2 in Folge das Gespräch an (z.B. indem der Telefonhörer abgehoben wird), sendet dieser die Statusmeldung OK, die von UA1 mit einem ACK beantwortet wird. Danach kann das Telefongespräch mittels RTP übertragen werden. Wird das Gespräch z.B. von UA2 beendet, sendet dieser eine BYE-Nachricht, die von UA1 mit der Statusnachricht OK quittiert wird.

 
Begriffsdefinitionen
In einem VoIP-Szenario handelt es sich bei den Nutzdaten um Telefoniedaten, also um das Gespräch selbst. Da oben beschriebener Ablauf und die zugehörigen Protokolle auch für weitere Mediendaten wie z.B. Video eingesetzt werden kann, soll eine Begrifflichkeit definiert werden, die im Folgenden allgemeingültig verwendet werden kann.
Stream: Ein Stream umfasst die Gesamtheit der zu übertragenen Mediendaten (Video, Audio…) bezüglich einer Sitzung. Beispiele für einen Stream sind ein Telefonat, ein Video oder ein Live-Konzert.
Payload: Ein Stream, den es zu transportieren gilt, wird in den meisten Fällen über mehrere RTP-Pakete übermittelt. Die in einem RTP-Paket übertragenen Nutzdaten wird als Payload bezeichnet. Die Menge aller Payloads einer zugehörigen Sitzung ergeben den Stream.

 
Protokolle
Im Folgenden werden nur die für den Transport von Streamingdaten maßgeblichen Protokolle, insbesondere das RTP, erläutert. Für weitere Protokolle im Bereich Voice over IP siehe [Bada05].

Session Initial Protocol (SIP)
Das Session Initial Protocol wird zur Einrichtung einer Sitzung zwecks Übertragung von Payloads eingesetzt. SIP liegt aktuell in der Version 2.0 vor und ist im RFC3261 spezifiziert. Es ist ein textbasiertes Protokoll, ähnlich aufgebaut wie HTTP. Der Austausch von Nachrichten erfolgt nach dem einfachen Request-Response-Muster. SIP nutzt überwiegend UDP als Transportprotokoll, der Well-Known Port ist 5060. Die SIP-Adressierung ist gemäß dem URL-Schema, z.B. user@domain oder user@ip-address.
 
Session Description Protocol (SDP)
Über das Session Description Protocol, welches Bestandteil von SIP ist, verständigen sich die User Agents während des Sitzungsaufbaus über die Regeln, nach denen die anschließende Übermittlung der Payloads erfolgen soll. So werden wichtige Parameter wie Medientyp oder Kodierungsart (Codecs) ausgehandelt. Die in einer Sitzung über SDP getroffenen Vereinbarungen werden in der nachfolgenden Phase der Übertragung der Payloads übernommen. Das Protokoll SDP ist im RFC 4566 festgelegt.
Im Normalfall vereinbaren die User Agents im Labor C055 den Codec G711 PCMA, der folgende Parameter aufweist (siehe RFC 3551):
Payload Type = 8; Payload-Größe = 160 Bytes; 1 Paket je 20 Millisekunden;  Media Type = Audio  

Real-Time Transport Protocol (RTP)
Nachdem eine Sitzung aufgebaut ist, wird  der Stream als eine zusammenhängende Folge von RTP-Paketen übermittelt. RTP nutzt üblicherweise UDP als Transportprotokoll und ist in RFC 3550 spezifiziert. Nachfolgende Abbildung nach RFC3550 zeigt den RTP-Header.

voip rtp-header 
Wichtige Header-Elemente sind:
- PT (Payload Type): Die Payload Type beschreibt zum einen den Medientyp, wie z.B. Audio, und zum anderen die
  Kodierungsart. Mögliche Kodierungsprofile sind im RFC 3551 beschrieben. Die Payload Type kann im Verlauf der
  Sitzung gewechselt werden.
- Sequence Number: Die Sequenznummer ist 16 Bit lang. Mit jedem RTP-Paket wird die Sequenznummer eines jeden
  User Agents um 1 inkrementiert. Die initiale Sequenznummer wird zufällig generiert.
- Timestamp: Der Zeitstempel beschreibt den relativen Zeitpunkt der Generierung des Payloads. Der Anfangswert wird ebenfalls zufällig ausgewählt.
- SSRC (Synchronization Source Identifier): Der Synchronisation Source Identifier (SSRC) ermöglicht eine eindeutige
  Identifizierung der Absenderquelle, wie z.B. ein Mikrofon oder eine Kamera.

 
Real-Time Control Protocol (RTCP)
RTCP dient zur Ergänzung von RTP und ist wie dieses in RFC 3550 spezifiziert. Über RTCP können die über RTP übermittelten Daten analysiert und kontrolliert werden. So tauschen die User Agents im Verlauf einer Sitzung ständig Statusberichte aus, die unter Umständen eine Reaktion wie z.B. Änderung der Payload Type oder Reduzierung der Bitrate zur Folge haben.



Literatur
[Bada05] A. Badachl: Voice over IP – Die Technik. Hanser Verlag, 2005.

[RFC4566] M. Handley, V. Jacobson: Request for Comments: 4566, SDP: Session Description Protocol. Juli 2006

[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler: Request for Comments: 3261 , SIP: Session Initiation Protocol. June 2002

[RFC3550] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: Request for Comments: 3550, RTP: A Transport Protocol for Real-Time Applications. Juli 2003.

[RFC3551] H. Schulzrinne, S. Casner: Request for Comments: 3551, RTP Profile for Audio and Video Conferences with Minimal Control. July 2003.

[BSI05] A. Adelsbach, A. Alkassar, K.-H. Garbe, M. Luzaic, M. Manulis, E. Scherer, J. Schwenk, E. Siemens: „VoIPSEC, Studie zur Sicherheit von Voice over Internet Protocol“, Bundesamt der Sicherheit in der Informationstechnik (BSI), 2005. 

Template Design © Joomla Templates | GavickPro. All rights reserved.

Log in to your account or Create an account