In the last two videos, we looked at the components
used in a voice network, as well as how they fit together.
In this video, we're going to dig into the protocols that make that possible.
These include SIP, SDP, RTP and RTCP.
SIP will be our focal point.
So we're going to start there.
SIP is the protocol that establishes, manages and terminates phone calls.
SIP was originally defined in RFC 3261,
and it has had additional features added since.
As it's defined in an RFC.
Any vendor can use it.
Every single device that uses SIP is
called a user agent or UA.
When two devices are talking with SIP, they follow the client server model
that makes the device that starts the conversation, the user agent client
and the device that responds the user agent server.
We usually think of the phone
as the client and the PBX on the server, but it can be the other way around.
It's really up to whichever device initiates the connection.
The devices will send a series of messages back and forth between each other.
This series of messages is called the SIP transaction.
The PBX is the heart of the voice system.
This is where phones register themselves and where the calls are maintained.
So in SIP terms, the PBX is called the SIP registrar.
Some devices like the SBC can be both a client and a server
for the same call flow.
When the call comes in, the SBC is the server, then
the SBC initiates a new connection to the PBX, so it's then the client.
So there are two parts to the call when the SBC's involved
and each part is called the call leg.
When an SBC or similar device handles
the SIP messages on behalf of the client, it's called a SIP proxy.
Because the SIP proxy handles all these zip requests.
It's in a good position to edit the SIP imessages if needed.
Sometimes a device will be a proxy for the voice traffic too
Voice traffic uses the RTP protocol, which we'll take a look at later.
If it is proxying voice traffic, the device is known as a back to back user
agent.
The SIP messages themselves are a series of requests and responses.
If you're familiar with HTTP, then you'll be quite comfortable with SIP.
For example, HTTP has a GET command, which is used to retrieve a Web object,
SIP has an invite command which asks a user agent to be part of the phone call.
In addition to commands, SIP and HTTP both have headers
which contain additional information about a request or response.
Oh, and technically, SIP is very flexible.
It can be used for many different purposes, not just voice.
It just happens to be really good at voice, which is what it's famous for.
Response messages
are also quite similar in that they have response codes,
if you've ever tried to load a web page and got a 404 message,
meaning the pages and found, then you've seen an HTTP response code.
So SIP has these too, which report on how a transaction is going.
These codes could be good news, or they could be errors.
Now, you may be wondering, why do I need to know this?
Well, when it comes to troubleshooting,
it's quite common to capture these SIP messages.
And if you understand how this works, even just at a basic level,
it will make it much easier for you to resolve any issues that you may have.
Let's take a look at a sip request.
The first line looks like this.
first, we can see the invite commands.
This simply means that we're inviting a sip endpoint to be a part of a phone call.
There are a lot of different commands that could be sent.
The most common ones are listed here.
For example, we can use the options command
to ask an endpoint what its capabilities are,
or we can use it as a keep alive message to see if a device is up.
After the command is the SIP address,
it's quite obvious, and it starts with the word SIP.
In this case, we have a phone number,
the IP address of the destination and the port we're using.
However, it won't always look like this SIP
address could also be an email address rather than the phone number and IP.
And finally, the last part shows
us the version of SIP that we're using. Version two in this case.
After the initial line, there are multiple headers,
don't get overwhelmed by everything you see here.
We're just going to look at the concepts of headers rather than the detail around
what each one does.
The reason we're not going into detail is because it is a lot of different headers.
Many of these are well known, but it's also possible to use
custom headers as well.
The important thing to know is that headers provide
more information about the request or response.
The to or from headers are obvious examples of this
from is where the calls coming from and to is where the call is going to.
So this could be
once again, an email address or an IP of a device.
As this is an invite message, it contains
the email of the user that we're inviting to the call.
Responses are very similar to requests.
The response starts with a single line.
This clearly shows us that we're using SIP version 2
It also includes a response code and description in this case, 200, OK.
There are six categories of response codes.
Anything in the 200 range simply means that all is well.
The 100 range is also good, but there's more information yet to come.
For example, the 180 response code means
the phone is ringing, but it hasn't been picked up yet.
Just like HTTP, the 400 and 500 ranges refer to some sort of error
404, for example, means that a resource is not found.
The rest of the response may look something like this.
It includes headers just like requests to which contain
even more information about the session.
If you're troubleshooting a phone call, you'll find these headers are very useful
to gather information about the call.
Let's take a look at a simple SIP transaction.
An endpoint will start the process by sending an invite message to the PBX.
This is informing it of its wish to start a phone call.
The PBX responds with a 100 trying message.
This tells the phone to wait while the PBX gets it set up.
The PBX will find the address of the destination phone and forward the invite on.
The destination phone now starts ringing.
So it will send back a 180 ringing message.
The PBX forwards this message on to the original phone.
The original phone plays a dialing sound for the person making the call.
Notice at this point that all response codes are in the 100 range.
These are called provisional responses.
They're keeping devices up to date with what's going on while still acknowledging
that there's more work to be done.
Eventually, someone picks up the ringing phone.
So this phone will send a 200 OK message to the PBX,
which is then forwarded on to the original phone.
The calling phone sends an acknowledgment
directly to the called phone.
RTP media now travels directly between the two phones
without the PBX being involved.
And when someone eventually hangs up, their phone will to send a bye message
to the other phone, which it will respond to with a 200 OK message.
Of course, that's a simple transaction for a simple phone call.
It gets more complicated when there are more devices involved,
when calls are forwarded, when IVR is used and so on.
When there are more SIP hops along the way
they will add VIA headers.
So every time they requested an SBC,
the SBC will open a new call leg and its own details to the SIP message.
The via header clearly identifies the sip version, the transport protocol
and the IP address and port number of the device.
It also includes a branch tag at the end.
This is a unique I.D., which is used to identify
this particular transaction.
If there are several SIP hops along the way,
then there will ultimately be several VIA headers is in the SIP message.
An interesting fact about SIP
is that he doesn't care about what type of media the phone call will use.
It doesn't care if it is voice or video traffic.
It doesn't care what codec will be used, it doesn't care about any of it.
All it wants to do is get all the parties involved to set up that call.
But it's information still needs to be negotiated between our endpoints.
So if SIP doesn't handle this, what does?
The answer is SDP.
This is a separate protocol that works hand-in-hand with SIP.
That is, it's extra information that can be sent along with certain SIP messages.
Oh, technically, it doesn't have to be used with SIP,
it can be used with other protocols like HTTP, if we need it to
To put it simply,
SDP is a list of well-known fields like the ones shown here.
They include the SDP Protocol Version,
the origin, which is information about the source of the call.
The session name session information.
Optional URI, email and phone number.
Connection information, which is IP address information
and optionally the bandwidth as required.
But the really interesting parts are around the media.
There is a section which defines the supported media types
such as audio, video, Instant Messenger,
as well as the codec and the protocol that's used to carry the data.
We're keeping it simple here.
Is this just an introductory video if you want to know more
Take a look at the links in the description.
It also gets interesting when we look at how this information is shared
between the endpoints.
This can be done in two different ways, which are called early offer
and delayed offer.
The device initiating the call
may send the SDP data along with a sip invite message.
In a case like this, the phone that's making
the call is proposing which media types to use for the call,
the recipient would then agree to this in their 200 OK response.
If there's no SDP information in the invite message,
it is called a delayed offer. In a case like this,
The responder would propose the media to use in their 200 okay message.
the calling phone would agree in their acknowledgment message.
Now either of these messages is fine.
Some devices just seem to prefer it a particular way.
Just be aware of the difference if you happen to be troubleshooting sip
messages.
Before we wrap up, let's take a very brief look at RTP.
The protocol it carries media and its friend, RTCP.
So far, everything we've
talked about is just about signaling and other information.
RTP, however, carries the actual audio
and video that we hear and see.
We could use other protocols for this purpose, of course, but RTP is
probably the most common, which is why we're focusing there.
RTP can be either TCP or UDP, but most often we'll use
UDP as UDP is very lightweight and won't try to resend missing data.
And that may not sound great, but remember that this is Real-Time Media traffic.
If we lose a few packets, it's usually best to try to move on
with the rest of the conversation.
RTCP is RTP's control protocol.
It's in charge of reporting on call statistics,
including packet loss and jitter,
and it will also manage the call with mechanisms like quality of service.
Of course, there's a lot more
to RTP and RTCP, but it's beyond the scope of this introductory series,
which is why we focus more on sip and SDP.
We've now reached the end of this introductory series.
I hope this has given you a solid foundation that you can build on.
You can now dig deeper into how particular vendors implement
the different features that you've seen here.
So thanks for watching, and I hope to see you again.