Configuring SIP Snooping SIP Snooping Configuration Guidelines
OmniSwitch AOS Release 8 Network Configuration Guide December 2017 page 14-11
Other source conditions are also supported but are not foreseen to provide real benefits.
The policy condition is not used as such in the hardware filtering entry, but is used by the SIP snooping
module to determine the policy rule that the new RTP flow is matching. Also, SIP policy rules are
supported in ingress and UNP policy lists.
Policy Action
All other policy actions are still supported for SIP policy rules. For instance:
• DSCP—marks the DSCP value for the RTP/RTCP packets and maps the internal priority to this DSCP
• Priority—forces the internal priority of the RTP/RTCP packets.
• Rate Limiter
To configure the policy action, use the commands as follows.
-> policy action <action_name> dscp 32 rtcp-monitoring {enable | disable}
-> policy action <action_name> dscp 46 rtcp-monitoring enable rtcp-dscp <num>
-> policy action <action_name> rtcp-monitoring disable trust-dscp
Policy Rule
A SIP policy rule is a rule that has the keyword SIP (audio/video/other) in the policy condition and a
corresponding policy action.
The SIP policy rule is configured as follows.
-> policy condition Voice_srcip_SIP1 source ip 10.10.0.0 mask 255.255.0.0 sip
audio
-> policy condition Video_srcip_SIP1 source ip 10.10.0.0 mask 255.255.0.0 sip
video
-> policy action DSCP56 dscp 56
-> policy action DSCP32 dscp 32
-> policy rule Voice_srcip_SIP1_rule condition Voice_srcip_SIP1 action DSCP56
-> policy rule Video_srcip_SIP1_rule condition Video_srcip_SIP1 action DSCP32
-> qos apply
Note that a SIP policy rule does not apply for the SIP signaling messages. A SIP policy rule can however
apply for a SOS call since a SOS call is a audio media. However, the DSCP marking and rate limiter for
an SOS call cannot be overwritten by a SIP policy rule.
Unsupported Topologies
The SIP snooping functions and the QOS actions require that the network paths used by the SIP signaling
messages and the RTP/RTCP flows are the same and are “symmetric”. For this reason, the following
topologies are not supported:
• ECMP Routing
• VRRP
In such topologies, it would be possible that one switch/router sees the SIP signaling messages and creates
the dialog with the appropriate QOS actions (i.e. ACLs), but the RTP/RTCP traffic will not be seen by this
switch/router. It would also be possible that the SIP signaling messages and/or RTP/RTCP packets are
load balanced between 2 switch/routers.
To Next Page
Loading...
