Sigh.
The last day at work in 2014 (Debtember 18^th), I spent it running yet another IOT (Interoperability Test) [1], which involves running tcpdump to capture the network traffic on our end to verify that we receive and send the data properly. After running a test, I would load the resulting capture into wireshark [2], filter for the SIP (Session Initiation Protocol) protocol only to find—
Nothing.
“Project: Sippy-Cup [3]” was getting the packets and responding correctly—well, as “correctly” as these things go [4], but I was not seeing any packets under wireshark, no matter what I did. But the whole test setup is so jury-rigged that it wouldn't surprise me at all if we were, in fact, doing NAT (Network Address Translation) over avian carriers [5] that it seemed rather pointless to spend the next few hours trouble shooting my inability to do network captures when the other participants were able to capture enough of the transaction to let us continue running the test.
Especially as I was [DELETED-one day from retirement [6]-DELETED] a few hours away from a two-week Christmas vacation.
And then today, I learned that we were, in fact, capturing data.
Why was wireshark not showing the packets?
Because I was telling wireshark to filter on SIP, which defaults to port 5060. We were running our SIP component on port 5061, because of some odd-ball router on our network that oh-so-helpfully looks for SIP traffic and attempts to proxy it anywhere else than our SIP component.
And because we were running on a non-standard port, wireshark wasn't showing us the proper packets as it was looking only for packets on port 5060.
I swear, I think IP (Internet Protocol)-over-avaian-carriers would be easier to deal with.
[2] https://www.wireshark.org/