FG 60E
v 7.2.4
I need help with the traffic shaping policy triggering and the traffic direction.
When I created a VoIP traffic shaping policy based on the traffic direction from the source to the destination, which includes RTP and SIP services, I experienced some problems with the SIP DSCP marking. Applied EF but the output for the SIP packages was still CS0.
The sessions output for the external inbound call for SIP session was:
session info: proto=17 proto_state=01 duration=540676 expire=179 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
state=may_dirty npu
statistic(bytes/packets/allow_err): org=62869363/107131/1 reply=56299023/112453/1 tuples=2
tx speed(Bps/kbps): 135/1 rx speed(Bps/kbps): 106/0
orgin->sink: org pre->post, reply pre->post dev=46->37/37->46 gwy=10.10.5.25/10.55.100.100
hook=pre dir=org act=noop 10.55.100.100:5060->10.10.5.25:5060(0.0.0.0:0)
hook=post dir=reply act=noop 10.10.5.25:5060->10.55.100.100:5060(0.0.0.0:0)
It shows that the phone (10.55.100.100) initiated the SIP conversation and not a PBX (10.10.5.25) (as I expected) (the call from outside) 10.55.100.100:5060->10.10.5.25:5060(0.0.0.0:0). I believe that my policy wasn't triggered because of the traffic direction in the session.
As it turned out, the call SIP session (starts with INVITE ....) was indeed initiated by the PBX and not the phone (from the packet capture output). And those initial SIP packets captured by the Fortigate session were just some periodic phone register requests.
My questions:
Do traffic policies depend on the sessions and the first (matched) traffic captured by the session? My initial policy direction setup was completely ignored.
Does the SIP session include all subsequent SIP packages? I see only one SIP session for the call.
I changed the policy to reflect this issue (?):
Note that source/destination duplication. It helped but looks weird to me.
Without the traffic shaping logic understanding it can be such a pain ...
Thanks.
1 Solution
