|
0:00:13
|
Ok, so we're back and we are going to take a look at our
|
|
0:00:20
|
demonstration. We're still with H.323 gatekeepers.
|
|
0:00:25
|
But we we're going to take a look into remote gatekeepers.
|
|
0:00:31
|
So sending LRQs and we remember the slides that we looked at a little bit earlier
|
|
0:00:39
|
in relation to how we look up remote gatekeepers.
|
|
0:00:42
|
Anyone remember how we are going to route a call to a remote gatekeeper
|
|
0:00:47
|
based on our ARQ flow chart?
|
|
0:00:54
|
And I'll bring that back up while anyone's wagering a guess on that
|
|
0:00:59
|
or hopefully not a guess, but remembering.
|
|
0:01:04
|
I'll just bring it back up here.
|
|
0:01:07
|
For sending an LRQ
|
|
0:01:09
|
we see that we can do it with a tech prefix match that happens to be
|
|
0:01:14
|
of the special type hop-off tech prefix.
|
|
0:01:17
|
That's one way.
|
|
0:01:19
|
And another way is if a zone prefix is matched
|
|
0:01:25
|
the target zone or destination equals whatever that matched zone
|
|
0:01:28
|
was and the answer to 'is the target zone local?'
|
|
0:01:32
|
is no, so it's a remote zone, a destination or target zone
|
|
0:01:38
|
was matched, but it's not local, it's remote.
|
|
0:01:41
|
So we're going to send an LRQ. Those are the two LRQ
|
|
0:01:44
|
output branches that we have here on our flow chart for
|
|
0:01:47
|
an admission request.
|
|
0:01:48
|
Try to look up the destination of a call.
|
|
0:01:50
|
Ok, so what we're going to take a look at is...
|
|
0:01:59
|
First of all, let's switch over to our corporate headquarter Router 1
|
|
0:02:04
|
and let's begin -- let's first do a sh run | s gatekeeper
|
|
0:02:10
|
and let's add to what we have here.
|
|
0:02:15
|
Let's add a remote zone.
|
|
0:02:18
|
So we've got three zone locals. We had zone SEA which originally
|
|
0:02:23
|
had CUCM Pub and Sub registered as gateways.
|
|
0:02:28
|
And then we had zone AMS for Amsterdam which was
|
|
0:02:31
|
the local zone that had the CME router registered to it.
|
|
0:02:36
|
And then we had zone local CUBE which was
|
|
0:02:39
|
the border element or IP-to-IP gateway
|
|
0:02:41
|
that was here on box on the corporate headquarter Router 1
|
|
0:02:46
|
We'll remember that towards the end of our example and demonstration
|
|
0:02:51
|
yesterday we moved zone, sorry we moved the CME
|
|
0:02:55
|
out of zone AMS and moved it into SEA in order to take a look at
|
|
0:03:00
|
single zone potential problems that could exist with routing a call
|
|
0:03:06
|
to -- I should say looping a call back to the gateway that
|
|
0:03:12
|
was the originating gateway.
|
|
0:03:14
|
So the gatekeeper selecting the terminating gateway
|
|
0:03:17
|
as the same as the originating gateway.
|
|
0:03:19
|
And we looked at how to overcome that with gateway
|
|
0:03:22
|
priority zero or never route to these particular gateway, these
|
|
0:03:27
|
H.323 IDs based on well, 3000 numbers don't live there.
|
|
0:03:33
|
Now again remember that our 3000 numbers are only temporarily
|
|
0:03:38
|
over on CME. We're actually invoking SRST right now.
|
|
0:03:43
|
In a real lab exam or even any sort of mock lab or multiprotocol lab
|
|
0:03:49
|
that you would get from any vendor, you wouldn't have
|
|
0:03:51
|
CME in usage with gatekeeper if that CME were used in SRST.
|
|
0:03:59
|
We're only doing it for the sake of demonstration
|
|
0:04:02
|
because we will be using phones back at our corporate headquarters
|
|
0:04:08
|
for the rest of our situation.
|
|
0:04:12
|
I mean I suppose you could. We obviously have made it work
|
|
0:04:15
|
it's not an impossibility to make work,
|
|
0:04:18
|
but it's unlikely mainly because even if you could move a
|
|
0:04:25
|
partition around like we did so that the 3001
|
|
0:04:29
|
is not more favorable or even if you created a more specific
|
|
0:04:32
|
or same specific route pattern and put it in a higher partition
|
|
0:04:35
|
which we're going to talk about in just a bit with
|
|
0:04:39
|
dial plan and the basics
|
|
0:04:42
|
you would still have to create some sort of access control list
|
|
0:04:44
|
because you couldn't as you would in the real lab you would just
|
|
0:04:47
|
down the serial interface in order to cause a disruption
|
|
0:04:52
|
in the WAN to invoke SRST
|
|
0:04:56
|
you wouldn't be able to do that and still have H.323
|
|
0:05:00
|
or RAS VoIP, IP being the keyword there, communications
|
|
0:05:05
|
between your remote site and between your corporate headquarter
|
|
0:05:11
|
or gatekeeper wherever it may lie.
|
|
0:05:16
|
Ok, so unless they had that ACL type thing there, it's doubtful that you would
|
|
0:05:21
|
experience something like that. You would more likely experience
|
|
0:05:24
|
from the outset, a topology where CME was standalone and the phones
|
|
0:05:28
|
were always registered over there at the CME
|
|
0:05:31
|
or you would experience a situation where all your phones
|
|
0:05:37
|
at all sites were registered to CUCM in which case you wouldn't
|
|
0:05:39
|
have gatekeeper to sites that you control.
|
|
0:05:44
|
You might have however what we're about to look at which is
|
|
0:05:47
|
gatekeeper between your CUCM and a remote or backbone gatekeeper.
|
|
0:05:53
|
Ok, so let's go ahead and jump into our config t and gatekeeper
|
|
0:05:59
|
subcommand and we're going to create a zone remote.
|
|
0:06:05
|
Ok, so we're going to create a zone remote and we're going to
|
|
0:06:10
|
take a look at...
|
|
0:06:15
|
By the way, we're not going to have time really to cover cluster today.
|
|
0:06:19
|
If you do want information on clustering, we do cover alternate
|
|
0:06:23
|
gatekeepers and the GUP Gatekeeper Update Protocol
|
|
0:06:26
|
in our deep dive series. We've already looked at local, prefix
|
|
0:06:30
|
zone prefix, we're about to do a zone remote.
|
|
0:06:34
|
The only other thing we haven't done is zone subnet.
|
|
0:06:36
|
Actually let's just cover that real quick.
|
|
0:06:40
|
If I do sh gatekeeper end points
|
|
0:06:45
|
I can see that my Pub and Sub are registered to zone SEA.
|
|
0:06:51
|
And I have their signaling and RAS IP addresses.
|
|
0:06:55
|
And my CME is registered to SEA.
|
|
0:06:59
|
And my local corporate headquarter router
|
|
0:07:02
|
IP-to-IP gateway is registered to the CUBE zone.
|
|
0:07:05
|
With zone subnet, it's a security command
|
|
0:07:10
|
and if you're at all familiar with access control lists
|
|
0:07:15
|
in IOS and hopefully you are. They're very useful for a myriad of things.
|
|
0:07:22
|
With ACLs, there's always an implicit deny any any
|
|
0:07:28
|
at the end of every access control list.
|
|
0:07:30
|
Whether you explicitly define it so that it shows up
|
|
0:07:34
|
or add options to it like deny IP any any log
|
|
0:07:38
|
or log input or what have you
|
|
0:07:41
|
or whether you don't do anything at all and you just have a permit TCP
|
|
0:07:47
|
any any 22 to allow destination SSH for instance.
|
|
0:07:53
|
There's always a deny any any as the last line.
|
|
0:07:58
|
Ok, sort of similar to the fact that there's always the null
|
|
0:08:02
|
entity as the last entity within any CUCM container.
|
|
0:08:08
|
So there's always a null partition within every calling search space.
|
|
0:08:13
|
So with gatekeeper and zone subnet
|
|
0:08:18
|
it's actually sort of the opposite way around.
|
|
0:08:20
|
And it's not process like an access control list which is top-down.
|
|
0:08:24
|
It's more looked at like partitions within a calling search space where
|
|
0:08:30
|
within a given calling search space we look at all of the partitions
|
|
0:08:34
|
including the none or null partition to see what is the best match.
|
|
0:08:39
|
These zone subnet commands are similar to an access control list
|
|
0:08:43
|
in some regards, but essentially in the functionality of what they block
|
|
0:08:48
|
and allow, but they are more like partitions in the sense that they are
|
|
0:08:55
|
not ordered top down or searched top down, they are
|
|
0:09:00
|
all looked at and then decided is there a good or best match.
|
|
0:09:05
|
Ok, and we have to first explicitly deny everything
|
|
0:09:11
|
if we want to then exclusively include any one gateway or subnet
|
|
0:09:21
|
or terminal, so the whole idea is that we are restricting
|
|
0:09:26
|
who is even allowed to register with us.
|
|
0:09:29
|
Ok, so let's say zone subnet
|
|
0:09:31
|
and the gatekeeper name or zone name.
|
|
0:09:34
|
So gatekeeper name SEA or zone name SEA.
|
|
0:09:38
|
And we're going to use the default to begin with, so all subnets or all
|
|
0:09:42
|
'other' subnets. 'Other' is a great keyword here.
|
|
0:09:45
|
Other than what we are about to later specify, so zone subnet
|
|
0:09:53
|
SEA default enable
|
|
0:09:56
|
and what we're actually going to say is no.
|
|
0:09:59
|
So here's what we're saying
|
|
0:10:02
|
and actually if I just go ahead and hit enter without the no
|
|
0:10:05
|
do sh run | s gatekeeper
|
|
0:10:11
|
Notice that that doesn't show up because that's the default.
|
|
0:10:15
|
Ok, so that is, the default is
|
|
0:10:18
|
by default enable all subnets within the zone SEA.
|
|
0:10:24
|
Allow all subnets or all hosts to register.
|
|
0:10:28
|
So if I issue that command again, but I jumped to the beginning of the line
|
|
0:10:32
|
and put the 'no' keyword in there
|
|
0:10:35
|
and hit enter, then do sh run | s gatekeeper
|
|
0:10:39
|
We see that actually show up
|
|
0:10:42
|
and we're saying, 'By default do not enable any subnets within the zone of Seattle.'
|
|
0:10:51
|
Now what this is going to do
|
|
0:10:55
|
do sh gatekeeper end points
|
|
0:10:58
|
is that at the next light-weight re-registration
|
|
0:11:02
|
we are actually -- in fact do debug ras
|
|
0:11:10
|
Now these gateways are already registered, so if we do a shut
|
|
0:11:15
|
and then a no shut
|
|
0:11:17
|
and we're sending unregistration messages to all the gatekeepers.
|
|
0:11:28
|
Ok, so we've no shut the gatekeeper.
|
|
0:11:31
|
It's back on.
|
|
0:11:35
|
Currently we have no end points.
|
|
0:11:37
|
And we're going to wait to see registration requests
|
|
0:11:43
|
come from these end points.
|
|
0:11:45
|
We could speed it up by going over here to Router 3
|
|
0:11:48
|
and say no gateway, gateway
|
|
0:11:54
|
And here we get
|
|
0:11:58
|
let's go back up
|
|
0:12:00
|
we get a gatekeeper request received
|
|
0:12:02
|
from .3
|
|
0:12:04
|
and we've sent a gateway rejection to .3
|
|
0:12:08
|
because we've said, 'No subnets are allowed.'
|
|
0:12:11
|
We also get one from .1 which is the CUBE here locally.
|
|
0:12:16
|
Ok, and we've said gatekeeper confirm.
|
|
0:12:19
|
We've allowed .1 to register.
|
|
0:12:22
|
We'll take a look at why in just a moment.
|
|
0:12:25
|
Ok, then we have -- actually allow just to see into
|
|
0:12:29
|
peer into our operations, then we get the registration request from .1
|
|
0:12:33
|
and we also send the registration confirm
|
|
0:12:37
|
and give some information.
|
|
0:12:40
|
Gatekeeper CUBE has registered with the gatekeeper.
|
|
0:12:44
|
So let's see what's next.
|
|
0:12:46
|
Here we go.
|
|
0:12:48
|
Gatekeeper request from .3 and a rejection.
|
|
0:12:51
|
And here is registration request from .20
|
|
0:12:57
|
and RRJ or Registration Rejection
|
|
0:13:00
|
same thing, registration request and
|
|
0:13:02
|
rejection from .10
|
|
0:13:05
|
So if we look at gatekeeper end points, we only got CUBE registered.
|
|
0:13:09
|
Now why did CUBE register?
|
|
0:13:11
|
Let's do undebug or do
|
|
0:13:14
|
undebug all
|
|
0:13:16
|
and let's do sh run | s gatekeeper
|
|
0:13:20
|
So why did CUBE register? Because we said, 'For the zone SEA
|
|
0:13:26
|
don't by default allow any subnets.'
|
|
0:13:30
|
But CUBE is registered in CUBE.
|
|
0:13:32
|
Why didn't CME register? Because we took it out of AMS
|
|
0:13:35
|
and we put it in SEA last.
|
|
0:13:37
|
So now what we can do is we can say zone subnet SEA
|
|
0:13:45
|
not default, but we're going to say specifically an IP network.
|
|
0:13:49
|
Let's say 177.1.10.0/24 enable
|
|
0:14:01
|
I think we have to do /24 as part of it, then enable
|
|
0:14:05
|
which is accept gatekeeper request and registration request from that subnet.
|
|
0:14:10
|
Ok, let's do debug ras
|
|
0:14:14
|
Let's look at our end points.
|
|
0:14:17
|
Actually let's look at our configuration.
|
|
0:14:20
|
So we've got the no subnet
|
|
0:14:23
|
whoops let me scroll back up
|
|
0:14:24
|
no subnet by default enable
|
|
0:14:29
|
I think I scrolled up too far there.
|
|
0:14:31
|
There we go.
|
|
0:14:32
|
No subnet by default enable, but do allow the subnet of
|
|
0:14:36
|
177.1.10.0/24 or 255.255.255.0
|
|
0:14:46
|
Notice we're still rejecting .3
|
|
0:14:49
|
but pretty soon... here we go.
|
|
0:14:52
|
No, are those them?
|
|
0:14:55
|
No that's the light-weight re-registration from the IP-to-IP gateway.
|
|
0:15:00
|
Let's look at the end points.
|
|
0:15:03
|
Ok, CUCM Pub and Sub still have not come back.
|
|
0:15:06
|
We could log in and force their hand real quick by doing a trunk.
|
|
0:15:14
|
Find
|
|
0:15:15
|
trunk called CUCM and let's just reset that real briefly.
|
|
0:15:25
|
And actually let's go reset the gatekeeper as well.
|
|
0:15:38
|
Here we go, we've got some 20 RCF registration confirm.
|
|
0:15:44
|
So let's look at our end points again.
|
|
0:15:47
|
And we've got the Pub and Sub registered.
|
|
0:15:51
|
CUBE is in a different zone, we do not have CME.
|
|
0:15:53
|
Let's do undebug all.
|
|
0:15:55
|
And now we're going to do
|
|
0:15:58
|
pretty much the same command.
|
|
0:15:59
|
For zone SEA let's do 177.1.254 let's just do the host of .3
|
|
0:16:07
|
so instead of /24 which wouldn't be a good subnet mask for .3
|
|
0:16:11
|
it would be a good subnet mask for .0
|
|
0:16:15
|
But let's do .3/32 so we're only going to allow or enable a particular host.
|
|
0:16:22
|
And we'll say no gateway.
|
|
0:16:26
|
And gateway.
|
|
0:16:27
|
And we're instantly going to see that it registered
|
|
0:16:32
|
back on the corporate headquarter gateway.
|
|
0:16:35
|
do sh gatekeeper end points
|
|
0:16:37
|
and we see that .3 registered.
|
|
0:16:40
|
And we could turn off for CUBE
|
|
0:16:43
|
the default certainly.
|
|
0:16:49
|
Let's do...
|
|
0:16:53
|
Let's do no zone subnet
|
|
0:16:57
|
CUBE enable
|
|
0:16:59
|
by default and then
|
|
0:17:03
|
whoops
|
|
0:17:08
|
Let's say zone subnet CUBE
|
|
0:17:12
|
I could have just typed it in. It would have been faster.
|
|
0:17:14
|
177.1.254.1/32 enable
|
|
0:17:21
|
So we could no shut
|
|
0:17:24
|
Actually sorry shut and then no shut
|
|
0:17:27
|
We will reset our gatekeeper over on CUCM.
|
|
0:17:36
|
And we will do a no gateway
|
|
0:17:38
|
gateway
|
|
0:17:40
|
here on corporate headquarter to force the CUBE.
|
|
0:17:43
|
And no gateway, gateway over on Branch 2
|
|
0:17:51
|
End out. Clear our buffer.
|
|
0:17:54
|
sh run | s gatekeeper let's just take a look at it.
|
|
0:18:00
|
Ok, so we've got the no zone subnet for SEA default.
|
|
0:18:03
|
And then the /32 host for CME
|
|
0:18:07
|
and the whole subnet for the corporate headquarter servers.
|
|
0:18:12
|
And then the no zone subnet for CUBE by default, but allow
|
|
0:18:15
|
the CUBE itself and if I do a sh gatekeeper end points
|
|
0:18:19
|
I should see that everything is correctly registered.
|
|
0:18:22
|
So there and I have my security.
|
|
0:18:28
|
Ok, so now let's get back to what we were doing.
|
|
0:18:30
|
Gatekeeper and zone remote
|
|
0:18:34
|
So what's the gatekeeper name?
|
|
0:18:37
|
What's the ID of the zone case sensitive?
|
|
0:18:40
|
Well, again this is something that if you had in the lab
|
|
0:18:43
|
they would have to give you something specific,
|
|
0:18:46
|
they'd have to tell you what the gatekeeper name was
|
|
0:18:51
|
or the zone name, so ours is going to be BB-GK
|
|
0:18:57
|
whoops sorry, of course that's not enough information
|
|
0:19:00
|
need to give it a domain name, let's say this is a remote zone called
|
|
0:19:04
|
itsp.com just generic.
|
|
0:19:10
|
Let's give it a RAS address.
|
|
0:19:12
|
Again the domain name is not too terribly important
|
|
0:19:14
|
or how we are using it.
|
|
0:19:17
|
The RAS address 177.1.254.254 again this would be something
|
|
0:19:23
|
they would have to inform you of.
|
|
0:19:30
|
And then that should be enough.
|
|
0:19:35
|
Well actually we should probably say it would be enough except
|
|
0:19:41
|
that we may want to invoke CUBE.
|
|
0:19:46
|
And in fact let's go ahead and do that.
|
|
0:19:49
|
Well you know what, let's set it up without CUBE and then
|
|
0:19:53
|
let's add in CUBE. Just like we did the others.
|
|
0:19:56
|
Shouldn't take that much more.
|
|
0:19:58
|
So we're going to go ahead and add that zone remote.
|
|
0:20:02
|
Ok, we've added the zone remote.
|
|
0:20:05
|
Remember we did say that we can only have one IP address per zone.
|
|
0:20:09
|
I'm sorry per gatekeeper for all the zones, but those are
|
|
0:20:12
|
only for local zones.
|
|
0:20:14
|
So in other words, if I went and added an IP address to AMS
|
|
0:20:17
|
if it was the same IP, it would simply add that IP to this line.
|
|
0:20:23
|
If it was a different IP, it would again add it to this line
|
|
0:20:26
|
it would take this away.
|
|
0:20:28
|
In fact, no matter what IP I gave it, if it was to any of the other zones
|
|
0:20:33
|
it would take away the IP off of this line. There can only be one IP address
|
|
0:20:37
|
per gatekeeper per for all of the local zones.
|
|
0:20:41
|
But I can have many remote zones and they each have
|
|
0:20:45
|
obviously a different IP because I'm defining a different remote gatekeeper.
|
|
0:20:48
|
Ok, so now we have to have either a zone prefix
|
|
0:20:56
|
as we saw with that slide
|
|
0:20:59
|
or -- let me just pop it back up here real quick.
|
|
0:21:03
|
We either have to have a zone prefix that is remote or
|
|
0:21:08
|
that maps to a remote zone
|
|
0:21:11
|
and that matches an actual prefix in the dnis
|
|
0:21:15
|
not including the tech prefix.
|
|
0:21:17
|
Or we have to have a tech prefix, but remember with tech prefixes
|
|
0:21:20
|
how did they match?
|
|
0:21:23
|
Tech prefixes if we remember
|
|
0:21:26
|
do sh gatekeeper gw type prefix
|
|
0:21:34
|
they matched based on dynamic registration.
|
|
0:21:38
|
So the zones -- I'm sorry the gateways dynamically registered
|
|
0:21:41
|
with the gatekeeper with their preferred tech prefix.
|
|
0:21:51
|
And in fact if you recall
|
|
0:21:53
|
the gatekeeper really had nothing to say
|
|
0:21:58
|
if take a look at the gatekeeper config
|
|
0:22:00
|
the gatekeeper really had nothing to say about the actual
|
|
0:22:03
|
tech prefix. It had to say about zone prefix,
|
|
0:22:06
|
but it had nothing to say about the tech prefix.
|
|
0:22:08
|
There was no configuration related to it in there, so
|
|
0:22:10
|
it was essentially allowing any gateway to register with
|
|
0:22:14
|
any tech prefix that it desired or chose to register with.
|
|
0:22:18
|
It just informed the gatekeeper of what it was.
|
|
0:22:22
|
However, we do have the idea or the ability
|
|
0:22:27
|
to have a tech prefix
|
|
0:22:32
|
whoops, sorry
|
|
0:22:36
|
So what we can say is GW I always type tech prefix, but
|
|
0:22:40
|
GW or gateway technology prefix.
|
|
0:22:44
|
I don't know why they don't say GW tech prefix
|
|
0:22:47
|
as opposed to GW type prefix, but
|
|
0:22:49
|
anyhow it's been that way for years.
|
|
0:22:51
|
So GW type prefix, this is how I can statically configure a tech prefix.
|
|
0:22:57
|
And I give it an E.164 prefix.
|
|
0:23:01
|
And it says that it may end in trailing dots.
|
|
0:23:04
|
So multiple, each defining a single digit.
|
|
0:23:08
|
And by the way, this does not -- this is important -- this does not
|
|
0:23:14
|
follow the convention of dial peers where if I have
|
|
0:23:20
|
destination pattern dot(.)
|
|
0:23:23
|
the more characters could be matched or incoming called number
|
|
0:23:27
|
dot(.) like one single dot or even if I had incoming called number
|
|
0:23:30
|
dot, dot (..) that doesn't only mean two digits or two characters
|
|
0:23:35
|
it could mean three or four or infinite
|
|
0:23:38
|
up to whatever the maximum string could be.
|
|
0:23:42
|
It would only be if I said incoming called number ..$
|
|
0:23:47
|
which is the regular expression for the end of the line
|
|
0:23:50
|
that it would only be able to have two characters or two digits.
|
|
0:23:56
|
With gatekeeper there is no regular expression in this statement
|
|
0:24:03
|
or zone prefix statements.
|
|
0:24:06
|
So if I say gateway type prefix 5.
|
|
0:24:12
|
whoops sorry
|
|
0:24:13
|
that means 5 and one additional character.
|
|
0:24:15
|
No more.
|
|
0:24:17
|
Now there could be more, but that's only what defines
|
|
0:24:19
|
the tech prefix, so there could be more digits to the dnis
|
|
0:24:22
|
it's just that that's all that defines the tech prefix.
|
|
0:24:26
|
However, typically we have something like 1# and remember
|
|
0:24:30
|
the gatekeeper added that asterisk which is the wildcard for any additional digits
|
|
0:24:35
|
and that is what we would typically want to do
|
|
0:24:37
|
unless we knew that we only wanted 1#....
|
|
0:24:42
|
so four exact digits.
|
|
0:24:47
|
Ok, so we can say GW type prefix
|
|
0:24:51
|
and note this says that it's an E.164 prefix.
|
|
0:24:56
|
Right
|
|
0:24:57
|
Well, wait a minute. If we go back to the slide
|
|
0:25:01
|
I thought that tech prefixes typically were used as
|
|
0:25:10
|
gateway specific or maybe even type of traffic
|
|
0:25:17
|
video or voice specific
|
|
0:25:20
|
and that they had a hash to separate them.
|
|
0:25:23
|
Well, first of all the hash is only used as a delineator.
|
|
0:25:30
|
Ok,
|
|
0:25:31
|
note that in digits that we can send
|
|
0:25:36
|
0, 1 so 0 through 9
|
|
0:25:41
|
we have additional digits on our keypad or we have additional
|
|
0:25:45
|
buttons which are asterisk and hash.
|
|
0:25:48
|
But those are just as they -- those are really just specific to
|
|
0:25:53
|
DTMF, Dual Tone Multi Frequency
|
|
0:25:56
|
and all they do is produce a frequency.
|
|
0:25:58
|
Here we're not defining frequency, we're defining actual digits in a string
|
|
0:26:03
|
and remember that the string
|
|
0:26:06
|
at least as far as the gatekeeper is concerned, an H.323 does not contain
|
|
0:26:10
|
asterisk or hash.
|
|
0:26:12
|
Asterisk is a wildcard as far as gatekeeper’s concerned
|
|
0:26:15
|
and hash is simply something that can be sent as a tech prefix
|
|
0:26:20
|
or at any point and is used typically as the delineator.
|
|
0:26:25
|
Ok,
|
|
0:26:29
|
So it's a little bit different than how we're used to inputting digits into CUCM.
|
|
0:26:34
|
But a tech prefix does not have to contain that hash as a delineator.
|
|
0:26:39
|
So we're used to putting in zone prefix as an E.164
|
|
0:26:43
|
part of the E.164 number.
|
|
0:26:44
|
In fact, we talked about having a tech prefix maybe
|
|
0:26:49
|
as 1# or even 521# whatever
|
|
0:26:56
|
and a zone prefix being the rest of the dnis, so maybe the entire
|
|
0:27:00
|
dnis as it came was 521#33155551212
|
|
0:27:21
|
for instance.
|
|
0:27:24
|
And we might say that 521 was the tech prefix
|
|
0:27:28
|
and 331 was the zone prefix.
|
|
0:27:36
|
But if you recall
|
|
0:27:39
|
and I don't know how to erase
|
|
0:27:44
|
all of this. If I do hidden that doesn't work.
|
|
0:27:48
|
So let me just jump back into that slide.
|
|
0:27:49
|
But if you'll recall, we certainly did have the ability
|
|
0:27:57
|
to let's say not have that 521
|
|
0:27:59
|
let's just say 33 for France
|
|
0:28:03
|
1 for Paris
|
|
0:28:05
|
55551212 as the Subscriber number.
|
|
0:28:13
|
We could make 33 the tech prefix
|
|
0:28:16
|
and we could make 1 the zone prefix.
|
|
0:28:22
|
Ok, there wouldn't be any problem with doing that.
|
|
0:28:25
|
We don't have to have a hash as the delineator
|
|
0:28:30
|
for the tech prefix.
|
|
0:28:32
|
So the only way that a tech prefix is going to get us over there
|
|
0:28:35
|
is if it is of the type hop-off.
|
|
0:28:38
|
Otherwise we can use a zone prefix.
|
|
0:28:41
|
So let's actually start.
|
|
0:28:44
|
Let me get back to that just in case I need to bring it up again.
|
|
0:28:48
|
Oh, did I delete it? Yep.
|
|
0:28:51
|
Ok, so do sh run | s gatekeeper
|
|
0:29:00
|
Alright, so let's do a zone prefix first.
|
|
0:29:05
|
And say zone prefix for BB-GK is 331 -- actually let's just say 33*
|
|
0:29:21
|
So what we have is a call's going to come in
|
|
0:29:24
|
is a tech prefix going to match? No because we don't have any
|
|
0:29:28
|
statically configured yet. We never went through with that command yet.
|
|
0:29:31
|
We will.
|
|
0:29:33
|
And there are no dynamically registered tech prefixes of 33
|
|
0:29:40
|
So does the zone prefix match? Well if the call is sent in with 33
|
|
0:29:45
|
as the beginning two digits of whatever length string, then
|
|
0:29:48
|
yes it will match and the remaining.
|
|
0:29:52
|
And then it will map to the zone BB-GK, will look up
|
|
0:29:55
|
is the zone BB-GK local?
|
|
0:29:58
|
Well no it's not. It's remote. So send an LRQ to this IP address.
|
|
0:30:02
|
It's really quite simple.
|
|
0:30:04
|
Backbone or remote gatekeeper is two commands.
|
|
0:30:08
|
Either zone prefix and zone remote or tech prefix with a hop-off type
|
|
0:30:13
|
and zone remote, so let's take a look at it.
|
|
0:30:16
|
Ok, so let's end out. Let's show our debugs.
|
|
0:30:20
|
We don't have any running. Good. Let's do debug gatekeeper
|
|
0:30:23
|
does everyone remember what it is? main 5
|
|
0:30:26
|
By the way, we also have calls 5
|
|
0:30:29
|
debug gatekeeper call 5
|
|
0:30:32
|
5 being the verbosity level.
|
|
0:30:35
|
In fact, let's just turn on call 5 as well so that you can see
|
|
0:30:39
|
what that looks like.
|
|
0:30:41
|
We'll go over to our CUCM.
|
|
0:30:43
|
We will go to our route patterns.
|
|
0:30:47
|
And we'll create a -- let's just copy this route pattern since
|
|
0:30:52
|
it already points to the right gateway.
|
|
0:30:55
|
Not that it's that hard to click a drop-down.
|
|
0:30:57
|
And we'll make a pattern. Now 33 is going to overlap with 3X
|
|
0:31:05
|
so we would have to take off urgent priority on the 3X
|
|
0:31:08
|
Ok, and remember in 7.01
|
|
0:31:13
|
there certainly is and can be an issue with when we're routing
|
|
0:31:18
|
a route pattern or pointing a route pattern directly to a gateway.
|
|
0:31:23
|
There's an issue with the interdigit timeout.
|
|
0:31:27
|
So either we need to lower that interdigit timeout which is
|
|
0:31:30
|
the T302 timer in service parameters
|
|
0:31:36
|
just open that up real quick.
|
|
0:31:47
|
And we've actually got two T302 timers, one for device general
|
|
0:31:51
|
which is the one that we want, it's the first one we'll come to
|
|
0:31:53
|
and then there's a second one which is H.323 T302 timers
|
|
0:31:58
|
so by default 15000 milliseconds or 15 seconds we could certainly lower that.
|
|
0:32:05
|
Let's lower it to maybe 8
|
|
0:32:13
|
not that we're going to keep this configuration around for long
|
|
0:32:16
|
as soon as we are done with gatekeeper we're going to
|
|
0:32:20
|
really not be using this 3XXX pattern because our 3000 series
|
|
0:32:26
|
numbers will be registered to CUCM and we'll place them back in the internal DN's partition.
|
|
0:32:35
|
But for right now, let's go ahead and copy this.
|
|
0:32:40
|
Actually sorry.
|
|
0:32:42
|
Let's go back to our 3XXX untick the urgent priority
|
|
0:32:47
|
click save
|
|
0:32:49
|
so we don't forget, and then we'll copy it.
|
|
0:32:53
|
And we'll say 33, let's say the route pattern is 331
|
|
0:32:59
|
actually let's just say 33 for the whole country and
|
|
0:33:04
|
bang for exclamation or exclamation I call it bang
|
|
0:33:09
|
for any additional digits
|
|
0:33:12
|
and these are digits 0 through 9
|
|
0:33:15
|
if take a look in help for this page, we see that an exclamation cannot
|
|
0:33:19
|
match asterisk or hash.
|
|
0:33:25
|
Somebody was trying to get into the room there.
|
|
0:33:28
|
Welcome.
|
|
0:33:31
|
And we're actually going to use the octothorpe or hash
|
|
0:33:35
|
as a trailing pattern.
|
|
0:33:41
|
So we will do let's say -- you know we certainly could do 9. or 0.
|
|
0:33:51
|
as a way to strip off that call, so let's just do called party transformation
|
|
0:34:03
|
PreDot Trailing#
|
|
0:34:06
|
and we're not going to output 2# as a prefix
|
|
0:34:09
|
or anything like that yet.
|
|
0:34:12
|
We will say urgent priority because once we've matched that hash
|
|
0:34:16
|
which the discard digits will strip off that trailing hash
|
|
0:34:21
|
but once we've matched that, regardless of the additional digits
|
|
0:34:26
|
because that exclamation does not match asterisk and hash
|
|
0:34:29
|
it will take any additional regular digits 0 through 9
|
|
0:34:32
|
then once we press the hash it will match urgent priority
|
|
0:34:36
|
and go ahead and send out right away.
|
|
0:34:42
|
Ok, so let's go ahead
|
|
0:34:47
|
and bring up our Variphy remote phones
|
|
0:34:59
|
and let's just bring our corporate headquarter phone 1 for right now.
|
|
0:35:07
|
You know what, that's a little busy. Let's bring up corporate headquarter phone 2
|
|
0:35:14
|
Ok, so let's go ahead and issue the number 33
|
|
0:35:20
|
Let's make sure our debug is running. It is.
|
|
0:35:23
|
Let's go clear off our screen.
|
|
0:35:25
|
331 and 55551212 was the example we gave.
|
|
0:35:36
|
whoops sorry
|
|
0:35:37
|
wrong phone
|
|
0:35:44
|
Ok, so we got a annunciator message saying that we couldn't
|
|
0:35:50
|
send the call. Oh! and that's because we didn't add the hash at the end.
|
|
0:35:55
|
So let's try it again.
|
|
0:35:57
|
Let's clear off our screen here our corporate headquarter.
|
|
0:36:08
|
Ok, and again it was because I didn't hit the 9 in there.
|
|
0:36:12
|
One of these days I'll actually dial the number right.
|
|
0:36:16
|
Let's see... somebody
|
|
0:36:19
|
ok, somebody asked a question
|
|
0:36:22
|
that they didn't quite understand the dial pattern with 33
|
|
0:36:28
|
exclamation or bang and then hash and then urgent priority
|
|
0:36:34
|
they said they thought it would route the call right away as soon as
|
|
0:36:36
|
the hash is pressed even if we did not have urgent priority.
|
|
0:36:39
|
"Is that correct?"
|
|
0:36:41
|
Well, in the case that there is no overlapping statements
|
|
0:36:45
|
then yes, it would be correct because
|
|
0:36:49
|
so going back to this dial or route pattern
|
|
0:36:56
|
even if we didn't have urgent priority, it would be dialed immediately
|
|
0:37:00
|
mainly because we don't have anything else that overlaps with that.
|
|
0:37:07
|
Once we got a more complex dial plan, the possibility would be there for overlap
|
|
0:37:11
|
but you're right, we probably don't have to press urgent priority.
|
|
0:37:14
|
I'll take it off.
|
|
0:37:16
|
Actually the reason I'm doing it is because we're pointing directly
|
|
0:37:19
|
to a gateway.
|
|
0:37:21
|
When we go and point route patterns through route lists
|
|
0:37:25
|
and route groups in CUCM 7.0
|
|
0:37:29
|
which is I don't know anyone running 7.0 or really any .0
|
|
0:37:34
|
in production environments.
|
|
0:37:38
|
This isn't actually -- I believe that was a fixed caveat
|
|
0:37:42
|
a resolved caveat, but when we're pointing directly to a gateway
|
|
0:37:45
|
we've got a little bit of an issue with urgent priority
|
|
0:37:48
|
or with interdigit timeout.
|
|
0:37:50
|
In fact, even if I had something like 911 or 112 which don't have
|
|
0:37:56
|
any overlaps, at least 911 doesn't
|
|
0:38:00
|
112 possibly could in the 1000 series numbers
|
|
0:38:04
|
although there aren't any other
|
|
0:38:07
|
digits in our route pattern or in our route plan
|
|
0:38:11
|
in CUCM currently that have 1 as a second digit
|
|
0:38:14
|
we still have an issue that it doesn't want to send to the gateway
|
|
0:38:16
|
unless we have urgent priority, so that's the reason I checked
|
|
0:38:19
|
urgent priority for right now is because I'm pointing directly to the gateway.
|
|
0:38:24
|
Ok,
|
|
0:38:26
|
so 933155551212 let's clear off our gatekeeper timers
|
|
0:38:35
|
and the debug again and press dial.
|
|
0:38:41
|
whoops
|
|
0:38:44
|
Ok, so we still got the same annunciator message
|
|
0:38:47
|
let me do undebug all.
|
|
0:38:49
|
But now we actually got what I wanted which was
|
|
0:38:52
|
the call coming through, so first of all we get an ARQ
|
|
0:38:55
|
is it an answer ARQ? No.
|
|
0:38:57
|
Ok, so let's take a look.
|
|
0:39:00
|
And we see the number come through. Remember we stripped
|
|
0:39:04
|
the 9, we did a 9. and we stripped predot
|
|
0:39:08
|
and we stripped the trailing hash
|
|
0:39:10
|
so 3315555 or quad 5 1212 is what came through.
|
|
0:39:19
|
Tech prefix match failed because we have no tech prefixes.
|
|
0:39:22
|
sh gatekeeper gw type prefix | 33
|
|
0:39:28
|
whoops
|
|
0:39:29
|
| in 33, there's none
|
|
0:39:32
|
whereas if we did | in 1#
|
|
0:39:36
|
actually we don't have any there, but we do have 2#
|
|
0:39:40
|
Alright, so we didn't have any tech prefix that matched 33
|
|
0:39:46
|
We matched a zone prefix 33 and the remainder 1 double 5, double 5 1212
|
|
0:39:54
|
So we're about to check the source. It came in from the zone Seattle.
|
|
0:39:57
|
About to check the destination.
|
|
0:39:59
|
Zone matched was BB-GK.
|
|
0:40:04
|
Ok, we're saying that this is a put this as a remote zone
|
|
0:40:08
|
from the zone list.
|
|
0:40:12
|
We have no out via name length.
|
|
0:40:15
|
That's zero.
|
|
0:40:17
|
By the way, you don't really have to worry about proxies.
|
|
0:40:21
|
There were such a thing
|
|
0:40:24
|
once upon a time called H.323 proxies.
|
|
0:40:27
|
Those are different than border elements.
|
|
0:40:31
|
They did a little bit of what border element did
|
|
0:40:35
|
in proxying a call through another entity
|
|
0:40:38
|
but they were far, far, far less robust, so
|
|
0:40:42
|
Cisco doesn't use any of the industry standard H.323 proxies anymore
|
|
0:40:47
|
in lieu of the much, much more capable border element
|
|
0:40:51
|
or IP-to-IP gateway.
|
|
0:40:56
|
By the way, notice that so some of this is the result of the
|
|
0:41:02
|
debug gatekeeper main 5, but some of it is the result of the debug
|
|
0:41:07
|
gatekeeper call 5, so one of the things that we get with a debug
|
|
0:41:11
|
gatekeeper call is BW, bandwidth.
|
|
0:41:16
|
Ok, which can be really nice.
|
|
0:41:22
|
Ok, so the zone local SEA, the remote zone BB-GK
|
|
0:41:27
|
Call direction is 1
|
|
0:41:30
|
so it's in an outbound
|
|
0:41:31
|
and note what we have let's see, proxy's returned 0
|
|
0:41:37
|
These are actually part of the debug call.
|
|
0:41:40
|
Let's actually just do
|
|
0:41:43
|
debug gatekeeper main 5 and I'm going to hit redial.
|
|
0:41:48
|
And hang up.
|
|
0:41:51
|
And do undebug all.
|
|
0:41:54
|
And note that right before I got these timer events, I turned off and
|
|
0:41:59
|
all we see is tech prefix match failed
|
|
0:42:03
|
matched zone, it sent the call, that's all we heard.
|
|
0:42:07
|
We didn't hear anything else.
|
|
0:42:09
|
Ok, well let's do a debug ras and let's see what we see.
|
|
0:42:14
|
I'm going to hit redial.
|
|
0:42:20
|
Undebug all.
|
|
0:42:23
|
So let's see what we have here.
|
|
0:42:29
|
We received a message from .20
|
|
0:42:31
|
which was an ARQ
|
|
0:42:36
|
Ok, then we sent a message
|
|
0:42:41
|
from ourselves, .1
|
|
0:42:44
|
1719, port 1719 which is RAS
|
|
0:42:47
|
to 177.1.254.254 which is the PSTN
|
|
0:42:52
|
as an LRQ, a location request.
|
|
0:42:55
|
And at the same time, we sent a message from us back to the Subscriber
|
|
0:42:59
|
saying request is in progress. Just wait a second, we'll talk to you.
|
|
0:43:05
|
Ok, so then we received a message of the length, the 111 characters
|
|
0:43:11
|
from the PSTN saying location confirm.
|
|
0:43:17
|
So we got a confirmation saying, 'Yeah, we've essentially got that number
|
|
0:43:24
|
here's the IP address to contact.
|
|
0:43:26
|
So what do we send back from us, the gatekeeper .1
|
|
0:43:31
|
to the Subscriber .10.20
|
|
0:43:36
|
we send back an admission confirm to the Subscriber.
|
|
0:43:43
|
Ok, and then we successfully received a message from the
|
|
0:43:46
|
Subscriber saying DRQ, disengage request.
|
|
0:43:51
|
So the gatekeeper routed everything properly.
|
|
0:43:54
|
Now remember we're never going to see an answer ARQ on this gatekeeper
|
|
0:43:59
|
if you recall, let me just bring up that slide again real briefly.
|
|
0:44:06
|
Ok, we're going to place an ARQ
|
|
0:44:08
|
It's going to look up, it's going to find the remote zone
|
|
0:44:10
|
it's going to send an LRQ to the PSTN backbone gatekeeper
|
|
0:44:14
|
send a request in progress back to us
|
|
0:44:17
|
the PSTN will do a lookup, it finds the gateway
|
|
0:44:21
|
sends an LCF back to us, location confirm
|
|
0:44:24
|
we send an ACF back to the Subscriber, we saw that happen.
|
|
0:44:29
|
And then we try to do a call setup.
|
|
0:44:31
|
All of that happened and that's all that we know about from
|
|
0:44:34
|
the gatekeeper except that the gatekeeper also then
|
|
0:44:38
|
saw the Subscriber send a DRQ, a disengage request.
|
|
0:44:42
|
Now we don't see what happens over here on the PSTN side.
|
|
0:44:47
|
On the PSTN side, once we've set the call setup
|
|
0:44:50
|
if there was indeed a call to be able to be setup
|
|
0:44:54
|
if there was a routable number over there on that IOS gateway
|
|
0:44:58
|
which is the PSTN router, it would have sent up
|
|
0:45:01
|
its own answer ARQ, but we can't see that because it doesn't
|
|
0:45:04
|
come to the physical Router 1 gatekeeper
|
|
0:45:09
|
it goes to the physical PSTN gatekeeper, the backbone.
|
|
0:45:15
|
And if it had sent up an answer ARQ, then the PSTN
|
|
0:45:19
|
would have answered with an ACF and it would have responded
|
|
0:45:22
|
with the call setup and then we would have tried to negotiate
|
|
0:45:26
|
and so we really don't know if any of that happened.
|
|
0:45:29
|
If what we got back for an H.225 call setup response.
|
|
0:45:36
|
But we do know that the Subscriber sent a DRQ,
|
|
0:45:40
|
a disengage request up to the gatekeeper.
|
|
0:45:44
|
Ok because we saw that... where's my mouse?
|
|
0:45:47
|
We saw that here, disengage received from the Subscriber
|
|
0:45:52
|
and then the message length which is only three characters
|
|
0:45:57
|
which is a DCF confirm from us to the Subscriber saying,
|
|
0:46:01
|
'Ok, confirmed. I've torn down the call.'
|
|
0:46:03
|
And then we saw registration request which is just incidental.
|
|
0:46:07
|
Ok, so we don't know why the call didn't work.
|
|
0:46:11
|
We can go dig in the traces
|
|
0:46:14
|
of CUCM and that's entirely possible we could find something there.
|
|
0:46:20
|
You know what, let's try it with a tech prefix. Let's see if we can get
|
|
0:46:23
|
it to route with a tech prefix.
|
|
0:46:25
|
So let's do sh run | s gatekeeper
|
|
0:46:30
|
and let's do config t
|
|
0:46:33
|
and let's actually get rid of the zone prefix 33
|
|
0:46:40
|
gatekeeper no zone prefix 33
|
|
0:46:44
|
So do sh run | s gatekeeper just to confirm that it's gone.
|
|
0:46:49
|
Yep, it's gone. There's only three zone prefixes and those are all local.
|
|
0:46:53
|
whereas as we did have the fourth in there.
|
|
0:46:55
|
Let's try that call again.
|
|
0:46:58
|
do debug gatekeeper main 5
|
|
0:47:02
|
Let's try the call again, let's hit redial.
|
|
0:47:07
|
And do undebug all.
|
|
0:47:09
|
Let's scroll up.
|
|
0:47:10
|
Now the tech prefix match failed and it matched the zone prefix of 3
|
|
0:47:18
|
because 33 was there, but we're only matching the zone prefix
|
|
0:47:23
|
of 3 whereas previously we had been matching the zone prefix of 33
|
|
0:47:28
|
so what zone prefix was it matching? Let me scroll to our configuration.
|
|
0:47:32
|
It's now matching SEA 3*
|
|
0:47:35
|
whereas there was a more specific 33* earlier.
|
|
0:47:40
|
Ok, so the source came in from SEA
|
|
0:47:45
|
and the destination went out to SEA as well.
|
|
0:47:51
|
Ok, so the source zone was SEA over here
|
|
0:47:54
|
destination was SEA, it's trying to select an IP-to-IP gateway.
|
|
0:47:58
|
It did and it's getting an answer call, but that's because
|
|
0:48:04
|
it's selecting the gateway of CME
|
|
0:48:09
|
and it probably sent the call in over here to CME
|
|
0:48:12
|
if we did a debug voip dial peer
|
|
0:48:16
|
and hit redial again.
|
|
0:48:22
|
Let's see...
|
|
0:48:28
|
3 it should have -- let's just do a debug ras and see who actually answered that call.
|
|
0:48:34
|
do debug ras
|
|
0:48:40
|
undebug all
|
|
0:48:45
|
and...
|
|
0:48:52
|
and let's see...
|
|
0:48:55
|
the ARQ, this is for the CUBE
|
|
0:49:01
|
the disengage request
|
|
0:49:05
|
for the CUBE and a disengage request for the Subscriber.
|
|
0:49:10
|
Oh, that was the original disengage request.
|
|
0:49:12
|
Oh! So what happened was it invoked the CUBE, but the CUBE
|
|
0:49:15
|
has nothing. If we look at the dial peers here
|
|
0:49:18
|
do sh | s voice
|
|
0:49:24
|
The dial peers we've got and by the way, I rearranged these dial peers
|
|
0:49:29
|
from yesterday so that we can continue using this corporate
|
|
0:49:34
|
headquarter gateway as our SIP gateway when it comes to
|
|
0:49:37
|
the added descriptions as well to the PSTN, so I took 100 and 101
|
|
0:49:42
|
our SIP dial peers for PSTN PRI gateway services
|
|
0:49:47
|
and then 200 and 201, our CUBE gatekeeper dial peers.
|
|
0:49:52
|
So the call came in. We didn't have a destination pattern
|
|
0:49:55
|
that matched 3 anything, so it never even went beyond the CUBE.
|
|
0:50:00
|
We could just take that -- let's see
|
|
0:50:03
|
gatekeeper
|
|
0:50:09
|
We could just take this statement out altogether, no zone prefix 3*
|
|
0:50:13
|
and then it wouldn't match a tech prefix or a zone prefix.
|
|
0:50:16
|
So let's try putting in a gw type prefix
|
|
0:50:21
|
for 33*, so we're going to use 33 as the tech prefix and we're
|
|
0:50:28
|
going to make it of the type hop-off.
|
|
0:50:31
|
So this always hops off at the specified zone.
|
|
0:50:34
|
And the gatekeeper name or zone name is BB-GK
|
|
0:50:40
|
and let's just do that.
|
|
0:50:46
|
Ok, so now we have our hop-off tech prefix.
|
|
0:50:50
|
And let's go ahead and add the zone prefix of 1*
|
|
0:50:56
|
and we'll make that
|
|
0:51:00
|
whoops sorry
|
|
0:51:01
|
It needs the zone name or gatekeeper name first, so
|
|
0:51:03
|
BB-GK and then 1*
|
|
0:51:12
|
So remember the tech prefix should match 33 and the remainder.
|
|
0:51:16
|
And then the zone prefix will match 1*
|
|
0:51:22
|
Ok,
|
|
0:51:24
|
let's see if that will work.
|
|
0:51:26
|
Ok do debug gatekeeper main 5
|
|
0:51:29
|
and let's hit redial.
|
|
0:51:35
|
Ok, do undebug all
|
|
0:51:41
|
Ok, matched the tech prefix 33
|
|
0:51:44
|
notice we don't even go into a zone prefix check
|
|
0:51:47
|
so at this point, this becomes completely irrelevant
|
|
0:51:51
|
because with the hop-off tech prefix, we don't even check
|
|
0:51:55
|
for a zone prefix anymore.
|
|
0:51:58
|
We've already matched a tech prefix to a zone
|
|
0:52:01
|
and that's the whole purpose of a zone prefix, so we don't need to.
|
|
0:52:04
|
So we matched the tech prefix about to check the source
|
|
0:52:08
|
is Seattle
|
|
0:52:09
|
about to check the destination is BB-GK
|
|
0:52:13
|
We found the zone list.
|
|
0:52:16
|
If we looked at a debug ras, we'd see the same thing
|
|
0:52:20
|
it went out as an LRQ, so first we looked at using a zone prefix
|
|
0:52:23
|
only to send that LRQ, now we've looked at using a
|
|
0:52:31
|
a hop-off tech prefix
|
|
0:52:33
|
statically defined hop-off tech prefix to match a number
|
|
0:52:37
|
and send it off to remote zone and send and LRQ,
|
|
0:52:41
|
but we still don't know why the call has failed.
|
|
0:52:45
|
All we saw earlier with the debug ras was a disengage request
|
|
0:52:49
|
from the originating gateway, the CUCM.
|
|
0:52:53
|
Ok, so
|
|
0:52:54
|
we're going to leave that config
|
|
0:52:57
|
sh deb, I don't think we have anything on, let's clear off our screen.
|
|
0:52:59
|
Let's go ahead and write our router config actually.
|
|
0:53:03
|
And let's now do a debug H.225 events
|
|
0:53:08
|
Let's see what happens here.
|
|
0:53:11
|
So we are going to see some events for registration, hopefully
|
|
0:53:14
|
we can do this quick enough. Let me just hit undebug all
|
|
0:53:18
|
and then turn it back on so that I've got it ready and
|
|
0:53:20
|
I'm going to hit redial.
|
|
0:53:27
|
And note here
|
|
0:53:31
|
very easily call disconnect for the reason unassigned number.
|
|
0:53:36
|
So the backbone and I'll just go ahead and show you the PSTN
|
|
0:53:53
|
And I actually don't even have the proper name setup for
|
|
0:53:58
|
for the zone that it's coming in from.
|
|
0:54:01
|
I could change that.
|
|
0:54:03
|
But it shouldn't make much of a difference.
|
|
0:54:12
|
Let's just go ahead and change that real quick.
|
|
0:54:32
|
and I named that...
|
|
0:54:36
|
that actually shouldn't matter.
|
|
0:54:38
|
I've got an active registration in there.
|
|
0:54:40
|
The domain name shouldn't matter.
|
|
0:54:42
|
whoops
|
|
0:54:50
|
Ok, and I also have do sh run int loopback 0
|
|
0:54:56
|
actually sorry
|
|
0:54:58
|
do sh run int loopback 0
|
|
0:55:02
|
so I've got this gateway, not necessarily CUBE, but a gateway registered with
|
|
0:55:09
|
may or may not be registered with the gatekeeper here.
|
|
0:55:20
|
And I actually have a tech prefix 33
|
|
0:55:25
|
That's fine, it would match the tech prefix, but it wouldn't match the zone prefix.
|
|
0:55:30
|
Let's go ahead and get rid of this zone prefix config.
|
|
0:55:44
|
Ok, so now I've only got the zone local and remote.
|
|
0:55:48
|
The gateway, the PSTN is registered with a tech prefix, so
|
|
0:55:52
|
do sh gatekeeper end points
|
|
0:55:56
|
We see the gateway registered.
|
|
0:55:58
|
By the way, we see the PSTN numbers
|
|
0:56:01
|
because I'm running CME here.
|
|
0:56:02
|
We don't see any numbers that begin with 33, we see numbers
|
|
0:56:05
|
begin with 31
|
|
0:56:07
|
and if I do sh gatekeeper gw type prefix
|
|
0:56:13
|
I see a gateway that's registered with 33, so that should route the call.
|
|
0:56:19
|
Let's just go ahead and do -- again this is not something
|
|
0:56:22
|
you would see in the real lab, but let's just do
|
|
0:56:24
|
debug gatekeeper main 5
|
|
0:56:29
|
over here.
|
|
0:56:32
|
And let's turn that back on over here. Let's run the call.
|
|
0:56:40
|
Ok, we still have disconnect is for an unassigned number over here.
|
|
0:56:45
|
And the PSTN
|
|
0:56:50
|
has matched the tech prefix, zone prefix match failed
|
|
0:56:54
|
so that just means it's going to use the...
|
|
0:57:05
|
What am I trying to say? It's going to use the
|
|
0:57:07
|
target or destination zone as the source zone.
|
|
0:57:10
|
So checking the source side
|
|
0:57:14
|
of the LRQ, the location request.
|
|
0:57:17
|
The source side is matched zone SEA which was a remote zone.
|
|
0:57:23
|
And there's no in via.
|
|
0:57:25
|
Checking the destination side
|
|
0:57:29
|
is BB-GK
|
|
0:57:31
|
Ok, and we did get an answer call equals 1, so the gateway
|
|
0:57:35
|
answered and said or asked for an answer admission request
|
|
0:57:42
|
said, 'Am I allowed to answer the call?'
|
|
0:57:44
|
And if we would have done a debug ras, we would have seen
|
|
0:57:47
|
on this backbone PSTN gatekeeper we would have seen the
|
|
0:57:54
|
the gateway essentially tried to ask to answer the call
|
|
0:58:00
|
and then also place a disengage request.
|
|
0:58:04
|
Why? Well we saw the answer right here when we looked at the
|
|
0:58:08
|
E.164 number assignment.
|
|
0:58:10
|
There simply are no numbers registered that begin in 33
|
|
0:58:17
|
and even if the numbers weren't registered in 33
|
|
0:58:20
|
the tech prefix should be enough to match the gateway,
|
|
0:58:23
|
but even if the gateway doesn't have the
|
|
0:58:25
|
numbers, the E.164 aliases registered
|
|
0:58:29
|
it still actually has to have somewhere in its dial plan
|
|
0:58:32
|
something related to 33, so something like a...
|
|
0:58:38
|
Let's just write this router config show
|
|
0:58:45
|
this is a slower router show
|
|
0:58:47
|
dial peer voice sum
|
|
0:58:51
|
and actually let me rerun that command | in 33
|
|
0:58:57
|
And we see some things that include 33, but nothing that
|
|
0:59:01
|
includes the beginning of the string
|
|
0:59:05
|
being 33, we have 31, +31, 31
|
|
0:59:09
|
We've got some 33 information, but that comes later in the string.
|
|
0:59:13
|
So nothing that begins with 33
|
|
0:59:16
|
So again the debug h225 events
|
|
0:59:21
|
is a great piece of configuration.
|
|
0:59:27
|
And it's what allow us to see used in the billing information actually
|
|
0:59:32
|
the clear ASCII text of the call disconnect reason unassigned number.
|
|
0:59:38
|
Ok, let's do one last thing with gatekeeper.
|
|
0:59:41
|
And that is sh run | s gatekeeper
|
|
0:59:49
|
Actually let's go over to the PSTN and do a debug h225 asn1
|
|
0:59:57
|
and let's try that call again. I'm just going to hit redial over here.
|
|
1:00:04
|
And let's do an undebug all.
|
|
1:00:07
|
And scroll all the way up to the top.
|
|
1:00:09
|
And we're going to see first of all a location request,
|
|
1:00:12
|
so we see RAS incoming.
|
|
1:00:15
|
And we've got the dial digits information.
|
|
1:00:20
|
The IP address in hex which is nice.
|
|
1:00:23
|
Port number in regular decimal. Why they do IP in hex, but port
|
|
1:00:27
|
in decimal. I don't know why the ITUT chose to do that.
|
|
1:00:32
|
From the source zone SEA.
|
|
1:00:35
|
Ok, then we have the H.225 nonstandard incoming PDU
|
|
1:00:43
|
So,
|
|
1:00:47
|
actually this is still with gatekeeper related information.
|
|
1:00:52
|
Gateway source information. 1002 is the phone it came from.
|
|
1:00:57
|
LCF what we're essentially saying is that backbone gateway is there
|
|
1:01:03
|
and there is an E.164 number that happens to be associated
|
|
1:01:06
|
with backbone gateway. It's the first one, it's not necessarily -- actually
|
|
1:01:11
|
we're sending that information even though it's not necessarily the
|
|
1:01:16
|
phone number that was requested.
|
|
1:01:18
|
So RAS outgoing, we're sending a location confirm.
|
|
1:01:24
|
Ok,
|
|
1:01:26
|
and here is an H.225 call setup
|
|
1:01:32
|
the dialed digits from the source address, so they're not really
|
|
1:01:35
|
dialed digits, this is the 'calling' number
|
|
1:01:37
|
is 1002
|
|
1:01:41
|
The dialed digits, the destination address is 33155551212, so
|
|
1:01:48
|
this coming from -- who is it coming from?
|
|
1:01:53
|
Let's see...
|
|
1:01:53
|
It's coming from...
|
|
1:01:58
|
if I can find the IP address here
|
|
1:02:02
|
here we go. IP address, so we can use Calculator.
|
|
1:02:12
|
And in the lab you have scientific Windows Calculator.
|
|
1:02:17
|
It's not quite as cool as this
|
|
1:02:19
|
Mac calculator that actually gives you binary and hex
|
|
1:02:24
|
but at least not the bits, but we'll do hexadecimal obviously.
|
|
1:02:29
|
So if we put in B1
|
|
1:02:34
|
and we go over to binary
|
|
1:02:36
|
we get 177
|
|
1:02:38
|
Ok, if we put in 01
|
|
1:02:43
|
Well that's easy to read in just about any language, that's .1
|
|
1:02:47
|
so this is 177.1. 0A
|
|
1:02:55
|
which is 10. and then 14 in hex is 20
|
|
1:03:01
|
So 177.1.10.20
|
|
1:03:04
|
So we see from the IP address that the -- and from the debug h225
|
|
1:03:10
|
that the call came in from the CUCM.
|
|
1:03:13
|
Ok, no problem let's clear this off.
|
|
1:03:17
|
Again, you're not going to have access to the PSTN in the real lab.
|
|
1:03:22
|
I'm just trying to prove the point.
|
|
1:03:24
|
So let's go to config t and gatekeeper.
|
|
1:03:27
|
And we're going to add to the zone remote
|
|
1:03:33
|
we're going to add an out via CUBE.
|
|
1:03:37
|
So now when you go out through that remote zone
|
|
1:03:44
|
go out via CUBE. Now we’re going to have to have a dial peer that would support that.
|
|
1:03:48
|
So do sh | s voice 2 something
|
|
1:03:56
|
So we've got our incoming dial peer will accept any number.
|
|
1:03:59
|
We're going to need one for outgoing.
|
|
1:04:01
|
So let's create a dial peer 202 voip
|
|
1:04:07
|
And we'll just say our outbound calls to our backbone gatekeeper.
|
|
1:04:18
|
And we'll say the -- session target RAS and QoS are the same.
|
|
1:04:23
|
But the destination pattern is going to be 331.T
|
|
1:04:37
|
Ok, so now let's do a -- let's clear this off
|
|
1:04:42
|
sh deb, debug gatekeeper main 10
|
|
1:04:50
|
and let's also debug h225 asn1 over here
|
|
1:04:54
|
do a redial
|
|
1:04:58
|
undebug all
|
|
1:05:01
|
undebug all
|
|
1:05:03
|
So we're on Router 1
|
|
1:05:05
|
We see that the call came in.
|
|
1:05:07
|
Matched the tech prefix.
|
|
1:05:12
|
The source zone is SEA. The destination zone is BB-GK
|
|
1:05:16
|
There's an out via zone which is CUBE.
|
|
1:05:19
|
Ok, selecting an IP-to-IP gateway.
|
|
1:05:22
|
Let's scroll down.
|
|
1:05:24
|
Found an IP-to-IP gateway, selected it.
|
|
1:05:29
|
And we got an answer call equals 1 that's from CUBE.
|
|
1:05:33
|
Then CUBE, so that was the inbound
|
|
1:05:35
|
dial peer asking if it could answer the call.
|
|
1:05:38
|
Then the outbound dial peer if it could send the call.
|
|
1:05:44
|
And so we're invoking CUBE.
|
|
1:05:46
|
Again we matched the tech prefix.
|
|
1:05:49
|
It's an ARQ nonstandard ingress network, so this is coming from CUBE.
|
|
1:05:55
|
About to check the destination is BB-GK
|
|
1:05:58
|
Out via, so received an ARQ for a zone that has an out via zone CUBE
|
|
1:06:03
|
but I am that via zone, so continue normal processing.
|
|
1:06:06
|
Put it in the remote zone
|
|
1:06:09
|
which is to send the LRQ.
|
|
1:06:12
|
We don't see any more information.
|
|
1:06:16
|
And if we look over here at the PSTN, yes we're going to have the RAS
|
|
1:06:21
|
The RAS LCF
|
|
1:06:24
|
Keep scrolling down, that's still RAS
|
|
1:06:26
|
Here's the H.225 information. We come from CUBE.
|
|
1:06:33
|
And if we scroll down
|
|
1:06:38
|
Did we prefix digits to that?
|
|
1:06:41
|
I don't think that had a tech prefix, did it?
|
|
1:06:43
|
sh run | s voice 20
|
|
1:06:52
|
No I didn't have a tech prefix in that.
|
|
1:06:53
|
Whoops
|
|
1:06:55
|
Ok,
|
|
1:07:01
|
Oh, I see. The CUBE itself actually had the 2# as its tech prefix.
|
|
1:07:07
|
That's not coming as part of the destination dialed digits.
|
|
1:07:11
|
That still begins with 33, it's just that it's reporting that that
|
|
1:07:15
|
CUBE gateway or IP-to-IP gateway
|
|
1:07:19
|
registered originally. It supports those prefixes, it registered with 2#
|
|
1:07:24
|
Anyhow,
|
|
1:07:26
|
so moving on down here's our IP address.
|
|
1:07:30
|
So we see B1
|
|
1:07:33
|
whoops
|
|
1:07:34
|
hex B1
|
|
1:07:37
|
is still going to be 177.1.FE.01
|
|
1:07:43
|
So FE is 254
|
|
1:07:47
|
and 01 is 1, so
|
|
1:07:50
|
177.1.254.1
|
|
1:07:57
|
So now we see the call actually coming from the CUBE.
|
|
1:08:00
|
That worked properly.
|
|
1:08:02
|
Let's go ahead and exit out of the PSTN and again
|
|
1:08:05
|
we'll clear off our screen, sh deb
|
|
1:08:08
|
debug h225 events
|
|
1:08:18
|
h225, not just 225
|
|
1:08:21
|
and redial again.
|
|
1:08:25
|
And even with CUBE we see a lot more information this time.
|
|
1:08:27
|
In fact, let me just undebug all real quick.
|
|
1:08:31
|
And this is because we're now -- this is actually all the information
|
|
1:08:37
|
from the gateway, the CUCM talking to us which because
|
|
1:08:44
|
our router is also the CUBE gateway.
|
|
1:08:46
|
So that's why we're seeing a lot of additional information.
|
|
1:08:50
|
But when it comes down to it at the very end of it after
|
|
1:08:56
|
we see all that Q.931 setup, connection everything
|
|
1:09:00
|
we still see the call disconnect reason equals unassigned number.
|
|
1:09:04
|
So that debug h225 event can be really useful.
|
|
1:09:08
|
If we were trying to debug a SIP ITSP, debug ccsip messages
|
|
1:09:15
|
and debug ccsip events
|
|
1:09:22
|
and actually error as well, those would be the three that I would use
|
|
1:09:27
|
might even look at media if I wanted to see why.
|
|
1:09:30
|
Maybe it was failing at a little more detailed level.
|
|
1:09:32
|
But debug ccsip messages events and error and we'll look at those debugs
|
|
1:09:36
|
certainly a little bit, but as far as gatekeeper
|
|
1:09:41
|
that should go over just about everything that you can expect
|
|
1:09:48
|
or funny, funny, hope to see in the lab.
|
