|
0:00:14
|
Ok, so let's get started.
|
|
0:00:19
|
If there were any other questions, go ahead and feel free to ask them at anytime,
|
|
0:00:23
|
as I'll be able to see those in my left window while we're doing
|
|
0:00:28
|
the demonstration in my right.
|
|
0:00:32
|
So let's log into our CUCM server,
|
|
0:00:34
|
and the first thing we're going to do,
|
|
0:00:37
|
we had already looked at our services and made sure they're started.
|
|
0:00:41
|
Let's just go back and verify those briefly for both servers.
|
|
0:00:45
|
By the way, if you did need to change your host names,
|
|
0:00:49
|
we mentioned those are already done for us on these particular servers.
|
|
0:00:52
|
But if you did need to change your host names to IP addresses,
|
|
0:00:54
|
it's a good idea to do that before
|
|
0:00:57
|
activating your CUCM servers --services on either server.
|
|
0:01:03
|
Let's just go to Control Center-Features,
|
|
0:01:06
|
and take a look at both servers
|
|
0:01:09
|
and make sure all services are properly started.
|
|
0:01:11
|
And it looks like other than the messaging interface,
|
|
0:01:14
|
we do have everything properly started including Directory Sync
|
|
0:01:19
|
for the Publisher .10,
|
|
0:01:22
|
and let's bring up the Subscriber here,
|
|
0:01:24
|
and other than messaging interface, we have everything running
|
|
0:01:28
|
for the Subscriber as well.
|
|
0:01:30
|
Ok, great.
|
|
0:01:33
|
We configured NTP the other day,
|
|
0:01:35
|
that's actually in the CUOS, let's just make sure that
|
|
0:01:38
|
still says "accessible".
|
|
0:01:50
|
And it says, "The service is accessible".
|
|
0:01:53
|
Great, so let's go to the CUCMA,
|
|
0:01:55
|
or Administration Interface,
|
|
0:01:58
|
log back in,
|
|
0:02:00
|
and let's begin setting up our server.
|
|
0:02:03
|
So, system server,
|
|
0:02:06
|
we should find both servers, they're already in IP address format,
|
|
0:02:11
|
go to Cisco Unified CM,
|
|
0:02:15
|
and we find the Pub and the Sub,
|
|
0:02:20
|
and they are currently not set for auto registration,
|
|
0:02:25
|
now before we set one to "auto registration on",
|
|
0:02:29
|
we need to take a look at the Unified CM group,
|
|
0:02:32
|
and see what it's set to in terms of who is the primary server
|
|
0:02:37
|
So I personally like to set up two groups
|
|
0:02:41
|
at least for an exam where I have...
|
|
0:02:44
|
I know that I'm going to have a Publisher and a Subscriber
|
|
0:02:46
|
I'd like to have one called Pub-Sub,
|
|
0:02:52
|
and of course I should have actually put that Subscriber
|
|
0:02:54
|
down below the Publisher before I hit save.
|
|
0:02:59
|
And then I'd like to copy this,
|
|
0:03:01
|
and have Sub-Pub,
|
|
0:03:05
|
it doesn't take very long to do
|
|
0:03:06
|
and just rearrange the order down here to where the Subscriber is
|
|
0:03:12
|
above, and I'm going to change this to be in auto registration,
|
|
0:03:15
|
CUCM group, and the reason is, is that if there's any task that calls for me to use
|
|
0:03:20
|
the Sub first as a Call Processing Unit or CPE,
|
|
0:03:25
|
then I have a group that's ready to do so,
|
|
0:03:27
|
and if I have anything that asks me to use the
|
|
0:03:30
|
Publisher first, I have something that's ready to go for that as well.
|
|
0:03:36
|
The Sub-Pub is true for our registration,
|
|
0:03:39
|
so I'm going to enable auto registration
|
|
0:03:43
|
only on the Subscriber.
|
|
0:03:45
|
And to do that, I'll simply say...
|
|
0:03:47
|
Let's make this 5000 and 5010,
|
|
0:03:54
|
it might not be a bad idea if I don't want to have to change too much
|
|
0:03:58
|
to go ahead and create a class of control partition,
|
|
0:04:04
|
and create a partition called let's say
|
|
0:04:09
|
PT_internal or phones or whatever you want to call it
|
|
0:04:16
|
maybe PT_internal-DNs is what I sometimes call it.
|
|
0:04:21
|
We're not going to go through and set up all our partitions
|
|
0:04:23
|
and calling search spaces just yet,
|
|
0:04:26
|
but we're just going to get one basic one
|
|
0:04:29
|
for each, out of the way.
|
|
0:04:31
|
We'll call this CSS_ , for now let's just call it phones.
|
|
0:04:37
|
Ok, we might rename it later.
|
|
0:04:41
|
But for right now we'll call it that.
|
|
0:04:45
|
And the reason is, is that when we go to our Unified CM,
|
|
0:04:53
|
sorry let's go to our device pool
|
|
0:04:57
|
and we're going to have a default device pool here.
|
|
0:05:06
|
We're going to have a calling search space for auto registration.
|
|
0:05:10
|
And let's have the Sub, Pub CUCM group,
|
|
0:05:13
|
calling search space for auto registration is CSS_phones.
|
|
0:05:18
|
And that's probably enough for right now.
|
|
0:05:21
|
Ok, we can go back and change things later from here.
|
|
0:05:27
|
And then we'll also go back to our CUCM,
|
|
0:05:29
|
to our Subscriber, choose a partition
|
|
0:05:33
|
for the internal DNs,
|
|
0:05:35
|
it's telling us I have to change the DN range first.
|
|
0:05:39
|
No problem.
|
|
0:05:41
|
5010, notice it automatically unchecked my "auto registration disabled" on the CUCM.
|
|
0:05:48
|
Add my partition, maybe I can go ahead and add if I want
|
|
0:05:51
|
an external phone number mask.
|
|
0:05:54
|
It's up to me if I want to let's say 206,
|
|
0:05:56
|
501XXXX,
|
|
0:06:02
|
and of course that won't work for all phones, but it will work for two of them.
|
|
0:06:08
|
And I don't want to change any ports.
|
|
0:06:10
|
And I'll go ahead and say save.
|
|
0:06:13
|
And I'll also do a reset.
|
|
0:06:19
|
So now I've got our registration enabled,
|
|
0:06:21
|
and I should begin to see phones
|
|
0:06:23
|
begin appearing in my database.
|
|
0:06:28
|
I don't see any yet.
|
|
0:06:30
|
Let's just go ahead and take a look at perfmon statistics.
|
|
0:06:37
|
So I'll go ahead and SSH over to the UCM Sub,
|
|
0:06:47
|
Ok, great, and let's say file, I'm sorry,
|
|
0:06:52
|
Yeah file, I'm going to do file list,
|
|
0:06:57
|
I want to do active log,
|
|
0:07:00
|
and I'm going to look in the base directory,
|
|
0:07:03
|
I see forward slash cm,
|
|
0:07:05
|
so I'm going to go back up and --
|
|
0:07:07
|
now this is not going to be tab completion able
|
|
0:07:10
|
I actually have to type it in, but I can drill down for each level.
|
|
0:07:13
|
So then I'm going to go to trace,
|
|
0:07:15
|
so I'm going to go up and add trace,
|
|
0:07:19
|
and from trace I'm going to add the trace for ccm,
|
|
0:07:27
|
whoops
|
|
0:07:28
|
trace/ccm,
|
|
0:07:29
|
and I've got my sdi and sdl
|
|
0:07:33
|
I always look in sdi if it doesn't contain enough information
|
|
0:07:37
|
sdl is more the programmatic C level information, so then I drill
|
|
0:07:43
|
into sdl if it doesn't have enough information in it.
|
|
0:07:46
|
And I'm going to go with the highest file,
|
|
0:07:50
|
and this is just listing it, it's there,
|
|
0:07:52
|
now I want to go back and change file list
|
|
0:07:55
|
to either file view or file tail
|
|
0:08:02
|
and...
|
|
0:08:06
|
Actually let's go ahead and just tail that file
|
|
0:08:14
|
and we'll watch what happens.
|
|
0:08:16
|
Now we don't see anything
|
|
0:08:21
|
in here yet. Let's see...
|
|
0:08:33
|
It looks like we've got some station initialization socket broken,
|
|
0:08:39
|
but this IP address is the Publisher,
|
|
0:08:45
|
hmmm,
|
|
0:08:46
|
this doesn't look exactly right, nor am I seeing any additional information
|
|
0:08:50
|
coming through, nor am I seeing phones coming up.
|
|
0:08:56
|
So,
|
|
0:08:58
|
let's exit out of this,
|
|
0:09:02
|
and take a look back,
|
|
0:09:06
|
actually what I'm going to do is, I'm going to
|
|
0:09:09
|
do utils system restart on this Subscriber.
|
|
0:09:14
|
Actually before I do that, let's just go ahead and do a
|
|
0:09:17
|
utils db replication status,
|
|
0:09:22
|
and this is going read and write information from
|
|
0:09:25
|
all the machines' databases so,
|
|
0:09:27
|
it won't really take that long, we'll see what the replication status is
|
|
0:09:33
|
just a few more moments,
|
|
0:09:38
|
and it tells us... Gives us something we can literally just
|
|
0:09:40
|
copy and paste right in to see the output.
|
|
0:09:46
|
And it does say "no errors or mismatches found"
|
|
0:09:49
|
replication status is good on all servers,
|
|
0:09:54
|
and then determine if a replication is suspect look for the following:
|
|
0:09:57
|
either number of rows do not match on all table nodes or
|
|
0:10:00
|
non zero values can occur in any of the other output columns.
|
|
0:10:06
|
So we can go down.
|
|
0:10:08
|
And it looks like for the rows
|
|
0:10:13
|
which is actually showing up here
|
|
0:10:17
|
those are the same on Pub and Sub
|
|
0:10:21
|
and extra missing mismatch or process,
|
|
0:10:24
|
these should all be zero for each Pub and Sub,
|
|
0:10:28
|
and we can just quickly keep pressing end to go down
|
|
0:10:33
|
and it certainly looks like everything, without going through every single one
|
|
0:10:39
|
it certainly looks like everything including some of the larger tables
|
|
0:10:41
|
have all of the rows the same.
|
|
0:10:47
|
Ok, so just to be sure that all communication
|
|
0:10:51
|
is working properly, let's just do a utils system restart
|
|
0:10:58
|
on the Subscriber,
|
|
0:11:04
|
and because we actually had our....
|
|
0:11:08
|
Well we -- I think we did have...
|
|
0:11:12
|
I think we did have our Publisher and our Subscriber
|
|
0:11:16
|
set to TFTP
|
|
0:11:19
|
on the...
|
|
0:11:24
|
on the DHCP parameters.
|
|
0:11:38
|
Let's bounce our TFTP service here on the CUCM Publisher.
|
|
0:11:45
|
And then once we've done that I'm actually going to change
|
|
0:11:53
|
the auto registration,
|
|
0:11:56
|
over to the Publisher just while the Subscriber stops.
|
|
0:12:51
|
and I'm going to change the group,
|
|
0:12:56
|
whoops,
|
|
0:12:57
|
I need to do this from the Pub group,
|
|
0:13:01
|
it will automatically deselect the other.
|
|
0:13:05
|
And I'm going to change the default device pool
|
|
0:13:10
|
to Pub, Sub
|
|
0:13:14
|
we can change it later.
|
|
0:13:23
|
And we've reset everything and now
|
|
0:13:26
|
I don't even know if I can get there in time,
|
|
0:13:28
|
I don't think I can, phones are already registering.
|
|
0:13:32
|
But,
|
|
0:13:34
|
I'll certainly try.
|
|
0:13:35
|
file list activelog/cm/trace
|
|
0:13:41
|
Whoops..
|
|
0:13:45
|
/cmm/sti and I'll try to grab this file in time,
|
|
0:13:53
|
before all the phones have registered.
|
|
0:14:03
|
And,
|
|
0:14:10
|
we actually see that we've got a Unity Connection trying to register
|
|
0:14:15
|
the device Cisco UM1-VI1,
|
|
0:14:20
|
there is no record for this device and
|
|
0:14:21
|
auto registration is not enabled for this device type.
|
|
0:14:24
|
Ok, so we see something else trying to register
|
|
0:14:28
|
there is already three phones that are registered.
|
|
0:14:35
|
Ok, and these are at my 177.1.11 and 1.11
|
|
0:14:39
|
so that's my CorpHQ Site,
|
|
0:14:40
|
.2.11, that's my Branch 1 Site
|
|
0:14:44
|
We do need to take a look at our Branch2 phones
|
|
0:14:47
|
and see if they're getting proper IP addresses and TFTP information.
|
|
0:14:54
|
Let's go back and take a look at our DHCP subnet
|
|
0:15:00
|
for Branch 2.
|
|
0:15:03
|
177.3, we don't have a TFTP server in here.
|
|
0:15:10
|
But we do have one I believe still
|
|
0:15:18
|
under the server configuration portion
|
|
0:15:23
|
Yep, 177.1.10.10,
|
|
0:15:28
|
so assuming that our Router3...
|
|
0:15:34
|
sh run int ser0/0/1:0.1 is still set up.
|
|
0:15:43
|
Ah, it's set up with the wrong IP helper address,
|
|
0:15:46
|
it's pointing to Router1.
|
|
0:15:49
|
Ok,
|
|
0:15:54
|
so let's change that.
|
|
0:16:07
|
Actually I want to say no IP helper address
|
|
0:16:09
|
before I add in IP helper address 177.1.10.10,
|
|
0:16:17
|
now it's setup properly.
|
|
0:16:20
|
Now they should be getting IP addresses properly
|
|
0:16:23
|
from the Publisher.
|
|
0:16:27
|
And they should be getting TFTP information,
|
|
0:16:31
|
and when they do,
|
|
0:16:37
|
hopefully we'll see them come up and register here.
|
|
0:16:40
|
The Subscriber restarted.
|
|
0:16:50
|
Let's go ahead and disconnect that dead TCP session and
|
|
0:16:53
|
bring it back up.
|
|
0:17:21
|
Ok, this is still the...
|
|
0:17:27
|
the voice mail trying to register.
|
|
0:17:38
|
We should see these phones come up fairly soon.
|
|
0:17:43
|
Let's just check the... Although you won't be able to see
|
|
0:17:45
|
this particular bit if you were in a real lab with real phones in front of you
|
|
0:17:49
|
you obviously could have access to the phones
|
|
0:17:52
|
and go in and check not just the
|
|
0:17:56
|
IP address, but also what TFTP server, what DNS server had been handed out
|
|
0:18:05
|
also what, under device configuration, so settings
|
|
0:18:11
|
and then three for device configuration
|
|
0:18:13
|
one for Unified CM configuration
|
|
0:18:17
|
what Unified CM one and two were setup.
|
|
0:18:23
|
And Unified CM 1 does point to 177.1.10.10,
|
|
0:18:36
|
for both of these,
|
|
0:19:16
|
Ok, let's from the Publisher
|
|
0:19:19
|
or Subscriber actually, they're both on the same subnet.
|
|
0:19:24
|
From the Subscriber, let's do a utils network ping
|
|
0:19:30
|
and let's ping 177.3.11.18
|
|
0:19:42
|
Ok, let's try to ping .1,
|
|
0:19:44
|
there we go,
|
|
0:19:46
|
we're getting a response from that,
|
|
0:19:48
|
.20 which is the switch
|
|
0:19:53
|
Switch2,
|
|
0:19:57
|
that's one of the reasons .20 was never handed out.
|
|
0:20:01
|
It is the switch.
|
|
0:20:03
|
We were talking about that the other day on Monday in Network Infrastructure
|
|
0:20:07
|
it was the switch.
|
|
0:20:11
|
So even though I put... If I do sh ip int br | ex unass
|
|
0:20:20
|
177.3.11.20 is the switch,
|
|
0:20:23
|
so it was effectively avoiding a contention there.
|
|
0:20:30
|
Ok, so I just reset those phones to see if they'll come up.
|
|
0:20:35
|
We're going to go ahead and look at the phones that we have for right now
|
|
0:20:38
|
while these other phones... I'm not really sure one of them might be
|
|
0:20:42
|
in sit mode, I guess I can check that as soon as they reset -- check their current...
|
|
0:20:47
|
Well actually I could check that from Switch2
|
|
0:20:50
|
sh cdp ne and f0/0.10 details,
|
|
0:20:57
|
nope that's Skinny, looks like it's the proper...
|
|
0:21:02
|
proper ref, proper firmware,
|
|
0:21:05
|
and .11,
|
|
0:21:07
|
Yep, they're both Skinny and they're both the proper firmware.
|
|
0:21:11
|
Ok, .19 and 18 respectively.
|
|
0:21:23
|
sh rn | inc ip routing,
|
|
0:21:34
|
and | inc ip route,
|
|
0:21:38
|
all right
|
|
0:21:39
|
that's pointing everything to, yep, 177...
|
|
0:21:56
|
Ok, everything looks good there.
|
|
0:21:59
|
We'll wait until these phones come up.
|
|
0:22:07
|
Oh, I have this helper address in the wrong place, I've got it under the serial interface
|
|
0:22:12
|
and that is a big issue
|
|
0:22:15
|
because that's not on the same broadcast domain.
|
|
0:22:18
|
All right, I might not have had enough coffee this morning.
|
|
0:22:25
|
I'm going to want to go under the interface for Fas0/0.11,
|
|
0:22:29
|
do sh run int Fa0/0.11, let's see what's there first.
|
|
0:22:34
|
And I did already have the proper IP helper address there.
|
|
0:22:40
|
Not sure why there even was a helper address in the other location.
|
|
0:22:53
|
And I can tell that by the fact that they had actually already got IP addresses
|
|
0:22:57
|
they saw the proper CUCM server.
|
|
0:23:02
|
Let's make sure that for some reason, maybe in previous attempts
|
|
0:23:05
|
we haven't run out of that 5000 range of IP addresses.
|
|
0:23:10
|
We'll check for unassigned DNs under route plane report,
|
|
0:23:13
|
there's currently none.
|
|
0:23:14
|
So that looks good.
|
|
0:23:48
|
Ok, we're able ping .19,
|
|
0:23:54
|
and .18 from the Branch2 Switch,
|
|
0:24:07
|
we're able to ping it from the router.
|
|
0:24:20
|
We're still not seeing a ping return from the Subscriber
|
|
0:24:24
|
for some reason.
|
|
0:24:29
|
Let's pull up Router1.
|
|
0:24:41
|
Ok, so something's blocking
|
|
0:24:45
|
my communications.
|
|
0:24:49
|
Whoops,
|
|
0:25:17
|
I certainly see that from there.
|
|
0:25:44
|
But for some reason I can't ping the phones from my corporate headquarter router.
|
|
0:25:51
|
Quite interesting. I see the routing entry.
|
|
0:26:04
|
I can certainly get across
|
|
0:26:10
|
to .1 and .20
|
|
0:26:14
|
Oh they both say they're updating their ctl now,
|
|
0:26:16
|
it could be that they were busy updating their security trust list
|
|
0:26:20
|
or certificate trust list and
|
|
0:26:23
|
they weren't responding to a ping.
|
|
0:26:27
|
Sometimes the phones do take a little bit of time to
|
|
0:26:31
|
get registered.
|
|
0:26:53
|
Oops.
|
|
0:27:06
|
Ok, well we will let those continue to
|
|
0:27:12
|
take their time and come up and
|
|
0:27:14
|
we'll just go on with the devices that we have registered already.
|
|
0:27:19
|
So we've got two CorpHQ and one Branch1 phone registered.
|
|
0:27:23
|
Let's go ahead and take a look-- let's add our phone NTP reference,
|
|
0:27:31
|
so we're going to say 177.1.10.10, the Publisher,
|
|
0:27:37
|
and we want phones to unicast
|
|
0:27:39
|
that, these are for SIP phones that need an NTP reference,
|
|
0:27:42
|
we're pointing them to the Publisher.
|
|
0:27:46
|
We're going to create our date/time groups.
|
|
0:27:50
|
We've of course got one already, CM local.
|
|
0:27:53
|
We'll just change that to Pacific..
|
|
0:27:58
|
Pacific Time,
|
|
0:27:59
|
or Pacific Standard Time.
|
|
0:28:03
|
And we'll make this
|
|
0:28:15
|
GMT - 8,
|
|
0:28:17
|
we'll leave the rest the same, unless of course we were told to change it.
|
|
0:28:21
|
24 hour to 12 hour date format, time format separator however we want.
|
|
0:28:26
|
We'll add the NTP phone reference
|
|
0:28:31
|
that we just created and save it.
|
|
0:28:36
|
And we will copy this.
|
|
0:28:37
|
And call it CST which is where our other Site is, we're just going to assume that it is.
|
|
0:28:43
|
Of course in the real lab you would be told
|
|
0:28:47
|
specifically where your Sites are and what date/time.
|
|
0:28:53
|
And we'll create one CEST
|
|
0:29:04
|
for Central European standard and daylight time.
|
|
0:29:10
|
Ok, then we'll go up and...
|
|
0:29:13
|
up to system, come back down, we'll deal with presence later
|
|
0:29:16
|
and we'll come to our regions.
|
|
0:29:20
|
We'll grab our default region,
|
|
0:29:24
|
and rename it as CorpHQ.
|
|
0:29:33
|
And we'll say save.
|
|
0:29:38
|
We're going to add a new
|
|
0:29:42
|
region and call it Branch1.
|
|
0:29:44
|
Could do R underscore, that's what I typically like to do.
|
|
0:29:49
|
So we'll rename this other one in just a moment.
|
|
0:29:51
|
And from R_1, region's not displayed use the default audio codec.
|
|
0:29:56
|
And the default video codec and loss type.
|
|
0:30:01
|
The default audio codec is G.729
|
|
0:30:05
|
The default video bandwidth is 384,
|
|
0:30:08
|
and the default loss type is low loss.
|
|
0:30:13
|
Lossy as opposed to low loss
|
|
0:30:15
|
means that if you were using the G.728/ILBC,
|
|
0:30:20
|
we will default to the ILBC
|
|
0:30:22
|
or Internet Low Bitrate Codec,
|
|
0:30:25
|
because that will be used instead of...
|
|
0:30:34
|
That will be used instead of G.728
|
|
0:30:36
|
because it has a much better
|
|
0:30:39
|
digiter buffer and algorithm for taking into account lossy links for the internet.
|
|
0:30:48
|
Ok, because we will very likely with gatekeepers be changing our
|
|
0:30:54
|
default inter-region or intra-region codecs due to bugs that may exist
|
|
0:31:04
|
in 7.0.1, we will go ahead and explicitly define everything,
|
|
0:31:09
|
so from Branch1 to Branch1
|
|
0:31:16
|
we'll use G.711.
|
|
0:31:20
|
And from Branch1 to CorpHQ
|
|
0:31:22
|
we'll use G.729
|
|
0:31:26
|
Ok, so the matrix Branch1..
|
|
0:31:29
|
whoops,
|
|
0:31:31
|
Branch1 to CorpHQ use a 729,
|
|
0:31:35
|
Branch1 to Branch1 use a 711.
|
|
0:31:41
|
And we'll rename CorpHQ to
|
|
0:31:47
|
R_CorpHQ.
|
|
0:31:52
|
So then we'll also add region Branch2
|
|
0:32:04
|
and we do of course want Branch2 to Branch2 to be 711
|
|
0:32:08
|
Branch2 to all others to be 729.
|
|
0:32:13
|
Ok, and if we need to change this later for anything like
|
|
0:32:18
|
music on hold which we will, then we'll do that then.
|
|
0:32:22
|
Ok, we'll look at LDAP in a moment.
|
|
0:32:26
|
Let's setup locations, but we're going to setup RSVP base locations.
|
|
0:32:33
|
So, let's do that in...
|
|
0:32:36
|
Yeah let's do that in just a moment.
|
|
0:32:41
|
SRST, we'll go ahead and setup our SRST references now.
|
|
0:32:51
|
For Branch1 it will be 177.1.254.2
|
|
0:32:55
|
which is the loopback.
|
|
0:33:03
|
And for Branch2, it will be .3 as the loopback,
|
|
0:33:11
|
and the reason we'll do that is that we'll go ahead and setup the device pools now
|
|
0:33:13
|
and the device pools will populate the SRST
|
|
0:33:17
|
reference in the phones so that when we're ready to fill back
|
|
0:33:20
|
we don't need to do an extra step,
|
|
0:33:23
|
reset the phones and spend additional time there.
|
|
0:33:27
|
So we'll call this Device Pool CorpHQ.
|
|
0:33:33
|
We will eventually do Sub, Pub.
|
|
0:33:42
|
We'll deal with some of this stuff certainly later,
|
|
0:33:47
|
as we come back to it when we come to routing we'll do local route group
|
|
0:33:51
|
when we come to media resources we'll do MRGL etc.
|
|
0:33:55
|
Now location hub none, this is one of those things
|
|
0:33:59
|
where when we set a location at a device, such as a phone.
|
|
0:34:06
|
If we leave it to the default, which is hub none
|
|
0:34:10
|
then what this means is that
|
|
0:34:12
|
it is hub...
|
|
0:34:15
|
well if it's on a... sorry if a location is set on a device to hub none
|
|
0:34:22
|
It's basically taking the none characteristic
|
|
0:34:26
|
which goes back to the lesser choice of device pool
|
|
0:34:30
|
and chooses whatever is there.
|
|
0:34:32
|
Now it's more specific if you set the location on a phone
|
|
0:34:38
|
or on any device to anything except for hub none,
|
|
0:34:42
|
so if I have location Branch1
|
|
0:34:46
|
and I've got location Branch2
|
|
0:34:49
|
and I've got location hub none defined.
|
|
0:34:51
|
And on a phone, I set the location to Branch1,
|
|
0:34:56
|
then that takes priority over whatever is configured at the device pool level.
|
|
0:35:02
|
However, if at the device pool level
|
|
0:35:07
|
I have something configured... I'm sorry
|
|
0:35:10
|
however if at the phone if I have hub none chosen,
|
|
0:35:15
|
then it chooses the none characteristic
|
|
0:35:19
|
which in everything else reverts back to the lower priority
|
|
0:35:24
|
to see what's configured there, so if I configure or just leave
|
|
0:35:27
|
hub none at the phone, it will go back to the device pool
|
|
0:35:32
|
and if I have something else configured here at the device pool,
|
|
0:35:35
|
that is what will take effect. If I have hub none configured
|
|
0:35:38
|
then it takes the characteristic of hub
|
|
0:35:41
|
if I have something else like Branch1 configured,
|
|
0:35:43
|
it will take the characteristic of Branch1.
|
|
0:35:47
|
Ok, so location is one of those things...
|
|
0:35:50
|
Or actually hub none specifically
|
|
0:35:54
|
with location -- not just location in general where hub none
|
|
0:35:57
|
is this unusual, this kind of phenomenon
|
|
0:36:01
|
entity that goes back to the device pool.
|
|
0:36:05
|
But anything else set in location at a device will take precedence
|
|
0:36:09
|
other than hub none. That goes back to the device pool.
|
|
0:36:11
|
Ok, so SRST, this is for the CorpHQ Site, we don't have any
|
|
0:36:17
|
everything else is fine,
|
|
0:36:20
|
we'll go ahead and copy this,
|
|
0:36:22
|
and copy it out to Branch1,
|
|
0:36:26
|
where we'll have Sub, Pub
|
|
0:36:27
|
we're going to change that for the CorpHQ as well in a bit.
|
|
0:36:32
|
Change it to CST Time, Region Branch1,
|
|
0:36:37
|
and I should have already gone ahead and configured locations. Let me just
|
|
0:36:40
|
configure those real briefly,
|
|
0:36:42
|
and then we'll come back and do RSVP with them.
|
|
0:36:46
|
So I've already got this hub none
|
|
0:36:49
|
I can't really change the name on it,
|
|
0:36:52
|
I could change the bandwidth, but I'm not going to
|
|
0:36:54
|
because we're going to use RSVP based.
|
|
0:36:56
|
So I'm just going to copy this and I'll call it
|
|
0:36:59
|
Location Branch1,
|
|
0:37:04
|
I'm just going to leave it unlimited for right now,
|
|
0:37:07
|
copy it, call it Branch2 and save it,
|
|
0:37:11
|
then we'll go back to device pool
|
|
0:37:13
|
and now I can go ahead and set these properly
|
|
0:37:18
|
so I can set this to Branch1, and SRST to Branch1,
|
|
0:37:24
|
ok, then I'll copy this out to device pool Branch2
|
|
0:37:28
|
date/time is CEST, region Branch2,
|
|
0:37:33
|
location Brach2, and SRST Branch2.
|
|
0:37:40
|
Ok so I've got my device pools setup,
|
|
0:37:43
|
and now we can go ahead and take a look
|
|
0:37:47
|
at our locations.
|
|
0:37:50
|
So with locations,
|
|
0:37:53
|
currently they're set to unlimited bandwidth.
|
|
0:37:55
|
We could set them to a static bandwidth,
|
|
0:37:59
|
this is called static location or Legacy locations.
|
|
0:38:03
|
If I happen to have RSVP set which is what we're about to do.
|
|
0:38:09
|
And I have a static bandwidth set,
|
|
0:38:13
|
then both take effect, one does not override the other.
|
|
0:38:18
|
So, in this case, first,
|
|
0:38:21
|
static locations would have to have enough bandwidth,
|
|
0:38:23
|
and then if it did, then it would engage
|
|
0:38:26
|
the RSVP agent to see if that had enough bandwidth.
|
|
0:38:29
|
There is no good reason to ever have both of them working together.
|
|
0:38:33
|
Ok, if you're using RSVP, which is the preferred,
|
|
0:38:37
|
then you're leaving your static at unlimited.
|
|
0:38:40
|
That is the CUCM decides, hey whatever the routers decide is cool with me,
|
|
0:38:45
|
but I'm not going to make a decision for them.
|
|
0:38:50
|
And same with video.
|
|
0:38:51
|
By the way, we only looked at a configuration so far
|
|
0:38:56
|
for IP RSVP bandwidth X,
|
|
0:39:01
|
and that takes effect for all traffic.
|
|
0:39:03
|
Voice and video, but there are ways to separate out voice from video.
|
|
0:39:09
|
We have application IDs, and all voice calls from CUCM
|
|
0:39:15
|
are actually tagged with this application ID
|
|
0:39:23
|
just like all video calls are tagged with this application ID for videos
|
|
0:39:27
|
and so we certainly have the ability to differentiate between those
|
|
0:39:32
|
types of calls in the routers
|
|
0:39:35
|
and carve out different bandwidths...
|
|
0:39:40
|
guarantees for Call Admission Control for them.
|
|
0:39:43
|
Ok, so from hub to hub, I can do an RSVP setting if I want.
|
|
0:39:51
|
So in other words, if I have a large campus,
|
|
0:39:53
|
I'm probably going to have different locations maybe for each building or something.
|
|
0:39:56
|
But I can have an RSVP setting.
|
|
0:39:58
|
We're going to leave it to the default.
|
|
0:40:01
|
Use system default which in the service parameters is set to no reservation.
|
|
0:40:09
|
If I look at Hub_None to Branch1,
|
|
0:40:12
|
let's just take a look at what these RSVP settings are.
|
|
0:40:15
|
"no reservation" is the system default
|
|
0:40:17
|
it's just what it is, there is no reservation, we're not engaging RSVP at all.
|
|
0:40:22
|
Optional with video desired
|
|
0:40:25
|
mandatory and mandatory video desired.
|
|
0:40:27
|
Typically you're going to want mandatory video desired.
|
|
0:40:31
|
What this is, is it is mandatory for RSVP to negotiate available bandwidth
|
|
0:40:38
|
for audio calls.
|
|
0:40:40
|
We want to try, we will engage RSVP for video calls as well,
|
|
0:40:46
|
however, if there's not enough bandwidth for a video call,
|
|
0:40:51
|
we will go ahead and allow that video call to fail and where we normally
|
|
0:40:56
|
have phones that are set to retry call as audio call if the video call fails
|
|
0:41:05
|
then the video's desired, however if it fails it will fall back to audio.
|
|
0:41:12
|
If there's enough bandwidth for audio. If there's not enough bandwidth for audio
|
|
0:41:16
|
obviously the call is going to fail period.
|
|
0:41:18
|
But then there's also mandatory,
|
|
0:41:21
|
which is mandatory for video calls as well,
|
|
0:41:24
|
so in other words, if we engage RSVP as a mechanism to determine
|
|
0:41:28
|
is there enough bandwidth to place a video call and RSVP says, "No there is not"
|
|
0:41:34
|
we won't try to fail back to an audio call.
|
|
0:41:37
|
This is useful for when CUCM is trying to setup RSVP or engage RSVP to setup a
|
|
0:41:45
|
telepresence call or any sort of video conferencing call.
|
|
0:41:49
|
So between locations, and I would have separate locations
|
|
0:41:51
|
defined for my telepresence or other video conference end points,
|
|
0:41:56
|
I would make sure that they're set to mandatory, period.
|
|
0:42:00
|
Ok, but for wherever I have phones, whether they have UCVTA or not,
|
|
0:42:06
|
I would have mandatory videos desired, but it might not be able to be
|
|
0:42:11
|
negotiated, so therefore an audio only call.
|
|
0:42:15
|
Optional video desired,
|
|
0:42:17
|
so this means we're going to try to use RSVP for video.
|
|
0:42:21
|
And if that fails go back to audio and
|
|
0:42:25
|
if audio fails, then we're still going to allow the call to go through.
|
|
0:42:30
|
So how is this going to work?
|
|
0:42:34
|
So it's optional, completely optional whether RSVP works.
|
|
0:42:37
|
Well let's take a look at service parameters to get a better understanding.
|
|
0:42:42
|
And specifically service parameters for the Call Manager Service,
|
|
0:42:55
|
and we're going to do a search for RSVP.
|
|
0:42:58
|
And here we have cluster wide parameters for QoS.
|
|
0:43:01
|
So we've got where Cisco sets the QoS specifics.
|
|
0:43:06
|
And notice, DSCP for audio calls when..
|
|
0:43:10
|
and for video calls when RSVP fails.
|
|
0:43:15
|
So what this is, is that if we chose optional video desired,
|
|
0:43:23
|
and there wasn't enough bandwidth for video or audio,
|
|
0:43:26
|
it failed its optional, but we're going to..
|
|
0:43:30
|
we're going to pass the call, but before we do that
|
|
0:43:32
|
we're going to send out the call with a different DSCP value.
|
|
0:43:36
|
So for a normal DSCP -- normal audio call
|
|
0:43:39
|
we're going to set it out with DSCP expedited forwarding.
|
|
0:43:44
|
Ok,
|
|
0:43:47
|
and DSCP for video calls, we're going to send out with AF41,
|
|
0:43:52
|
Assured Forwarding class for drop preference one.
|
|
0:43:58
|
Now of course you could change that, you could change that to CS4.
|
|
0:44:00
|
Ok, so notice, of the first there bits that
|
|
0:44:04
|
first is set, but last three bits none is set.
|
|
0:44:07
|
With AF41 the first three bits, the one is set so
|
|
0:44:13
|
one, two, four the place holder is set
|
|
0:44:16
|
and then the last three bits, one does not necessarily mean...
|
|
0:44:21
|
First of all the four is binary to decimal four
|
|
0:44:26
|
when we're just looking at these first three bits here.
|
|
0:44:30
|
From left to right, the first three bits.
|
|
0:44:33
|
But when we're looking at the last three bits
|
|
0:44:37
|
we can clearly see that that's actually a two
|
|
0:44:39
|
010 so that's a two place holder,
|
|
0:44:42
|
so that does not necessarily correlate with
|
|
0:44:46
|
the number that you see. One two and three are just the
|
|
0:44:50
|
drop probability selectors per se
|
|
0:44:54
|
because this is four, two where we still for the first three bits
|
|
0:44:59
|
from left to right, we still have one in the four position
|
|
0:45:03
|
one, two four, but then one, two, four the second
|
|
0:45:07
|
is actually the...
|
|
0:45:12
|
The second three bits indicates a four decimally, but it's
|
|
0:45:16
|
considered drop probability two.
|
|
0:45:18
|
Ok, and these have to do with what these different bits indicate.
|
|
0:45:23
|
Low through -- you know high through put, low drop, things like that.
|
|
0:45:29
|
But anyhow, AF41 is what by default Cisco marks video calls at.
|
|
0:45:34
|
We can change that.
|
|
0:45:36
|
But when RSVP fails,
|
|
0:45:40
|
we're going to change by default
|
|
0:45:42
|
DSCP to zero.
|
|
0:45:44
|
Best effort before we send it out.
|
|
0:45:46
|
If we want, we could send that to CS1.
|
|
0:45:49
|
CS1 is typically used for scavenger traffic.
|
|
0:45:53
|
DSCP per hop behavior of CS1 or decimal value of 8.
|
|
0:46:02
|
Ok,
|
|
0:46:04
|
but AF11 might be a good choice,
|
|
0:46:08
|
so it's better than scavenger traffic, obviously we don't want it relegated
|
|
0:46:13
|
down to, you know, 1% of our bandwidth or something
|
|
0:46:17
|
but maybe we want to classify it as something different
|
|
0:46:20
|
so that we can have a second
|
|
0:46:22
|
class setup for lower priority calls.
|
|
0:46:26
|
Ok, I haven't really seen this used too much.
|
|
0:46:29
|
I haven't really ever actually seen anyone setup locations
|
|
0:46:36
|
with RSVP
|
|
0:46:38
|
where they're saying, from one Site to another Site
|
|
0:46:42
|
they're doing optional video desired.
|
|
0:46:44
|
But obviously there is reason out there for it.
|
|
0:46:48
|
The RFC is written to allow for it and
|
|
0:46:54
|
so maybe you can find a practical application for it.
|
|
0:46:59
|
Ok, so we're going to do mandatory video desired
|
|
0:47:01
|
for both Branch1 and 2.
|
|
0:47:05
|
So from Hub_None to Branch1 and 2 is mandatory video desired,
|
|
0:47:09
|
and to itself is no reservation.
|
|
0:47:13
|
So if we go check Branch1,
|
|
0:47:15
|
that has done the converse which is Branch1 to Hub_None
|
|
0:47:20
|
is mandatory video desired,
|
|
0:47:22
|
to Branch1 itself no reservation,
|
|
0:47:25
|
we just need to add in Branch2.
|
|
0:47:30
|
And so that will have setup Branch2
|
|
0:47:34
|
to be successfully configured automatically as well.
|
|
0:47:40
|
And so now what we need to do is
|
|
0:47:42
|
we're telling our phones if you want to make calls between sites,
|
|
0:47:45
|
you have to have RSVP.
|
|
0:47:47
|
However, we have to provide the mechanism for RSVP.
|
|
0:47:52
|
So right now our phones are all sitting in
|
|
0:47:55
|
the... I'm not sure why the Branch2 phones aren't registering
|
|
0:47:58
|
I'm going to take a look at that in a little bit more but
|
|
0:48:02
|
for right now our phones are all sitting in the device pool
|
|
0:48:05
|
CorpHQ, however our Branch1 phone is certainly not
|
|
0:48:13
|
that phone, so let's just go ahead and say Branch1 Phone1
|
|
0:48:20
|
Whoops,
|
|
0:48:22
|
and we're going to set it to the device pool for Branch1
|
|
0:48:27
|
and we'll save this,
|
|
0:48:31
|
we'll go and change our DN as well
|
|
0:48:33
|
to let's say 2001,
|
|
0:48:46
|
and we'll go back to our list, it's updating right now.
|
|
0:48:51
|
And,
|
|
0:49:05
|
we'll change these phones here real quick as well.
|
|
0:49:12
|
And I'm actually changing the order just based on what I have in front of me.
|
|
0:49:50
|
Ok, so these phones.. The other one is resetting
|
|
0:49:52
|
and we can go ahead and go to our end user
|
|
0:49:55
|
for variphy and add these phones to its control.
|
|
0:50:10
|
That way we should be able to...
|
|
0:50:14
|
log into our variphy agent
|
|
0:50:31
|
and be able to begin controlling our remote phones.
|
|
0:50:45
|
Ok, so currently,
|
|
0:50:48
|
CorpHQ phone can certainly dial over to 1002,
|
|
0:50:55
|
and that works, no problem.
|
|
0:50:57
|
And we'll see this phone update here its screen in just a moment.
|
|
0:51:00
|
And we can answer and we'll get feedback
|
|
0:51:04
|
and I've gone ahead and hung up.
|
|
0:51:06
|
However,
|
|
0:51:09
|
if we try to have our Branch1 phone
|
|
0:51:13
|
dial
|
|
0:51:17
|
we get reorder tone and we specifically get...
|
|
0:51:24
|
if I can bring up my drawing here,
|
|
0:51:28
|
whoops, it did say it, we get not enough bandwidth.
|
|
0:51:36
|
Ok,
|
|
0:51:38
|
so the reason is, is that we've set
|
|
0:51:48
|
we've set our Branch1 phone
|
|
0:51:51
|
even though it shows a location of Hub_None,
|
|
0:51:56
|
we mentioned that, that goes back to the device pool
|
|
0:51:59
|
when it's set at Hub_None,
|
|
0:52:01
|
and the device pool is set to the location of L_Branch1.
|
|
0:52:07
|
And if we look at those locations,
|
|
0:52:08
|
it's set to engage and use RSVP, but we don't have RSVP configured yet.
|
|
0:52:14
|
So it's not going to allow anything, any communications to occur because
|
|
0:52:19
|
it's mandatory for audio calls at the minimum.
|
|
0:52:24
|
Ok,
|
|
0:52:25
|
here's the retry video call as audio call.
|
|
0:52:28
|
If we didn't have this checked, then a video call would fail as well.
|
|
0:52:32
|
Ok,
|
|
0:52:35
|
so,
|
|
0:52:39
|
in order to move forward we need to setup RSVP.
|
|
0:52:42
|
So let's go ahead and go out to our Router1,
|
|
0:52:47
|
we'll also bring up Router2 here as well.
|
|
0:52:52
|
Oops, put these in the proper order.
|
|
0:52:55
|
And let's go ahead and do conf t,
|
|
0:52:59
|
and we're going to do sccp
|
|
0:53:02
|
and we're going to want to configure
|
|
0:53:04
|
sccp i -- sorry not ip, precedence, but sccp ccm
|
|
0:53:10
|
identifier is going to be 177.1.10.10
|
|
0:53:17
|
oops,
|
|
0:53:20
|
if I can type here
|
|
0:53:21
|
and that will be identifier1 priority,
|
|
0:53:24
|
actually we don't even need to put in priority
|
|
0:53:27
|
oops,
|
|
0:53:29
|
priority1, ok we do have to, and then we can just hit enter
|
|
0:53:33
|
we can put in version.
|
|
0:53:36
|
We're going to want at least 5.0.1 or above.
|
|
0:53:40
|
In the lab, depending on the IOS version you see for your routers
|
|
0:53:44
|
you may only see 5.0.1 That's perfectly fine.
|
|
0:53:47
|
If you see 7.0+, that's better,
|
|
0:53:50
|
but 5.0.1 is the minimum you're going to want to put in.
|
|
0:53:54
|
Ok, then we're also going to want to do
|
|
0:53:57
|
sccp local, and tie that to a loopback0 interface
|
|
0:54:03
|
we don't have to, but it's really a good idea.
|
|
0:54:08
|
And we're going to want to turn sccp on, but we'll do that in a little bit.
|
|
0:54:12
|
So let's do sccp ccm group,
|
|
0:54:16
|
and we'll create group1,
|
|
0:54:18
|
from within here, we're going to say associate ccm
|
|
0:54:24
|
identifier1 as a priority of 2.
|
|
0:54:28
|
Did I put in my Sub as well? I think I only put in the Pub.
|
|
0:54:33
|
Ok, the priority here really doesn't matter.
|
|
0:54:35
|
The priority here is actually for Legacy configuration
|
|
0:54:39
|
where we use dspfarm conference bridge
|
|
0:54:46
|
instead of -- and dspfarm transcode instead of dspfarm profiles.
|
|
0:54:50
|
So the older PVDM1s.
|
|
0:54:54
|
Ok, but we're going to say ccm1 priority2,
|
|
0:54:59
|
and we're also going to say ccm2, identifier2 priority1
|
|
0:55:05
|
except that it doesn't really exist yet, so let's jump back out and create that.
|
|
0:55:09
|
sccp ccm 177.1.10.20
|
|
0:55:16
|
is identifier2 priority1 or 2, it really doesn't matter
|
|
0:55:25
|
and version5, jump back in
|
|
0:55:30
|
to the group
|
|
0:55:34
|
and try to put that associate to as priority1 and again
|
|
0:55:39
|
no problem, that works.
|
|
0:55:42
|
By the way, we can tell it that
|
|
0:55:44
|
we want to bind the interface
|
|
0:55:47
|
to a group
|
|
0:55:52
|
such as loopback0
|
|
0:55:55
|
and we can also deal with specifics on
|
|
0:56:03
|
on the IP precedence or DSCP value, but it actually is set to CS3 by default,
|
|
0:56:11
|
so we really don't have to do anything there.
|
|
0:56:14
|
Ok, so let's go ahead and exit out
|
|
0:56:18
|
and do our dspfarm profiles.
|
|
0:56:23
|
Now we only have to turn on
|
|
0:56:26
|
DSP services, dspfarm under our voice card which is our
|
|
0:56:32
|
actual PVDM DSPs
|
|
0:56:34
|
if we're going to use those DSPs for whatever it is we're creating
|
|
0:56:39
|
and here we're not, so I'm going to go ahead and create -- I'll leave one
|
|
0:56:43
|
profile1 and 2 as...
|
|
0:56:47
|
no actually I'll leave -- yeah we'll just go ahead and use 1 and2
|
|
0:56:50
|
as our MTP so profile1 is going to be an mtp
|
|
0:56:56
|
and I'm going to say no codec because it defaults to G.711
|
|
0:57:08
|
ulow and instead, codec G.729
|
|
0:57:13
|
and I can say g729r8, ar8
|
|
0:57:21
|
r8 by the way is rate of 8.
|
|
0:57:23
|
I can say abr8
|
|
0:57:28
|
but hopefully we don't want our phones ever negotiating nxb so let's just
|
|
0:57:32
|
leave them at g729r8 and ar8.
|
|
0:57:37
|
Ok,
|
|
0:57:39
|
and then I'm going to say max sessions software
|
|
0:57:44
|
and I'm going to -- let's just say it can be 10.
|
|
0:57:49
|
Ok, I'm also going to RSVP enable this
|
|
0:57:52
|
and I'm going to TRP enable this
|
|
0:57:58
|
for firewall traversal.
|
|
0:58:01
|
Ok, so do sh run | s dsp|sccp
|
|
0:58:10
|
I see that I've got my sccp commands
|
|
0:58:13
|
my ccm group, my dsp profile which is currently shut down
|
|
0:58:18
|
I need to remember to no shut that.
|
|
0:58:22
|
First of all I have to associate it.
|
|
0:58:24
|
So let's do associate to application skinny
|
|
0:58:29
|
and then do a no shut,
|
|
0:58:33
|
so now this is no shut, I need to now jump back into my ccm group
|
|
0:58:36
|
and do an associate profile, profile 1
|
|
0:58:41
|
and call it what am I going to call it when it registers to CUCM.
|
|
0:58:46
|
Back in the old days with PVDM1s you had to have something tied to
|
|
0:58:51
|
a Fast Ethernet or Ethernet, so it had a MAC address
|
|
0:58:54
|
and you had to register it with a MAC address.
|
|
0:58:56
|
That hasn't been the case since PBDM2s.
|
|
0:58:58
|
Ok, someone has to we need to bind the interface in the group
|
|
0:59:02
|
as well as the main skinny.
|
|
0:59:05
|
The truth is, the main skinny -- yeah you definitely do need to
|
|
0:59:09
|
bind it in the group, most of these commands out here at the main skinny
|
|
0:59:13
|
other than just like defining the ccm,
|
|
0:59:15
|
an identifier and version, but like the priority
|
|
0:59:18
|
this really doesn't take effect this is only for the old PVDM1s,
|
|
0:59:22
|
so here's the thing, they initially created the IOS structure
|
|
0:59:27
|
for the first hardware they had, the PVDM1s.
|
|
0:59:30
|
Packet Voice Data Module 1s, the DSPs.
|
|
0:59:33
|
And then they used the existing structure
|
|
0:59:35
|
and added on, so a lot of this stuff like
|
|
0:59:38
|
sccp, precedence, iep precedence
|
|
0:59:43
|
three or whatever, a lot of these stuff
|
|
0:59:46
|
was for the old PVDM1s.
|
|
0:59:48
|
But then they kept some of the stuff like the
|
|
0:59:50
|
definitions of the ccm and identifier and version
|
|
0:59:54
|
and ignored other bits of it.
|
|
0:59:57
|
As they used and built on
|
|
0:59:59
|
to the additional cc -- IOS structure
|
|
1:00:03
|
for skinny groups.
|
|
1:00:05
|
Ok, so we call the ccm identifiers
|
|
1:00:08
|
that we've done, but now we assigned them the actual priority that
|
|
1:00:11
|
we want for our groups and this was with the advin of the PVDM2s
|
|
1:00:15
|
and of course we have PVDM3s now as well.
|
|
1:00:18
|
PVDM2 is what you'll have in the lab.
|
|
1:00:21
|
So yes you do need to bind it here.
|
|
1:00:24
|
This is actually, whoops, this is actually what's going to take effect.
|
|
1:00:29
|
Ok so we need to associate this profile1 and register it as
|
|
1:00:33
|
let's say CorpHQ 729 MTP.
|
|
1:00:42
|
Ok and we're also going to...Let's just go ahead and while we're at it...
|
|
1:00:48
|
I don't think we'll need a 711 for anything, it can't hurt.
|
|
1:00:52
|
It's not very hard to create a second mtp with the default codec of G.711
|
|
1:01:09
|
note by the way, if I just put in codec g729r8, it's says,
|
|
1:01:15
|
"A codec's already configured and it's not compatible."
|
|
1:01:19
|
do sh run | s sccp|rs, I'm sorry dsp
|
|
1:01:30
|
and this where as soon as we defined it, it was automatically
|
|
1:01:34
|
codec 711. So I'm going to go ahead..
|
|
1:01:36
|
I'm just going to go ahead and add...
|
|
1:01:42
|
I'm just going to go ahead and add both of --
|
|
1:01:43
|
all of this stuff as well except for the codec.
|
|
1:01:49
|
And no shut and I'm going to jump back up here in the group
|
|
1:01:52
|
and I'm going to register profile 2
|
|
1:02:00
|
as 711 mtp.
|
|
1:02:05
|
Ok, so once again for this do command
|
|
1:02:12
|
here's my full configuration
|
|
1:02:16
|
for everything that I need.
|
|
1:02:17
|
Now remember, it's very easy to copy this
|
|
1:02:22
|
paste it,
|
|
1:02:25
|
and just change a few variables
|
|
1:02:27
|
like let's say Branch 1.
|
|
1:02:32
|
Actually I think there's too many characters there.
|
|
1:02:35
|
If I remember correctly.
|
|
1:02:38
|
It does only allow a certain number of characters.
|
|
1:02:40
|
So, yep that looks good I'll add in no shut,
|
|
1:02:50
|
no shut
|
|
1:02:53
|
and everything else should be... Yep everything else should be good.
|
|
1:02:58
|
Yep, I don't see anything missing, so let's go ahead and go over to Branch 1,
|
|
1:03:03
|
conf t, I'll copy everything
|
|
1:03:06
|
and paste it in,
|
|
1:03:08
|
actually the only thing I haven't done in Router 1 was just to say
|
|
1:03:11
|
sccp enter, but I'm not going to do that yet until
|
|
1:03:16
|
I actually configure them in...
|
|
1:03:19
|
Ah! The codec, yep, if I want to use this, I have this as part of our scripting.
|
|
1:03:24
|
If I want to do this I need to say, sorry no
|
|
1:03:33
|
no codec g711 first,
|
|
1:03:40
|
Ah, it's not shut down,
|
|
1:03:59
|
and this is part of the fun of scripting
|
|
1:04:01
|
is that you have to account for all this stuff
|
|
1:04:06
|
not that this is scripting.
|
|
1:04:08
|
Sort of manual.
|
|
1:04:13
|
Actually those wouldn't be shut on the next two.
|
|
1:04:17
|
Ok, so...
|
|
1:04:22
|
I'm also going to do this for Branch 2
|
|
1:04:24
|
as well, and actually if I ever wanted this to fall back
|
|
1:04:29
|
to SRST, then I would need to add in SRST parameters as well,
|
|
1:04:35
|
so 254.3 for Branch 2,
|
|
1:04:40
|
identifier 3, priority 3,
|
|
1:04:47
|
and you can have...
|
|
1:04:52
|
you can have your resources fall back
|
|
1:04:55
|
to...
|
|
1:05:00
|
to SRST.
|
|
1:05:06
|
Ok, so... By the way don't worry about the dspfarm resource provider
|
|
1:05:11
|
not registered, it's just simply saying we haven't associated an application
|
|
1:05:15
|
and created a register statement for those just yet.
|
|
1:05:19
|
Ok, so it hasn't been registered with the skinny application as of yet.
|
|
1:05:25
|
And we haven't done the final thing which is actually turn on skinny.
|
|
1:05:29
|
So we'll do that in a bit.
|
|
1:05:32
|
Ok, so let's go ahead and go over to our Media Resources,
|
|
1:05:38
|
and MTPs, Media Termination Point.
|
|
1:05:44
|
And we have our software MTPs from CUCM,
|
|
1:05:48
|
if we want to make sure those are never used
|
|
1:05:50
|
it's very easy, we could put these in a group
|
|
1:05:53
|
that's isolated or we can simply come up to service parameters
|
|
1:06:00
|
and we could change for the service parameter for
|
|
1:06:02
|
IP Voice media streaming app which is what controls them.
|
|
1:06:06
|
And we could say that for the mtp, we're going to turn the run flag to false.
|
|
1:06:12
|
Now notice, these are not cluster wide parameters.
|
|
1:06:15
|
These are per servers.
|
|
1:06:16
|
These are cluster wide parameters.
|
|
1:06:19
|
Such as supported music on hold codec,
|
|
1:06:22
|
but if I want to turn off let's say conference bridge in mtp,
|
|
1:06:25
|
I have to do those, set the run flag to false
|
|
1:06:28
|
and do those per server.
|
|
1:06:34
|
So I need to switch over, switch those to false,
|
|
1:06:37
|
and save.
|
|
1:06:39
|
And now those MTPs will not ever be able to be negotiated.
|
|
1:06:44
|
Ok, notice they changed state to unregistered.
|
|
1:06:49
|
So did the software conference bridge.
|
|
1:06:54
|
However, the annunciator, which I did not change the run flag,
|
|
1:06:58
|
they're still registered.
|
|
1:07:01
|
And they're currently registered with the Pub
|
|
1:07:03
|
because they're at the CorpHQ and that CorpHQ has
|
|
1:07:06
|
Pub-Sub as first.
|
|
1:07:09
|
If I change it to Sub-Pub,
|
|
1:07:12
|
well then, those annunciators should
|
|
1:07:15
|
unregister and in just a moment reregister with the Subscriber.
|
|
1:07:21
|
Remember that just because a media resource happens to be
|
|
1:07:25
|
running on a Publisher doesn't mean it's registered with the Publisher.
|
|
1:07:28
|
Ok, this is just where the media resources
|
|
1:07:31
|
is on the Publisher, but it's registered with the primary CPE.
|
|
1:07:35
|
Ok, I know we're getting a little bit into media resources
|
|
1:07:38
|
it's sort of necessary in order to talk about RSVP.
|
|
1:07:43
|
So IOS enhanced, what's the name?
|
|
1:07:45
|
I don't know, let's go see what we called it.
|
|
1:07:50
|
We called one CorpHQ-711-MTP
|
|
1:07:53
|
and the device pool, it's at the CorpHQ Site.
|
|
1:07:56
|
It is a TRP, or can be a TRP.
|
|
1:08:02
|
So let's save it.
|
|
1:08:03
|
Now, we're also going to copy this
|
|
1:08:06
|
and have one that's 729
|
|
1:08:09
|
at the CorpHQ Site and it can be a Trusted Relay Point.
|
|
1:08:12
|
Right.
|
|
1:08:14
|
So...
|
|
1:08:16
|
And these are currently unregistered because I need to go hit
|
|
1:08:22
|
skinny enter.
|
|
1:08:25
|
So let's go ahead and do sccp enter
|
|
1:08:29
|
and do sh sccp,
|
|
1:08:33
|
and it looks like it's connected
|
|
1:08:36
|
for both of these, so if I hit find these should show up as
|
|
1:08:39
|
registered with the Subscriber for the loopback interface.
|
|
1:08:44
|
Right.
|
|
1:08:45
|
So how is it going to know if both of these are able to be Trusted Relay Points?
|
|
1:08:51
|
How is it going to know which one to use?
|
|
1:08:54
|
The 711 or the 729.
|
|
1:08:58
|
Anyone want to take a guess at that?
|
|
1:09:03
|
That's a function of the region.
|
|
1:09:07
|
So whatever region is used to negotiate within CUCM,
|
|
1:09:13
|
the proper codec or the maximum allowable codec,
|
|
1:09:17
|
that is what we'll use to determine which type of resource needs to be used.
|
|
1:09:25
|
Now we didn't specify anything on here
|
|
1:09:29
|
about codecs. We do have a devise pool which contains
|
|
1:09:33
|
regions so we can use that to help us negotiate,
|
|
1:09:37
|
but the entity itself, the skinny entity itself
|
|
1:09:43
|
registers with CUCM with the supported codecs.
|
|
1:09:47
|
So that's how CUCM knows what codecs
|
|
1:09:51
|
can be used with the given mtp that we're talking about.
|
|
1:09:57
|
The name has nothing to do with it.
|
|
1:10:00
|
Ok, so let's copy these over to
|
|
1:10:04
|
Branch 1 and put it at the proper place,
|
|
1:10:12
|
and let's just go ahead and enter sccp on Branch 1 and Branch 2
|
|
1:10:18
|
and do a right as well
|
|
1:10:20
|
for all these devices.
|
|
1:10:26
|
And we see that it's registered.
|
|
1:10:28
|
And we'll copy this,
|
|
1:10:32
|
for 729, it'll be rejected,
|
|
1:10:37
|
oops, we don't even need to reset,
|
|
1:10:39
|
we just need to refresh.
|
|
1:10:41
|
Maybe we do need to reset.
|
|
1:10:44
|
Actually because we had turned it on first...
|
|
1:10:50
|
It's still rejected, interesting.
|
|
1:10:54
|
Ok, let's just go over to Branch1 and say no skinny
|
|
1:11:01
|
and skinny,
|
|
1:11:04
|
and there, they're both registered.
|
|
1:11:06
|
So just do a quick reset from that side.
|
|
1:11:08
|
And let's go ahead and copy this Branch 1
|
|
1:11:11
|
over to Branch2
|
|
1:11:14
|
with the proper device pool, save that
|
|
1:11:17
|
copy that to its bigger brother 711
|
|
1:11:28
|
and we'll do the same thing from Branch2,
|
|
1:11:31
|
this is why I like to wait before running those commands.
|
|
1:11:35
|
Everything’s registered on both of the Branch2s as well,
|
|
1:11:40
|
so we now have all of our mtps
|
|
1:11:43
|
that also speak of RSVPs
|
|
1:11:48
|
able, and there, will the call work now?
|
|
1:11:53
|
Shouldn't.
|
|
1:11:59
|
Nope still says right here, not enough bandwidth.
|
|
1:12:03
|
Why? Well we've enabled RSVP
|
|
1:12:07
|
enabled...
|
|
1:12:10
|
We've configured RSVP enabled mtps
|
|
1:12:13
|
on our router, but if we do a debug ip rsvp..
|
|
1:12:19
|
Let's do debug ip rsvp reservation and path.
|
|
1:12:34
|
So path messages, and reservation messages
|
|
1:12:37
|
if I that sh deb, term mon, sh logg
|
|
1:12:43
|
Logging to, who, is that us?
|
|
1:12:45
|
That's us good.
|
|
1:12:47
|
So if we do that, and we try to make the call again...
|
|
1:12:50
|
Now we're trying to make the call from Branch1, but we should
|
|
1:12:52
|
still see the message come across to corporate head -- well actually
|
|
1:12:56
|
we might not.
|
|
1:12:58
|
Let's just end out, do the same thing.
|
|
1:13:01
|
debug ip rsvp path,
|
|
1:13:05
|
and reservation, and sh deb
|
|
1:13:09
|
sh logg, good.
|
|
1:13:13
|
Let's try the call again.
|
|
1:13:19
|
We don't even see anything happening here.
|
|
1:13:22
|
Now that's not because we aren't trying to invoke
|
|
1:13:28
|
an RSVP enabled MTP,
|
|
1:13:30
|
but because we don't have RSVP configured at all.
|
|
1:13:34
|
So, let's go ahead and configuration,
|
|
1:13:37
|
let's go into interface,
|
|
1:13:42
|
we could do this on every interface, so we could do it on the inbound interface
|
|
1:13:46
|
which actually do sh ip int br | ex unass
|
|
1:13:56
|
The inbound interface is the VLAN,
|
|
1:13:57
|
we could start there, but we really don't have to in this case,
|
|
1:14:02
|
we just need to make sure that
|
|
1:14:03
|
every place we can leave the router has it.
|
|
1:14:06
|
So this is the interface we're primarily concerned with.
|
|
1:14:09
|
So let's say ip rsvp bandwidth, and we want to allow let's say
|
|
1:14:16
|
five calls, ok.
|
|
1:14:18
|
In the lab, just as in real life
|
|
1:14:21
|
you know, no use necessarily trying to add it up
|
|
1:14:28
|
just to possibly get it wrong, 24 times 5 is 120 + 16, there's our number 136.
|
|
1:14:36
|
That's what we want to have.
|
|
1:14:39
|
Ok so note, do sh run int ser0/0/1:0.1
|
|
1:14:47
|
there's our command,
|
|
1:14:49
|
and if we look at the physical interface,
|
|
1:14:52
|
we see that it's added IP RSVP bandwidth with no actual bandwidth.
|
|
1:14:56
|
Ok, so that's fine.
|
|
1:14:58
|
So now let's try to make that call again
|
|
1:15:02
|
Ok, now we still don't see anything go across.
|
|
1:15:04
|
Now one of the problems is, we've got all of these RSVP agents,
|
|
1:15:09
|
however, they're not in any sort of MRGLs or MRG ordered list.
|
|
1:15:13
|
So we sort of do have to begin to talk about
|
|
1:15:16
|
media resource groups and lists.
|
|
1:15:18
|
At least to a basic degree.
|
|
1:15:21
|
Let's go ahead and create three media resource groups.
|
|
1:15:27
|
One will be MRG, and we'll expand on this later.
|
|
1:15:30
|
Branch1,
|
|
1:15:37
|
and we're going to place our Branch1 specifics in here.
|
|
1:15:41
|
We'll expand on this more in media,
|
|
1:15:43
|
we're not going to go too much into it right now.
|
|
1:15:47
|
Branch2,
|
|
1:15:52
|
we're going to create and copy and call it CorpHQ,
|
|
1:15:59
|
because basically what we need to do is
|
|
1:16:07
|
be able to have a way to tell
|
|
1:16:10
|
our phones which set of MTPs they're supposed to use
|
|
1:16:19
|
in order to try to setup the RSVP link.
|
|
1:16:23
|
So..
|
|
1:16:30
|
so what we're going to do is simply... And anything that's
|
|
1:16:33
|
considered a list, you have to reset
|
|
1:16:35
|
it tells you you have to reset it except that an MRGL doesn't have a reset button.
|
|
1:16:39
|
So that's a fun little parser error on their part.
|
|
1:16:49
|
Click the reset button, Ok I'll be sure to do that.
|
|
1:16:51
|
Oh yeah it doesn't exist.
|
|
1:17:01
|
Ok, so I've basically setup a mini-structure
|
|
1:17:04
|
whoops, I obviously forgot to click
|
|
1:17:06
|
copy on one of these, so Branch1 might contain branch -- nope
|
|
1:17:11
|
I just didn't copy it over to Branch2 yet.
|
|
1:17:22
|
Ok, so now I've got all three,
|
|
1:17:24
|
in each MRGL, or Media Resource Group List
|
|
1:17:27
|
contains its respectively named media resource group
|
|
1:17:31
|
which contains their respective IOS MTP
|
|
1:17:37
|
entities.
|
|
1:17:38
|
Ok, so now we're going to go back to our device pools
|
|
1:17:42
|
and setup our device pool for Branch1,
|
|
1:17:46
|
has MRGL Branch1, save, and we're going to reset those devices,
|
|
1:17:53
|
and I'm clicking reset in the other window,
|
|
1:17:58
|
CorpHQ has the MRGL for CorpHQ,
|
|
1:18:03
|
save and reset,
|
|
1:18:09
|
and the device pool Branch2 has MRGL Branch2,
|
|
1:18:16
|
save and reset.
|
|
1:18:22
|
Ok, so let's just do a check this again.
|
|
1:18:24
|
Yep,
|
|
1:18:26
|
got that, so once those phones reset
|
|
1:18:29
|
which they're currently doing so
|
|
1:18:32
|
I should have hit restart rather than reset,
|
|
1:18:36
|
then we'll be able to try this again,
|
|
1:18:40
|
and in the meantime let's just go ahead and configure on CorpHQ
|
|
1:18:46
|
interface ser0/0/1:0.1
|
|
1:18:52
|
ip rsvp band 136
|
|
1:19:09
|
Ok, so let's try our call again,
|
|
1:19:14
|
and this time we do hear the call go through
|
|
1:19:16
|
and we're seeing the RSVP messages.
|
|
1:19:22
|
So I'm just going to go ahead and
|
|
1:19:25
|
flip over and hit mute on this side,
|
|
1:19:28
|
and we can take a look at what is actually negotiated.
|
|
1:19:34
|
Ok, so we see that we received a path message
|
|
1:19:37
|
from 127.0.0.1,
|
|
1:19:40
|
so from the local router, that's because it's the RSVP agent taking over.
|
|
1:19:44
|
And the RSVP message goes from loopback or on Router2
|
|
1:19:49
|
so from Router2 loopback to Router1 loopback.
|
|
1:19:54
|
New path message passed, it's parsing.
|
|
1:19:58
|
Ok, we received a message. There is no matching existing path state.
|
|
1:20:05
|
So we're triggering outgoing due to a new incoming path state.
|
|
1:20:11
|
Ok, we're building a hop object with the source address of 177.0.1.2
|
|
1:20:17
|
that's the serial interface from Branch1 Router2.
|
|
1:20:21
|
Now, this would be something where
|
|
1:20:25
|
the carrier might not necessarily be able to...
|
|
1:20:29
|
or actually the carrier doesn't have RSVP enabled
|
|
1:20:33
|
and so your -- probably your far side router
|
|
1:20:38
|
is not going to necessarily know about
|
|
1:20:39
|
your public IP address,
|
|
1:20:42
|
and so you're going to want to change the source of your address,
|
|
1:20:44
|
your RSVP source to a loopback.
|
|
1:20:48
|
A loopback something that's actually passed in your routing protocol
|
|
1:20:51
|
over to the far side. So that way it knows how to respond.
|
|
1:20:54
|
That's the way you get over in terms of -- that's the way you hop
|
|
1:20:58
|
over non-RSVP enabled MPLS carrier routers
|
|
1:21:04
|
is you change the source address of your RSVP messages
|
|
1:21:07
|
to a loopback or to another interface,
|
|
1:21:10
|
but preferably a loopback for redundancy
|
|
1:21:12
|
that is passed in your routing protocol.
|
|
1:21:15
|
Ok, that's the way it knows how to respond.
|
|
1:21:21
|
So after we did this, we successfully received a reservation message
|
|
1:21:26
|
from a receiver, so from, here we go
|
|
1:21:30
|
from Router1, notice we're still on Router2 up here.
|
|
1:21:33
|
But from Router1 back to Router2,
|
|
1:21:36
|
we received a reservation message,
|
|
1:21:38
|
the reservation was not found
|
|
1:21:40
|
so we created a new one and we admitted the new reservation
|
|
1:21:43
|
and gave it a tag.
|
|
1:21:45
|
Ok,
|
|
1:21:52
|
so we restarted requesting 40 kilobits per second
|
|
1:21:58
|
and if we keep scrolling down
|
|
1:22:02
|
we should see that there is a change in the reservation.
|
|
1:22:06
|
And now we start requesting 24K.
|
|
1:22:09
|
There's still only one RSVP message that's up.
|
|
1:22:14
|
But what we've seen is that
|
|
1:22:17
|
the... They are essentially seen show ip rsvp
|
|
1:22:25
|
let's see, reservations,
|
|
1:22:30
|
we see that we have a bidirectional
|
|
1:22:34
|
whoops,
|
|
1:22:34
|
we keep getting information here.
|
|
1:22:36
|
We see that we have -- let me scroll down just one
|
|
1:22:40
|
to stop it from scrolling, there we go.
|
|
1:22:41
|
We see that we have a bidirectional reservation.
|
|
1:22:46
|
with 24k bits per second,
|
|
1:22:51
|
Ok, and this is a single single call.
|
|
1:22:54
|
Ok, so we've seen RSVP work just properly,
|
|
1:22:57
|
no problem.
|
|
1:22:59
|
And if we tear this down
|
|
1:23:03
|
we'll see the RSVP messages. We've received a reservation teardown message
|
|
1:23:08
|
from Router2, we're on Router1.
|
|
1:23:11
|
So we're dropping that.
|
|
1:23:16
|
And we see that that reservation is now gone.
|
|
1:23:29
|
Someone asked the question, the media resources that are not assigned
|
|
1:23:32
|
in MRG and MRGLs are accessed by all phones.
|
|
1:23:37
|
Or in other words, accessible by all phones.
|
|
1:23:39
|
Is that correct?
|
|
1:23:40
|
So which one would it choose in this case?
|
|
1:23:42
|
That's exactly part of what the problem was
|
|
1:23:45
|
is that it didn't know which one to choose,
|
|
1:23:47
|
so it actually places anything
|
|
1:23:50
|
and this is getting into media again, but
|
|
1:23:54
|
just looking at these real quick.
|
|
1:23:56
|
If we see all of our mtps
|
|
1:23:58
|
and before we had placed them in a -- the two Branch1
|
|
1:24:03
|
in the Branch1 MRG, the two Branch2 in the Branch2 MRG
|
|
1:24:07
|
and the two Corporeate Headquarter,
|
|
1:24:08
|
in the CorpHQ Media Resource group
|
|
1:24:11
|
they were all in a default MRG
|
|
1:24:15
|
called the none or null or default media resource group.
|
|
1:24:18
|
It's just one that when we happen to go to
|
|
1:24:23
|
media resources, media resource group.
|
|
1:24:25
|
But there's actually a default one that doesn't show up.
|
|
1:24:28
|
It's called the null or the none.
|
|
1:24:30
|
And any resources that are found inside there which are
|
|
1:24:35
|
all resources by default,
|
|
1:24:37
|
are serviced in the same way
|
|
1:24:40
|
that resources within the MRG are serviced.
|
|
1:24:43
|
Notice once we change available to selected,
|
|
1:24:46
|
there's no up or down arrow right here.
|
|
1:24:48
|
Is there?
|
|
1:24:50
|
There's no up or down arrow.
|
|
1:24:51
|
So there's really no way to deal with
|
|
1:24:55
|
the order in which something should be chosen.
|
|
1:24:57
|
It's not 711 is chosen first then 729,
|
|
1:25:02
|
I can't order those around, but I can certainly
|
|
1:25:06
|
deselect them and then select them,
|
|
1:25:08
|
so that now 729 appears at the top of the list,
|
|
1:25:11
|
but there's really no order.
|
|
1:25:13
|
So it basically asks all available resources
|
|
1:25:17
|
or at least says
|
|
1:25:18
|
"What is available with these resources?"
|
|
1:25:21
|
so if we needed a 729 call, because that's what regions between
|
|
1:25:25
|
phones dictated, then when it was looking at
|
|
1:25:30
|
all mtp resources,
|
|
1:25:34
|
because RSVP was required,
|
|
1:25:37
|
it was first saying, "Who has RSVP enabled?"
|
|
1:25:41
|
Everyone, ok great.
|
|
1:25:42
|
Actually you two don't, so you're out of the question.
|
|
1:25:45
|
Of course we unregistered them anyway,
|
|
1:25:46
|
but if we hadn't changed the run flag
|
|
1:25:48
|
they wouldn't have been out of the question.
|
|
1:25:50
|
So out of eight, now there's six.
|
|
1:25:52
|
Ok, who can support G.729?
|
|
1:25:55
|
One, two, three, ok you other three are out of the question,
|
|
1:25:59
|
so now there's three left.
|
|
1:26:00
|
Out of those three,
|
|
1:26:03
|
what else is there to determine?
|
|
1:26:05
|
There's nothing, so it load balances it just round-robins and goes through.
|
|
1:26:09
|
So whichever one it happened to have checked first,
|
|
1:26:11
|
maybe it was sending it to the CorpHQ
|
|
1:26:14
|
or maybe to the Branch2, or maybe to the Branch1,
|
|
1:26:17
|
regardless we didn't have RSVP configured on any of them,
|
|
1:26:20
|
but we could actually do an experiment.
|
|
1:26:24
|
We won't just for time's sake, but we could turn on RSVP
|
|
1:26:27
|
on all the routers and put all three of these
|
|
1:26:33
|
back into a global -- or not assign to any MRG
|
|
1:26:36
|
and just see which one it chose first.
|
|
1:26:39
|
And of course that wouldn't be the natural path
|
|
1:26:42
|
of the packet, so it's up to you, the administrator
|
|
1:26:44
|
and the designer's job, even in the CCIE lab, to make sure that
|
|
1:26:50
|
you put the appropriate
|
|
1:26:53
|
RSVP enabled 729 MTP,
|
|
1:26:56
|
the local one in the local MRG
|
|
1:27:00
|
and make that MRG ordered first
|
|
1:27:02
|
in the list of MRGL -- MRGLs, so list of MRGs
|
|
1:27:08
|
so that it gets chosen first and is the appropriate
|
|
1:27:12
|
RSVP enabled mtp in the path, the natural path
|
|
1:27:17
|
of the IP per the routing protocol.
|
|
1:27:21
|
Ok, so that's up to you.
|
|
1:27:22
|
Ok, so let's go ahead and... We've been lecturing for
|
|
1:27:27
|
or demoing for an hour and a half
|
|
1:27:29
|
we can still look at LDAP, but we'll do that when we come back
|
|
1:27:32
|
and we'll look at telephony features.
|
