Debugging is part of life as an engineer. If I had a dollar for every time I double and triple checked my configuration to confirm, then got to the point where it was time to run debugs, I would be a rich motherfucker.
Debugging on IOS is pretty damn good. I applaud Cisco for how well they build these sort of features into their products, not to mention how well documented they are. But, as Mick Jagger once said, “You can’t always get what you want”.
That’s what happened today when I started looking into a problem getting T38 to work with the following call flow: Verizon SIP trunk –> Acme Packet 3820 –> CUCM SME –> CUCM Leaf –> MGCP connected VG224
We see the re-invite for T38 version 0 sent to Verizon, and they send us a 200 OK with SDP indicating T38 version 0 as well. The call stays up for 32 seconds, and then we hang up and send Verizon a BYE.
All the debugs looked good, so it was time to start capturing packets. In this environment, it’s pretty difficult to get a network engineer to do a port span – so we chose to capture packets on the VG224.
Here’s the config we used to do this:
debug vpm signal
monitor capture buffer holdpackets
monitor capture point ip cef t38trace FastEthernet 0/0 both
monitor capture point associate t38trace holdpackets
monitor capture point start t38trace
monitor capture point stop t38trace
monitor capture buffer holdpackets export tftp://10.98.1.198/t38capture.pcap
no monitor capture point ip cef t38trace FastEthernet 0/0 both
no monitor capture buffer holdpackets
If you want to read more about capturing packets in IOS – check out this Link.