We're going further in this video
to see how a larger voice and network might look.
There are a few extra components we'll look at, as well
as more complicated topologies.
We still have the same basic building blocks that we would have
in a simple system.
This includes switches, hard phones and soft phones.
Of course, a large network will have a lot more of them.
The phones still register themselves to a PBX.
Maybe there's even more than one PBX for high availability.
The PBX more or less works in the same way. It routes calls
between end points, has a list of phone numbers and extensions.
And as dial plans, which define how to reach groups of phone numbers.
And of course, there'll be one or maybe more SIP trunks to a voice provider
so we can make external calls and receive them too.
But for a more
complicated deployment, we might see some more components and features.
For example, it's common to see video enabled phones or apps.
There might be a server running fax over IP.
Believe it or not, some people still use faxing.
We might have a hardware gateway on the edge of the network.
This is a device that connects our digital VoIP system
to some old fashioned PSTN or ISDN lines.
The Gateway converts between digital and analog phone calls.
And also on the edge, we would probably have
a session border controller or SBC
at a high level, it's a device that sits between different voice networks.
It applies voice policy a bit like a firewall
and manages calls between the two networks.
We'll have a detailed look at this later.
And there might
be voice capture servers that can record voice calls
if you've ever called a call center and they say
your call may be recorded for quality management.
That's a voice capture server at work.
It's also worth noting that a PBX doesn't have to be located on site.
It could be cloud hosted or if the organization is large enough,
PBXs could be spread across a few sites.
Not to mention that it's likely that the PBX will integrate
with third party applications to add more features.
These include sending voice mail in outlook call forwarding.
Click to dial, instant messaging, call-queue management
and interactive voice response.
Let's take a look at the voice gateway in a bit more detail.
VoIP is IP based and is therefore very logical.
However, you might still want to integrate physical phone lines.
This includes PSTN, ISDN and TDM links.
This is what your voice gateways for.
It's the hardware that connects your physical lines,
if you have any, to your IP-based network.
Traditionally, larger companies did this to have a back up to their SIP trunks.
However, this is becoming less common as services are becoming fully digital.
one way this is done is to put special hardware
in the session border controller on the edge of your voice network.
We'll see SBCs in just a moment.
The other way is we have provider to host all this for you,
and they just pass the phone calls to you over the SIP trunk.
When it comes to routing calls between the physical links
and the digital phone network, the PBX needs to be involved.
Remember, the primary function of the PBX is call routing.
The PBX and Voice
Gateway need to be able to communicate with each other to do this.
They use the media control Gateway Protocol or MGCP.
This uses a series of control messages similar to the SIP protocol,
which is used to set up calls and retrieve call information.
We also need to think of the actual voice portion of the phone call,
the legacy side uses electrical signals while the IP network
is entirely digital, on the legacy side,
we have DSP modules.
These are the hardware modules that the physical phone lines connect to.
These modules are in charge of the electrical signals.
They represent your voice on the phone call.
To pass this information to the IP network,
the Gateway needs to use a codec to convert it.
This is using a process called transcoding.
We'll see transcoding again soon.
But as I said, voice gateways are becoming less common
because most services being deployed now are using SIP.
The concepts, though, are still relevant.
We can deploy a session border controller on the edge of our voice network.
There is one or more sip trunk to connect the SBC to the provider.
The SBC also connects to our data network.
So an SBC usually sits on the edge of your network, and in some cases
you might have SBCs between your head office and branch offices.
There are several reasons that we might use an SBC.
These include security, policy, enforcement, codec management and others.
And we'll take a look at these soon.
first, let's take a look at how a phone call through the SBC works,
let's
imagine in a phone call comes in from the service provider.
This starts as sip traffic and comes
over the sip trunk to the SBC.
As far as the service provider is concerned,
this is where the call terminates.
The SBC looks at the call information for things like the number
that's being called, the number that's calling and things like this.
Using this information, it decides where this call should be sent.
In a simple example, like this one,
the best place to send the call would be to the PBX.
So the SBC starts an entirely new connection to the PBX using SIP.
As far as the PBX is concerned, the SBC is the source of the phone call.
We can see here that the SBC is acting as a proxy for SIP traffic.
This means that the service provider will never communicate directly
with anything in our network beyond the SBC.
The PBX just does what it normally does,
it finds a destination phone and tells it to ring. Once again,
It uses SIP.
When someone picks up
the phone, the voice call can begin.
Remember that this uses RTP traffic and not sip.
As I mentioned in the last video,
the PBX will not usually be involved in this part.
It just sets up the phone calls
while the RTP traffic flows directly between the phones.
The SBC, on the other hand, proxies RTP traffic on behalf of the client,
which means that all voice traffic must flow through the SBC.
This makes the SBC a B2BUA server
that is a back to back user agent server.
This is the official term for a device that has all the media flowing through it.
Please understand, though,
that the SBC is not needed for internal calls.
They continue working as they always have.
We looked at the process for an incoming call,
and the good news is that the same principle is used for an outgoing call.
The phone signals the PBX, which in turn signals the SBC.
The SBC signals the provider, which ultimately signals the remote phone.
Of course, there might be a lot going on in the provider's area that we don't see.
The remote phone is picked up and the voice media starts,
this flows from the phone to the SBC.
SBC to the provider where they will likely have their own SBCs
and eventually to the remote phone.
Even in this very simple topology,
you can see some benefits to using SBCs.
We've already seen that we have call admission control.
This is setting up the phone calls and getting them to the right place.
And this also involves security, which will soon see.
We have a
clearly defined border at the edge of the network.
We can easily see the line where our network meets the provider's network.
This also helps to troubleshoot where faults are.
For example, if calls are not showing up on the SBC logs,
then the problem will be with the provider.
But if the call is reaching the SBC and it's still not working,
then the problem is within our network.
And, of course, we hide aspects of our topology
from our provider, such as IP addressing and PBX details.
They see the calls as terminating on the SBC
and see very little, if anything, of our internal network.
Some SBCs are actually
physically routers with call features added.
I've previously used Cisco's ISR routers with CUBE licensing,
which are just normal
routers with voice features added in.
This means we can have all the traditional network
technologies on the SBC, so that's things like quality of service.
ACLs firewall rules.
NetFlow, sFlow, and direct connections to the WAN.
As we just mentioned, security is a major
part of the SBCs job is like a firewall in some ways.
But rather than dealing with ports, protocols and applications,
it applies policies.
For example, we might use the SBC to encrypt some traffic
or to authenticate endpoints before allowing a call.
Of course, we can also use it for toll fraud prevention,
toll fraud is where someone gains access to your phone system
and uses it to make their own calls.
And that can become rather expensive.
The SBC can be configured with the IP addresses
that are allowed to make phone calls and will reject all others.
For that matter, we can also white list PBXs by their IP addresses
or direct certain calls to one PBX or another, depending on our needs.
This is called call routing.
We might even have more than one sip trunk to more than one provider.
We might use the SBC to send long distance calls over one sip trunk,
but use the other for local calls.
The final major feature of the SBC is inter-working.
This is where the SBC translates between different call types.
For example, you may primarily be using SIP in your voice network,
however, you may have some old equipment that uses the H323 protocol.
This protocol was a competitor to sip at one time,
however, a sip has become the more common choice.
The SIP and H323 protocols are incompatible,
so these normally don't work together.
However, if you put an SBC between them, it could
translate between the two which allows communication,
or we could completely filter out
one protocol or another if that's what we want to do.
Or perhaps you have a branch site with a slow WAN link for better phone
calls, you might decide to use a codec at this site that uses less bandwidth.
We might pick up an external call at the main office,
and it might be using a high quality codec like G 711.
When it's forwarded to the branch site, it needs to be renegotiated
to a bandwidth saving codec like G729.
The SBC can handle this renegotiation,
as well as the transcoding between the different codecs.
You can also handle escalation, which is where more data is added to the call.
Perhaps a voice call escalated to include video.
And the last example of Inter working is SIP normalization.
SIP is like HTTP in some ways.
For one, it uses headers.
These include information such as where the call came from
and where it's going to, you know, that sort of thing.
There are some headers that all devices understand and some that are optional,
we can use the SBC to strip out, add in or modify
any of these headers.
This is particularly useful for hiding private information
from within our network.
Now that we've seen the components that go into a more complicated voice network,
we can take a look at the protocols that make it work.
Join me in the next video and we will see SIP, SDP and RTP.