Essaye donc de remplacer l'instruction egress vlan832 de ta config par

Code: [Sélectionner]

egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"ce qui devrait préserver la prio 6 pour le DHCP.

Merci beaucoup ! ça fonctionne nickel !

Je suppose que l'instruction

Code: [Sélectionner]

interfaces {
    ethernet eth1 {
        vif 832 {
            egress-qos "0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7"
        }
    }
}
bien que nécessaire pour que le dhclient patché soit opérationnel provoque quelques effets de bord sur le traffic normal.

Essaye donc de remplacer l'instruction egress vlan832 de ta config par

Code: [Sélectionner]

egress-qos "0:0 1:0 2:0 3:0 4:0 5:0 6:6 7:0"ce qui devrait préserver la prio 6 pour le DHCP.

Bonne remarque. Effectivement du coup je conseille la configuration egress-qos que tu donnes, qui limite les effets de bord au maximum.

Je viens de tester, ça a l'air de marcher...

Edit: Enfin, je parle de ma solution à base de siproxd_orange 

Quand vous faites des captures wireshark ça vous arrive aussi d'avoir UDP à la place de RTP pour le flux audio ? Chez moi ça le fait quand je commence la capture alors que l'appel est en cours ou si j'appelle depuis mon PC. Si je recommence à partir de mon PC c'est toujours UDP qui s'affiche, par contre si je rappel par mon smartphone, ça affiche bien RTP. Et si je rappel encore via mon PC  c'est toujours RTP et ça le restera tant que je n'aurais pas arrêté la capture.

On dirait un bug non ?

En gros ça fait :

capture > appel en cours : UDP
capture > appel PC : UDP
capture > appel smartphone : RTP
capture > appel PC : UDP > appel smartphone : RTP > appel PC : RTP

Les softphone sont csipsimple et linphone.

Si n'affiche pas RTP mais UDP c'est qu'il ne sait pas comment interpréter une trame (il manque l'ouverture de la session SIP par exemple), typique d'une capture en cours d'appel par exemple.

Il me semble que dans ce cas, on peut tout de même lui spécifier le protocole utilisé, "à la main".

RTP c'est sur de l'UDP (et plus rarement sur TCP).

Quand Wireshark affiche 'RTP' pour une trame c'est qu'il a analysé ce qui s'est passé avant et déduit que cette trame c'est du RTP (et il indique la 'setup frame' en commentaire dans le detail de la trame). Si n'affiche pas RTP mais UDP c'est qu'il ne sait pas comment interpréter une trame (il manque l'ouverture de la session SIP par exemple), typique d'une capture en cours d'appel par exemple.

D'accord donc c'est normal pour la capture en cours d'appel, par contre, ça le fait aussi si je démarre la capture avant d'appeler, hors WS reçoit bien les paquets sip dans les deux cas.