HI Harvy66,
thank you for your clear answer, I got the point (although I don't like it :)).
You are right, I can have the shaping less effective (or not at all) when bandwidth drops down, but unfortunately is in that moments I need it most, so I figured another possibility. As VOIP traffic flows in the Lan2Lan tunnel, may be I can:
Office2 (bad internet)
On the WAN: PRIO on ipsec traffic for Lan2Lan without specifying the maximun bandwidth available
In Ipsec interface: PRIO on VOIP traffic, again without specifying the maximun bandwidth available
Office1 (good internet)
On the WAN: shape on ipsec traffic for Lan2Lan (HFSC or even simpler CBQ or CODEL or any of those mix) with bandwidth set to a reasonable value, let's say 20Mb or so
On Ipsec interface: shape on the VOIP traffic (HFSC or…) with a bandwidth set to sustain a bunch of concurrent calls, let say 512Kb or so
Actually, the Lan2Lan tunnel is openvpn and serves traffic other than VOIP (smb, http, ssh...). May be is better to setup another Lan2Lan Ipsec just for VOIP (instead to substitute the openvpn one) to better try to guarantee low latency to VOIP (that is my only requirement at moment) with PRIO/shaping above.
In my mind, this should at least help VOIP latency when bandwidth at Office2 falls down (PRIO), and the shaping on Office1 should help with queue starvation PRIO introduces when bandwidth at Office2 is not (too much) oversubscribed.
Does this make sense to you?
Thank you very much!
Ciao,
S.