Yeah, this configuration makes very little sense. Based on what you have here I can only infer that the device that was connected to the phone was virtualizing a network card (like a Hypervisor software of some kind). If this is the whole configuration on the port, it's saying the following:
Allow a phone to be connected and run in a different VLAN as data (switchport voice vlan 203)
The data coming through this device will be tagged with multiple VLANs present (switchport mode trunk)
As it's a trunk, here's the encapsulation (switchport trunk encapsulation dot1q)
Don't tag VLAN 3 (switchport trunk native vlan 3)
On this trunk, as VTP is used, don't learn or allow VLANS 5 through 1001 (switchport trunk pruning 5 - 1001)
Now the description in the most alarming part to me... this implies that this is the default configuration for all ports on the switch, and possibly throughout the entire network. I don't see a BPDUGuard on a port that is always up as a trunk, nor any spanning tree, so... I mean... switching loops and VTP domain jacking is possible. That's fun.
I know you didn't ask for advice, but here's what I would do:
switchport access vlan 3 (looks like that's what the admin was going for)
switchport voice vlan 203 (if no phone, then no problem)
If you do port security or plan on it in the future, definitely explicitly add:
switchport mode access
Call it a day. Get that trunk stuff off of those ports.
