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:
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!
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:
Code:
###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!