Konzeptueller Ablauf einer Videokonferenz über SIP/RTP

Aus Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Grundlegendes

  • es gibt konzeptuell zwei Stellen: Anrufer und Gegenstelle
  • entspricht in Netzwerk-Termen: Client und Server
  • alle Teilnehmer können sowohl Anrufer als auch Gegenstelle werden
  • eine dritte Stelle kann eine Vermittlungsrolle übernehmen

Netzwerk-Protokolle

  • SIP dient dem Aushandeln der Konferenz
  • RTP der Übertragung nach erfolgreicher Aushandlung
  • beide können durch eine Firewall gestört werden und einen Vermittler erforderlich machen

Szenario

  • ein Anrufer möchte gerne eine Gegenstelle anrufen

Hürde 1: Wo ist die Gegenstelle ?

  • IP+Port der Gegenstelle (Server) müssen dem Anrufer bekannt sein, sind es aber i.d.R. nicht
  • Lösung: Auflösung Nutzername auf IP+Port über ID@Provider Token, z.B. matthias.bock@ekiga.net
    • SIP-Provider werden auch Registrar genannt
  • jedes Telefon teilt seine IP+Port dem ihm einkonfigurierten Provider/Registrar beim Online-Gehen mit:
Hallo Ekiga, ich bin übrigens hier zu erreichen
  • dazu muss das Telefon seine externe IP+Port u.U. erst herausfinden
    • Protokoll: STUN
    • fragt einen oder mehrere Server, welche IP+Port sie als Absender sehen, wenn hier sie kontaktiert
    • Port ist wichtig, für den Fall dass Port-Mapping vorliegt (z.B.: mehrere SIP-Nutzer im LAN)
  • danach: Telefon -> SIP -> ekiga.net
PUBLISH sip:meinsipaccount@ekiga.net
User-Agent: Ekiga/3.3.2
Via: SIP/2.0/UDP hier = 92.144.31.32:5064
  • ein PUBLISH ist kurzlebig: eine bis mehrere Minuten -> Anwesenheit muss immer wieder bestätigt werden (push)
  • der Provider teilt IP+Port auf Nachfrage dem Anrufer mit:
Hallo Ekiga, ist der matthias.bock erreichbar ?
Ja, der ist dort
  • die Nachfrage ist i.d.R. nur am Provider authentifizierten Teilnehmern möglich (die dort ebenfalls einen Account haben)
    • das erschwert (zunächst) Cross-Provider-Gespräche
    • -> Peering = Provider vermitteln untereinander ...

Konferenz aushandeln (technisch)

  • technisch: Anrufer -> SIP -> ekiga.net
INVITE matthias.bock@ekiga.net
SDP Session Description: unterstützte Codecs hier
...
  • Ekiga antwortet: ekiga.net -> SIP -> Anrufer
Giving a try
  • an der Gegenstelle kommt die Einladung an: ekiga.net -> SIP -> Gegenstelle
INVITE matthias.bock@ekiga.net
From: meinsipaccount@ekiga.net
User-Agent: Ekiga/3.3.2
Via: SIP/2.0/UDP hier = 92.144.31.32:5064
...
  • die Gegenstelle antwortet: Gegenstelle -> SIP -> ekiga.net
Trying, Ringing
  • Ekiga bestätigt dem Anrufer: ekiga.net -> SIP -> Anrufer
OK
SDP Session Description: unterstützte Codecs dort
  • Anrufer weiß nun, IP+Port sowie unterstützte Codecs der Gegenstelle
  • Anrufer versucht eine direkte Verbindung zur Gegenstelle ...
Hallo dort, wollen wir telefonieren ?

Hürde 2: durch das Feuer sprechen

  • eine Firewall weist die Verbindungsanfrage aus dem Internet zurück
Du kummst dort ned rein!
  • eine Firewall, das kann Hardware (z.B. Internet-Router) oder Software sein (z.B. Windows-Firewall, ZoneAlarm, Kaspersky, Norton etc.)

der Empfänger muss u.U. erst die relevanten Ports am Router zum Endgerät durchschalten

  • die Videokonferenz-Software kann das potentiell automatisch machen, per UPnP:
Lieber Router, bitte stelle es mir durch,
wenn diese und jene relevanten Ports hier aus dem Internet kontaktiert werden
  • Probleme:
    • nicht jeder Router kann UPnP
    • u.U. ist es zwar verfügbar, aber nicht (standardmäßig) aktiviert
  • kann man vom Endnutzer erwarten, dass er die Router-Konfigurationsseite öffnet und UPnP aktiviert ?
  • wenn das nicht geht, kann man erwarten, dass er den Port ggf. manuell durchstellt ?
  • -> im Regelfall eher nicht, deshalb muss es für diesen Fall einen Workaround geben:

wenn die Verbindung zustandegekommen ist ...

  • ... übertragen sich beide Seiten gegenseitig und im Regelfall direkt (ohne Vermittler) über das Internet einen Audio und ggf. auch einen Video-Stream
  • Protokoll: RTP über UDP über IP/IPv6
    • UDP port range 5000-5100
    • Real-Time Transport Protocol: RTP version, Paypload type (Audio und/oder Video), Payload
  • Audio-Codecs:
    • SPEEX
    • GSM
    • ...
  • Video-Codecs:
    • Theora
Meine Werkzeuge
Namensräume
Varianten
Aktionen
Navigation
Werkzeuge