Régulateur de trafic

On 09/10/2013 21:53, Geo Cherchetout wrote:> Bonjour,

(...)

Serait-il possible de disposer entre Linphone et mon port ethernet une
sorte de sas avec un portier imposant une discipline telle que les
paquets RTP partent à intervalles réguliers ?

oui, je pense que c'est jouable avec tc


--
Remplacez yahou par yahoo et com par fr pour me répondre en direct

Laurent

Le 22/10/2013 12:03, *Essomba* a écrit fort à propos :

> Serait-il possible de disposer entre Linphone et mon port ethernet une
> sorte de sas avec un portier imposant une discipline telle que les
> paquets RTP partent à intervalles réguliers ?

oui, je pense que c'est jouable avec tc

Merci. Un proche m'avait déjà indiqué tc, dont j'ai lu le manuel plusieurs
fois, et retenu le mot « discipline », mais j'aurais besoin d'un peu plus
d'aide. Des exemples d'applications seraient particulièrement appréciés...

On 22/10/2013 13:27, Geo Cherchetout wrote:> Le 22/10/2013 12:03,
*Essomba* a écrit fort à propos :

> Serait-il possible de disposer entre Linphone et mon port ethernet
une
> sorte de sas avec un portier imposant une discipline telle que les
> paquets RTP partent à intervalles réguliers ?

oui, je pense que c'est jouable avec tc

Merci. Un proche m'avait déjà indiqué tc, dont j'ai lu le manuel
plusieurs fois, et retenu le mot « discipline », mais j'aurais besoin
d'un peu plus d'aide. Des exemples d'applications seraient
particulièrement appréciés...

le manuel ... tu parles du lartc ? ( http://www.lartc.org/howto/ )

Quand j'ai utilisé ce truc là, j'ai marqué les paquets avec iptables car
la syntaxe de marquage de tc est imbitable.

Le script que j'avais créé ressemble à ça (je l'ai simplifié pour
l'exemple ... pas tapé si ça marche pas out of the box ;) )

#!/bin/bash -ex

ITF=eth1

# on supprime tout
tc qdisc del dev $ITF root || true

# on attache le HTB à root
tc qdisc add dev $ITF root handle 1:0 htb default 30

# limite à 64k
tc class add dev $ITF parent 1:1 classid 1:10 htb rate 64kbit prio 0

# la queue discipline
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb 10

# la redirection en fct du marquage iptables
tc filter add dev $ITF parent 1:0 protocol ip prio 0 handle 10 fw
classid 1:10

# Flusher toute la table de marquage
iptables -t mangle -F

# Marquer les paquets RSTP
iptables -t mangle -o $ITF -A OUTPUT -p udp --dport 554 -j MARK
--set-mark 10

Ce truc là devrait limiter la bande passante des paquets RTSP à 64k. Il
suffit que tu augmente la taille de la file pour lisser le trafic.

J'ai considéré ici le trafic rtsp sur le port 554 UDP.

Si tu as des questions n'hésite pas, le LARTC se lit facilement ... une
fois que tu l'as compris ;)

--
Remplacez yahou par yahoo et com par fr pour me répondre en direct

Laurent

Le 22/10/2013 13:41, *Essomba* a écrit fort à propos :

le manuel ... tu parles du lartc ? ( http://www.lartc.org/howto/ )

Merci de plus belle, avec ça et ton script j'ai de quoi m'occuper pour
quelque temps. :-) Si j'aboutis, je ne manquerai pas de revenir ici en
rendre compte.

Le 22/10/2013 15:36, j'ai écrit :

Si j'aboutis, je ne manquerai pas de revenir ici en rendre compte.

Ce n'est pas encore un véritable aboutissement, mais le flux de données émis
par Linphone sous la contrainte de tc est déjà beaucoup plus régulier. J'ai
lu et relu la doc sans y comprendre grand chose et fait de très nombreux
essais dans le vain espoir d'améliorer la gigue qui est encore beaucoup trop
importante (0,2 ms en moyenne passé les deux premières minutes de
communication au cours desquelles c'est plutôt 1 ms) mais n'ai finalement
pas changé grand chose au script d'Essomba. Voici ma version actuelle, je
reste ouvert à toute suggestion d'amélioration :

#!/bin/bash -ex

ITF=eth0

# on supprime tout
tc qdisc del dev $ITF root || true

# on attache le HTB à root
tc qdisc add dev $ITF root handle 1:0 htb default *10*

# limite à 85600 bits/s (paquets de 20 ms) ou 78400 (paquets de 30 ms)
# taille des paquets imposée par l'opérateur
tc class add dev $ITF parent 1:1 classid 1:10 htb rate *78401* prio 0

# la queue discipline
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb *1*

# la redirection en fct du marquage iptables
tc filter add dev $ITF parent 1:0 protocol ip prio 0 handle 10 fw classid 1:10

# Flusher toute la table de marquage
iptables -t mangle -F

# Marquer les paquets *RTP*
iptables -t mangle -o $ITF -A OUTPUT -p udp *--source-port 7078* -j MARK
--set-mark 10

Salut,

faudrait que tu sépares le trafic pour mettre tes paquets RTP
prioritaires. Tu le fais ainsi : (ce qui est important est le default)

# on envoie le trafic non traité dans la file 20
tc qdisc add dev $ITF root handle 1:0 htb default 20

Ensuite je pense que tu devrais brider ta ligne en sortie pour éviter
que ce soit ton FAI qui le fasse pour toi. Il vaut mieux garder les
files chez soi. Si tu as un ADSL a par exemple 1Mbit/s en remonté (et
que tu as testé), tu peux brider ton interface en sortie à 1Mbits/s ainsi :

# on bride l'interface en sortie à 1Mbit/s
tc class add dev $ITF parent 1:0 classid 1:1 htb rate 1024kbit

ensuite viennent les deux classes (haute priorité et tout venant)

# le trafic RTP shapé à 78401
tc class add dev $ITF parent 1:1 classid 1:10 htb rate 78401 prio 0

# le reste shapé à 1024*1024-78401
tc class add dev $ITF parent 1:1 classid 1:20 htb rate 970175 prio 1

# la discipline d'entrée du RTP. Si juste un seul processus envoie du
RTP à la fois, tu peux mettre perturb à 0
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb 0

# le reste. On perturbe à 10 (c'est la valeur que j'ai vu la plus utilisée)
tc qdisc add dev $ITF parent 1:20 handle 20: sfq perturb 10

Le filtrage et le marquage restent le même. Tu n'as pas besoin de
marquer le trafic non traité, il est envoyé dans la file 20: .

De cette manière là :
- tu as gardé les files chez toi, donc tu maîtrises ce qui se passe sur
ton réseau en upload ;
- tu as prioritisé ton trafic RTP qui ne sera plus perturbé par le reste
du trafic.

Tout ceci ne marche bien sûr que si la machine où tu reshape le trafic
est ton routeur de sortie. Sinon tu peux être perturbé partout.

L

Geo Cherchetout wrote:

Le 22/10/2013 15:36, j'ai écrit :

Si j'aboutis, je ne manquerai pas de revenir ici en rendre compte.

Ce n'est pas encore un véritable aboutissement, mais le flux de données
émis par Linphone sous la contrainte de tc est déjà beaucoup plus
régulier. J'ai lu et relu la doc sans y comprendre grand chose et fait
de très nombreux essais dans le vain espoir d'améliorer la gigue qui est
encore beaucoup trop importante (0,2 ms en moyenne passé les deux
premières minutes de communication au cours desquelles c'est plutôt 1
ms) mais n'ai finalement pas changé grand chose au script d'Essomba.
Voici ma version actuelle, je reste ouvert à toute suggestion
d'amélioration :

#!/bin/bash -ex

ITF=eth0

# on supprime tout
tc qdisc del dev $ITF root || true

# on attache le HTB à root
tc qdisc add dev $ITF root handle 1:0 htb default *10*

# limite à 85600 bits/s (paquets de 20 ms) ou 78400 (paquets de 30 ms)
# taille des paquets imposée par l'opérateur
tc class add dev $ITF parent 1:1 classid 1:10 htb rate *78401* prio 0

# la queue discipline
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb *1*

# la redirection en fct du marquage iptables
tc filter add dev $ITF parent 1:0 protocol ip prio 0 handle 10 fw
classid 1:10

# Flusher toute la table de marquage
iptables -t mangle -F

# Marquer les paquets *RTP*
iptables -t mangle -o $ITF -A OUTPUT -p udp *--source-port 7078* -j MARK
--set-mark 10

Le 27/10/2013 10:47, *laurent* a écrit fort à propos :

# la discipline d'entrée du RTP. Si juste un seul processus envoie du
RTP à la fois, tu peux mettre perturb à 0
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb 0

J'ai essayé 0, 1 et 10 sans jamais de résultat probant. Avec « ma » version
du script, la valeur 1 était la seule donnant des résultats pas complètement
horribles.

De cette manière là :
- tu as gardé les files chez toi, donc tu maîtrises ce qui se passe sur
ton réseau en upload ;
- tu as prioritisé ton trafic RTP qui ne sera plus perturbé par le reste
du trafic.

Tout ceci ne marche bien sûr que si la machine où tu reshape le trafic
est ton routeur de sortie. Sinon tu peux être perturbé partout.

Merci pour ces compléments. Malheureusement, le résultat obtenu est moins
bon puisque j'observe à présent quasiment le même bazar qu'en l'absence
d'intervention : Mon opérateur de VoIP imposant depuis quelques jours des
paquets de 30 ms, sur 8 intervalles consécutifs, en moyenne 1 est à 40 ms ,
un autre à 20ms et 6 seulement à 30 ms, toutes durées affectées d'une gigue
moyenne de 3 ms. (Cas moyen, des fois c'est pire.)
Je recopie ci-dessous la version actuelle du script utilisé pour qu'on
puisse y détecter d'éventuelles erreurs mais, si je peux me permettre un
avis, le problème signalé ne semble pas imputable à une concurrence entre le
flux VoIP et d'autres flux émis par mon pc. En effet, il s'agit d'un simple
pc de bureau où aucune autre application communicante ne s'exécute lors de
mes essais et où les trafics sont donc négligeables devant la capacité de ma
connexion adsl (960 kbits/s en ATM dans le sens montant actuellement).
D'ailleurs, la cadence des paquets RTP émis est aussi régulière que souhaité
quand linphonec, la version ligne de commande de Linphone, envoie un fichier
wav au lieu du signal fourni par ma carte son, ou quand j'utilise Ekiga ou
Qutecom.
Le besoin serait donc plutôt de compenser un défaut inhérent à Linphone ou à
sa bibliothèque mediastreamer2 que de protéger son flux sortant des
influences extérieures.

$ cat ./regulix.sh

#!/bin/bash -ex

ITF=eth0

# on supprime tout
tc qdisc del dev $ITF root || true

# on envoie le trafic non traité dans la file 20
tc qdisc add dev $ITF root handle 1:0 htb default 20

# on bride l'interface en sortie à 700 kbit/s
tc class add dev $ITF parent 1:0 classid 1:1 htb rate 700kbit

# le trafic RTP shapé à 78400
tc class add dev $ITF parent 1:1 classid 1:10 htb rate 78400 prio 0

# le reste shapé à (700*1024)-78400
tc class add dev $ITF parent 1:1 classid 1:20 htb rate 638400 prio 1

# la queue prioritaire
tc qdisc add dev $ITF parent 1:10 handle 10: sfq perturb 0

# le reste
tc qdisc add dev $ITF parent 1:20 handle 20: sfq perturb 10

# la redirection en fct du marquage iptables
tc filter add dev $ITF parent 1:0 protocol ip prio 0 handle 10 fw classid 1:10

# Flusher toute la table de marquage
iptables -t mangle -F

# Marquer les paquets RTP
iptables -t mangle -o $ITF -A OUTPUT -p udp --source-port 7078 -j MARK
--set-mark 10

Le 09/10/2013 21:53, j'ai écrit :

Serait-il possible de disposer entre Linphone et mon port ethernet une sorte
de sas avec un portier imposant une discipline telle que les paquets RTP
partent à intervalles réguliers ? Il serait probablement plus logique de
modifier le code de Linphone ou de mediastreamer, mais le dispositif de mes
rêves aurait l'avantage de pouvoir profiter à d'autres softphones. Si, comme
je le suppose, c'est possible, j'en appelle à votre savoir et à vos
suggestions...

Pour les personnes intéressées, je dévoile mes procédés de télécopie sur
VoIP ici : http://cherchetout.pagesperso-orange.fr/FaxOverVoIP.html

J'ai bataillé un certain temps avec tc mais, s'il est possible avec cet
outil de freiner des paquets de données trop rapprochés, il n'est pas
possible d'accélérer des paquets trop distants les uns des autres. L'effet
bénéfique attendu ne se manifeste donc qu'au bout d'un temps de l'ordre de
deux minutes, le temps je suppose qu'un tampon de données se forme derrière
l'obstacle. En outre, la limite de débit à fixer n'est pas la même selon la
taille des paquets RTP, la part relative des en-têtes n'étant pas la même
sur des paquets de 160 échantillons et sur des paquets de 240 échantillons,
or c'est l'opérateur qui impose sa loi à ce sujet. Pas toujours la même d'un
moment à un autre. (Ni même d'un sens de transmission à l'autre.) Il n'est
donc pas possible de prévoir une règle qui marche à tous les coups.

J'ai donc dû chercher autre chose et j'ai enfin trouvé une solution mais
elle met à profit une particularité de Linphone que je n'avais pas évoquée
dans l'énoncé du problème. Il faut en effet savoir que le défaut signalé ne
se manifeste pas quand linphonec, version en ligne de commande de linphone,
lit un fichier wav. Le flux de données envoyé sur le réseau est alors d'une
régularité presque parfaite. Une solution consiste donc à enregistrer le
signal audio à transmettre dans un fichier tampon à ce format avec la
commande arecord et à désigner ce fichier à linphonec au moment d'établir la
communication. N'ayant pas réussi à émettre un fichier et, en même temps,
recevoir directement dans le périphérique normal, j'ai utilisé le même
artifice à la réception : Linphone déverse les données reçues dans un
fichier et j'écoute ce fichier avec aplay.

Voici donc un scénario qui me permet d'avoir une conversation affranchie du
problème de gigue propre à Linphone.


1) Je démarre le daemon linphonec :
$ linphonecsh init -b ~/.linphonesimplerc -l ~/linphonecsh.log -d 2



2) Je m'enregistre auprès du registraire de mon opérateur :
$ linphonecsh register --host sip.ovh.fr --username 0033972xxxxxx --password
zzzzzz



3) Je vérifie l'enregistrement :
$ linphonecsh status register



4) Je demande à linphonec d'utiliser des fichiers :
$ linphonecsh generic "soundcard use files"



5) Je lance mon appel :
$ linphonecsh dial sip:0555wwwwww@sip.ovh.fr

sleep 1

linphonecsh generic "record /dev/shm/retour.wav"

aplay -D hw:0,0 -f S16_LE -c 1 -r 8000 -t wav --buffer-size–
/dev/shm/retour.wav &

arecord -D hw:0,0 -f S16_LE -c 1 -r 8000 -t wav --buffer-size–
/dev/shm/buff.wav &

linphonecsh generic "play /dev/shm/buff.wav"



6) Je raccroche quand je pense avoir dit assez de bêtises :
$ linphonecsh generic "terminate"



7) Je fais le ménage dans les fichiers :
$ killall arecord

killall aplay

rm -f /dev/shm/buff.wav

rm -f /dev/shm/retour.wav



8) Éventuellement, j'arrête le daemon linphonec :
$ linphonecsh exit


Simple comme un coup de fil. ;-)

Bon, il serait peut-être plus sûr de prévoir un script expect avec linphonec
en mode interactif plutôt que linphonecsh mais on verra ça une autre fois.

Merci pour votre patience et à bientôt pour de nouvelles aventures.