Stottern in der Leitung trotz QoS

[freak96]

Hallo zusammen,
ich betreibe schon einige Jahre einen Asterisk-Server auf einer VPS bei netcup. Daran angeschlossen sind SIP Telefone von snom beziehungsweise Gigaset Dect Handys über die N510 Basisstation. Als Router wird eine Fritz!Box 7390 an einem easybell DSL-Anschluss verwendet (13500 Down- und 1100 kbit Upload).
Seit einiger Zeit kommt es vermehrt zu schlechter Gesprächsqualität eingehend, d.h. ich kann den Anrufer nicht verstehen, die andere Richtung ausgehend ist einwandfrei. Es reicht bereits zeitgleich ein YouTube Video zu schauen und der Gesprächspartner ist nicht mehr zu verstehen.

Auf der Asterisk-Seite werden die Daten mit tos=cs3 / cos=3 für SIP und tos_audi=ef / cos_audio=5 gekennzeichnet. In den Paketen stehen die DSCP Parameter auch drin, das konnte ich mit tcpdump überprüfen. Nur leider kommt davon an der FritzBox und am Telefon selber nichts mehr an, hier Auszüge aus den Mitschnitten:

###Asterisk -> phone, packet sent by Asterisk
Frame 6219: 224 bytes on wire (1792 bits), 224 bytes captured (1792 bits)
Ethernet II, Src: <Asterisk mac> (<Asterisk mac>), Dst: IETF-VRRP-VRID_0a (00:00:5e:00:01:0a)
Internet Protocol Version 4, Src: <Asterisk ip>, Dst: <home ip>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xb8 ([B]DSCP: EF PHB[/B], ECN: Not-ECT)
    Total Length: 210
    Identification: 0x31b7 (12727)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x7d7c [validation disabled]
    [Header checksum status: Unverified]
    Source: <Asterisk ip>
    Destination: <home ip>
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 32482, Dst Port: 49436
GigE Vision Streaming Protocol  ##SRTP, vermutlich von Wireshark falsch erkannt


###Asterisk -> phone, same packet received by phone
Frame 802: 228 bytes on wire (1824 bits), 228 bytes captured (1824 bits)
Ethernet II, Src: AvmGmbh_a1:6e:a5 (c0:25:06:a1:6e:a5), Dst: SnomTech_35:c4:ac (00:04:13:35:c4:ac)
Internet Protocol Version 4, Src: <Asterisk ip>, Dst: 192.168.178.39
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 ([B]DSCP: CS0[/B], ECN: Not-ECT)
    Total Length: 210
    Identification: 0x31b7 (12727)
    Flags: 0x02 (Don't Fragment)
    Fragment offset: 0
    Time to live: 55
    Protocol: UDP (17)
    Header checksum: 0x1181 [validation disabled]
    [Header checksum status: Unverified]
    Source: <Asterisk ip>
    Destination: 192.168.178.39
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 32482, Dst Port: 49436
GigE Vision Streaming Protocol


##phone -> Asterisk, packet sent by phone
Frame 801: 224 bytes on wire (1792 bits), 224 bytes captured (1792 bits)
Ethernet II, Src: SnomTech_35:c4:ac (00:04:13:35:c4:ac), Dst: AvmGmbh_a1:6e:a5 (c0:25:06:a1:6e:a5)
Internet Protocol Version 4, Src: 192.168.178.39, Dst: <Asterisk ip>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xa0 ([B]DSCP: CS5[/B], ECN: Not-ECT)
    Total Length: 210
    Identification: 0x4205 (16901)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x3793 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.178.39
    Destination: <Asterisk ip>
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 49436, Dst Port: 32482
GigE Vision Streaming Protocol


##phone -> Asterisk, same packet received by Asterisk
Frame 6216: 224 bytes on wire (1792 bits), 224 bytes captured (1792 bits)
Ethernet II, Src: JuniperN_7d:60:c0 (f0:1c:2d:7d:60:c0), Dst: <Asterisk mac> (<Asterisk mac>)
Internet Protocol Version 4, Src: <home ip>, Dst: <Asterisk ip>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 ([B]DSCP: CS0[/B], ECN: Not-ECT)
    Total Length: 210
    Identification: 0x4204 (16900)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 56
    Protocol: UDP (17)
    Header checksum: 0xb5e7 [validation disabled]
    [Header checksum status: Unverified]
    Source: <home ip>
    Destination: <Asterisk ip>
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 49436, Dst Port: 32482
GigE Vision Streaming Protocol

## phone -> sipgate, @fritzbox
Frame 7115: 232 bytes on wire (1856 bits), 232 bytes captured (1856 bits)
Logical-Link Control
Ethernet II, Src: AvmGmbh_a1:6e:a8 (c0:25:06:a1:6e:a8), Dst: HuaweiTe_e9:a9:ce (30:d1:7e:e9:a9:ce)
PPP-over-Ethernet Session
Point-to-Point Protocol
Internet Protocol Version 4, Src: <home ip>, Dst: 212.9.44.249
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xa0 ([B]DSCP: CS5[/B], ECN: Not-ECT)
    Total Length: 200
    Identification: 0x6332 (25394)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 63
    Protocol: UDP (17)
    Header checksum: 0x81dd [validation disabled]
    [Header checksum status: Unverified]
    Source: <home ip>
    Destination: 212.9.44.249
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 50546, Dst Port: 23276
Real-Time Transport Protocol


## sipgate -> phone @fritzbox
Frame 7116: 232 bytes on wire (1856 bits), 232 bytes captured (1856 bits)
Logical-Link Control
Ethernet II, Src: HuaweiTe_e9:a9:ce (30:d1:7e:e9:a9:ce), Dst: AvmGmbh_a1:6e:a8 (c0:25:06:a1:6e:a8)
PPP-over-Ethernet Session
Point-to-Point Protocol
Internet Protocol Version 4, Src: 212.9.44.249, Dst: <home ip>
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 ([B]DSCP: CS0[/B], ECN: Not-ECT)
    Total Length: 200
    Identification: 0x0000 (0)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 55
    Protocol: UDP (17)
    Header checksum: 0xedaf [validation disabled]
    [Header checksum status: Unverified]
    Source: 212.9.44.249
    Destination: <home ip>
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 23276, Dst Port: 50546
Real-Time Transport Protocol

Wenn ich testweise einen Sipgate-Account auf dem Telefon eintrage fehlen die QoS/DSCP-Parameter bei sämtlichen eingehenden Paketen ebenso, d.h. ich vermute das Problem eher bei easybell/Telefonica als im Asterisk. Hat jemand da ähnliche Probleme (gehabt) bzw. kann mir sagen inwieweit die DSCP-Werte überhaupt an der Fritz!Box ankommen (sollten)?
Ich habe die eingebaute Mitschneidefunktion der Fritz!Box benutzt, da waren auch noch PPPoE-Pakete dabei, insofern gehe ich mal davon aus, dass diese noch nicht von der FritzBox bearbeitet wurden.
Die Situation derzeit ist auf Dauer untragbar, dann müsste ein neuer Provider her, von dem ich sicher weiß, dass QoS unterstützt und weitergeleitet wird, auch wenn ich mir nicht vorstellen kann, dass easybell dies nicht tut?! Mehr Bandbreite geht leider nicht.

Vielen Dank!

 

[thtomate12]

Zeigt die FB Fehler bei DSL-Verbindung an?

 

[andreas00]

Die Situation derzeit ist auf Dauer untragbar, dann müsste ein neuer Provider her, ...

Da kann ich dich beruhigen. Denn deine Bedenken in Bezug auf die Sprachqualität der Telefonie über easybell kann ich nicht bestätigen. Auch wenn ich meinen Hybrid-VDSL-Anschluß der Telekom bis zum Anschlag - was den Down- und Upload betrifft - nutze, ist in beiden Richtungen die Sprachqualität der Telefonie über easybell hervorragend. Auch mehrere Gespräche gleichzeitig oder auch gleichzeitig ein Fax versenden sind kein Problem.

 

[freak96]

@thtomate ja, vereinzelt zeigt die FB Fehler an. Die Synchronisation ist jedoch stabil. Spürbare Auswirkungen gibt es keine.




@andreas00 so wurde mir easybell auch empfohlen, ich bin dort schon 3 Jahre Kunde und anfangs war auch alles gut Aber telefonieren und gleichzeitig im Internet surfen ist zur Zeit absolutes No-Go und daher tippe ich auf nicht funktionierende Priorisierung. Ich habe leider keinen anderen Internetzugang mit dem ich ausführlich genug testen kann, um die Ursache einzugrenzen.

 

[sparkie]

im tcpdump muss aber erkennbar sein warum die Qualitaet so schlecht ist. Sieht man denn dort Hinweise auf verlorene Pakete?

 

[andreas00]

@andreas00 ... ich bin dort schon 3 Jahre Kunde und anfangs war auch alles gut

Also ich bin schon seit ca. 5 Jahren bei denen Kunde und bis heute noch sehr zufrieden.

@andreas00 ... Aber telefonieren und gleichzeitig im Internet surfen ist zur Zeit absolutes No-Go und daher tippe ich auf nicht funktionierende Priorisierung.

Nach meinem Wissensstand muß doch nicht der Provider easybell die Priorisierung durchführen, sondern der eigene Router, wie in deinem Fall doch die AVM.

Bei mir übernimmt die Priorisierung für meine TK-Anlage Auerswald 5020 ein Router der Firma Lancom, den ich hinter den Speedport Hybrid der Telekom geschaltet habe.
Diese Konfiguration läuft schon seit ca. über einem Jahr sehr stabil und zuverlässig.

 

[KunterBunter]

Dann erkläre mal, wie dein Lancom-Router die VoIP-Daten eingehend priorisiert. Sagt der dem DSL-Provider Bescheid, welches Paket als nächstes geschickt werden soll?

 

[andreas00]

Dann erkläre mal, wie dein Lancom-Router die VoIP-Daten eingehend priorisiert. Sagt der dem DSL-Provider Bescheid, welches Paket als nächstes geschickt werden soll?

Ich regle es mit Hilfe der Mindestbandbreite. Das heißt, der nachgeschalteten TK-Anlage wird eine Mindestbandbreite garantiert.

 

[freak96]

Nach meinem Wissensstand muß doch nicht der Provider easybell die Priorisierung durchführen, sondern der eigene Router, wie in deinem Fall doch die AVM

der Flaschenhals ist ja nicht die FritzBox sondern die DSL-Leitung davor, ergo muss providerseitig entschieden werden was über die Leitung geht und was nicht.

Ich habe nochmal ausfürlich tcpdumps erstellt, versucht das ganze mal mit Belastung und ohne durchzuführen. Unten ein Screenshot von Wireshark auf die anregung von sparkie.
Zum Setup: 77.x ist die IP-Adresse der FritzBox (oberes Fenster) und 188.x die des Servers (vs2, unteres Fenster) auf dem Asterisk läuft. Ich habe ein internes Telefonat gemacht, deswegen die zwei RTP-Ströme. Im oberen Fenster der dump der FritzBox, man achte auf die Verloren-Spalte. Unten die zeitgleiche Aufnahme auf der Serverseite mit tcpdump. Die absolute Zahl empfangene + verlorene Pakete oben, gibt genau die Paketzahl unten. Am Telefonhörer selbst war wieder kaum etwas von der Gegenseite zu verstehen.

Ich habe noch eine interessante Entdeckung gemacht, die aber noch ausführlicher Tests bedarf: Melde ich den easybell-Account direkt auf einem Telefon im Lan an, gibt es während des Gesprächs per easybell keine Probleme, insbesondere funktionieren auch parallele Gespräche über den Asterisk Server ohne Verständigungsprobleme. Evtl wird seitens easybell nur zeitweise Bandbreite reserviert und auch nur für eigene Gespräche, dies werde ich noch ausfürlich testen und berichten

 

[andreas00]

der Flaschenhals ist ja nicht die FritzBox sondern die DSL-Leitung davor, ergo muss providerseitig entschieden werden was über die Leitung geht und was nicht.

Zurzeit stehe ich etwas auf dem Schlauch: Welchen Provider meinst du? Deinen VIOP-Provider easybell oder deinen DSL-Provider?

Und war da nicht mal was mit Netzneutralität, welche wir Kunden doch haben wollten? Also alle IP-Pakete gleichberechtigt zum DSL-Anschluß weiterleiten?

Auf der Abbildung ist mir unter Nutzdaten noch aufgefallen, dass dein System mit zwei unterschiedlichen Codecs (g711A und g711U) arbeitet. Eventuell ist dass das Problem.

 

[freak96]

Zurzeit stehe ich etwas auf dem Schlauch: Welchen Provider meinst du? Deinen VIOP-Provider easybell oder deinen DSL-Provider?

Achso, das hatte ich vielleicht noch nicht klar genug ausgedrückt.
DSL-Provider ist ebenfalls easybell, ich habe dort den Komplett easy Tarif mit festnetzflatrate. Neben easybell für Festnetz Sind Personal-VoIP (eingehende Anrufe & Mobilfunk) sowie voip2gsm (Ausland, fallback) weitere VoIP Provider, aber das tut hier ja auch eigentlich nichts zur Sache.

Die Codec-Fehlkonfiguration sollte ich wirklich mal beheben, da hast du natürlich recht. Der Server ist jedoch Leistungsfähigkeit genug und Anrufe über easybell oder Personal-VoIP sind immer durchgehend alaw-kodiert und zeigen ja die gleiche Symptomatik.

 

[rentek]

Das kommt mir bekannt vor. Seit vorgestern bemerke ich, dass eingehende Faxe nicht mehr gehen. In der Fritzbox sieht man ein erhebloches Packet-Loss. Möglicherweise ist da gerade irgendwo eine Störung. Easybell ist informiert. Mal schauen, ob und was die morgen finden.

 

[andreas00]

Seit einiger Zeit kommt es vermehrt zu schlechter Gesprächsqualität eingehend, d.h. ich kann den Anrufer nicht verstehen, die andere Richtung ausgehend ist einwandfrei. Es reicht bereits zeitgleich ein YouTube Video zu schauen und der Gesprächspartner ist nicht mehr zu verstehen.

Du könntest dir auch mal den Trace vom DSL-Anschluß zum Netcup-Server und vom Netcup-Server zum DSL-Anschluß genauer anschauen. Denn die meisten Provider nehmen für die Hin- und Rückroute gern mal unterschiedliche Routen.

 

[freak96]

Routenverfolgung zu vs2.* [188.*]
über maximal 30 Hops:


  1     1 ms     1 ms     1 ms  fritz.box [192.168.178.1]
  2    10 ms     8 ms     8 ms  rdsl-osbk-de80.nw.mediaways.net [62.52.194.229]
  3     9 ms     7 ms     8 ms  ae2-0.04.xmws.99.osn.de.net.telefonica.de [62.53.12.236]
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5    20 ms    19 ms    19 ms  ae12-0.0001.corx.02.fra.de.net.telefonica.de [62.53.6.233]
  6    19 ms    19 ms    18 ms  bundle-ether16.0002.dbrx.02.fra.de.net.telefonica.de [62.53.26.4]
  7    23 ms    19 ms    31 ms  ae8-0.0001.prrx.13.fra.de.net.telefonica.de [62.53.2.59]
  8    22 ms    21 ms    21 ms  gw-decix.ffm.netcup.net [80.81.193.182]
  9    34 ms    27 ms    23 ms  vs2.*[188.*]


Ablaufverfolgung beendet.

traceroute to home.* (77.*), 30 hops max, 60 byte packets
 1  gw02.netcup.net (188.68.56.3)  0.254 ms  43.044 ms  42.964 ms
 2  gw01.netcup.net (46.38.224.33)  0.202 ms  0.342 ms  0.292 ms
 3  ae2-0.pr03.decix.de.hansenet.net (80.81.192.232)  3.796 ms  3.818 ms  3.766 ms
 4  ae8-0.0001.dbrx.01.fra.de.net.telefonica.de (62.53.5.200)  4.149 ms  4.105 ms ae8-0.0002.dbrx.01.fra.de.net.telefonica.de (62.53.6.86)  4.215 ms
 5  ae1-0.0001.corx.02.fra.de.net.telefonica.de (62.53.0.78)  16.528 ms ae1-0.0001.corx.01.fra.de.net.telefonica.de (62.53.0.66)  14.019 ms ae3-0.0001.corx.02.fra.de.net.telefonica.de (62.53.0.80)  15.154 ms
 6  * * *
 7  xe-0-2-0-0.0001.dirx.01.osn.de.net.telefonica.de (62.53.2.171)  13.031 ms  12.969 ms xe-0-2-0-0.04.xmws.99.osn.de.net.telefonica.de (62.53.2.193)  15.285 ms
 8  eth-trunk60.80.rdsl.99.osn.de.net.telefonica.de (62.53.12.235)  16.244 ms eth-trunk61.80.rdsl.99.osn.de.net.telefonica.de (62.53.12.237)  16.882 ms  16.818 ms
 9  x4*.dyn.telefonica.de (77.*)  19.995 ms !X  20.421 ms !X  21.295 ms !X

So wie das für mich hier aussieht läuft die Route zwar über andere Server, die könnten aber von den IP-Adressen her in den gleichen Subnetzen stehen. Ich denke das es ausgehend keine Probleme gibt, liegt an der Priorisierung der FritzBox, die für den Upstream funktioniert. Das hatten wir ja schon diskutiert

Das kommt mir bekannt vor. Seit vorgestern bemerke ich, dass eingehende Faxe nicht mehr gehen. In der Fritzbox sieht man ein erhebloches Packet-Loss. Möglicherweise ist da gerade irgendwo eine Störung. Easybell ist informiert. Mal schauen, ob und was die morgen finden.

berichte mal was das ergeben hat Ich denke aber dass deine Störung eine andere Ursache hat, ich habe schon wochenlang Probleme :/

Edit: Hier noch ein kurzes Update meinerseits Seitdem ein Snom IP-Telefon den easybell-VoIP Account eingerichtet hat, sind die Probleme behoben. Dabei ist nicht wichtig, dass auch über den Easybell-Account telefoniert wird, nur registriert muss er sein. Zur Fehlersuche hat sich zudem das Programm MTR bewährt, da man hier entsprechende Werte für DSCP spezifizieren kann