Thomas Osterried
IN-Berlin e.V. Berlin
Datum |
2005-04-29 Fr |
Zeit |
20h |
Ort |
IN-Berlin |
Adresse |
Lehrter Str. 53 |
Referent |
Thomas Osterried |
Thema |
VoIP / SIP |
Voice over IP - SIP
Abstrakt
VoIP ist heute in aller Munde.
Dieser Vortrag klärt die Fragen
- was ist VoIP?
- wie geht es?
- wie aufwendig ist es?
- was passiert technisch?
- Protokolle
- codecs / Bandbreite
- Routing / NAT-Problematiken
- Sicherheit (Verschlüsselung, Schutz vor Missbrauch)
- Zuverlässigkeit
- Integration bereits vorhandener TK Infrastruktur
Zielgruppe sind Privat-Anwender, d.h. es werden keine "Business"-Lösungen vorgestellt.
Nach der Einführung folgt der praktische Teil. Wir haben Leihstellungen (Hard-/Software):
- Hardware
- Grandstream-Adapter
- Zyxel WLAN Handheld
- Cisco IP-Phone
- AVM Fritz!Box Fon WLAN 7050
- Software
- Gnomemeeting
- XLite
- mit eingebautem Mikro am Notebook
- mit Headset
- Bluetooth-Headset
Vortrag
Internet-Telefonie ist seit Anfang 2004 in Aller Munde. Die Technik (H.323, SIP, ..) ist deutlich älter.
Mit der zunehmenden Versorgung der Bevölkerung mit Breitband-Zugängen kamen denn auch die Telefon-Anbieter auf den Plan, Telefonie über das Internet ins POTS (Plain old Telephone System zu vermitteln.
Standard
Die Standards
- H.323
- ITU-Standard. 1996 Version 1, 2003 Version 5 (was geschieht aktuell noch?) ITU = Internet Telecommunications Union
- SIP
- IETF-Standard- SIP+SDP(Aushandlung Codecs, Transport-Protokolle, etc..)+STP. Datenstrom wie bei H.323 in RTP. RTP ist Internet Standard (RFC). IETF = Internet Engineering Task Force
Man erkennt also schon die unterschiedliche Herkunft der Standards.
Nicht-Standard: Skype
H.323 und SIP können mehr als nur "Telefonie". Sie sind prinzipiell in der Lage, Audio und Video zu übertragen, Konferenzen zu schalten / managen, Faxe zu vermitteln, etc..
H323 ist ein sehr komplexes Protokoll (ASN1)
SIP basiert auf dem HTTP-Protokoll; ähnlicher Header-Standard. Adressierung: sip:user@domain
H323 wie SIP sind UDP basierte Protokolle. Grund: Schnell und effizient. Router können Pakete wegwerfen wenn keine Bandbreite zur Verfügung steht. Ist zwar nicht schön, bedeutet aber eine deutlich geringere Latenz als wenn der Datenstrom gesichert, z.B. auf TCP liegent, verschickt würde.
NAT
- UDP bedeutet NAT-Problem. Router erkennt eine Session nicht als solche. Arbeitet mit Timeouts. Danach anderer Source-Port. Intelligente Router lesen das SIP-Protokoll mit. Bisher so gut wie nicht auf dem Markt zu finden.
- H.323 funktioniert sehr schlecht hinter NAT.
- Bei SIP gibt es mehrere Ansätze, auch mit "dummen NAT-Routern" zuverlässig zu arbeiten
- Beispielsweise penetriert das STUN-Protokoll den NAT-Router. Dadurch vermag der eigene SIP-Client festzustellen, hinter welcher Art NAT er sitzt.
- IETF: neuer Ansatz anstelle Stun ist ICE (Interactive Connection Establishment)
- Zu gruter letzt seien sog. Applicationlayer-Gateways genannt
- Gatekeeper bei H.323
- Oder auch der Betrieb einer eigenen Nebenstellenanlagensoftware (PBX - private branch exchange)
Das führt für diesen Vortrag aber zu weit; wir beschränken uns auf die direkte Nutzer<->Nutzer bzw. Nutzer<->Anbieter Verbindung.
Sprachqualität
Die Sprachqualität hängt von verschiedenen Faktoren ab:
- IP hat keine Bandbreiten-Garantien (im Gegensatz zu z.B. ATM)
-> Packetloss, Pakete überholen sich, werden im schlimmsten Fall sogar dupliziert.
- Prioisierung (QOS) muss auf den Routern stattfinden (an Hand des UDP Ports nicht eindeutig machbar), also Type-of-Service bit.
- geringe Latenz ist wichtig (Sprachkomfort)
- Beispiel Handy: wenn Netz "überlastet", wird auf Halb-Duplex geschaltet
-> man kann nicht gleichzeitig sprechen. ..sehr gewöhnungsbedürftig
- Beispiel Handy: wenn Netz "überlastet", wird auf Halb-Duplex geschaltet
Codecs - Codierung / Digitalisierung der Sprache
- Teils standard-übergreifend; nicht alle Codecs finden sich in allen Standards
- Teils selbst standardisiert (ITU, ETSI)
Samplezeit (z.B. 20-30ms Bursts) -> mehr oder weniger "spürbare" Latenz
- mehr oder minder verlustbehaftet
- alle in VoiP verwendeten Sprachcodecs komprimieren verlustbehaftet - vgl. Konzepte wie jpeg Komprimierung in der Bildverarbeitung
- können mit "Paketverlust" umgehen
-> daher können
- die Audio-Daten als RTP-stream in udp übertragen werden
- Latenzzeit gering gehalten werden
- Begriffe die man mal gehört haben sollte:
- G.711a/u-Law, G.722, G.723.1 ACELP, G.726, G.728, G.729, GSM, iLBC, Speex
- Teils lizenzbehaftet und deshalb nicht in allen Produkten zu finden, v.a. nicht in Freier Software
Heisser Tip: iLBC. Link: http://de.wikipedia.org/wiki/Voice-over-IP (Codecs)
- G.711a/u-Law, G.722, G.723.1 ACELP, G.726, G.728, G.729, GSM, iLBC, Speex
Telefonie
Nachdem wir jetzt festgestellt haben dass und wie wir Sprache über Datennetze übertragen können, verschaffen wir uns einen Überblick über die Möglichkeiten von Internet-Telefonie, gehen auf NAT-Problematiken genauer ein, welche Rolle der z.B. ein SIP Anbieter spielt, ob das "Telefon"-Gespräch im Internet bleibt, oder ins Festnetz (POTS) geht, im Ungünstigsten Fall gar von Internet über den Anbieter ins Festnetz geht, dort vermittelt wird, und über den Anbieter des Gesprächspartners wieder ins Internet geht (was natürlich nonsense ist und absolut unerwünscht), weshalb Inter-IP-Telefonie zu allermeist kostenlos ist (man manchmal aber spezielle Vorwahlen wählen muß, welchen Vorteil dabei das enum-Verfahren bietet), etc..
Wir wollen also Internet-Telefonie machen. Dazu stellen wir uns folgende Fragen:
1. Welchen Standard möchten wir nutzen?
- a) H.323, SIP, etc.. b)
Nur Inter-Inet Telefonie? (-> Was haben Freunde / Bekannte?)
- von/nach POTs (gar als Ersatz für den traditionellen Telefonanschluß)
-> welcher Anbieter (mit oder ohne monatliche Vertragskosten, ..)
2.
- In Software? (Gibt es eine zuverlässige Applikation fuer Linux, Mac, Win$?)
- In Hardware? (kann ich z.B. mehrere SIP-Anbieter bzw. Rufnummern verwalten?)
- Mögliche Entscheidungskriterien hier: Zuverlässigkeit, Upgrade-Fähigkeit (bei Hardware: gibt es den Hersteller in einem Jahr noch?
Immerhin gibt es häufig Softwarefehler (-> Zuverlässigkeit, kaputte Codecs, Sicherheitsprobleme (ge-root'etes Telefon.. - ganz neue Dimensionen..)), Weiterentwicklung des Standards, etc..), initialie Investitionskosten (bei Software-Lösung 0), Benutzbarkeit (Telefonieren am PC bedingt, dass der PC an ist, man haeufig mit Kabel an die Soundkarte gebunden ist, dass man ggf. seine Multimedia-Programme ausmachen muss; Telefonieren mit Telefon: gewohntes Gespraechsverhalten, Bedienung wie immer)
3. DSL / Nat
- Kommt Router mit SIP oder H.323 klar (bei H.323 zumindest ist mir kein Konsumer-Produkt bekannt)?
- oder Gatekeeper oder PBX Software nötig / wünschenswert / vom Nutzer vom Aufwand her handlebar?
4. Welchen Codec..
- unterstützt der SIP-Anbieter
- meine Soft/Hardware
- Größter gemeinsamer Nenner ist G.711a/u mit 64kBit netto (~90kBit effektiv) und GSM (sehr schlechte Sprachqualität).
- G.711a/u: Habe ich die Bandbreite? Bei 128kBit aDSL upstream würde das nur zeitgleich ein Telefongespräch zulassen.
- Die DSL-Geschwindigkeit, -Latenz, -Auslastung bestimmt Entscheidung über den sinnvollsten Codec.
Die Wahl des Codecs wird zunehmend weniger wichtig, da die SIP-Software häufig selbst dynamisch den besten Codec für die aktuelle Auslastung der Leitung wählen kann (teils sogar während des Gesprächs umstellen kann)
Soft- und Hardware
Software
- ist einfach upzudaten
- s. Diskussuion um Sicherheitsprobleme
- es ist "billig", mit neuen technischen Entwicklungen mitzuhalten
- gringe Investition (ideal 0€)
- umständlich (meine persönliche Einschätzung)
- PC muss an sein; Software muß laufen; Multimedia-Anwendungen beim Telefonieren schließen
- Mikro am PC (kurze Leitung..); Eingebautes Mikro im Notebook: inakzeptabel
- Lösung: Bluetooth Headset
- entspricht nicht dem "normalen" Telefon-Verhalten
-> irritiert irgendwie beim Telefonieren; gewöhnungsbedürftig
- kann Oma mit umgehen?
- für SIP
- Mac, Win$: xlite
- Linux: linphone, kphone (naja); gnomemeeting aktuell in Entwicklung (bereits gute und stabile H.323 Applikation)
- für H.323
- Win$: Netmeeting
- Linux: gnomemeeting
Harware
- kostet $$
-> welche Hardware empfehlenswert? - 99€ will man nicht einfach so in den Sand setzen
-> s. praktischer Teil der Veranstaltung
- Firmware-Updates verfügbar? (wie Wahrscheinlich bei "noname"-Anbietern?)
- teils sehr gut, teils aber auch fehlerbehaftet
- stotternde codecs
- wenige codecs
- schlecht zu bedienen
- hält ggf. Verbindung zum Anbieter nicht
-> schlechte Erreichbarkeit
kann meinst keine Verschlüsselung (-> Privacy)
Business-Lösungen auf dem Markt vorhanden (dann aber meist komplette umstellung der TK-Infrastruktur am Standort auf VOIP); Asterisk als freie unix-Variante sei hier empfohlen
Fuer das ältere H.323 sind keine Produkte im Consumer-Bereich zu finden. Erwähnen sollte man Video-Konferenzing-Boxen, an die man den Fernseher und eine Videokamera anschließt.
An Hardware (haben wir teils hier): Cisco, Grandstream (Telefon, Adapter), Zyxel WLAN Phone, etc..
Die diversen Macken gehen wir im praktischen Teil durch
Wahl des Anbieters
* H.323
- kaum etwas zu finden.
- Meist nur Gatekeeper für Video-Konferenzen
http://www.microtelco.com/, arbeitet u.A. mit http://www.linuxjack.com/ (eine PCI Karte die Gnomemeeting bedienen kann)
* SIP:
- manche ohne Grundgebühr
- meist mit Guthaben-Konto und Online-Rechnung
mache mit gegenseitigem Abgleich des Nummernblocks anderer Anbieter (-> vermitteln Inet<->Inet Gespräche kostenlos)
manche mit ENUM Abfrage (zum ENUM-Konzept: s. http://www.denic.de/de/enum/index.html)
- Unvollständige Liste von Anbietern (wertfreie alphabetische Sortierung):
- bluesip, freenet, nikotel, mediascape, qsc, sipgate, uvam..
Links
Eine sehr schöne Doku zu dem was SIP ist hat mir google heute geliefert:
Wikipedia
http://de.wikipedia.org/wiki/Voice-over-IP (wem's nicht genügt mag es dort verbessern ;))
Linkliste zu Soft und Hardware, Anbietern. uvam:
Und wo gute Konzepte greifbar sind, ist die Telekom nicht weit:
http://www.voip-info.de/news.php - Meldung vom 6.5.2005 -- ..Herr schmeiss Hirn ra'!
Photos
Changes
Thomas
- Für die Fotos möchte ich mich ausdrücklich bedanken
- Manuskript heute abschließend online gestellt - 2005-05-15
License
(c) 2005 Thomas Osterried; GPL - see http://www.fsf.org/
Feedback
Wie hat es Euch gefallen?