As we learned in the previous recipe, SIP (RFC 3261 and various extensions) is a signaling protocol that is used for creating, modifying, and terminating user sessions between one or more participants. While sending SIP requests, the session parameters are sent via SDP (SDP, RFC 4566) which enable users to agree on a set of compatible media types between them. When sessions are created, the voice or video is carried by RTP and optionally controlled by RTCP (RTCP is optional, and can be used by multimedia applications, but it is not a mandatory protocol).
SIP defines endpoints as User Agents (UAs), and the process of creating a session involves UA negotiation in order to agree on a characterization of a session that they would like to create. For additional services such as locating session participants, registration, call forwarding, and others, SIP defines network hosts called servers to which UAs can send registrations, invitations to sessions, and other requests.
In this recipe, we will discuss the signaling part of the protocol suite, which is SIP, and how to use Wireshark in order to troubleshoot signaling problems, while in the next recipe, we will learn about RTP and RTCP.
Problems in voice and video over IP can be categorized in to two groups:
- Problems of call establishment, modification, and termination: These will be problems such as instances when you pick up the phone and you don't hear a dial tone, you hear the dial tone but cannot dial a number, you dial a number but the other side doesn't get the call, and so on. These types of problems are usually caused by signaling issues.
- Problems of quality: These are problems related to quality, such as voice quality, disturbances (like noise) during the call, video freezes, and so on, which are usually caused by networking problems, RTP problems, or various types of media issues.
In this recipe, we will discuss the first type, and in the next recipe the second type.
While facing problems of the first type, in most of the cases you are having signaling problems. Connect the Wireshark to the network, and follow the steps in this recipe in order to solve it.
We have two major types of messages in SIP: methods and responses. Methods are commands initiated by one side of the session, and responses are generated as a reply.
While troubleshooting an SIP session, keep track of the responses and what they say. Only the major types are brought here.
After you've connected Wireshark to the network, follow these steps:
- When a UA desires to establish a multimedia session, it sends an INVITE method to the remote UA. In the following diagram, you can see an example for a basic call flow.
- In the following screenshot, you see an example for a telephone call flow:
- To see the detailed call flow, navigate to Statistics | Flow Graph, and mark the following:
- Displayed packets
- General flow
- Standard source/destination addresses
The Graph Analysis window is shown for reference as follows:
- After INVITE, you should see Trying, Session Progress, Ringing, or a combination of them coming from the other side.
- We can see here how the session progresses between the initiator on 93.172.121.146 to the responder on 192.168.3.2:
- The INVITE method is sent from the session initiator; this will always be the first packet that starts the conversation.
- The responder answers with Trying (code 100), Session progress (code 183), and after three seconds with Ringing (code 180). Then it answers with OK (code 200), meaning that the handset was picked up.
- The initiator sends ACK, and the session is established.
- If an error message is received at this stage, the connection will not be established.
Tip
Don't forget that SIP works over UDP, and since UDP does not open any connection to the other side before sending the request, it can be possible that a request will not arrive to the destination simply because of a network-reachability problem. For this reason, when you don't get a response, it can be that INVITE simply didn't get to the destination because of a network problem.
- When there is a telephone switch between the user clients, the session will look like the one shown in the following screenshot. You will hear the term IP telephone switch, Call manager, IP PBX, and others. They all mean a telephony switch that handles the signaling between devices. The SIP terms together make up a Proxy that we will talk about in the How it works... section of this recipe.
- Here you see that the switch has two interfaces—the first one on the internal network (10.179.236.162), and the second one on the external network (212.179.236.162):
- The client on the left, 10.219.62.150, sends an INVITE request to the switch (numbered as 1 in the preceding screenshot).
- The switch replies by saying that it is Trying (numbered as 2 in the preceding screenshot).
- The switch sends INVITE to the client on the right (numbered as 3 in the preceding screenshot).
- The client sends Trying (code 100), and then the session progresses (code 183) to the switch (numbered as 4 in the preceding screenshot).
- After a while, the switch sees that the client has not responded, and to notify the initiator, it sends them code 488, which means invalid or not acceptable, with an explanation as to why it was not accepted (numbered as 5 in the preceding screenshot).
- The switch sends a Cancel message to the client on the right (numbered as 6 in the preceding screenshot).
- To allocate problems in SIP, do the following:
- Draw the network with all of its components.
- Check for the error codes.
- Figure out the reason for the errors.
- SIP error codes are listed in the following table, along with their possible reasons. Unless mentioned otherwise, codes are defined in RFC 3261.
The 1xx codes or provisional/informational codes are those where the received request is still in process, and the receiver notifies the sender about it. They are described in detail in the following table:
|
Code |
Event Name |
Reason |
|---|---|---|
|
100 |
Trying |
The request has been received and accepted by the server, and an action is being taken for this call. |
|
180 |
Ringing |
The UA that received the call is alerting the end user. This is the message that is sent back to the client while doing so. |
|
181 |
Call forward |
The call is being forwarded to another destination. |
|
182 |
Queued |
The called party is temporarily unavailable, and the server saves the message for later delivery. |
|
183 |
Session progress |
The session is being handled by the receiving server. Additional details on the call progress can be conveyed in the message header. |
The 2xx codes or the success codes indicate that the action was successfully received, understood, and accepted. They are described in detail in the following table:
The 3xx codes indicate that a redirection action needs to be taken in order to complete the request. They are described in detail in the following table:
|
Code |
Event Name |
Reason |
|---|---|---|
|
300 |
Multiple choices |
The address in the request was resolved to several choices, and the accepting server can forward it to one of them. The UA can use the addresses in the contact header field for automatic redirection, or confirm it with the sender before redirecting the message. |
|
301 |
Moved permanently |
The user could not be located at the address in the Request-URI, and the requesting client should try at the address provided in the contact header field. The sender should update its local directories with the change. |
|
302 |
Moved temporarily |
The requesting client should retry the request at the new address/addresses provided in the contact header field. |
|
305 |
Use proxy |
The requested resource must be accessed through the proxy, whose address is given by the contact field. |
|
380 |
Alternative service |
The call was not successful, so the recipient sends this response for alternative services to be made available on the receiver. These services are described in the message body. |
The 4xx codes or client error indicate that the request contains bad syntax or cannot be fulfilled in this server. They are described in detail in the following table:
The 5xx codes or server error codes indicate that the server failed to fulfill an apparently valid request. They are described in detail in the following table:
|
Code |
Event Name |
Reason |
|---|---|---|
|
500 |
Server internal error |
An unexpected condition prevented the server from fulfilling the request. |
|
501 |
Not implemented |
The functionality that requested to fulfill the request is not supported by the server. |
|
502 |
Bad gateway |
A gateway or proxy received an invalid response from the downstream server it accessed while attempting to fulfill the request. |
|
503 |
Service unavailable |
The server is temporarily unable to process the request due to temporary overloading or maintenance of the server. |
|
504 |
Server time out |
The server processing the request has sent the request to another server in order to process it, and the response did not arrive on time. |
|
505 |
Version not supported |
The server does not support the SIP protocol version that is used in the request. |
|
513 |
Message too large |
The server was unable to process the request since the message length is too long. |
The 6xx codes or global failure codes indicate that the request cannot be fulfilled at any server. They are described in detail in the following table:
SIP is an application-layer control protocol that is used to establish, maintain, and terminate calls between two or more end nodes.
SIP defines two basic classes of network entities—clients and servers:
- A client is an entity (or application) that sends SIP requests
- A server is an entity (or application) that responds to those requests
For connectivity to other network types, we have gateways. A gateway connects between SIP and Public Switched Telephone Networks (PSTN), or SIP and H.323.
As illustrated in the following diagram, a client is made of User Agent Client (UAC) and User Agent Server (UAS), and each client can initiate or respond to requests.
SIP servers can be of various types:
- Proxy Server: This receives SIP requests from a user agent or another proxy and forwards or proxies the request to another location
- Redirect Server: This receives requests from a user agent or proxy, and returns a redirection response (3xx), indicating where the request should be present
- Registrar: This receives SIP registration requests and updates the user agent information to a location service or other database
In the following diagram, you see how they all fit together:
An IP phone registers to the registrar (1). The registrar checks with the organization server (2), and if it's all OK, it sends an SIP request to the provider's proxy (3). The provider's proxy checks with the DNS server for the IP address of the requested client's domain (4), and then it forwards the requests to the destination proxy (5). The destination proxy sees that the client is not in its place and checks with the location server for its location (6). When found, the SIP request is forwarded to the destination client (7). The destination client confirms the acceptance of the request to the sender (8). When all is okay, an RTP session is opened on the UDP ports described in SDP when opening the session (9).
The SIP message is built as you see in the following diagram:
The first part is the Request line in which we have:
- The method; INVITE in this case
- The requested URI
The second part is Message Header, in which we have:
- Call-ID: This provides a unique ID for the call
- From: This indicates the initiator of the call
- To: This indicates the destination of the call
- CSeq: This contains the sequence number, which contains an integer followed by the request method. Each successive request during the call will have a higher CSeq number, and the caller and called parties each maintain their own separate CSeq counts.
- Via: This indicates the path taken by the request so far and indicates the path that should be followed in routing responses.
- Contact: This contains one or more SIP URIs that provide the other party in the session with information for contacting the initiating user
- Allow: This indicates which methods are allowed
- Supported: This indicates whether parameters such as timers are supported
- Max-Forwards: This is the maximum number of hops to pass to the destination
- Content-Length: This is the byte count of the message body
- Message Body: This contains information on the codecs that are supported by the sender; for example, timers supported
When debugging a phone call, first filter the call with the Call-ID parameter. To do so, you can do one of the following:
- Look for the Call-ID parameter in the Message Header field in the SIP header, right-click on it, and select Apply as Filter, as illustrated in the following screenshot
- Use the VoIP Calls feature from the Wireshark menu
When debugging an SIP trunk that is signaling between IP PBXs, try to figure out whether there is there a specific call that doesn't work or whether all calls have the same problem.
To troubleshoot VoIP calls, the best way is to read the SIP messages. They will tell you what to do.