[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
How Session Mirroring Works
If session mirroring is required on a gate, the PGCPD process
embeds appropriate data in the gate open/modify request that it sends
to the PIC. This data includes direction information to indicate whether
the packet is mirrored before applying NAT actions or after. It also
includes the decrypted correlation number and Target IDs that need
to be embedded in the packet sent to the delivery function.
The PIC then:
- Marks the gate that needs to be mirrored and
obtains the destination for the mirrored packets from the CLI configuration.
- Processes the packets as it normally does. It applies
DSCP, latching, and rate limiting as appropriate.
- Additional mirrored packets that are sent as a result
of session mirroring do not impact rate limiting. The replicated packets
do not count against policer counters that are used to compute the
rate for the gate.
- Mirrored packets are sent with DSCP marks that are applied
to the gate as they are for a normal flow.
- If the original packet is dropped because of rate limiting;
no mirroring occurs.
- Latch or relatch actions on the gate do not impact mirroring.
- Generates one copy of the packets received
on mirrored gates for each target ID specified in the PGCP request,
encapsulates the mirrored packets, and sends them to the configured
delivery function.
Session mirroring can be enabled or disabled any time during
a gate’s life by employing PGCP commands. If mirroring is enabled
in one stream of a termination, all streams in the context are mirrored.
Both RTP and RTCP packets are mirrored for a gate marked for mirroring.
[Contents]
[Prev]
[Next]
[Index]
[Report an Error]
