In this section, we'll take a look at how SIP works when a connection is created between two phones, and how RTP works to transmit the live data between the two.

The example capture that we'll use for this chapter and the next one is available on the Wireshark SampleCaptures page (https://wiki.wireshark.org/SampleCaptures). If you scroll down and look for the SIP and RTP section, we'll be using the MagicJack+ short test call:

Download MagicJack+ short test call and open it in Wireshark.

Once you have that open, we'll take a look at our capture and notice that we have a variety of packets; it has not been yet been cleaned up:

We can see that there's some ARP, some UDP traffic, ICMP, some SIP, and some RTP; we also have some SMB in the end. So there's a mixture of stuff; this is like a real capture. In order to pick out just the SIP traffic, which is one of the many protocols but the most common protocol to use for VoIP, we simply enter sip for our display filter and apply it:

There are a number of other protocols in use as well, such as Skinny, which is a very popular one for Cisco networks, but the standard one is SIP. What SIP does is create the connection between two devices. If you look at the left-hand side of the following screenshot, you can see the Time column. We have 159 seconds. So, what we have here is one series of connection attempts. It's all very quick, very much in the same time frame. Then, we have another packet: 166 seconds, and then we have another couple in the 170s. It's important to note because we're missing some data.

As mentioned earlier, the capture also consists of some RTP traffic. What happens is, SIP creates the connection between the two devices. However, the actual data, that is, the video traffic or the voice traffic (whatever it is), is transmitted over the real-time protocol, RTP, directly between the two devices. So if we're filtering on SIP, we'll not be able to see it. What we need to do is add rtp to this and that'll flush out some of this missing time frame we have here.

For that, we'll type sip || rtp, and you can see that we now have our connection creation with SIP:

As you can see, we have RTP, which is the transfer of the voice traffic, and then we have some SIP goodbye commands at the bottom. And just like with the other protocols we've spoken about, they use status codes in SIP, just like with many others. So, we have the 400 series, which is a problem; we have 100 series, which is a success; and there are some other commands as well.

What we see in the preceding capture are a number of connections and then some actual data traffic sent. And this is actually a very good capture because it shows us a problem as well as a solution.

So, earlier, we discussed about status codes. Here, we have a Status: 100 Trying:

What we have is a local device, which looks like some sort of phone, that is trying to create an SIP connection out to magicJack. It's providing an INVITE command, saying: Please invite the following device into the connection. And this is being sent to 216.234.64.8 address; it's being sent to the magicJack SIP server. The SIP server is handling the connection between one phone and the other, and then once that connection is established it is hands off with the communication. It does not act as a proxy and pass through all the data traffic, it only creates the connection. So we can see that here we have 216.234.64.8. Our device is sending a request to it, saying: Invite the following phone number. Try to call it. The server responds back and says: All right. I'm going to try it out, but you're not authorized.

We then have a second request:

The phone calls out to the server again and says: Please invite the following number. Trying to call it. The server responds back, saying: ok. I'm trying it. I'm going to ring that phone. We then have a success, and it provides us with a Session Progress.

If we expand SIP, we can see that we have Session Progress:

So, we have a success here.

Then, we have additional data about who the call is from and to, as well as what's in the body:

Then, you can see in the body section:

Here we have Media Description, name and address (m): audio; what port is using RTP. So here we are defining in SIP that we'll use RTP to transfer audio traffic between the two devices defined in the message header From and To.

Once that connection is established, we see that our local phone, this 192 address, is now connected to a different public address; look at that last octet:

We also see that we're using G.711, which is the encoding scheme. There are a number of different encoding schemes out there: some of them are better quality, but with a higher bandwidth; some have less bandwidth with the lesser quality. It's up to you as to which one you want to use, but G.711 is a very common one.

In the RTP information, we can see that we have a Payload type: ITU-T G.711 PCMU (0):

ITU is yet another standard body, just like IEEE and IETF. They define certain protocols and encoding schemes such as G.711. Then, we have a whole bunch of data packets between the two devices direct, all with RTP. Then, down at the bottom we have a connection request to terminate the connection, so there's a goodbye:

Then, we have a status OK, saying that we terminate the connection. What we can do is take a look at these in the Telephony statistics area.

Anything you want to know about your VoIP traffic can be found under this section in Wireshark:

Two of the greatest spots to go look are VoIP Calls or SIP Flows; it really depends which one you want to go into. But if we go into VoIP Calls, we see that here's the one phone call:

If we had a bunch of phone calls happening at the same time in one packet capture, they would all show up here in a nice chart and they would have what times they started and stopped, who initiated the connection, who's it from and to, what protocol were they using, and so on. What we can do is select that and go to Flow Sequence, and we can see a great diagram of what ports are on local side on the local phone, what ports are on the remote side on the SIP server, and what ports were used here on the actual device:

You can see that there are three devices in use. All the SIP traffic (look at the right side in the Comments: you see what protocol's in use) goes to the middleman. Once the connection is established, then we have RTP traffic. The audio traffic in real time goes to and from between these two devices on RTP direct. Then, when we want to terminate the connection, we send a goodbye and then an ok to acknowledge that, and we've terminated the SIP connection. But again, remember it occurred to the control server, the SIP server. This is a really great way of being able to diagnose what's going on in a phone call, and if you have a problem with the SIP connectivity, with some sort of VoIP provider, taking a look at this and telling them what commands are sent and which ones are received is very helpful for the troubleshooting person to diagnose what's going on. They can compare what we see to what they saw and it's very helpful, especially the commands 100 Trying; 200 OK; ACK; and BYE.

In comparison, we can take a look at the Statistics | Flow Graph:

We've looked at this earlier:

You can see that the flow graph is a bit more complicated to look at. You can still get some of the same information from it, but it's more difficult to view since it's per packet. It's always better to use the other flow graph. Even though we can address this to displayed packets by selecting the option Displayed packets from Show, it's still for every single packet. So if you're just talking about the basic connectivity or the basic flow, the other flow graph is better. If you need extreme detail, you can take a look at that in here.

You can also take a look at the Telephony | SIP Statistics:

The SIP Statistics will give you a count of how many different occurrences have happened of different requests:

Remember how there are different codes that are in use, just like HTTP and FTP, and all the other ones we've looked at? Same thing here, and it will give us a count of how many times certain things have occurred. So, this was the SIP Responses, and then we have SIP Requests; and you see that there are two acknowledgments, a goodbye and an unauthorized, and if you have a long packet capture with a bunch of problems, you can take a look at this, and, of course, you can sort that based on your counts and see which ones are the most common. If you see a bunch of 400 or 500 errors, that might be a problem that you need to investigate.

And just like with SIP Flows, we can take a look at RTP, which is the audio traffic, the actual voice traffic, and look at the RTP Streams in addition to the SIP Streams:

So remember we had that one connection from the phone to the magicJack phone? We see that in the bidirectional setup. So, we have the connection from the phone out to the magicJack, and then from magicJack back to the phone. And these are both RTP; the payload is G.711, like we talked about before. It also gives us some good information about the jitter. The jitter is a very useful statistic to look at. The lower the jitter, the better things are for voice traffic. Any sort of packet loss that you have (which is also a column shown earlier); any sort of jitter that you have; or any latency: these are all major problems for voice traffic, be it any sort of real-time traffic: video traffic, voice traffic, and so on.

Jitter is the difference in latency between different packets, and you have massive swings from one packet to another. You can have a lot of audio quality problems as packets are arriving at different times and get jumbled up in the software. You might have some packet loss as well in that sort of situation, so then you're losing certain words, and that's when you start getting really weird crackling problems; you get dropped words; you might have one side that's completely silent and the other side can hear. You can have all sorts of strange problems when you have a lot of jitter or packet loss. In this section, we looked at some VoIP traffic using SIP and RTP and how to filter on those, as well as how to look at some statistics and some flow graphs on them.