PCAP - SIP Fault finding with packet captures

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 simple records all of the communications data and allows for it to be loaded into applications for analysis.

Along with a understanding of SIP it is possible to ascertain where faults and errors occur.

Location, Location, Location

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).

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@ SIP/2.0" tells that this is an invitation to a call. It also gives the SIP address of the receiving endpoint (sip: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@>;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, 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. Lets describe the individual methods:

  • 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 are 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 extend 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).



Call Encryption - TLS/SRTP walkthrough
Embedded thumbnail for Call Encryption - TLS/SRTP walkthrough
Hosted Directory LDAP - Lightweight Directory Access Protocol
Embedded thumbnail for Hosted Directory LDAP - Lightweight Directory Access Protocol
Cloud PBX Explainer
Embedded thumbnail for Cloud PBX Explainer
Zoiper Softphone Configuration
Embedded thumbnail for Zoiper Softphone Configuration
Call Conferencing
Embedded thumbnail for Call Conferencing
Receptionist Console
Embedded thumbnail for Receptionist Console

Search Help Portal

Get in touch

VoiceHost Limited
Norfolk Tower
Surrey Street

UK Freephone 0800 2 545454

International +44 1603904090

support [at] voicehost.co.uk

Connect With Us

Download the iOS App from the Apple App Store

Get the Android app from the Google Play store