|
0:00:13
|
So let's take a look now at Unified CM Express
|
|
0:00:17
|
also known and we'll refer to throughout this and probably other
|
|
0:00:21
|
lessons as CME or possibly CUCME
|
|
0:00:25
|
so first let's talk about some of the basics of
|
|
0:00:30
|
skinny IP phones and we'll also take a look at SIP phones
|
|
0:00:34
|
as we mentioned, we think those are a lot less likely to be
|
|
0:00:36
|
tested, so we probably won't go over those in CME mode
|
|
0:00:39
|
although there's really not that much additional work or
|
|
0:00:45
|
difficulty that needs to be configured, it's really just a
|
|
0:00:47
|
difference in terms of how those are set up and we do cover
|
|
0:00:52
|
those exhaustively in the deep dives incidentally if you're interested
|
|
0:00:55
|
in those for real world deployments, but with
|
|
0:00:58
|
both skinny and SIP IP phones in either traditional SRST fallback
|
|
0:01:06
|
or CME whether it's CME as SRST or just standalone CME
|
|
0:01:12
|
and really I should just quickly say that both traditional SRST
|
|
0:01:16
|
and CME are essentially the same engine.
|
|
0:01:20
|
They really are the same underline programming engine.
|
|
0:01:22
|
But these skinny and SIP phones we program them
|
|
0:01:28
|
for skinny with things called ephones and ephone DNs
|
|
0:01:33
|
and for SIP with things called voice register pools
|
|
0:01:37
|
and voice register DNs, but all these are, is effectively
|
|
0:01:41
|
templates that create dial peers
|
|
0:01:46
|
and we already know dial peers. We've already talked about the IOS
|
|
0:01:49
|
dial plan, we have used dial peers for years most of us
|
|
0:01:53
|
and we -- or at least if we're at this class probably
|
|
0:01:59
|
at least for a given six months hopefully if you've been coming
|
|
0:02:03
|
up in the proper way through your CCNA voice and CCNP voice
|
|
0:02:08
|
studies, but we already know dial peers
|
|
0:02:12
|
so if we know dial peers, we understand the fundamental
|
|
0:02:17
|
under workings of the actual foundation of CME whether it be
|
|
0:02:25
|
skinny or SIP phones. Now there is a big
|
|
0:02:27
|
difference and we're not going to get into the complete
|
|
0:02:30
|
architecture as to why, but skinny phones which have been
|
|
0:02:35
|
around for years, years longer than SIP phones in CME
|
|
0:02:41
|
those create -- and in fact they've been around since I believe
|
|
0:02:45
|
CME was originally dubbed ITS or the IP telephony system
|
|
0:02:51
|
in IOS and I believe that came out in either 2001 or
|
|
0:02:54
|
2002, but when they first came out and really
|
|
0:03:01
|
it's followed this ever since and there's actually a great
|
|
0:03:04
|
deal of reasoning why, we go into a lot of it in the deep dives
|
|
0:03:06
|
there's a lot more functionality that can be provided by this
|
|
0:03:09
|
but skinny phones actually create POTS dial peers
|
|
0:03:13
|
and they create physical ports, so they create EFXS ports.
|
|
0:03:19
|
So hopefully we know or remember the idea of
|
|
0:03:24
|
FXO versus FXS, FXO being Foreign Exchange Office
|
|
0:03:29
|
typically connecting to an actual CO trunk line or a
|
|
0:03:33
|
carrier trunk line, CO meaning the Central Office
|
|
0:03:38
|
or carrier and FXS meaning Foreign Exchange System
|
|
0:03:47
|
and essentially this is an end point. This is a telephone.
|
|
0:03:52
|
FXS traditionally is associated with an analog phone
|
|
0:03:57
|
that's plugged into an FXS port.
|
|
0:03:59
|
FXS, FXO are sort of like male, female in terms of
|
|
0:04:04
|
if we're referring to electrical components, we have a male
|
|
0:04:08
|
and a female, those go together, FXS and FXO
|
|
0:04:11
|
are the male, female of the TDM, at least analog TDM
|
|
0:04:17
|
world so they can go back to back, but getting back to
|
|
0:04:20
|
our CME and skinny phones, FXS being a Foreign Exchange
|
|
0:04:25
|
I said Foreign Exchange System, I should have said Foreign Exchange
|
|
0:04:28
|
Station, but a Foreign Exchange Station when Cisco first created
|
|
0:04:33
|
the CME or the ITS, they created the skinny phones
|
|
0:04:39
|
as they created them as POTS dial peers, they...
|
|
0:04:44
|
if I have some sort of a dial peer that's of the type
|
|
0:04:47
|
POTS, I have to have a port associated with it
|
|
0:04:49
|
unless of course it's my inbound POTS dial peer.
|
|
0:04:52
|
But all of outbound POTS dial peers have to be associated
|
|
0:04:55
|
with a port.
|
|
0:04:59
|
In order to do that, they came up with the EFXS port
|
|
0:05:03
|
or Electronic Foreign Exchange Station.
|
|
0:05:05
|
So let's take a look here.
|
|
0:05:07
|
Here we've got our Unified Communication Manager Express
|
|
0:05:11
|
ISR router or ISR G2 router
|
|
0:05:15
|
and we've got skinny phone 1 and this let's say phone 1 places
|
|
0:05:21
|
a call to phone 2, so let's dial phone 3002
|
|
0:05:28
|
This goes in through the voice port of 50/0/1
|
|
0:05:35
|
Ok, so the ephone 1 creates this voice port
|
|
0:05:40
|
50/0/1
|
|
0:05:43
|
This then hits the inbound dial peer. Now real briefly
|
|
0:05:48
|
if we remember back to our part three of our dial plan
|
|
0:05:52
|
in this ATC series, we talked about digit manipulation order
|
|
0:05:58
|
of operations and we really could have even gone back
|
|
0:06:02
|
to a more fundamental level before that and said here is the
|
|
0:06:05
|
call flow in a router, so if there is an inbound call
|
|
0:06:10
|
and it's coming in a TDM, a Time Division Multiplexing
|
|
0:06:13
|
circuit, it's going to come in through a port and then
|
|
0:06:17
|
it will come in through a dial peer. If it's not TDM, if it's VoIP
|
|
0:06:21
|
it simply comes in through a VoIP type dial peer. There's no port.
|
|
0:06:26
|
Then we talked about the digit manipulation order of
|
|
0:06:30
|
operations, so really that's where we introduce that
|
|
0:06:32
|
whole call flow. This is really no different at all.
|
|
0:06:36
|
So a call comes in through a virtual EFXS voice port
|
|
0:06:41
|
and the reason it begins with 50 is because if we
|
|
0:06:44
|
remember the 50/0 or the digit/digit/digit
|
|
0:06:51
|
the first digit from the left is the slot, the second digit
|
|
0:06:56
|
sandwiched in the middle is the subslot and the third digit
|
|
0:07:00
|
on the right is the port. This could also be referred to
|
|
0:07:04
|
as, from the left, network module
|
|
0:07:06
|
or now actually referred to as system module
|
|
0:07:10
|
and then subslot or a slot on the network module
|
|
0:07:15
|
or system module in the middle and then on the right
|
|
0:07:18
|
the port on that slot because any given slot such as maybe
|
|
0:07:23
|
a two T1 or two E1 Vwick might have
|
|
0:07:28
|
two ports for instance.
|
|
0:07:31
|
Ok, so the reason they used 50 was because they were
|
|
0:07:35
|
essentially using the rational that currently there are not
|
|
0:07:40
|
and probably there never will be 50 service modules or
|
|
0:07:43
|
network module slots in any given router and if it is
|
|
0:07:47
|
then it's probably something of the size of a 10 thousand or
|
|
0:07:51
|
12 thousand GSR or a CRS 1 type router in which case
|
|
0:07:57
|
that's not how they're referred to anyway and
|
|
0:07:59
|
it's a totally different IOS and it's probably not running
|
|
0:08:02
|
CME, but so that's the idea is they use this number that
|
|
0:08:07
|
was well beyond anything that would ever be represented by
|
|
0:08:10
|
a virtual port.
|
|
0:08:13
|
Ok, so we come in through then the dial peer and notice
|
|
0:08:17
|
that this is a POTS dial peer and it begins at 20 thousand.
|
|
0:08:22
|
So you're able to create dial peers to a very high number
|
|
0:08:26
|
however, dial peers in the range of 20 thousand
|
|
0:08:30
|
2000X or really 20XXX that hold 20 thousand range.
|
|
0:08:39
|
So up to a thousand phones is reserved
|
|
0:08:42
|
and as CME begins to scale beyond a thousand phones which
|
|
0:08:45
|
it's close to being able to do maybe by the time you watch
|
|
0:08:48
|
this, able to do. They'll probably reserve the 21 thousand series
|
|
0:08:52
|
range or maybe it's actually already reserved.
|
|
0:08:54
|
I haven't actually tried to create a dial peer with that number yet.
|
|
0:08:59
|
And then actually we'll take a look on the next slide and see that
|
|
0:09:01
|
SIP phones use the 40 thousand series range, so
|
|
0:09:06
|
it's probably that there's 20 thousand through 40 thousand
|
|
0:09:08
|
reserved for POTS phones and 40 through 60 reserved
|
|
0:09:12
|
for VoIP SIP phones and then beyond that you can continue
|
|
0:09:16
|
using the numbers again. At any rate, we have
|
|
0:09:19
|
our POTS dial peer.
|
|
0:09:22
|
Then it's going to hit the outbound dial peer so this is
|
|
0:09:25
|
assuming that a skinny phone is calling another skinny phone
|
|
0:09:29
|
both registered to the CME router.
|
|
0:09:32
|
So then it hits the outbound POTS dial peer of the other skinny
|
|
0:09:35
|
phone. This is ephone DN 2
|
|
0:09:37
|
How can we tell this? Because the dial peer is 20,002
|
|
0:09:44
|
and then this leaves voice port 50/0/2, so this just happens to be
|
|
0:09:49
|
although it of course doesn't have to be this way, but
|
|
0:09:51
|
this just happens to be that ephone DN 2 is assigned
|
|
0:09:56
|
to ephone 2 and then of course it hits skinny phone 2
|
|
0:10:01
|
So again, this voice port was created by ephone 1
|
|
0:10:06
|
and we see things like type, the button assignment
|
|
0:10:10
|
and a Mac address, so how did we on voice port 50/0/1
|
|
0:10:15
|
get station ID number and station ID name?
|
|
0:10:20
|
This came by the assignment of button 1:1 that we see here
|
|
0:10:25
|
which is ephone DN index tag 1 and we saw number
|
|
0:10:32
|
3001, now if I can just pull up a PIN here real briefly,
|
|
0:10:37
|
let me see if I can get PowerPoint's PIN to cooperate
|
|
0:10:41
|
here we go.
|
|
0:10:43
|
I see that button 1:1
|
|
0:10:46
|
this is saying button 1 on the actual ephone is assigned
|
|
0:10:55
|
to DN index tag 1
|
|
0:10:59
|
It has nothing to do with the number. It's using the
|
|
0:11:03
|
index tag and assigning that index tag to button 1
|
|
0:11:08
|
The colon just means a one for one assignment
|
|
0:11:10
|
and we'll take a look when we type button and then question mark
|
|
0:11:13
|
in IOS, we'll see that there's other operators that we can
|
|
0:11:16
|
use, so we could use button 1 to say the first button and then
|
|
0:11:20
|
instead of saying a colon a one for one assignment
|
|
0:11:22
|
we can say things like O for overlay multiple DNs
|
|
0:11:26
|
on top of a single button, a concept that is not found
|
|
0:11:29
|
in CUCM. We can say C, so we could say 1C1 for
|
|
0:11:37
|
button 1 uses DN 1, but uses it in a fashion to allow
|
|
0:11:43
|
call waiting for overlaid DNs
|
|
0:11:47
|
We can do M so that button 1 monitors ephone DN 1
|
|
0:11:53
|
this is similar to a speed dial or similar to a busy lamp field
|
|
0:12:00
|
although not exact, we can also do 1W1, so button 1 watches
|
|
0:12:05
|
DN 1, this is much more similar to a speed dial busy lamp field
|
|
0:12:12
|
or BLF speed dial with call pickup tick box, but we'll look at
|
|
0:12:16
|
a number of these things. There's a lot of different
|
|
0:12:18
|
operators that we can use there, so anyhow, the number 3001 here
|
|
0:12:23
|
this has not only populated the destination pattern 3001$
|
|
0:12:28
|
remember dollar sign is a regular expression means the
|
|
0:12:30
|
end of the line, but it's also populated the station ID number
|
|
0:12:36
|
3001 up here on the voice port.
|
|
0:12:39
|
So this is my calling number.
|
|
0:12:43
|
If I gave not the label because the label goes beyond Desmond Hume
|
|
0:12:47
|
it contains Desmond Hume X3001, this is simply the label
|
|
0:12:51
|
that's put up there on the line, but the name Desmond Hume
|
|
0:12:54
|
populates my station ID name up here on my phone.
|
|
0:12:59
|
So for saying that the ephone DN creates the POTS dial peer
|
|
0:13:03
|
then how does this name affect something on the actual
|
|
0:13:06
|
port? Because of the button assignment and because
|
|
0:13:09
|
it's the first button that's assigned.
|
|
0:13:13
|
Or I should say the DN is assigned to the first button.
|
|
0:13:17
|
Now this description, we don't see this anywhere in here.
|
|
0:13:23
|
And so in CME, the description on the first epone DN or the
|
|
0:13:31
|
ephone DN that's applied to the first line or first button
|
|
0:13:36
|
that will be at the very top right of the display, that will be the external
|
|
0:13:39
|
phone number mask whatever we put in here and it doesn't even have
|
|
0:13:41
|
to be a number like it does in CME -- I'm sorry in CUCM.
|
|
0:13:47
|
And it has nothing to do with AAR, we don't really have that
|
|
0:13:50
|
concept because CME wasn't built for across the WAN
|
|
0:13:53
|
so it has no idea of locations or call admission control per se
|
|
0:13:58
|
natively to CME and we'll also see that whatever applies
|
|
0:14:02
|
to the top right display is different or the place that we
|
|
0:14:06
|
put it is different from skinny phones to SIP phones
|
|
0:14:10
|
so in a skinny phone it's going to be put on the ephone DN that's
|
|
0:14:13
|
applied to the first button. In a SIP phone it's actually going to
|
|
0:14:17
|
be on the phone -- the voice register pool or what the
|
|
0:14:21
|
equivalent of the ephone for skinny would be.
|
|
0:14:28
|
Ok, so then we go out ephone DN 2 that's the
|
|
0:14:32
|
dial peer voice 20,002 as I mentioned
|
|
0:14:35
|
and then the call leaves through the ephone
|
|
0:14:38
|
or the virtual port, the EFXS port.
|
|
0:14:42
|
And then of course the call alerts at the phone
|
|
0:14:44
|
or rings, so looking at SIP IP phones, these are not
|
|
0:14:49
|
ports and dial peers. Again, because skinny phones are creating
|
|
0:14:53
|
POTS dial peers, they have to have ports
|
|
0:14:57
|
but SIP phones use VoIP dial peers
|
|
0:15:01
|
and VoIP dial peers if we're just thinking back to traditional
|
|
0:15:04
|
VoIP dial peers which really there is no difference
|
|
0:15:07
|
they don't have any ports.
|
|
0:15:09
|
Ok, there's no physical TDM functionality, everything is
|
|
0:15:13
|
virtual, it's IP based.
|
|
0:15:15
|
So if a SIP phone 3 places a call to SIP phone 4
|
|
0:15:21
|
then we come in dial peer voice 40,001 and all of the
|
|
0:15:27
|
specifics that we had configured show up under that dial peer
|
|
0:15:33
|
and we leave through dial peer 40,002
|
|
0:15:37
|
and it alerts at the phone.
|
|
0:15:39
|
Ok, again, so this was actually created
|
|
0:15:45
|
by not only the voice register pool which indicates the phone.
|
|
0:15:50
|
Now in SRST, either SIP SRST or CME as SRST which there's really
|
|
0:15:56
|
no difference when it comes to SIP at all even in the
|
|
0:16:00
|
configuration. In skinny there's a difference. Traditional SRST is
|
|
0:16:04
|
call manager fallback. CME as SRST is obviously the telephony service
|
|
0:16:08
|
configuration with that special mode SRST command, but in
|
|
0:16:14
|
SIP whether it's SRST fallback or native CME, there's really not
|
|
0:16:19
|
much of a difference in terms of the commands that we use
|
|
0:16:23
|
the voice register global which would be equivalent to the telephony
|
|
0:16:27
|
service in skinny or the voice register pool which would be
|
|
0:16:34
|
analogous to the ephone in skinny or the voice register DN
|
|
0:16:40
|
which would be analogous to the ephone DN in skinny.
|
|
0:16:48
|
There's really no difference in the configuration
|
|
0:16:51
|
or I should say there's really no difference in the use of the
|
|
0:16:53
|
entities. Unlike with CME
|
|
0:16:58
|
skinny for telephony service -- I'm sorry call manager fallback
|
|
0:17:02
|
we simply have the call manager fallback and everything goes there.
|
|
0:17:05
|
We don't have ephones, we don't have ephone DNs.
|
|
0:17:10
|
But in SIP, other than the fact that with traditional
|
|
0:17:16
|
SIP CME, we typically create one voice register
|
|
0:17:22
|
pool per device and we use ID Mac.
|
|
0:17:26
|
So instead of Mac address, we use ID and we specify that we're
|
|
0:17:29
|
basing this ID based on Mac address and we create one
|
|
0:17:32
|
pool per phone. That's typical.
|
|
0:17:35
|
In SRST mode, we cannot use Mac -- well actually if the phone is
|
|
0:17:41
|
local we can, if it's across the WAN we definitely cannot
|
|
0:17:44
|
it's typically a good idea actually if you wanted to get
|
|
0:17:49
|
it to work every time, it's a good idea not
|
|
0:17:51
|
to use ID Mac
|
|
0:17:53
|
and instead to use ID network or even a particular host, so
|
|
0:17:59
|
you're specifying that let's say an entire subnet of phones
|
|
0:18:02
|
can fall back and whatever phones are specified by that
|
|
0:18:06
|
subnet or VLSM will get the information there and
|
|
0:18:11
|
a lot of this information when we say mode SRST for SIP under
|
|
0:18:15
|
voice register global, a lot of that goes away.
|
|
0:18:18
|
We can't necessarily put all of the specific such as number 1 DN 1
|
|
0:18:24
|
and again, that's because the SIP phones when they
|
|
0:18:28
|
fall back, they instruct the CME SRST SIP server
|
|
0:18:33
|
as to what they're existing DNs are, if fact, if you put the
|
|
0:18:37
|
number DN, it will effectively just ignore it.
|
|
0:18:42
|
But we're looking at traditional SIP CME and so we've got our
|
|
0:18:47
|
voice register DN analogous to our ephone DN. We've got our
|
|
0:18:51
|
number, name and label, notice we have no description here
|
|
0:18:56
|
to deal with the top right display. That's actually done
|
|
0:18:59
|
on the voice register pool or the equivalent of the
|
|
0:19:02
|
ephone and that's because with SIP, if we look at the
|
|
0:19:07
|
RFC for SIP and how it actually works or is
|
|
0:19:12
|
supposed to work per the industry standard it is
|
|
0:19:16
|
that individual line's register
|
|
0:19:19
|
rather than a device and actually I could have if I'm
|
|
0:19:23
|
manually setting up my Mac address dot CNF file or
|
|
0:19:27
|
SEP Mac address dot CNF file or SIP Mac address dot CNF file
|
|
0:19:32
|
however I'm labeling it, however the particular system wants it
|
|
0:19:35
|
in this case it would be SEP Mac address dot CNF
|
|
0:19:39
|
but if I'm setting that up, I can actually have each individual line
|
|
0:19:43
|
of a given physical device registered to different
|
|
0:19:46
|
call processing engines. One to CME, one to Skype, one to
|
|
0:19:51
|
asterisk, but of course we're dealing with just Cisco servers
|
|
0:19:56
|
and everything in the lab, but because of that, it's not
|
|
0:20:00
|
dependant on the voice register DN as to what
|
|
0:20:04
|
goes in the top right display where external phone number
|
|
0:20:07
|
mask would populate in CUCM.
|
|
0:20:09
|
Instead, it's on the device itself, the voice register pool, so
|
|
0:20:12
|
that's where we put the description. A user name and password is
|
|
0:20:16
|
because the device needs to authenticate to us. This is not
|
|
0:20:20
|
just for let's say Voice mail user name and password
|
|
0:20:23
|
for future imports, this is actually so the device can register to us.
|
|
0:20:28
|
Because this is a VoIP dial peer, we need to specify some
|
|
0:20:32
|
sort of voice class codec or else specify the codec hard coded.
|
|
0:20:38
|
So by default, VoIP dial peers are G.729
|
|
0:20:43
|
So if we wanted, we could change the default to G.711
|
|
0:20:46
|
or just like a VoIP dial peer and as is typically
|
|
0:20:51
|
preferable so that it can negotiate we'll give it a voice class codec
|
|
0:20:55
|
and then put our primary codec, probably G.711 as preferred
|
|
0:21:00
|
and then if it needs to, it can negotiate a secondary or
|
|
0:21:03
|
tertiary preference.
|
|
0:21:05
|
Voice codec does work by the way with CME.
|
|
0:21:09
|
It works in 124-22 T, there were a few issues with it working
|
|
0:21:13
|
in 124-20 T, so it depends on the IOS you see in the lab.
|
|
0:21:19
|
And then here just like we on the skinny phones
|
|
0:21:23
|
had button 1:1 on the device, here we have number 1
|
|
0:21:27
|
DN 1, number 1 DN 1 is how we're applying
|
|
0:21:32
|
index DN 1 up to the first button.
|
|
0:21:38
|
And of course we always have the type. If we don't
|
|
0:21:40
|
have a type command for either our SIP or our skinny phones
|
|
0:21:47
|
then the CME engine will actually not in any way
|
|
0:21:52
|
produce the SEP Mac address dot CNF for SIP
|
|
0:21:57
|
or SEP Mac address dot CNF dot XML file for skinny phones.
|
|
0:22:02
|
Ok, that type is very important.
|
|
0:22:04
|
But anyhow, it's the combination of the two that then creates
|
|
0:22:09
|
and populates the actual VoIP dial peer.
|
|
0:22:13
|
Ok, so then the call leaves through voice register pool 2
|
|
0:22:17
|
and voice register DN 2 as we have it set up here and of course
|
|
0:22:20
|
that's the VoIP dial peer. So a mixture of these
|
|
0:22:23
|
really wouldn't be any different. If a call comes in from a SIP phone,
|
|
0:22:26
|
it comes in from a VoIP dial peer only, but it goes out
|
|
0:22:29
|
through a POTS dial peer out through a EFXS port
|
|
0:22:33
|
to the skinny phone.
|
|
0:22:36
|
And we've already talked about how these are created.
|
|
0:22:39
|
Now we had already talked about previously in the IOS
|
|
0:22:43
|
dial plan class of restriction. In IOS in general this says
|
|
0:22:48
|
for CUCME and that's how we're going to apply it today, but it's
|
|
0:22:52
|
global for IOS, it doesn't have to be CME, I could
|
|
0:22:55
|
do this on an IOS gateway then it was let's say an H.323 or...
|
|
0:23:01
|
or a SIP gateway to the PSTN.
|
|
0:23:05
|
But we talked about this really brief or we actually talked about
|
|
0:23:09
|
it in depth previously, we're just going to touch on it again
|
|
0:23:11
|
real briefly just as a refresher to bring it to the front of your mind
|
|
0:23:15
|
because we're going to be applying this today
|
|
0:23:18
|
and we talked about it earlier, but we didn't really apply it in the demonstration.
|
|
0:23:22
|
as it wasn't really too terribly relevant at the time.
|
|
0:23:26
|
So we have the idea of a core list incoming
|
|
0:23:31
|
and any time we have an incoming, we're going to
|
|
0:23:33
|
use the analogy of a key ring.
|
|
0:23:38
|
And the members of that incoming core list will be known
|
|
0:23:40
|
as keys and we label them LOK, so Lock Or Key
|
|
0:23:44
|
because every time we go to a locksmith to have a lock created
|
|
0:23:49
|
they don't give us just a lock, but they also give us the lock
|
|
0:23:53
|
and the key as sort of a single unit and it's us that
|
|
0:23:57
|
installs the lock and then we separate the key and we
|
|
0:24:00
|
keep that key separate so that we can apply it later
|
|
0:24:04
|
to let us into whatever we have locked.
|
|
0:24:07
|
So in IOS, our lock and keys and are going to be effectively
|
|
0:24:11
|
the same entity. In fact, they will be the same entity,
|
|
0:24:15
|
so that's why we referred to them as Lock Or Key.
|
|
0:24:17
|
When are they a lock? They're a lock when
|
|
0:24:20
|
the member is applied to a door. They're a key
|
|
0:24:23
|
when the member is applied to a key ring.
|
|
0:24:26
|
More specifically, they're a lock when applied to a
|
|
0:24:30
|
door which is always an outgoing core list
|
|
0:24:34
|
we see over on the right
|
|
0:24:36
|
and they are a key when applied to a key ring which is
|
|
0:24:41
|
always an incoming core list.
|
|
0:24:44
|
So if I have an incoming core list, it's known as a key ring
|
|
0:24:46
|
and or I'm applying the entities that I set up globally.
|
|
0:24:50
|
I'm only applying my key rings on the incoming
|
|
0:24:54
|
and the LOK becomes the L, the Lock -- I'm sorry, it becomes
|
|
0:24:58
|
the K, the Key in the key ring.
|
|
0:25:01
|
And if I'm applying an outgoing core list, that is going to be
|
|
0:25:06
|
what I name globally as a door and the LOK becomes
|
|
0:25:13
|
the L, the Lock, applied to the door.
|
|
0:25:15
|
So if I'm placing a call here to 07037373, I first of all
|
|
0:25:23
|
come in the ephone DN or voice register pool based on
|
|
0:25:28
|
what device I'm going off hook on, my skinny or SIP phone
|
|
0:25:33
|
and I always choose the outbound dial peer before
|
|
0:25:41
|
we ever deal with anything else on that dial peer, so
|
|
0:25:45
|
always look at the destination pattern to try to match before
|
|
0:25:51
|
we ever apply or look at core lists or if we were dealing
|
|
0:25:55
|
with voice translation rules, anything like that.
|
|
0:25:58
|
And this is opposite to CUCM.
|
|
0:26:00
|
CUCM looks at the calling search space and the partitions and it
|
|
0:26:04
|
doesn't even see partitions that are not in the calling
|
|
0:26:08
|
party's calling search space and so it never even has the
|
|
0:26:12
|
ability to match, so this is a different fundamental thinking
|
|
0:26:16
|
as we talked about before, so it in IOS, it matches the destination
|
|
0:26:20
|
pattern, matches the dial peer, then it does a comparison
|
|
0:26:26
|
to check the outgoing locks against -- on the outgoing doors
|
|
0:26:31
|
against the keys for the incoming key ring and we
|
|
0:26:34
|
mentioned previously I'll stick to this, unless you're
|
|
0:26:38
|
forced to otherwise, only ever put one lock on one door.
|
|
0:26:43
|
I will have multiple keys on my key ring, but I'll only ever
|
|
0:26:47
|
put one lock on one door.
|
|
0:26:49
|
Now if you're -- and this is practical lab base setting where
|
|
0:26:56
|
you're probably just given a general requirement and told to make
|
|
0:26:59
|
it work and you're going to use core lists, you're going to use
|
|
0:27:03
|
class of restriction as the tool to make the requirement
|
|
0:27:08
|
work. If you were back studying for your CCNA Voice
|
|
0:27:12
|
or CCNP Voice, they may give you scenarios where
|
|
0:27:15
|
there are multiple locks on a door, but of course
|
|
0:27:18
|
probably at this point you're just looking at your CCIE Lab
|
|
0:27:23
|
requirements, but it can be simply said that if there
|
|
0:27:26
|
were multiple locks on the door or there were multiple
|
|
0:27:30
|
members on the outgoing core list that the incoming
|
|
0:27:34
|
core list, the key ring, has to be a super set or equal to
|
|
0:27:41
|
in terms of member matching, so in other words, the key ring
|
|
0:27:44
|
has to have one key for every lock. Now it might have
|
|
0:27:49
|
more keys, but if there were three locks, then it would have to
|
|
0:27:53
|
at least have those very same three keys. It might have
|
|
0:27:56
|
five, it might only have the three, but it has to at least
|
|
0:27:59
|
have the same three keys as the same outgoing core list
|
|
0:28:04
|
locks on the door.
|
|
0:28:06
|
Ok, so the call proceeds and of course if for some reason
|
|
0:28:11
|
I didn't have a match for instance -- let me actually
|
|
0:28:14
|
go back. If this ephone DN tried to place a call down
|
|
0:28:18
|
here, I have member LOK local. This has member LOK national.
|
|
0:28:23
|
That's not a match. I don't have a key to unlock
|
|
0:28:26
|
this -- I would meet with a call failure, but still
|
|
0:28:31
|
the dial peer would have been matched based on the
|
|
0:28:33
|
dialed digits first.
|
|
0:28:36
|
The other thing to look at is that if there is no...
|
|
0:28:40
|
First of all, if there's no outgoing door, the analogy makes sense
|
|
0:28:44
|
if there's no door, then there's no key. It's just basically an opening in the wall
|
|
0:28:47
|
and I can leave even if I have a key ring or if I don't
|
|
0:28:52
|
have a key ring that is I have an incoming core list or I
|
|
0:28:55
|
don't have an incoming core list, if there's no outgoing
|
|
0:28:58
|
core list, well then that makes sense. There's no door, there's no lock
|
|
0:29:01
|
it doesn't matter whether I have a key or not. I can go out that door.
|
|
0:29:05
|
But the converse also holds true which is that if I forgot
|
|
0:29:10
|
my key ring at home when I left home to go to the office
|
|
0:29:14
|
and I get to the office and there's a lock on the door
|
|
0:29:17
|
first of all, there's a door, that is there's a core list
|
|
0:29:20
|
outgoing and of course there is a member or a
|
|
0:29:23
|
lock on that door. If I don't have my key ring, I become a
|
|
0:29:29
|
social hacker and I can easily get anyone to open
|
|
0:29:35
|
the door for me, so the simple way or I should
|
|
0:29:40
|
say the technical way to think about it and maybe the simple way
|
|
0:29:42
|
to think about it is if there is no outgoing core list
|
|
0:29:46
|
and/or if there is no incoming core list, I have full access.
|
|
0:29:53
|
Ok,
|
|
0:29:56
|
it tries to check the locks against the keys, however there are no
|
|
0:30:00
|
keys, so there is full access. The call will be completed.
|
|
0:30:09
|
Now one thing to take a look at for skinny phones in CME
|
|
0:30:13
|
is this idea of lines.
|
|
0:30:15
|
By default, if I just set up and ephone DN, give it an
|
|
0:30:19
|
index number and hit enter, it will be effectively a single line.
|
|
0:30:23
|
When I say single line, this is not the equivalent of the
|
|
0:30:28
|
word line in CUCM. In CUCM, line is a DN applied to a device.
|
|
0:30:33
|
Here in IOS in CME, when it says single line, dual line
|
|
0:30:39
|
or octo line, this is actually referring to the media channels.
|
|
0:30:42
|
So a single line is an ephone DN that has a single media
|
|
0:30:50
|
channel, so if this were the only ephone DN applied to
|
|
0:30:54
|
the phone, button 1:1 and ephone DN 1
|
|
0:30:58
|
was a single line, then I'd have one media channel
|
|
0:31:02
|
I could place one outgoing or receive one incoming
|
|
0:31:06
|
call, but I couldn't do both. I couldn't be on an outgoing call
|
|
0:31:10
|
and receive call waiting. For this I need two media channels
|
|
0:31:14
|
or a dual line. There's also the idea of an octo line.
|
|
0:31:18
|
So I have the ability to have up to eight media channels.
|
|
0:31:22
|
In CUCM, this is implicit that I have multiple media channels
|
|
0:31:29
|
and I restrict how many media channels I can use
|
|
0:31:33
|
once the DN is applied to the device. On the line
|
|
0:31:36
|
I scroll to near the bottom and I have my busy trigger
|
|
0:31:42
|
and then I have my maximum number or calls supported, so
|
|
0:31:47
|
I could limit the phone to maybe say six calls, but a busy
|
|
0:31:52
|
trigger of three which means that I have six media channels
|
|
0:31:56
|
but once I have three of those media channels utilized
|
|
0:32:00
|
through whatever means, inbound, outbound, conference transfer
|
|
0:32:03
|
whatever, once I have three of those media channels utilized
|
|
0:32:07
|
there are still three more that I can use to initiate
|
|
0:32:12
|
any sort of a call or a transfer a conference or something
|
|
0:32:16
|
but any inbound calls to my DN will ring to the
|
|
0:32:21
|
call forward busy operator.
|
|
0:32:24
|
By operator, I don't mean a person, I mean whatever
|
|
0:32:28
|
was configured for my call forward busy criteria.
|
|
0:32:32
|
So here in CME, the octo line gives me
|
|
0:32:37
|
eight media channels and then I also have -- so just
|
|
0:32:41
|
to start out with and then I also have the ability to
|
|
0:32:46
|
limit the total amount of calls per line and the busy
|
|
0:32:51
|
trigger and that can be done through ephone DN
|
|
0:32:55
|
templates and we'll take a look at that.
|
|
0:32:58
|
Ok, so some of the things that we take a look at
|
|
0:33:00
|
first of all barge which is really only cbarge in
|
|
0:33:04
|
CME and so the difference between barge and cbarge
|
|
0:33:08
|
if you'll recall, barge was using the target phone
|
|
0:33:14
|
whomever I'm trying to barge into. It was using that
|
|
0:33:17
|
target shared line phone, the DSPs built into that
|
|
0:33:21
|
IP phone and what was called the built-in bridge.
|
|
0:33:24
|
We don't have that in CME, we only have conference bridge
|
|
0:33:29
|
or conference barge or cbarge.
|
|
0:33:33
|
And we don't have any ability to have single button barge.
|
|
0:33:38
|
So for shared lines I can't assign that I just pressed the
|
|
0:33:42
|
button of that shared line and it will go into cbarge automatically.
|
|
0:33:47
|
I have to press the shared line, see the remote in use
|
|
0:33:51
|
state and message appear at the bottom and then press
|
|
0:33:54
|
the cbarge soft key in order to actually barge in
|
|
0:33:58
|
and I have to have a conference, a hardware conference bridge
|
|
0:34:01
|
registered to CME in order to use that.
|
|
0:34:05
|
By the way -- so first of all, we only have cbarge
|
|
0:34:09
|
we don't have barge, we don't have single line barge or
|
|
0:34:13
|
cbarge, so we only have traditional cbarge.
|
|
0:34:16
|
And we don't have any of those in call manager fallback in
|
|
0:34:22
|
traditional SRST.
|
|
0:34:25
|
So either standard CME or CME as SRST and cbarge
|
|
0:34:31
|
only, so with octo line we can use cbarge
|
|
0:34:35
|
with a busy trigger, we can set that on an octo line, but not
|
|
0:34:41
|
single or dual line, so this is just kind of going over some
|
|
0:34:44
|
of the things, if it has the dash, it means that is not supported
|
|
0:34:47
|
in that particular type of a line.
|
|
0:34:53
|
So for instance, conferencing this as eight-party with a dual
|
|
0:34:57
|
line we could have four directory numbers, so
|
|
0:34:59
|
four ephone DNs that were dual line ephone DNs to
|
|
0:35:03
|
comprise that full eight-party conference.
|
|
0:35:05
|
With an octo line we can just use one ephone DN that's
|
|
0:35:10
|
setup as octo-line. I don't really care about FXO trunk optimization
|
|
0:35:14
|
right here.
|
|
0:35:16
|
Huntstop channel, so each line or each media channel
|
|
0:35:21
|
has the ability to hunt not only between ephone DNs
|
|
0:35:24
|
or POTS dial peers, but also within that POTS dial peer
|
|
0:35:30
|
or within that ephone DN we've got the multiple channels.
|
|
0:35:34
|
Obviously if there's a single line or a single channel
|
|
0:35:36
|
there is no channels to hunt, we only have the one.
|
|
0:35:39
|
But if I have multiple either dual or octo, I can actually hunt
|
|
0:35:43
|
between those channels or I can say no huntstop channel.
|
|
0:35:48
|
So don't stop hunting.
|
|
0:35:51
|
I'm sorry, huntstop channel says stop hunting between the channels.
|
|
0:35:55
|
No hunt stop channels says double negative, don't
|
|
0:35:58
|
stop hunting or effectively allow hunting between the channels.
|
|
0:36:03
|
Intercom, you can only do that with a single line,
|
|
0:36:07
|
not with dual or octo.
|
|
0:36:09
|
Key system or one call per button or one line seized
|
|
0:36:13
|
so one, typically one FXO line per button.
|
|
0:36:17
|
We can make a CME look like an older key system unit,
|
|
0:36:21
|
KSU, if you're familiar with the telephony terms,
|
|
0:36:23
|
our traditional telephony terms, we're not going to worry about
|
|
0:36:26
|
that in the lab because we don't have FXO ports.
|
|
0:36:29
|
Maximum total calls that I said we could do under the
|
|
0:36:32
|
template, the busy trigger and the max calls can only be done with octo.
|
|
0:36:38
|
MWI, this doesn't mean that a single line or a dual line or
|
|
0:36:42
|
an octo line DN can't necessarily have an MWI lit for that line.
|
|
0:36:49
|
They can. It just means that we can't turn
|
|
0:36:52
|
a ephone DN into the actual MWI operator, so the actual
|
|
0:36:58
|
MWI on number or the actual MWI off number. Only a single
|
|
0:37:01
|
line can do that and it's good that you understand these
|
|
0:37:04
|
because there are going to be things like let's say you were told to
|
|
0:37:07
|
set up paging or park where if you're just in the default mode
|
|
0:37:11
|
of creating octo lines for everything, you're going to wonder
|
|
0:37:14
|
why paging and park don't work.
|
|
0:37:17
|
If you're in just the habit of saying, 'Ok, for all my...
|
|
0:37:21
|
all the ephone DNs that I'm going to set up to be applied
|
|
0:37:25
|
to buttons to the actual IP phones I'm going to set up as
|
|
0:37:29
|
octo lines, but any system ephone DN, so paging,
|
|
0:37:35
|
park, a conference or something like that, I'm just going to set up
|
|
0:37:38
|
as a single line.' Well, that won't work either because conferencing
|
|
0:37:41
|
doesn't work for single line.
|
|
0:37:43
|
Paging and park do, but the other doesn't.
|
|
0:37:47
|
Or a shared line. If I want to have privacy, it doesn't work
|
|
0:37:51
|
on a dual line or a single line, it does on an octo.
|
|
0:37:53
|
So it's good to know these and by the way, they are in
|
|
0:37:57
|
the documentation, so not only if you forget how to
|
|
0:38:03
|
set up park, can you just go to the documentation website
|
|
0:38:05
|
and look under the CME administration guide which
|
|
0:38:09
|
we're going to look at here next in the demonstration time
|
|
0:38:13
|
and we're going to say, 'What's the steps to create a call park
|
|
0:38:17
|
ephone DN and it will tell us to create -- it'll specifically
|
|
0:38:21
|
tell us, 'Create a single line
|
|
0:38:23
|
or a single channel ephone DN.' or else it will actually just say,
|
|
0:38:27
|
'Create an ephone DN, but when we look at the configuration
|
|
0:38:30
|
example, it will not show the word dual line or the word
|
|
0:38:34
|
octo line as an argument after the ephone DN tag.
|
|
0:38:40
|
But there is also this chart in there as well just in case
|
|
0:38:45
|
we forgot.
|
|
0:38:46
|
Ok, finally before we move on to our demonstration
|
|
0:38:49
|
look at some useful show commands. We looked at
|
|
0:38:53
|
these before, if you remember in the IOS portion of our dial plan.
|
|
0:38:58
|
We're showing them again because they're going to be
|
|
0:39:00
|
useful again in terms of our CME implementations.
|
