VoIP profile

Often when a question is asked as generically as this it's difficult to answer. In a way you're really asking "How can I support a SIP-based VoIP network", which is a huge topic of its own.

Personally I find there's little benefit in customizing too much with profiles for something like SIP since the 'optimal layout' depends too much on what you're looking for in that moment. If you have a specific goal, the tools in Wireshark (like custom columns/sorting, or the different time field types) can help, but you need to start with a question.

As a 'default', I do set a custom colour rule for SIP traffic just so it stands out over the default for UDP (I make it purple), and I also include SIP errors in my catch-all 'something is wrong or at least cautionary' colour rule that I set above everything else, but those are the only SIP-specific things I would start with, where what columns I'd want to set would depend a lot on what I was trying to do (and why I was opening that packet capture file to begin with).

Now, for just 'validating a VoIP network', you need to develop a test plan, where Wireshark is just one tool that can be used within the scope of that plan. Examples of things you'd want to validate would be:

• Call setup time
• End-to-end delay of RTP/media
• Jitter
• Capacity of the network to support the calls.
• Network QoS design (queuing model, prioritization, marking/classification, etc.)
• Per-use-case call flow validation
• High-availability/redundancy testing and validation.

If you are looking at this as an "example call that didn't work", as with any signaling flow the key is to follow the call flow. Where did it break? For your question of what things should be watched out for, I can say with SIP that every vendor seems to do something differently and I've seen it break at just about every possible point, so that question is just too open-ended to answer. I've literally had a case where a UDP port number was dynamically changing for the RTP stream mid-call after a given number of seconds in a call, so there's no quick checklist to cover all the possible bases here - just follow the call flow and make sure your test plan includes all the use-cases you have for the service.