It’s encapsulated in SIP SDP is formalized in our FC forty-five
thats how sip works.
Sixty-six and what SDP does for us that sip doesn’t do is describe what’s in the call. What we’re gonna be using for the media session or this the call itself. And that includes things like the media type and the Kodak we’ll take a look at a packet here and the second connection info such as the IP address and then there’s a session name and it’s just a name that we use to more easily refer to the collection of packets that constitutes the session the duration and there’s actually a whole bunch of bunch of stuff in the SDP packets.
Now for those of you that are familiar with H.R. 3 2 3 those types of calls start with H.R. 2 2 5 just set up the call and that’s where CIP comes in. But to give us the information about the session itself H.R. 3 2 3 uses H.R. 2 4 5. And that’s kind of the place that SDP fits for Sepp. So here’s an example. STV packet you can see there’s an awful lot of information about the Kodak there but there’s also the IP address that we’re using.
There is our time description. And so this is the information about the call if you take a look at the line that’s highlighted there you’ll see audio 34 0 0 8. That’s actually the port that we’re going to use. And so if we looked at the RTP packets that come up later on in this conversation you would see that RTP is actually using that particular port for the conversation. Now this is again similar to what aged up to four or five DOES WITH A SHOT THREE TO THREE It sets up the the connection tells us how we’re going to drop out of our signaling protocol into our transport protocol. So let’s take a second and return to sip. So we talked about some basic structure.
Sip has the two and the from values sip also has the call I.D
This is how we identify all the packets that go along with the particular call and sequence numbers. The methods that are supported sip addressing that is used. Those are all part of the SIP packets. But I didn’t show you yet the collection of packets that are used on a regular basis. So on this particular image what we see on the top part here is a phone starting up.
So we’re gonna see that the phone registers so have some details about the supported methods and then we return a couple of statuses here from both sides. Now the collection of packets below that you can sort of see that the number changes. So you went from packet numbers 1 12 through 1 15 and then we had packets that were ten through twenty-five here. And that’s because we’re looking at two different captures. They’re from the same phones but two different parts of the operation.
So the first part is the phone starting up finding the call server and registering and then the second one is an actual call. And so in this case one dot eleven here has initiated the call goes out and calls server and says hey I want to call this guy so we can see that there’s the invite that goes and then the trying and ringing messages and then we have the connection is actually made with the CIP or SDP packets being swapped to describe how we’re gonna set up this session and then we drop into RTP which is our transport protocol.
Now the other thing that I’d like to point out here are those statuses or the codes. And so in these these packets here we can see the status of one hundred one eighty two hundred. And that’s because we’ve got a couple of very common codes here. Provisional codes and then success codes and I’ll outline those a little bit for you later on. In this image you’re just isolating those Sim packets that have something to do with the call. Now what I also wanted to point out here is that a very handy tool in Wireshark and how many peak and other packet capture analysis software tools is the ability to flowchart the conversation.
So this becomes an important skill for us not only in being able to read one of these diagrams but actually be able to generate one. And so here we can see the two sides of the conversation. One dot one and one dot eleven. And here are the messages flowing back and forth as indicated by the arrows. So this is who’s sending the message to who. And the codes that go along with it. And then of course we can see the RTP stream toward the the middle bottom.
And then lastly we see a set message that we haven’t actually talked about yet. And that’s how we close down a sip conversation with the SIP by message and then the acknowledgement coming from the other side. And these are the zip codes here. I mentioned that the one x x those are provisional codes we don’t really know what’s going on. There’s not a real problem we just sort of waiting. We see this very commonly when nodes you’re trying to contact each other with invites and especially when we’re going across between cultures.
The 200 series or the 2 x x series Those are happy codes that tells you that what you were trying to do work three X X means some form of redirect. Again very commonly between systems anything begins with a four or five or six that’s bad. These are error codes of some kind and hopefully we can stay away from those but if you’re trying to set up a sub trunk or something like that and you’re getting annoying tones in your phone when you’re trying to call likely that you’re generating for x x 5 x x x x x error code messages as we get rain and wind down today I wanted to close up with SIP trunks and sip security a little bit SIP trunks are one of those things that everybody talks about.
Sometimes they seem a little bit confusing. But if we take a look at what is referred to as the SIP trapezoid This is an image right out of the SIP bar of. You can see that I’ve tried to include all the reference information for the image as I didn’t make this one. We can see that there are two maybe call servers or proxies here and we see Alice and Bob on the two sides there. So if you can imagine a system that Alice is residing on as having one particular set of dial patterns. So here at our I.T. where everything begins with a 4 7 5 and over there are bombs phone maybe everything begins with
7 7 7. So any time you’re calling from Alice to anybody in Alice’s organization it’s handled by the local callers but when you’re trying to call somebody outside you’ve got to have sort of a gateway to send this to and that’s really what SIP trunks are all about. So Alice is proxy or Alice’s call server recognizes that when she dial 7 7 7 it’s destined for the network that Bob Wright resides on. So it’s got to be sent to the other end of the sub trunk in this case the block C dot com proxy in the same way when Bob wants to call Alice. He’s got to dial 4 7 5 and so that dial pattern is being recognized as being part of Atlanta. So there are two parts to a sip trunk. One is what dial pattern are you’re trying to reach and then what is the account or endpoint that’s associated with this particular dial pattern. And that’s pretty much the nuts and bolts of a zip trunk if you are a networking kind of person sip trucking is not unlike static or default routing. So that’s kind of what we have to do it to set up a dial pattern or a network pattern and send it to somebody and then they have to figure out a way to send it back to us.
Sip and RTP security
Well if you were taking a look at Voice over IP security the two big weaknesses that we have are going to be in SIP and RTP although for different reasons. SIP is very easy to read and understand. So that means the SIP signaling messages such as registration such as calls invites they’re all very easy to spoof and so SIP is susceptible to injects and hijacks and manner of the middle attacks as you as you saw from the packet capture and especially if you’ve been reading the chapter The SIP header format and the SIP fields are actually very easy to understand. So again for an attacker that makes it very easy to read RTP has a completely different problem. RTP as you may remember is the transport protocol and so you encode the audio or the video with a particular Codec and then send it across.
And so if you just had the data you have no idea what it means but RTP is very handy and then it tells you exactly what codec was used to encode this data with G that 711 being the most popular one. So that means that anybody that understands how a codec works and that has support for the codec that you used can be fed your packets and then replay them. So for those of you that are fans of wireshark or omni peak both of them have the ability to playback G that 711 streams and so that’s the basic problem with RTP is that you can collect RTP packets and then play them back at random. You can also inject RTP packets into streams by giving them the same the same values as the RTP stream and just direct them at the destination IP address. But the most common problem is with replay.