Fastpath und höherer Upstream

haeberlein

Aktives Mitglied
Mitglied seit
10 Mrz 2004
Beiträge
1,717
Punkte für Reaktionen
0
Punkte
36
Hallo!
Weiss jemand unter den "Technikern" ob Fastpath und höherer Upstream Qualitätsverbesserungen bei der VoIP Telefonie bringen?
Meistens habe ich sehr gute Qualität aber manchmal ,vor allem Abend, gibts auch Aussetzer ,was nicht so toll ist. Momentan habe ich allerdings noch T-DSL 786 ohne Fastpath.
 
Diese Frage sollte man mal von Support Spezialisten von SIPGATE bzw. Nikotel beantworten lassen.
Das hat dann auch den Charakter eines offiziellen Statements, d.h. die müssten sich des Themas mal genauer annehmen.
Ich werde die Frage an SIPGATE u. Nikotel stellen.
Mal schaun was die antworten. Ich halt Euch auf den laufenden hierzu.

[highlight=red:8edd8c541f]1. Fastpath (FP):[/highlight:8edd8c541f]
Ich denke, dass es keinen Einfluss haben dürfte, ganz im Gegenteil.
Du hast zwar mit FP geringe Pingzeiten, allerdings ist auch das sogenannte "Interleaving" (IL) ausgeschaltet.
IL ist das Fehlerkorrekturverfahren bei Paketverlusten durch schlechte Leitungen, Traffic overload etc, die sich dann bei VoIP wieder durch schlechte Sprachqualität (Aussetzer) bemerkbar macht.
Allerdings kann bei VoIP das IL verfahren, eigentlich auch nicht viel retten, denn auch wenn "verlorenes" Sprachpaket "nachgeschoben" wird, als "Aussetzer" ist das ganze auf jedenfall Fall zu hören.
Ob FP oder IL, ich werde dem ganzen keine zu grosse Bedeutung beimessen. Wie gesagt wenn Pakete verloren gehen, ist es auf jedenfall hörbar, auch wenn IL die Fehler ausgleicht. Die Pingzeiten zwischen 30-100 ms mit oder ohne FP sollten ausreichend schnell seien.
Mehr Info zum Thema FP siehe unter:

http://www.fastpath.de

P.S. Vielleicht hilft zu diesem Problem, die von Grandstream ankündigte FW, die den neuen Codec iLBC unterstützt. Dieser soll ja gerade den Qualitätsverlust durch Paketverluste verbessern.

http://www.grandstream.com/y-news.htm bzw. das Attachement.

[highlight=red:8edd8c541f]Schnellerer Upload:[/highlight:8edd8c541f]
Nachdem die erforderlich Bandreite bei ca. 80 kbit/s liegt, ist also ein Standard T-DSl upload von 128 kbit/s notwendig.
Anders ist die Sache natürlich, wenn noch zusätzlich DSl Traffic in Deinem Netzwerk läuft.
Dann ist mehr Upload Bandbreite sicherlich notwendig.
Gruss
flitze101
 
habe leider von beiden Anbietern keine Antwort bekommen
 
Fastpath wirkt sich nicht aus auf VoiP.

Mehr Upload natürlich schon, denn je mehr, desto besser. :)
 
Prinzipiell, ist es natürlich immer gut möglichst viel UL Bandbreite zuhaben.
Wenn aber "nur" ca. 80kb Bandbreite gebraucht werden und was wesentlich ist, sonst kein bzw. wenig Verkehr in Deinem Netzwerk ist, dann sollten auch 128kb UL für die erforderlich Qualität reichen.

Die Qualität wird nicht besser wenn Du mehr hast.

Die Qualitätseinbussen, Paketverlust, Traffic overload entstehen ausserhalb des Einflussbereiches von Deinem lokalen Netzwerk. Also hinter dem DSLAM (Digital Subscriber Line Accesss Multiplexer), Broadband Remate Access Server (BRAS) bzw. den beteiligten Routern des Internets, weil dort kein QOS für Deine Sprachverbindung garantiert wird.

Grundsätzlich gibt es zwei Möglichkeiten, die verbindungsorientierte Telefonie auf ein paketorientiertes Netzwerk abzubilden. Für VoIP in Firmenumgebungen hat sich derzeit H.323 als Standard etabliert. H.323 hatte ein klassisches Telefonnetz als Vorbild und stellt quasi eine Erweiterung auf Verbindungen über Datenpakete dar.
Für Heimuser ist der zweite Standard namens SIP interessanter. Bei SIP (Session Initiation Protocol) hat man sich die paketorientierte Kommunikation vorgenommen und dieser Features wie Verbindungsauf- und -abbau zwischen Teilnehmern beigebracht. Hierbei werden auch Problematiken berücksichtigt, welche in Firmennetzen nicht auftauchen. Unternehmen haben üblicherweise die volle Kontrolle über ihr Netzwerk, die Routen von Paketen durch das Netzwerk sind festgelegt, und Paketverluste treten nicht auf. All dies ist bei VoIP über das weite Internet nicht gewährleistet: der Telefonie-Anbieter muss nicht zwangsläufig auch der Anbieter des Breitbandanschlusses, über den die Sprach-Datenpakete wandern, sein. SIP setzt sich als flexibleres und wenig komplexes Protokoll aber auch im Geschäftbereich immer mehr durch.


Quality of Service
Ein weiterer Knackpunkt ist QoS, die Qualität eines Dienstes (auch Dienstegüte genannt). Bei einem herkömmlichen Telefonat wird zum Gesprächsbeginn eine Verbindung zwischen den beiden Teilnehmern geschaltet. Für die Dauer des Gesprächs hat man dann diese Leitung fest gebucht, und kein anderer Teilnehmer kann die reservierte Bandbreite mitbenutzen (auch nicht, wenn beide Gesprächspartner gerade mal nichts sagen).
Bei der paketorientierten Kommunikation im Internet ist dies anders: es gibt weder einen festen Weg, noch kann man sich auf eine bestimmte Bandbreite verlassen. Es ist sogar die regel, dass man sich die Bandbreite mit vielen anderen Paketen verschiedenster Dienste teilt. Aufeinanderfolgende Pakete können auch durchaus mal den Weg über verschiedene Router und Routen nehmen. Je nach Auslastung der Routen können Pakete schon mal verloren gehen oder in unterschiedlicher Reihenfolge beim Empfänger ankommen.

Um zeitkritische Anwendungen wie Telefonie dennoch über ein paketorientiertes Netzwerk betreiben zu können, benötigt man eine Paketpriorisierung. Diese kann je nach verwendetem Protokoll anders aussehen. Router können dann bei Überlastung die Pakete mit einer höheren Priorität vorrangig behandeln
Im Header jedes IP-Paketes gibt es ein Feld namens ToS (Type of Service), mit dem der Diensttyp und damit seine Priorität definiert werden kann. Allerdings ist der derzeit gebräuchliche IP-Standard mit der Versionsnummer 4 schon wieder so alt, dass zu der Zeit, als er festgelegt wurde, niemand ernsthaft an Quality of Service gedacht hat. Dementsprechend stiefmütterlich wird das ToS-Feld auch in aktuellen Hard- und Software-Implementierungen bedacht, nämlich meist gar nicht.

Dies bekommt man nun bei der IP-Telefonie im Heimbereich zu spüren. Damit ein IP-Telefon jederzeit mit seiner zugedachten Aufgabe bereit steht, muss die Verbindung ins Internet möglichst permanent bestehen. Damit bleiben Internet-Tarife, die minutenbasiert abgerechnet werden, schon mal außen vor, wenn das Ganze noch finanzierbar bleiben soll. Besser sind hier Tarife mit definiertem Übertragungsvolumen, am Besten gleich eine Flatrate. Üblicherweise lässt ein Flatrate-Kunde die Verbindung aber nicht ungenutzt bestehen, sondern erzeugt einen mehr oder minder großen Datenverkehr. Vor allem Tauschbörsen sorgen für eine nicht gerade geringe Bandbreitenauslastung.
Der übliche DSL-Anschluss bietet zwar einen ausreichend großen Downstream aus dem Internet nach Hause; der Upstream hingegen beträgt nur ein Bruchteil des Downstreams. Für normale Downloads spielt das keine Rolle, der Weg ins Internet wird nur selten ausgenutzt. Deshalb merkt man üblicherweise auch keinen Unterschied, ob nun eine Tauschbörse den Upstream nun zu einem Großteil ausfüllt oder nicht.

Will man jedoch nun über denselben Anschluss telefonieren, ändert sich die Situation schlagartig. VoIP benötigt in beiden Richtungen dieselbe Bandbreite; 80 kbps sollten schon bereit stehen. Zusätzlich sind VoIP-Datenpakete auch noch sehr zeitkritisch und müssen möglichst verzögerungsfrei weitergeleitet werden. Tauschbörsen bauen zudem noch permanent Verbindungen zu anderen Teilnehmern auf und ab, so dass die eine VoIP-Verbindung einfach in der Masse untergehen muss. Es kann also passieren, dass man dank großzügigem Downstream seinen Gesprächspartner gut verstehen kann, während dieser aufgrund eines völlig überlasteten Upstreams nur Wortfetzen und Knackser zu hören bekommt.

Quellenhinweis:
http://www.k-hardware.de/artikellist.php?s=&kat_id=3&prtype_id=89
 
iLBC kannste vergessen!!!

Bei Nikotel wirds garnciht untersützt!

Bei SIPGATEe.. weis nicht... Kann da jemand was zu sagen?!
 
Mal für alle etwas zum Nachlesen, um die Verwirrung zu entwirren :D

http://www.lanline.de/O/148/Y/82692/VI/2429849/default.aspx

Ob FP oder IL, ich werde dem ganzen keine zu grosse Bedeutung beimessen. Wie gesagt wenn Pakete verloren gehen, ist es auf jedenfall hörbar, auch wenn IL die Fehler ausgleicht.

Laut dem obigen Artikel gehören Pakete besser nicht nachgeliefert, lieber verworfen. Demnach dürfte ausgeschaltetes IL in diesem Fall besser sein.
*Ist Fastpath nicht eine geniale Lufterfindung, WENIGER IST MEHR ! weniger "Service" bedeutet mehr Kosten :D *..nur am Rande..* Hier wird der Kunde wieder einmal veräppelt.

Im Header jedes IP-Paketes gibt es ein Feld namens ToS (Type of Service), mit dem der Diensttyp und damit seine Priorität definiert werden kann. Allerdings ist der derzeit gebräuchliche IP-Standard mit der Versionsnummer 4 schon wieder so alt, dass zu der Zeit, als er festgelegt wurde, niemand ernsthaft an Quality of Service gedacht hat. Dementsprechend stiefmütterlich wird das ToS-Feld auch in aktuellen Hard- und Software-Implementierungen bedacht, nämlich meist gar nicht.

Hier gibt es von der Firma Linksys einen Kabel/DSL Router mit integrierten 4fach Switch der QoS IEEE802.1p und IP TOS/DS ermöglicht.
Info zum Router -> http://www.linksys.com/products/product.asp?grid=34&scid=29&prid=604 Preis unter 100€

Laut einem Post auf diesem Forum ist es sogar möglich, dass durch Firmwareupgrade eines WireLessLan Routers ebenfalls QoS möglich ist.
Link zum Artikel -> http://www.ip-phone-forum.de/forum/viewtopic.php?t=117

Ebenfalls ein Linksysgerät von einem Tochterunternehmen von Cisco, scheinbar stecken in diesen Geräten verborgene Funktionen :D... Da spart man sich wohl Produktionskosten in dem dieselbe Platine verbaut wird ;)
 
Faspath wirkt sich zumindest in der Theorie positiv auf VoIP aus, weil die Netz-Latenz etwa 30ms kürzer ist (je Richtung) gegenüber einen "normalen" T-DSL-Anschluss.

Sipgate nutzt übrigens folgende Codecs:

a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:10 L16/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000
 
Tor schrieb:
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:10 L16/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000

Wie gewinnst du diese Daten? Ich konnte über Sipgate mit iLBC kein Gespräch aufbauen, und Sipgate unterstützt laut Auskunft des Supports iLBC nicht und weiß auch nicht, wann und ob es überhaupt mal unterstützt wird.
 
Der Sipgate-Server signaliert ankommende Gespräche so (im SDP-Body der SIP-Nachricht). Ob es tatsächlich funktioniert habe ich nicht ausprobiert und wenn du es erwähnst bin ich am Überlegen ob Sipgate nicht eine andere Software für abgehende Gespräche benutzt. Schaue ich mir nachher an.

Gruß, Tor
 
Etwas OT, aber ich will nochmal sicher gehen: Sipgate bietet dem Adapter/Telefon/Software beim Verbindungsaufbau diese ganzen Codecs an, aus denen sich dann letztere den Gewünschten aussuchen!?
 
Robinson: Fast. Dein Endgerät antwortet mit einer ähnlichen Liste der unterstützten Codecs und die Reihenfolge in der Liste entspricht die Priorität. Die erste Übereinstimmung wird also verwendet.

Wenn dein Endgerät einen bestimmten Codec erzwingen will, kann diese Liste selbstverständlich auch nur einen Eintrag haben.

Gruß, Tor
 
Super!! Auf diese Info warte ich schon lange!!! :groesste:
 
Ich konnte es jetzt ausprobieren: Sipgate bietet bei abgehenden Gesprächen nur PCMA, PCMU, GSM und iLBC.

Gruß, Tor
 
Ins festnetz oder zu einem anderen IP Nutzer???
 
Ins Festnetz, aber ich hätte es vielleicht auch wirklich probieren sollen.

Der Server meint zwar, dass er GSM und iLBC unterstützt, lehnt aber solche abgehende Verbindungen ab. Bei ankommende Verbindungen klappt GSM. Bei iLBC wird die Verbindung aufgebaut, aber die Sprachübertragung Festnetz->Sipgate ist gestört.

Gruß, Tor
 
So, und jetzt bin ich mal wieder etwas verwirrt. Mein Anschluß hat nur 64kbit/s upstream, PCM ist also nicht möglich. Trotzdem kann ich raustelefonieren, wenn ich G729 einstelle. D.h. doch, dass der G729 bei abgehenden Gesprächen akzeptiert wird!? Hast Du jetzt die Richtungen vertauscht (abgehend/eingehend vom Server oder von mir aus gesehen) oder wo steckt der Hacken? Ankommende Gespräche kann ich nicht annehemen, da die anscheinend immer mit PCM verbunden werden, was zusammen mit Deinen Informationen meine "Theorie des Vertauschens" bestätigt!?

Wo Du schonmal am Testen bist, wie sieht es mit Nikotel aus?
 
Ich meinte abgehend/ankommend von dir aus gesehen, aber die Signalierung ist ja sowieso falsch. Wenn nicht unterstützte Codecs aufgelistet werden, kann es ja auch sein, dass unterstützte Codecs nicht aufgelistet werden. Da in beiden Fällen die Software Asterisk eingesetzt wird, ist es auch merkwürdig, dass Codecs nur in eine Richtung funktionieren sollten. Vielleicht gehen die Gespräche über verschiedene Gateways, die unterschiedlich konfiguriert sind. Oder ist eine Sache von geht mal, geht mal nicht. Gerade konnte ich auch abgehende Verbindungen mit GSM und iLBC aufbauen, wo bei iLBC die Sprachübertragung aber auch nur in eine Richtung funktioniert.

Bei Nikotel kann ich nicht testen, da ich kein Guthaben mehr habe und so weder anrufen noch angerufen werden kann. SIPPS und X-Lite kann aber den ganzen SIP-Traffic anzeigen. SIPPS unter "Erweitert -> Session Logdatei" und X-Lite unter "Advanced System Settings -> Diagnostics -> Diagnostic Logs". Du musst nur die richtige Nachricht erwischen und erkennen was vom Server kommt und was von deiner Software geschickt wird, was zumindest bei X-Lite recht einfach ist.´

Ein Rufaufbau wird so signaliert (abgehendes Gespräch):

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 217.228.214.54:5061;rport;branch=z9hG4bK80D21BD18DD6442CBA1CE205BCA6D6AC
From: Sipgate <sip:[email protected]:5061>;tag=870957238
To: <sip:[email protected]>
Contact: <sip:[email protected]:5061>
Call-ID: [email protected]
CSeq: 21818 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite release 1103a
Content-Length: 200

v=0
o=8009110 1029062 1029078 IN IP4 217.228.214.54
s=X-Lite
c=IN IP4 217.228.214.54
t=0 0
m=audio 7004 RTP/AVP 98 101
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Hier habe ich in X-Lite nur iLBC aktiviert und der Sipgate-Server antwortet so:

SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 217.228.214.54:5061;rport=5061;branch=z9hG4bK80D21BD18DD6442CBA1CE205BCA6D6AC
From: Sipgate <sip:[email protected]:5061>;tag=870957238
To: <sip:[email protected]>;tag=as560e9e9b
Call-ID: [email protected]
CSeq: 21818 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 218

v=0
o=root 27060 27060 IN IP4 217.10.66.69
s=session
c=IN IP4 217.10.66.69
t=0 0
m=audio 14140 RTP/AVP 97 101
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:eek:ff - - - -



Gruß, Tor
 
Guter Tip mit der Logdatei in SIPPS, hatte ich noch gar nicht gefunden! Darin sieht man u.a. auch, dass Sipgate mit Asterisk-Software und Nikotel mit Cisco-Hardware arbeitet.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.