What are Pcap files? How do I get them? What do they mean?
A Pcap or 'Packet Capture' is also known as a log or SIP trace. As the name suggests it simply records all of the communications data and allows for it to be loaded into applications for analysis. Along with an understanding of SIP it is possible to ascertain where faults and errors occur. The location of the Pcap is important as VoiceHost can obtain them from our edge network but they can also be of value locally (from inside a local network or behind a firewall).
TLS and SRTP traffic will require decrypting and for obvious reasons we do not share encryption keys.
PCAPS also fall under various data protection laws legislation including GDPR and RIPA. You must adhere to legislation as do we.
Performing and Analysing SIP Packet Captures
Two programs are useful for this purpose but bear in mind that TLS and SRTP traffic will require decrypting and for obvious reasons we do not share encryption keys.
Collectors:
- TCPdump (Linux) www.tcpdump.org
- WinPcap (Windows and bundled with Wireshark - see below )
Analysing:
- Wireshark www.wireshark.org (Windows + MacOS)
Message Headers and Call Flows are the quickest way to determine VoIP faults
Let's describe the most important message headers in the example above.
The request start line: The string "INVITE sip:13@10.10.1.13 SIP/2.0" tells that this is an invitation to a call. It also gives the SIP address of the receiving endpoint (sip:13@10.10.1.13) and identifies the version of the protocol (SIP/2.0).
- Call-ID: This is a unique identifier of the given SIP session. It usually consists of a random string and the IP address of the sender.
- CSeq: This is an ID that identifies the particular SIP transaction. As mentioned in the previous section, the same CSeq: is always shared by a request and its related response or responses. The CSeq: identifier is composed of a sequence number (incremented for each new request) and the name of the particular request.
- From: This field ('From: "Test 15" <sip:15@10.10.1.99>;tag=as58f4201b' in our example message) contains the address of the caller with an optional display name and with optional tags. From: is a mandatory field in all SIP requests and responses. In SIP responses, From: is always a copy of the From: field in the related request message. Note that in our example, 10.10.1.99 is the IP address of the Asterisk PBX which plays the role of a SIP proxy. The actual caller (phone number 15) might be located elsewhere but the proxy will not show the actual IP address in message headers.
- To: This field contains the address of the called party. To: is a mandatory field. The To: fields in responses are copied from the related request message.
- Via: The Via: headers are used to record the route of the request. Each proxy server on the path of the message will add one Via: entry. Thanks to this, the replies can be routed back along the same path.
- Content-type: This field describes the media type of the message body. The type is usually "application/sdp", denoting the Session Description Protocol (we will look at SDP later). The message body can be sometimes empty (e.g. the REGISTER message) and then the Content-type: header is not present.
- Content-length: This is the length of the message body in octets. This header is always present but can be 0 (denoting there is no message body).
The message body carries a message of the Session Description Protocol. This message contains a description of the audio (and possibly video) channel that the calling endpoint wants to establish. We will look at the Session Description protocol later in a greater detail.
SIP Requests
SIP originally only had 6 requests (also called methods). These requests have been a part of the standard since SIP 1.0.
Individual methods can be described as:
- INVITE — This is a request to establish a call (a session). We have seen an example of the message above.
- CANCEL — This method is used to stop an INVITE that is in progress (that is, the call has not been established yet).
- ACK — The ACK request is used to confirm that the endpoint has received a final response in a transaction. Typically, after the called party accepts a call, the caller confirms the receipt of the accepting response (200 OK) with the ACK method.
- BYE — The BYE method is used to end an established call (compare with CANCEL that is used to stop the session before it has been established).
- REGISTER — The REGISTER method is used to register the SIP endpoint at the registrar server. This method does, in fact, the same as the Registration Request (RRQ) in H.323.
- OPTIONS — This request is used to ask the other party for the list of SIP methods it supports. The response may also contain the set of capabilities (i.e. audio/video codecs) of the responding party.
In addition to these six requests, several other SIP methods have been added, either in SIP 2.0 or in other individual RFCs. For example, the INFO method was defined in RFC2976. It can be used to carry application-level information that is relevant to the session, for example, participant images or account balance information. The INFO method can also be used to carry DTMF digits.
The three methods SUBSCRIBE, NOTIFY, and MESSAGE extends SIP with instant messaging features. If you send the SUBSCRIBE method, you are asking the other party to send you notifications about status changes ("available", "busy", "away", etc.). The status change notifications are then sent in the NOTIFY messages. Last, the method MESSAGE is used to send instant messages. The text of the instant message is simply transported in the body of the method (Content-Type: is usually text/plain).
