SCCP Call Flow with DNS
The first thing that happens is I pick up the phone handset and I want to dial a number. The first thing that happens is I pick up the handset and now I have to query a DNS server and say, "Hey I'm looking for Communications Manager 1." The DNS server then responds back to me, "Oh here is where it's located with the IP address." Now I send the signalling information over to the Communications Manager and the process continues on. Maybe I'm dialing digits so the digits are sent to the Communications Manager it says "oh okay, you know, you're looking for this particular phone" and now that phone rings and if that handset gets picked up and we are communicating we now stream via RTP. But you can see how if I add that DNS server to the mix, it's an extra step.
If I remove that DNS server it happens much quicker and more efficiently behind the scenes. Now to the end user may not be noticeable, unless that DNS server is down. If for some reason the DNS server is down or unavailable, now I can't do my name resolution, I can't find my Communications Manager server. So, I should be okay statically configuring my Communications Manager's IP addresses so that I can locate them without using DNS.
SCCP Call Flow without DNS
A Skinny Client Control Protocol phone communicating without using DNS – there's no extra look up. Like you can see on the next image I am able to from the IP phones perspective look up by the IP address where that communications server lives. So, I don't have to go through the extra step.
In the Communications Manager I can go to system server and that's where I can statically configure the IP address of the server. Right now by default if you just install the system there's a name there, so if I remove the name, put in the IP address, I have now removed the DNS reliance and what'll happen too is the TFTP files that my phone downloads will also contain the IP addresses so there really will be no DNS reliance whatsoever, once I've made these changes.
Centralized Remote Branch Call Flow
Let's start to look at the call flows. Within my own environment if I have a centralized and a remote branch location what will happen is my signalling will take place. I pick up the phone, I am using Skinny and I am dialing digits. The centralized environment says the Communications Manager is going to know where that remote phone is. So if I dial extension 4004 for example, I now do the look up via the Communications Manager and the Communications Manger says "Oh you're looking for a phone over in this branch location". So now the branch location is signalled ringing, hopefully they pick up the handset and answer the call and once that takes place the Communications Manager kind of steps out of the loop. And now I'm streaming my voice directly between my IP phone A and my IP Phone B in this example.
Now, it could be going through various routers and WAN-links to reach that destination, but the Communications Manager, steps out of the link and the media is going to flow through that path between your phones.
Centralized Architecture PSTN Backup Call Flow
If we have a centralized deployment, and I have an IP WAN Link maybe reaching out to my branch locations and for some reason it goes down – what are my options? Well, you might not have a backup link and then we wouldn't be able to communicate with our branch locations, but my guess is most environments you have a connection out to the PSTN and you would rather the call be placed even if you have a little bit of long-distance charge incurred through the public switch telephone network. So what'll happen is if I pick up my handset, I dial my digits and the Communications Manager attempts to send the call down the IP WAN path and finds that "Oh wait a minute it's down, we could re-route the call through the public switch telephone network to that branch location". Now, with the branch location I just want to explain a few things that you're seeing on the image below.
There is a Survivable Remote Site Telephony solution (SRST). What that means is that branch router has special software running on it so that it could take over as the phone system. So it's going to manage all of those phones in that branch location because remember we lost the WAN connection and if this is a centralized deployment I've now lost access to the Communications Manager which was managing those phones. Those phones were registering across the IP WAN, they were also sending signalling information across the IP WAN and now that's gone. So first off, SRST needs to be running on that branch router. I also, as a side note, have to make sure that I have a gateway call control protocol that can be running. If I used something like MGCP, MGCP is a client server based protocol for managing that gateway and if I lose communication with the Communications Manager, MGCP will no longer operate. So I have to have a fall back and that fall back could be H.323 or it could be SIP running as the call control protocol on that gateway. The call control protocol is responsible for routing the call.
So while SRST can handle your phones and the features on the phones we have to have that call control protocol running on that gateway in order for calls to take place. Another thing, if I was registered with the centralized Communications Manager from the branch location's perspective and the WAN went down I no longer appear as an IP phone registered at the central site. So now if someone attempts to dial me, it acts like I'm not registered, I'm not available. There is an option called call forward unregistered. We can set up a parameter in there that says "oh in the event that you find this phone unregistered dial this number". Now this number could be the PSTN number to that phone or it could be any number like a cell phone for example as a backup number so call forward unregistered would help us in rerouting calls through the public switch telephone network from anybody at the central sites perspective because the phone appeared as being unregistered.
Still focusing on the fact that we might have a centralized Communications Manager cluster and branch locations that are dependant upon that Communications Manager cluster. We also need to look at PSTN backup considerations. So from the Communications Manager's perspective if I dial a four digit extension – that's not going to be enough for a fully qualified PSTN number. So, behind the scenes I'm going to have to make sure that I tack on the appropriate digits depending upon the gateway's path that I've chosen to get out to the PSTN. So in other words if I dial 4004 that's not enough. If I went across the WAN I'm good to go, if I have to go across the PSTN behind the scenes we as administrators can say "oh if you take this path through the PSTN add on 5554004". Now that's a fully qualified PSTN number.
Distributed Architecture Call Flow
Let's now look at a distributed environment. What this means is maybe I have different locations that are rather large in size. I could have a Communications Manager cluster at each location. Now the benefits here are that they're independent. I don't have to have SRST running at the branch locations and my signalling doesn't necessarily have to go across the IP WAN all the time. So in other words, my IP phone when I pick up the handset and the Skinny Client Control Protocol is running and says "okay play dial tone, okay here's the digits you've dialed" that information doesn't necessarily have to go across the WAN link now. It can stay local until I need to tie into maybe remote location. If I'm dialing somebody at one of the other locations that has a Communications Manager cluster some signalling obviously has to go across to signal I want to call you and I want you to make this particular phone ring. Again, we do benefit because the RTP media path will then run across the IP WAN so we get some toll savings there. Now to set this up and to make these two clusters communicate with each other we set up an intercluster trunk. Now of course if we're going through routers and across the IP WAN it's also traversing through that path but again the Communications Managers have stepped out of the solution at this point until somebody does something like press hold or park the call or hang up the call. Now of course the signalling will take place to the Communications Managers to tell it what has happened.
With a distributed environment it's pretty close to the centralized architecture, but the big benefit here is that we have Communications Manager clusters in each location. So we get two things. We can eliminate the need for SRST and we can limit some of the signalling traffic now, because now if I'm in a branch location with my own cluster and I want to call somebody within my branch I'm not sending that signalling traffic across any kind of intercluster trunk, it stays local. The only time I send signalling traffic across that intercluster trunk is if I need to reach somebody for example at that branch location. We have all the signalling protocols for intercluster trunks - SIP and H.323. What we don't have is MGCP because again we don't have a centralized deployment with all of these different gateways we're managing with MGCP now, we have independent routing protocol such as H.323, SIP, and then the intercluster trunk to actually tie these Communications Managers together. Also, we still have back-up through the PSTN. So just like a centralized deployment if the WAN was down and we couldn't send our stream across the WAN we could fail over as a backup to the PSTN but again, going to have to tack on some digits to make it that fully qualified E.164 address through the PSTN.
Here's an example of what that PSTN backup call flow would look like - let's pretend the WAN has gone down. Well, if I'm in the main location dialing to the remote location through the Communications Manager cluster first I try the WAN, it's down, then I try my PSTN gateway if I have that set up. And through that path again I have to tack on some digits and now the call will go across the PSTN, come into the remote branch location, and of course ring the appropriate telephone device.