Client has to record their customer calls. A previous engineer setup a HP 2610 100Mbit switch with port 2 as the monitor port and 1, 3-48 as monitored ports. The ports are for PoE phones and the monitor port is so SIP traffic can be reassembled and recorded.

I would have used a gigabit uplink port for monitor, but that's just me...

Now, here's the rub. The phones have computers plugged into the phone switch port. There is no VLAN configuration, there is nothing that I see to prevent the computer traffic from hitting the monitor port also.

Describing to customer: To imaging this, think of an room with 47 doors and one special door. There is a “duplicator” in the middle. Calvin comes in, gets duplicated and goes out his exit of choice. The duplicate goes out the special exit. No problem.

Now there are cars lined up at all three entrances/exits to this intersection and they are being duplicated and sent on their way, except there is a line for the special exit.

My question is does this “block”, preventing any more traffic flow until it clears, or does it “drop”, allowing traffic to flow and the extra cars at the special exit are destroyed.

I want to recommend not connecting their computers through their phones, and instead home-runs to their access switch. Monitor only the VoIP phone ports.

And replace this ancient switch because I hate installing JRE6U45 to access old hardware.


It's very simple: traffic amounts exceeding a port's capacity are simply dropped. The switch buffer can hold (very) short bursts of data but when the buffer capacity is exhausted, excess traffic is dropped. For reference, a 1 MB buffer can hold 8 milliseconds of 100 Mbit/s traffic or 800 microseconds with 1 Gbit/s.

In real workflows you can configure QoS to select which kind of traffic is forwarded with priority and less susceptible to be dropped but this is not likely to work with mirror ports.

The basic problem in this case is bad design. SIP protocols should be produced by the application and not be recreated by frame forensic.

  • Thanks Zac. I suspected the traffic would be dropped. I agree with the bad design. Wonder how many of the recorded conversations are unintelligible. If the design was only for ext calls, no problem, but they required internal calls be recorded as well and this was the manufacturer design from a few years ago. Will validate this and hopefully change. Jul 13 '18 at 21:41

Switches can have tiny buffers, but in general, any excess traffic for a switch interface is simply dropped. You should be able to check the interface utilization for the monitor interface to see how much, if any, traffic is being dropped.

The monitor function of a switch is really designed to be used to troubleshoot, then be disabled when done troubleshooting, and you should not depend on it for such an application. I have seen this before where Cisco RSPAN was used for call recording, but that broke down when different switches were added because they didn't support Cisco RSPAN.

There are other, better methods to achieve call recording. I have seen this done on the SIP gateway, and in some cases, phones can be configured to support sending a separate stream to a specific address.

  • Thanks Ron. I'll check with Mitel to see if there is another way of handling this. Was due to a need to record internal as well as external calls. System design only allowed for external calls, but will be upgrading from an older platform in a few weeks. Jul 13 '18 at 21:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.