Haperende en Krakende Telefonie

[Ivan Dil]

Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,
op een laptop(MacBook) was een update gaande, een vrij grote, toen er
gelijktijdig een binnenkomend gesprek kwam. Het gesprek was niet
mogelijk, ik heb toen ingelogd in de fritzbox om de belasting te
bekijken, zie

Loading Image...

Waarom een updatende MacBook ook een groot deel van de uitgaande
bandbreedte gebruikt weet ik niet. De data wordt door de fritzbox ook
als realtime aangemerkt, wat ik vreemd vind. Ik heb bij prioritization
"Internet Telephony" als Real-time application(high priority) staan, en
mijn server als Background application(low priority).

Loading Image...

Ik weet niet of XS4ALL Telefonie onder deze "Internet Telephony"
prioritazion valt of deze is voor SIP devices in het netwerk. Ik vraag
me dit af door het probleem dat ontstaat als er veel uitgaande
bandbreedte utilization is. Telefonie zou dan de hoogste prioriteit
horen te hebben.

"Normaal" ziet het bandbreedte gebruik er tijdens een goed en duidelijk
werkende telefonie er zo uit,

Loading Image...

Deze verschilt niet bijzonder veel van er als er geen telefoon gesprek
plaats vindt en er alleen traffic is van mijn server,

Loading Image...

Ik weet niet hoe dit probleem op te lossen is, zou ik nog iets kunnen
met de fritzbox prioritation, of iets anders.

Iemand een idee?

PS: Ik heb hierover al eens contact gehad met de helpdesk, deze gaf als
oplossing up te graden qua abbo. Dit zag ik niet als oplossing omdat dan
de uitgaande bandbreedte door andere devices in het netwerk ook meer
gebruikt wordt. Mijn inziens gaat het fout met het toekennen
van de prioriteit van de traffic. Ook is het zo dat telefonie niet veel
bandbreedte gebruikt. Ze hebben toen wel onze lijn omgezet
van ADSL > VDSL, wat in het begin een instabiele lijn opleverde, nu geen
problemen meer. Qua telefonie maakt ADSL, dan wel VDSL niet uit.

[Rob]

Post by Ivan Dil
Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,

Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.

De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.

Er zijn allerlei "oplossingen" voor, maar het blijft lapwerk.
Wel moet ik zeggen dat het sinds ik door XS4ALL op een nieuwe access
router overgezet ben, voor mij veel beter werkt. Ik weet niet of
iedereen al overgezet is en/of dat er toch nog verschillende modellen
of configuraties in gebruik zijn, maar sinds deze wijziging hebben
realtime zaken (VoIP enzo) veel minder last van volgeplempte TCP
sessies (downloads). Ik schat in dat er nu "Fair queueing" gedaan
wordt. (dat betekent dat als er meerdere parallelle datastromen zijn,
de router om en om van iedere stroom een pakketje doorstuurt ipv dat
ze doorgestuurd worden in volgorde van arriveren)

[Ivan Dil]

Post by Rob

Post by Ivan Dil
Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,

Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.
De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.
Er zijn allerlei "oplossingen" voor, maar het blijft lapwerk.
Wel moet ik zeggen dat het sinds ik door XS4ALL op een nieuwe access
router overgezet ben, voor mij veel beter werkt. Ik weet niet of
iedereen al overgezet is en/of dat er toch nog verschillende modellen
of configuraties in gebruik zijn, maar sinds deze wijziging hebben
realtime zaken (VoIP enzo) veel minder last van volgeplempte TCP
sessies (downloads). Ik schat in dat er nu "Fair queueing" gedaan
wordt. (dat betekent dat als er meerdere parallelle datastromen zijn,
de router om en om van iedere stroom een pakketje doorstuurt ipv dat
ze doorgestuurd worden in volgorde van arriveren)

Bedankt Rob, ik zit te denken om weer een "fixed" line te nemen, weet
alleen niet of dat mogelijk is en of dat een oplossing is.

[Miquel van Smoorenburg]

Post by Rob

Post by Ivan Dil
Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,

Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.
De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.

Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".

Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Mike.

[Rob]

Post by Miquel van Smoorenburg

Post by Rob

Post by Ivan Dil
Al enige tijd hebben we problemen met telefonie, de andere persoon aan
de andere van de lijn kan ons niet goed verstaan. Het geluid hapert,
kraakt, noem maar op en een normaal gesprek is niet mogelijk. Ben er al
een tijd mee bezig geweest om uit te zoeken hoe ik het op kan lossen.
Mijn vermoeden was dat de server die ik thuis heb draaien de oorzaak
was. Dit "bleek" te kloppen, na het aantal TCP connections en de
bandbreedte te beperken leek het probleem opgelost te zijn. Nu is de
kwaliteit van de telefonie wisselend, afhankelijk wat er voor ander
verkeer er op het netwerk plaats vind. Vanmorgen was het weer het geval,

Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.
De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.

Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".

Volgens mij is het niet gescheiden op de manier waarop andere providers
dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
op dezelfde connectie. Ook het probleem met verkeer naar buiten is er
dan niet.

Post by Miquel van Smoorenburg
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Ik las dat het fout ging toen er een Macbook een update ging doen en
ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
verkeer bij horen lijkt me.

[Arwin Vosselman]

Post by Rob
Volgens mij is het niet gescheiden op de manier waarop andere providers
dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
op dezelfde connectie. Ook het probleem met verkeer naar buiten is er
dan niet.

VoDSL, <http://nl.wikipedia.org/wiki/VoDSL>.

[Ivan Dil]

[...]

Post by Rob

Post by Miquel van Smoorenburg
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Ik las dat het fout ging toen er een Macbook een update ging doen en
ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
verkeer bij horen lijkt me.

Dat las ik in je eerste reactie al, maar het betreft upstream, waarom
een MacBook zoveel upstream traffic genereert bij een update is mij een
raadsel.

Loading Image...

BTW, de binnenkomende spraak (downstream) is altijd glashelder.

[Miquel van Smoorenburg]

Post by Rob

Post by Miquel van Smoorenburg
Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".

Volgens mij is het niet gescheiden op de manier waarop andere providers
dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
op dezelfde connectie.

Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.

Post by Rob
Ook het probleem met verkeer naar buiten is er
dan niet.

Naar buiten geldt exact hetzelfde, als het over dezelfde
lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
net is begonnen met versturen- daar moet je helaas op wachten.
Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.

Post by Rob

Post by Miquel van Smoorenburg
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Ik las dat het fout ging toen er een Macbook een update ging doen en
ik schat in dat dit een DOWNload was. Daar zal toch niet veel upload
verkeer bij horen lijkt me.

Jawel dus, dat is het probleem.

Mike.

[Rob]

Post by Miquel van Smoorenburg

Post by Rob

Post by Miquel van Smoorenburg
Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".

Volgens mij is het niet gescheiden op de manier waarop andere providers
dit doen. Dat gaat net zo als jullie bij TV doen: apart kanaal, los
van internet, vaste voorgeconfigureerde bandbreedte, niet afhankelijk
van dataverkeer. Dat is niet hetzelfde als prioriteit geven aan verkeer
op dezelfde connectie.

Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.

Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.
Het geven van prioriteit werkt ook alleen maar als het op exact de
juiste plaats gebeurt, en daar is vaak ook nog wel wat op af te dingen
zelfs in een router.

Ook weigert XS4ALL de prioriteit te bepalen aan de hand van het IP
header veld wat daar voor bedoeld is, wat het ook niet beter maakt.
Gelukkig is dat issue opgelost met de nieuwe routers, die zelf al een
goede inschatting maken kennelijk zonder daar naar te kijken.
(of is men uiteindelijk toch "om" gegaan?)

Post by Miquel van Smoorenburg

Post by Rob
Ook het probleem met verkeer naar buiten is er
dan niet.

Naar buiten geldt exact hetzelfde, als het over dezelfde
lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
net is begonnen met versturen- daar moet je helaas op wachten.
Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.

Tja maar toch is dat kennelijk niet voldoende, of het werkt bij hem niet.

[Miquel van Smoorenburg]

Post by Rob

Post by Miquel van Smoorenburg
Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.

Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.

Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
welk packet (of cell, meestal) vooraan in de queue komt op
basis van een paar bits in de ATM header. Niks anders dan naar
bits in een VLAN header of een IP header kijken.

Post by Rob
Het geven van prioriteit werkt ook alleen maar als het op exact de
juiste plaats gebeurt, en daar is vaak ook nog wel wat op af te dingen
zelfs in een router.

De XS4ALL routers shapen en queuen op de snelheid "op papier", maar
zetten voor voip verkeer ook een 'prio' bitje in de ethernet
header, waardoor verderop in het netwerk (de DSLAM) dat verkeer
ook nog eens in de priority-queue gezet kan worden.

Post by Rob
Ook weigert XS4ALL de prioriteit te bepalen aan de hand van het IP
header veld wat daar voor bedoeld is, wat het ook niet beter maakt.

Er is bijna niemand die dat buiten een besloten netwerk doet. Dat
is niet "weigeren", dat is "best common practice".

Post by Rob

Post by Miquel van Smoorenburg
Naar buiten geldt exact hetzelfde, als het over dezelfde
lijn gaat: welke packets mogen eerst. Als een VOIP packet altijd voorin
de rij geplaatst wordt, dan maakt het niet uit hoeveel packets
daarachter staan te dringen. Behalve dat ene 1500 byte voor je dat
net is begonnen met versturen- daar moet je helaas op wachten.
Dat is bij 1 Mb/s upload maximaal zo'n 12-15 ms.

Tja maar toch is dat kennelijk niet voldoende, of het werkt bij hem niet.

Door een bug in de fritzbox. (vanaf FritzOS 6.05, geloof ik).

Mike.

[Rob]

Post by Miquel van Smoorenburg

Post by Rob

Post by Miquel van Smoorenburg
Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.

Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.

Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
welk packet (of cell, meestal) vooraan in de queue komt op
basis van een paar bits in de ATM header. Niks anders dan naar
bits in een VLAN header of een IP header kijken.

ATM werkt met cellen. Als je een circuit bouwt met een bepaalde gecommitte
snelheid dan zijn er voor dat circuit cellen gereserveerd. Packets hoeven
geen aaneengesloten cellen te zijn. Het verkeer in dat circuit loopt
door op de geconfigureerde snelheid wat er verder ook gebeurt op die
verbinding.

Dat is heel wat anders dan serialiseren van verkeer op een medium
als ethernet. Het kan ongeveer hetzelfde uitwerken, maar dat doet het
alleen als het heel goed geconfigureerd is en overal goed geimplementeerd.

Routerfabrikanten hebben ook andere dingen aan hun hoofd (zoals goed
presteren in naieve throughput testen) en maken dit soort dingen keer
op keer kapot. Nu ook weer kennelijk.
Dat zal met ATM circuits niet zo snel gebeuren.

[Miquel van Smoorenburg]

Post by Rob

Post by Miquel van Smoorenburg

Post by Rob

Post by Miquel van Smoorenburg
Jawel toch. Denk erover na: het enige wat er gebeurt is dat bepaalde
packets eerder over de lijn mogen dan anderen. Of dat nou wordt
bepaald op basis van VLAN tag, of op basis van source-ip, of
ergens anders op, dat maakt niet uit.

Maar het verschil is dat er niet een "de lijn" is. Er kunnen ook
verschillende lijnen zijn. Bijvoorbeeld als er ATM gebruikt wordt.

Dat snap ik niet. Ook als er ATM gebruikt wordt is er nog steeds
maar 1 lijn. Met verschillende ATM VCs erop, maar dat is niet
veel anders dan VLANs op ethernet. Dan wordt bij ATM bepaald
welk packet (of cell, meestal) vooraan in de queue komt op
basis van een paar bits in de ATM header. Niks anders dan naar
bits in een VLAN header of een IP header kijken.

ATM werkt met cellen. Als je een circuit bouwt met een bepaalde gecommitte
snelheid dan zijn er voor dat circuit cellen gereserveerd. Packets hoeven
geen aaneengesloten cellen te zijn. Het verkeer in dat circuit loopt
door op de geconfigureerde snelheid wat er verder ook gebeurt op die
verbinding.
Dat is heel wat anders dan serialiseren van verkeer op een medium
als ethernet. Het kan ongeveer hetzelfde uitwerken, maar dat doet het
alleen als het heel goed geconfigureerd is en overal goed geimplementeerd.

Als ik erover nadenk is dat nog steeds hetzelfde. Goed, je hebt
kleinere cellen dus wat minder jitter, maar waar je het over
hebt is prima op een ander packet-switched netwerk zoals
IP of ethernet te realiseren. En dat gebeurt ook op grote schaal.

Dat moet je ook alleen aan de edge doen, waar de bottleneck is
en waar je niet al te veel queues nodig hebt. In de core moet
je geen QoS/CoS doen. Links daarin horen namelijk gewoon niet
congested te zijn. En bij geen congestie doet QoS/CoS/whatever niks.

Post by Rob
Routerfabrikanten hebben ook andere dingen aan hun hoofd (zoals goed
presteren in naieve throughput testen) en maken dit soort dingen keer
op keer kapot. Nu ook weer kennelijk.
Dat zal met ATM circuits niet zo snel gebeuren.

Ja, omdat niemand meer ATM gebruikt :) Zo is het KPN ATM netwerk
zo'n beetje leeg, en wordt het eind dit jaar definitief uitgezet.
Iedereen en z'n moeder is over op ethernet. Enige ATM wat nog
bestaat is tussen een modem en een DSLAM op ADSL.

Mike.

[Ivan Dil]

[...]

Post by Miquel van Smoorenburg

Post by Rob
Dit is een beetje inherent aan de manier van VoIP telefonie die XS4ALL
gebruikt. Het VoIP verkeer loopt over het publieke internet. Dit
heeft voordelen, want je kunt je XS4ALL VoIP account op een willekeurige
internet aansluiting gebruiken. Maar het heeft ook de nadelen waar je
nu mee komt.
De meeste andere providers kiezen ervoor een apart kanaal met gegarandeerde
bandbreedte te gebruiken voor telefonie. XS4ALL doet dit wel voor TV,
maar niet voor telefonie.

Jawel. Al tijden. Maar dat is alleen het verkeer van de SIP server
naar de klant toe. Je kan alleen verkeer voorrang geven dat
je verstuurt, niet aan verkeer dat je ontvangt. Je kan immers
niet achteraf zeggen "dat packet dat ik net ontvangen had was niet
superbelangrijk, stuur de volgende toch maar daarvoor".
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.
Mike.

Dus zoals het nu configureerd is in de fritzbox zou de XS4ALL VOIP
voorrang behoren te krijgen boven het andere verkeer?

http://i.imgur.com/cu92Eks.png

[Miquel van Smoorenburg]

Post by Ivan Dil

Post by Miquel van Smoorenburg
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Dus zoals het nu configureerd is in de fritzbox zou de XS4ALL VOIP
voorrang behoren te krijgen boven het andere verkeer?
http://i.imgur.com/cu92Eks.png

Zo zou het out of the box moeten zijn ja. Zoals ik al eerder
in deze thread zei, als het niet werkt is het een bug in
Fritz!OS (vanaf 6.05 denken we). Is in onderzoek bij AVM.

Mike.

[Ivan Dil]

Post by Miquel van Smoorenburg

Post by Ivan Dil

Post by Miquel van Smoorenburg
Waar OP het hier over heeft is dat het gaat haperen als hij
verkeer naar buiten stuurt. In dat geval hoort de priorisatie
in de Fritzbox te gebeuren- die moet VOIP packets gewoon altijd
vooraan zetten in de rij, en dat gebeurt blijkbaar niet.

Dus zoals het nu configureerd is in de fritzbox zou de XS4ALL VOIP
voorrang behoren te krijgen boven het andere verkeer?
http://i.imgur.com/cu92Eks.png

Zo zou het out of the box moeten zijn ja. Zoals ik al eerder
in deze thread zei, als het niet werkt is het een bug in
Fritz!OS (vanaf 6.05 denken we). Is in onderzoek bij AVM.

Bedankt Mike, het is dus wachten op een fix in de firmware!