|
0:00:13
|
Ok, good morning everyone or good day to some of you
|
|
0:00:17
|
depending on your time zone.
|
|
0:00:20
|
Welcome to our last day of CCIE Voice advanced
|
|
0:00:24
|
technologies class. Today we're going to talk and look
|
|
0:00:28
|
at presence and then we're going to wrap up with a good
|
|
0:00:32
|
long discussion and hopefully interaction on strategy as well.
|
|
0:00:38
|
So let's dive into presence.
|
|
0:00:43
|
First of all, dealing with presence in general
|
|
0:00:46
|
this is a function that revolves around the CCM server
|
|
0:00:51
|
itself and mainly the publisher in terms of it's actually the
|
|
0:00:57
|
CCM server with no help from the CUP server or Cisco Unified
|
|
0:01:03
|
Presence server at all that deals with the actual
|
|
0:01:06
|
presence status of any of the phones
|
|
0:01:10
|
and we have some terms the person that is being watched
|
|
0:01:16
|
and either knowingly allowing that or at least the administrator
|
|
0:01:20
|
has configured allowing a a person to be watched.
|
|
0:01:23
|
The watched person is known in Cisco language as the
|
|
0:01:28
|
presentity.
|
|
0:01:29
|
And really in the SIP RFCs
|
|
0:01:32
|
as all of this presence functionality are extensions of SIP RFCs
|
|
0:01:38
|
and actually the simple protocol
|
|
0:01:41
|
which is an extension of SIP.
|
|
0:01:43
|
So we have person A here and they've got their phone
|
|
0:01:47
|
that is open to being watched. Maybe their
|
|
0:01:50
|
laptop they don't have CUPC installed or they're not running it
|
|
0:01:53
|
at the time, so that's effectively closed.
|
|
0:01:58
|
And the presence service again lives on the actual
|
|
0:02:01
|
CCM server, so a registration will have preceded any sort
|
|
0:02:07
|
of publish, so the phone or the CUPC client
|
|
0:02:11
|
whatever it is we'll have registered of course with the
|
|
0:02:15
|
server, the CCM server, and then we'll publish their
|
|
0:02:20
|
status so every time a state change goes into effect
|
|
0:02:25
|
whether it's an off hook or going on hook after
|
|
0:02:30
|
being busy on the line for a while, that is
|
|
0:02:33
|
effectively published from the CCM service to the
|
|
0:02:38
|
presence service. Again, pretty much all running on the same
|
|
0:02:40
|
server. It's really not necessarily the phone that publishes that
|
|
0:02:44
|
as much as it is the server that basically instructs it to.
|
|
0:02:50
|
But all this functionality is on the CCM server.
|
|
0:02:54
|
Then there's the watcher, so we've got the presentity
|
|
0:02:58
|
or we could call them the watchee on the left
|
|
0:03:00
|
and then the watcher and they effectively do
|
|
0:03:02
|
a subscribe. Now regardless of whether they're running
|
|
0:03:07
|
a skinny phone or a SIP phone
|
|
0:03:11
|
the skinny phones have or the skinny protocol
|
|
0:03:15
|
have or has been extended and modified to include
|
|
0:03:19
|
this sort of SIP like functionality
|
|
0:03:22
|
for a SIP subscribe.
|
|
0:03:25
|
And normally a person who is a watcher is normally
|
|
0:03:30
|
also a presentity as well.
|
|
0:03:32
|
So they can and most likely will be or have a
|
|
0:03:37
|
presentity aspect to them as well.
|
|
0:03:40
|
And so every time a publish is made from the presentity
|
|
0:03:45
|
or watchee on the left, that is effectively pushed
|
|
0:03:49
|
because the watcher has subscribed to that particular
|
|
0:03:53
|
user's or person's DN status
|
|
0:03:56
|
that will effectively be pushed to the watcher in the form
|
|
0:04:00
|
of whatever. Whether it's a busy lamp field speed dial
|
|
0:04:06
|
or status change on the Cisco Unified personal communicator, the CUPC client
|
|
0:04:12
|
whatever it is we'll take a look at that.
|
|
0:04:16
|
So looking at presence components
|
|
0:04:20
|
here we see that we've got a phone and a user with a
|
|
0:04:23
|
really old computer it looks like
|
|
0:04:25
|
green screen terminal almost at the top left
|
|
0:04:28
|
we have the CUCM server and then we've got
|
|
0:04:31
|
a person which is effectively a watcher at the bottom left
|
|
0:04:35
|
so the person at the top left is going to be the
|
|
0:04:37
|
presentity.
|
|
0:04:39
|
So as soon as they go off hook, we're pushing a
|
|
0:04:42
|
busy status to the watcher and we see that in the form
|
|
0:04:46
|
as an example here of a BLF speed dial or a Busy
|
|
0:04:50
|
Lamp Field speed dial.
|
|
0:04:51
|
And if you're relatively new to voice or voice concepts in general
|
|
0:04:59
|
or even Cisco, BLF or Busy Lamp Field is
|
|
0:05:03
|
a very old telephony term in general.
|
|
0:05:08
|
Ok, so this used to be where we would have
|
|
0:05:11
|
multiple, multiple 25 pairs running to reception and main
|
|
0:05:15
|
consoles and there were literally lamps that were actually lit and
|
|
0:05:20
|
so we'd have relays and as someone went off hook
|
|
0:05:24
|
on their line, there would literally be an electrical
|
|
0:05:26
|
pulse that was sent as an early form of status or
|
|
0:05:30
|
watching and that busy lamp field would light up
|
|
0:05:34
|
at maybe like I said like a reception desk or something
|
|
0:05:37
|
like that or a manager's desk.
|
|
0:05:39
|
But we still call them busy lamp fields and we still
|
|
0:05:41
|
for the most part on phones have the translucent buttons
|
|
0:05:45
|
over to the right or left depending on the model of
|
|
0:05:49
|
phone and that corresponds with as we see here the two
|
|
0:05:53
|
little -- if we can see
|
|
0:05:56
|
the difference between just a regular phone -- if we just have
|
|
0:05:59
|
a regular picture of a phone, this is either
|
|
0:06:02
|
our own line or something that we really can't monitor
|
|
0:06:05
|
per se. If we have the ability to monitor so
|
|
0:06:08
|
let's say we've set up a BLF speed dial, we'll typically
|
|
0:06:11
|
see -- if you can actually see behind those two little
|
|
0:06:14
|
handsets, there is
|
|
0:06:18
|
basically 12 little squares indicating the keypad.
|
|
0:06:22
|
So if we see that little those 12 little white
|
|
0:06:24
|
squares behind the phone, that's indicating the keypad
|
|
0:06:29
|
and the fact that we have the ability to watch whether it's
|
|
0:06:33
|
configured properly or not from the administrative
|
|
0:06:36
|
position is something else, but we should have the ability
|
|
0:06:39
|
to watch that particular DN.
|
|
0:06:42
|
And also it should be noted that we don't
|
|
0:06:46
|
as watchers, bottom left here, we don't watch the entire user
|
|
0:06:50
|
or the entire phone of the presentity or of the
|
|
0:06:53
|
watchee. What we are able to do is watch individual DNs.
|
|
0:07:02
|
So if you want to watch more than one DN
|
|
0:07:04
|
all the things that we're about to talk about need to be
|
|
0:07:06
|
set up for each of those DNs.
|
|
0:07:09
|
Ok, in terms of we're going to talk about subscribe
|
|
0:07:12
|
calling search space on the part of the watcher
|
|
0:07:15
|
and the fact that that subscribe calling search space
|
|
0:07:18
|
needs to have the partition or contain the partition
|
|
0:07:21
|
of the presentity, the watchee, the person being watched. Actually
|
|
0:07:25
|
the specific DN being watched. And so if they have multiple
|
|
0:07:28
|
DNs let's say for instance like our IPA manager or
|
|
0:07:32
|
something like that and we'll use that as a good example
|
|
0:07:35
|
outside of our normal here in demo in just a bit
|
|
0:07:39
|
then this subscribe CSS needs to be able to have
|
|
0:07:43
|
or contain those individual, possibly multiple partitions.
|
|
0:07:51
|
Back in CUCM 5 when subscribe CSS and presence
|
|
0:07:56
|
really first came to communications manager or call manager
|
|
0:07:59
|
as some might still call it.
|
|
0:08:02
|
We really didn't have the ability to watch individual
|
|
0:08:05
|
DNs. We were just able to watch the entire phone
|
|
0:08:07
|
and any DNs on that phone we would be able to as the watcher
|
|
0:08:12
|
see the status change. Once we got into six, we began
|
|
0:08:16
|
associating the individual users with the lines
|
|
0:08:20
|
the presentity or watchee or watched however you want to call it
|
|
0:08:24
|
persons their DNs or users per DN, users per line, so remember
|
|
0:08:30
|
a line is a DN that's applied to a phone device.
|
|
0:08:33
|
And that gave us the much more granular control to
|
|
0:08:35
|
say, 'Hey if this person down here at the bottom left
|
|
0:08:38
|
James wants to watch this person up here
|
|
0:08:41
|
Ben for instance
|
|
0:08:46
|
we can be very granular if Ben has six lines and
|
|
0:08:48
|
each of them are for different business units and James should
|
|
0:08:52
|
only watch one of those, we can be granular per line.
|
|
0:08:57
|
So also, another thing we can do just on the phones without
|
|
0:09:00
|
needing to involve the CUP server yet is
|
|
0:09:04
|
we also have the ability to see BLF speed dial changes or
|
|
0:09:09
|
sorry, not BLF speed dial, but Busy Lamp Field changes as
|
|
0:09:12
|
it were called for call history list, so whether we
|
|
0:09:17
|
were on missed calls, placed calls, received calls
|
|
0:09:22
|
or even the corporate directory
|
|
0:09:25
|
as long as one of those four as long as the
|
|
0:09:29
|
user inside that we're watching is an internal user obviously
|
|
0:09:35
|
if they're out on the PSTN unless we have some sort of
|
|
0:09:38
|
SIP trunk to a provider and agreement for SIP simple
|
|
0:09:43
|
status or presence type messages back and forth
|
|
0:09:47
|
then we're not really talking about the PSTN too much in any way.
|
|
0:09:51
|
We're talking about internal users registered all in the same
|
|
0:09:54
|
cluster and this also goes between clusters as well and
|
|
0:09:58
|
this capability gets much more enhanced in version
|
|
0:10:02
|
8.0, 8.5, 9 etc.
|
|
0:10:07
|
In version 7, there is certainly some limited
|
|
0:10:10
|
status between clusters in terms of watching and
|
|
0:10:14
|
and being able to be watched it's really not that difficult
|
|
0:10:18
|
between CUCM clusters; however, the actual CCIE
|
|
0:10:23
|
voice lab is unlikely to have multiple clusters
|
|
0:10:26
|
multiple two or three -- not that it's impossible, they certainly
|
|
0:10:31
|
could, in fact, they could have a backbone cluster
|
|
0:10:35
|
that you're not responsible for configuring, but has a
|
|
0:10:39
|
phone hanging off of it simply for setting up things
|
|
0:10:42
|
like SIP trunks between or ICT trunks, but I think it's
|
|
0:10:49
|
less likely and I think it's a lot less likely even more so
|
|
0:10:53
|
than that, that you would have multiple clusters that
|
|
0:10:56
|
you would be responsible for configuring mainly because
|
|
0:11:00
|
there's already enough work for you to do and that would
|
|
0:11:03
|
add a lot more additional work that wouldn't really prove
|
|
0:11:06
|
that much benefit in terms of proving your expertise
|
|
0:11:11
|
any more.
|
|
0:11:14
|
However, we can do some watching. In terms of watching
|
|
0:11:17
|
between CUCM and CME, so the Unified Commutations
|
|
0:11:23
|
manager and express, there is the ability to
|
|
0:11:28
|
set up a SIP trunk between those two and to do
|
|
0:11:32
|
or to configure watching on both sides the BLF speed dial
|
|
0:11:38
|
will actually only work one way in the versions that we have
|
|
0:11:41
|
in the lab, so with CUCM 7.0.1 and CME either 7.0.0 which
|
|
0:11:49
|
is 124 20 T or CME 7.0.1 which is IOS 124 22 T
|
|
0:11:58
|
either one of which they could have in the lab
|
|
0:12:00
|
and you could be presented with either one, they only
|
|
0:12:07
|
work really one way, so I think it's less likely that
|
|
0:12:10
|
you would see that, you could see -- certainly you could see
|
|
0:12:13
|
presence within CME and you certainly probably will see some
|
|
0:12:17
|
form of presence within just CUCM.
|
|
0:12:22
|
And another option is that we have CUCM
|
|
0:12:25
|
pushing that presence status as requested
|
|
0:12:28
|
as subscribed to, to the CUP server
|
|
0:12:31
|
and this will be useful for things like we see here
|
|
0:12:35
|
which is the IP phone agent that we'll configure in just a little bit
|
|
0:12:40
|
so the IP phone agent is an IP phone service or XML
|
|
0:12:44
|
service that is subscribed to -- from the actual phone
|
|
0:12:50
|
and we can run right on the phone display as
|
|
0:12:53
|
well as the other option and something we'll probably
|
|
0:12:56
|
likely see in the lab if we see tasks related to presence
|
|
0:12:58
|
is the CUPC or Cisco Unified Personal Communicator
|
|
0:13:05
|
running as either soft or desk phone control
|
|
0:13:09
|
probably both,
|
|
0:13:10
|
on the Windows XP Utility machine in our lab environment
|
|
0:13:18
|
and both of these require CUPS
|
|
0:13:21
|
but as far as the lab, these are the only two things
|
|
0:13:23
|
that require the CUP server, the IP phone agent
|
|
0:13:27
|
which is configured on CUCM as a XML service and subscribed
|
|
0:13:33
|
to for the phones on the CUCM, but actually the service points
|
|
0:13:38
|
to the CUP server and it requires the CUP server
|
|
0:13:41
|
and then the CUPC.
|
|
0:13:43
|
So Cisco Unified Presence in general not a real
|
|
0:13:47
|
large point section of the exam, probably not going to be
|
|
0:13:49
|
a very big part of it at all.
|
|
0:13:52
|
It certainly could be worth a few points, maybe five
|
|
0:13:56
|
I mean I would think outside tops would be like eight
|
|
0:13:59
|
or nine points, maybe ten, but I honestly don't see
|
|
0:14:03
|
it going that high. First of all, there's not a lot to do
|
|
0:14:07
|
it's really not that difficult to configure, so it's one of those
|
|
0:14:11
|
things that if you just in your own lab
|
|
0:14:15
|
self-study time practice 15 to 20 times repetitiously
|
|
0:14:21
|
preferably all fairly close to each other so that you
|
|
0:14:25
|
build that sort of muscle memory. I really think that
|
|
0:14:28
|
presence can be an easy few points added onto you
|
|
0:14:31
|
any exam.
|
|
0:14:33
|
It should not be difficult at all. It should be one --
|
|
0:14:35
|
viewed as one of those things that is what I call
|
|
0:14:38
|
low hanging fruit, so something that's easy to reach up and grab
|
|
0:14:41
|
those points.
|
|
0:14:42
|
So there's two types of presence tested as we mentioned.
|
|
0:14:45
|
There's the CUCM presence standalone so those things
|
|
0:14:48
|
that can be configured without CUPS which are the BLF speed
|
|
0:14:51
|
dial and BLF call history lists and then the components which
|
|
0:14:55
|
require the CUP server, the CUPC and the IP phone messenger
|
|
0:15:00
|
or IPPM.
|
|
0:15:03
|
So we already mentioned this, CUCM is the heart of all
|
|
0:15:06
|
presence status updates everyone's -- sorry, every one phone's
|
|
0:15:10
|
and CUPS subscribed to the CUCM for status
|
|
0:15:13
|
so we've already mentioned all the components, the CUPC
|
|
0:15:16
|
and IP phone messenger
|
|
0:15:19
|
so looking at the presence components within CUCM.
|
|
0:15:22
|
The BLF speed dials and call history lists
|
|
0:15:25
|
which call history lists are not enabled by default
|
|
0:15:28
|
you need to enable these globally for all phones in
|
|
0:15:34
|
enterprise parameters, not service parameters.
|
|
0:15:37
|
For a BLF speed dial to work, the only thing that we really
|
|
0:15:41
|
need for it to work is the watcher, the person doing the
|
|
0:15:46
|
watching, so the person with the BLF speed dial on their phone
|
|
0:15:50
|
needs to have a subscribe calling search space set up on their
|
|
0:15:55
|
phone device that contains the partition of the presentity
|
|
0:16:02
|
or the DN being watched.
|
|
0:16:05
|
We don't need anything like presence groups although there
|
|
0:16:08
|
is a default presence group and it's a required field
|
|
0:16:13
|
on every device and it's actually already set to the
|
|
0:16:15
|
default presence group on every device, gateways
|
|
0:16:19
|
and trunks and phones alike
|
|
0:16:23
|
we don't really have to have any sort of proper
|
|
0:16:26
|
presence group set up in order for BLF speed dials to
|
|
0:16:29
|
work, so for instance, if I have multiple presence
|
|
0:16:32
|
groups and they -- and let's say I have -- I'm on phone A
|
|
0:16:39
|
and I'm watching DN 3001
|
|
0:16:42
|
and my subscribe CSS on my phone A device contains
|
|
0:16:47
|
the partition of 3001 and the DN of 3001 or at least
|
|
0:16:52
|
the phone that contains that DN has a presence group
|
|
0:16:57
|
B and I have presence group A and those have a
|
|
0:17:00
|
disallow subscription I will still be able to see DN 3001
|
|
0:17:05
|
as it has state changes.
|
|
0:17:09
|
So it doesn't matter what presence group whether I'm
|
|
0:17:12
|
in the same or a different allow or disallow subscription
|
|
0:17:16
|
between the inter-presence group subscribe or subscription
|
|
0:17:21
|
policy has no bearing on just plain BLF speed dials.
|
|
0:17:26
|
So presence groups are needed for BLF call history
|
|
0:17:30
|
lists and corporate directory to work and they're needed for
|
|
0:17:34
|
CUPS applications and of course the relationship
|
|
0:17:38
|
is allow and disallow between them.
|
|
0:17:41
|
So there's no way to control relationship
|
|
0:17:44
|
within a presence group, so if I have two entities
|
|
0:17:48
|
two phones in the same presence group, there's no
|
|
0:17:51
|
way other than subscribe CSS and watched or presentity
|
|
0:17:56
|
partition to control intra or within
|
|
0:18:00
|
presence group subscriptions.
|
|
0:18:05
|
However, between presence groups if I set them up by default
|
|
0:18:09
|
and we'll see this in the demo, they just like most other things
|
|
0:18:14
|
in CUCM, have the default subscription policy
|
|
0:18:19
|
which goes back to service parameters and in service
|
|
0:18:22
|
parameters, the default is to disallow subscription
|
|
0:18:25
|
so if I create four different presence groups, by default,
|
|
0:18:28
|
they cannot subscribe to one another for call history
|
|
0:18:31
|
lists and corporate directories.
|
|
0:18:33
|
I can change the default to allow which sort gets rid
|
|
0:18:37
|
of the whole reason to have presence groups unless
|
|
0:18:41
|
I guess of course you want to have a lot of
|
|
0:18:43
|
presence groups and you want them all to be allowed
|
|
0:18:45
|
but you want to configure a few explicitly for disallow
|
|
0:18:48
|
but typically most people leave all presence groups to
|
|
0:18:52
|
disallow and then configure a few to be able to explicitly allow.
|
|
0:18:59
|
Looking at a few specifics, so we already mentioned this.
|
|
0:19:01
|
The BLF speed dial, the only thing necessary is that a watcher
|
|
0:19:04
|
has the subscribe CSS that contains the presentity DN's
|
|
0:19:07
|
partitions. For BLF call history lists
|
|
0:19:10
|
we normally need the inter-presence group allow
|
|
0:19:13
|
subscription as we just mentioned as well as a subscribe CSS
|
|
0:19:18
|
to see the presentity's DNs partition, however, there's a
|
|
0:19:21
|
few exceptions.
|
|
0:19:22
|
If the watcher already has a BLF speed dial to that
|
|
0:19:26
|
given presentity that they're looking for in the BLF
|
|
0:19:29
|
or sorry, in the call history list or corporate
|
|
0:19:32
|
directory, then it doesn't really matter what the
|
|
0:19:34
|
inter-presence subscribe policy states, the watcher
|
|
0:19:38
|
can see the BLF call history list for that user.
|
|
0:19:40
|
So if I have a subscribe CSS that allows me to see DN
|
|
0:19:45
|
3001, the partition
|
|
0:19:47
|
and I have that BLF speed dial configured on my device
|
|
0:19:52
|
then I will also be able to see that user in call history list even
|
|
0:19:57
|
though they have presence group B, I have presence
|
|
0:19:59
|
group A and there's a disallow between them.
|
|
0:20:03
|
Now, conversely if I had presence group A
|
|
0:20:07
|
they had presence group B on their device, we have
|
|
0:20:10
|
disallow between us, actually they have
|
|
0:20:12
|
presence group B on their -- not their device, but their
|
|
0:20:15
|
line. The one on the device is used for you looking to another
|
|
0:20:20
|
entity, the one on the line is used for the presentity
|
|
0:20:25
|
that I'm trying to watch
|
|
0:20:28
|
but we've got two different presence groups. Me on the
|
|
0:20:31
|
device, them on the line I'm trying to see their
|
|
0:20:34
|
3001 in call history lists, the two presence groups have
|
|
0:20:38
|
disallow and I do not yet have a BLF speed dial
|
|
0:20:41
|
for that given DN even if I have a subscribe CSS
|
|
0:20:47
|
that can see that partition, then that's where the presence group
|
|
0:20:51
|
disallow subscription will not allow me to see their call
|
|
0:20:54
|
history list, but if I added that subscribe -- I'm sorry that
|
|
0:20:57
|
BLF speed dial to my phone device, then I would be able to
|
|
0:21:01
|
see it even in call history lists.
|
|
0:21:03
|
Another thing, another exception is that if a
|
|
0:21:06
|
presentity has a shared line with a remote destination
|
|
0:21:10
|
profile or mobile connect or single number reach
|
|
0:21:14
|
then they will be able to be watched via
|
|
0:21:17
|
BLF call history lists
|
|
0:21:19
|
again, regardless of the inter-presence subscribe policy.
|
|
0:21:22
|
The subscribe CSS for let's say me the watcher still
|
|
0:21:27
|
is required. That's always required.
|
|
0:21:30
|
Ok, but if they have a shared line with remote destination
|
|
0:21:34
|
profile, then they will be able to be watched
|
|
0:21:37
|
in call history lists.
|
|
0:21:40
|
So taking a look at the CUP server.
|
|
0:21:43
|
There's a detailed process to perform the integration.
|
|
0:21:45
|
Looking at that version 3 blueprint, the only thing
|
|
0:21:48
|
that we actually see mentioned
|
|
0:21:52
|
regarding integration
|
|
0:21:55
|
is specifically with the presence server with
|
|
0:21:58
|
CUPS, so when we were talking about Unity Connection
|
|
0:22:06
|
and UCCX, we mentioned how those servers would
|
|
0:22:10
|
likely and were -- really we were informed that they would
|
|
0:22:14
|
be pre-integrated for us whether they worked properly or not
|
|
0:22:17
|
is another story, whether we have to troubleshoot
|
|
0:22:19
|
them, but mostly they would be pre-integrated for us.
|
|
0:22:25
|
However, presence server the integration is really
|
|
0:22:28
|
much of the task.
|
|
0:22:32
|
Setting up UPC
|
|
0:22:34
|
the Unified Personal Communicator and the IP phone messenger really
|
|
0:22:38
|
isn't that much of much more configuration
|
|
0:22:43
|
beyond the actual integration and making sure that the
|
|
0:22:46
|
two servers can talk to each other.
|
|
0:22:48
|
Now there is sort of two steps to the CUPS
|
|
0:22:51
|
integration with CUCM.
|
|
0:22:53
|
The first step is as soon as you spin the disks
|
|
0:22:57
|
the DVDs to build the presence server
|
|
0:23:00
|
and you boot it up for the first time and you go to the
|
|
0:23:03
|
web page, the administration web page, there's sort of a
|
|
0:23:06
|
little flash -- not Adobe flash type thing, but there's sort of a
|
|
0:23:11
|
little splash screen, a little pre-integration wizard that
|
|
0:23:15
|
you have to run through and I think it's either three
|
|
0:23:17
|
or four pages long.
|
|
0:23:19
|
But it basically asks what is the host name and IP
|
|
0:23:24
|
address of the CCM publisher server.
|
|
0:23:28
|
What's the AXL admin or AXL user name and password
|
|
0:23:34
|
and it also needs to know what the actual host name
|
|
0:23:36
|
is of the CUP server as well itself
|
|
0:23:40
|
and whether it's going to be a fully qualified domain name
|
|
0:23:42
|
whether using DNS or not
|
|
0:23:44
|
and in order to get that to work, you have to
|
|
0:23:48
|
have already created or defined an application server
|
|
0:23:53
|
with the host name of the CUP server back in CUCM.
|
|
0:23:57
|
So back in the system column and then down to application
|
|
0:24:00
|
server we have to have already created for the type
|
|
0:24:04
|
server CUPS we have to have created the actual
|
|
0:24:07
|
host name there
|
|
0:24:09
|
and then that little three or four page -- I think
|
|
0:24:12
|
it's three-page pre-integration wizard is allowed to be run.
|
|
0:24:17
|
We've already run that particular -- it's just called the
|
|
0:24:21
|
post installation script, we've already run that
|
|
0:24:24
|
on our racks and so when you go to use the CUP server
|
|
0:24:27
|
on our racks, that portion is already done for you.
|
|
0:24:29
|
The lab very well may also have that particular
|
|
0:24:33
|
three-page post installation script done for you. It may
|
|
0:24:36
|
not and it's difficult if it doesn't. In fact, the most difficult
|
|
0:24:40
|
thing is -- it's not difficult to find the host name of the
|
|
0:24:44
|
CUCM or CUP server, you just need to if nowhere else
|
|
0:24:50
|
you can find them, just SSH so RDP or Remote Desktop
|
|
0:24:54
|
Protocol over to your XP machine
|
|
0:24:56
|
in the lab and then you will have Putty and the
|
|
0:24:59
|
ability to SSH into both the CUCM publisher
|
|
0:25:03
|
and the CUP server and type show myself.
|
|
0:25:08
|
Show myself and that will show you the host name
|
|
0:25:10
|
of each server respectively.
|
|
0:25:13
|
And then you'll be able to fill in all the rest of the
|
|
0:25:14
|
info, add that application server for CUPS to the CUCM
|
|
0:25:21
|
and that three-page post installation script is not a
|
|
0:25:24
|
big deal.
|
|
0:25:28
|
But again, it might be done for you in the lab.
|
|
0:25:30
|
Pass that, then I would recommend first of all using the CUPS installation
|
|
0:25:37
|
guide quick checklist to ensure that you cover
|
|
0:25:39
|
each configuration task and in the correct order
|
|
0:25:43
|
some have to be done in the correct order, there are
|
|
0:25:46
|
certain prerequisites for others to be done, but
|
|
0:25:49
|
mostly they could be done in just about any order.
|
|
0:25:51
|
The important thing is that you don't miss any step and
|
|
0:25:54
|
the problem or I should say challenge or difficulty
|
|
0:25:58
|
not really a problem is that you find yourself
|
|
0:26:01
|
in all different parts of the CUCM server back and forth
|
|
0:26:06
|
from the left columns of system over to the right
|
|
0:26:09
|
columns of device and users etc.
|
|
0:26:12
|
and then back and forth to the CUP server as well and
|
|
0:26:14
|
we'll go over some of the steps in the slides here
|
|
0:26:17
|
and then we certainly will do all of them together in the
|
|
0:26:20
|
demonstration, so we're not going to leave you hanging, but I would recommend
|
|
0:26:23
|
looking at that checklist just to make sure that you
|
|
0:26:27
|
don't miss anything. Again, I would also recommend that
|
|
0:26:30
|
you do this integration maybe spend two or three days
|
|
0:26:35
|
and do nothing but CUPS integration just get very fast at it. In fact,
|
|
0:26:40
|
one of the things we're going to talk about in strategy is
|
|
0:26:42
|
sort of a best practice on how to go about practicing some
|
|
0:26:48
|
of the things such as this that just doing two or three
|
|
0:26:54
|
or four days in a row of the same thing and having
|
|
0:26:57
|
a high degree of repetition almost to the point of boredom
|
|
0:27:01
|
almost to the point where you could -- well actually not
|
|
0:27:04
|
almost, but literally to the point where you become
|
|
0:27:06
|
bored with it, you can do it in your sleep
|
|
0:27:08
|
without thinking about it. That's the kind of muscle
|
|
0:27:11
|
memory that we want to build and even if you do that
|
|
0:27:14
|
let's say three months before your next lab attempt
|
|
0:27:17
|
and don't it again until two weeks before your lab attempt
|
|
0:27:20
|
you'll find two weeks before your lab is you're working through
|
|
0:27:24
|
any eight-hour practice multiprotocol mock lab
|
|
0:27:27
|
that your CUPS integration and things of that nature
|
|
0:27:30
|
things that just require a high degree of repetition
|
|
0:27:33
|
to remember that it comes back to you very easily.
|
|
0:27:38
|
So again, it's not a difficult process, it's quite quick and
|
|
0:27:40
|
it's the same tasks every time, so these should be easy points
|
|
0:27:44
|
just use the checklist to make sure you don't forget anything.
|
|
0:27:47
|
Most common scenarios in the lab regarding the
|
|
0:27:52
|
CUPS server would involve obviously the soft phone, the
|
|
0:27:55
|
CUPC, CUPC for desk phone control where it actually
|
|
0:28:00
|
asserts CTI control over the desk phone instead of being used as a
|
|
0:28:03
|
standalone soft phone and one of the major differences
|
|
0:28:06
|
being with soft phone mode, it is a shared line with your
|
|
0:28:11
|
primary desk phone, but all the RTP and signaling
|
|
0:28:15
|
comes to your laptop and it's probably mostly
|
|
0:28:19
|
most often used when you're travelling
|
|
0:28:21
|
or away from your desk and then when you're back
|
|
0:28:24
|
at your desk, you can just click the little icon select
|
|
0:28:27
|
desk phone control and use it as a great presence tool
|
|
0:28:32
|
directory look-up tool as well as Voice mail
|
|
0:28:36
|
kind of sort of preview tool
|
|
0:28:39
|
in conjunction with your desk phone, so if you go to
|
|
0:28:41
|
make a call or see someone's presence, right click and say
|
|
0:28:44
|
call this person, it will actually trigger your desk phone to
|
|
0:28:47
|
do the ringing, the RTP stream and SIP or skinny
|
|
0:28:51
|
signaling will go back and forth between your desk phone
|
|
0:28:53
|
and CUCM and then just the SIP simple messaging
|
|
0:28:57
|
will go back for presence back and forth between
|
|
0:29:00
|
your CUPC and your actual CUP server.
|
|
0:29:09
|
So note that some of these required dependencies
|
|
0:29:11
|
on other servers other than just CUPS, most often the CUCM.
|
|
0:29:14
|
One of them dealing with Voice mail integration or
|
|
0:29:17
|
being able to see message waiting indicator, number of
|
|
0:29:21
|
messages, previews to those message, listen to those messages
|
|
0:29:25
|
that requires a dependency on that particular CUPC
|
|
0:29:29
|
or Cisco Unified Personal Communicator
|
|
0:29:33
|
software phone and user having a user/voice mailbox
|
|
0:29:39
|
on the Unity Connection server
|
|
0:29:42
|
and for that particular user, each user has a class of service
|
|
0:29:48
|
and we need to make sure that the class of service
|
|
0:29:51
|
has IMAP control enabled
|
|
0:29:54
|
for that class of service for whatever user.
|
|
0:29:59
|
Ok, so looking at a brief checklist for CUCM
|
|
0:30:02
|
to integrate the CUP server.
|
|
0:30:04
|
We need to make sure we have a user assigned to the
|
|
0:30:07
|
device. The owner user ID set on the device actually
|
|
0:30:11
|
user assigned to the line and the owner user ID
|
|
0:30:13
|
set on the device.
|
|
0:30:14
|
Standard CTI enabled
|
|
0:30:18
|
which is on by default.
|
|
0:30:20
|
A primary extension needs to define -- be defined on the
|
|
0:30:23
|
actual user for the end user.
|
|
0:30:26
|
In order to allow desk phone control, we need to
|
|
0:30:32
|
have -- and really, there are two application users
|
|
0:30:36
|
defined in CUCM and we'll see these application user names
|
|
0:30:40
|
at least the defaults already in the CUPC -- or sorry the CUP server
|
|
0:30:45
|
so it's easy to copy the name out of there. I would highly
|
|
0:30:48
|
recommend using Notepad both for the user names
|
|
0:30:52
|
one as we see here is the CTI GW
|
|
0:30:56
|
and capitalization is required. You could change it on the
|
|
0:31:03
|
CUP server, so it doesn't have to stay capital CTI
|
|
0:31:06
|
capital GW, however, just make sure that whatever's
|
|
0:31:10
|
on the CUP server and what's over on the CUCM
|
|
0:31:13
|
server match, so I would highly recommend Notepad
|
|
0:31:16
|
copy and paste for both the users, but then also
|
|
0:31:19
|
you're going to have a password and confirm password
|
|
0:31:23
|
for each user on each server.
|
|
0:31:26
|
So that's two passwords -- let's say cisco and confirm
|
|
0:31:30
|
cisco for the CTI gateway user on the CUP server, so
|
|
0:31:34
|
that's two, then there's the phone messenger
|
|
0:31:37
|
user for the IP phone messenger application and so that's two more
|
|
0:31:42
|
passwords on the CUP server and then you have those same
|
|
0:31:46
|
two users with their password and confirm password
|
|
0:31:49
|
over on the CUCM application user, so that's eight times you're
|
|
0:31:54
|
putting it in. If you just put it into Notepad cisco and then
|
|
0:31:58
|
copy it from Notepad and paste it into your eight separate
|
|
0:32:01
|
fields on the two separate servers, it's going to save
|
|
0:32:06
|
a lot of headache in terms of troubleshooting did I
|
|
0:32:10
|
accidentally key in the wrong password, did you get moving fast
|
|
0:32:14
|
with your fingers and type in cisoc or something like
|
|
0:32:18
|
that on one server, but on the other server cisco
|
|
0:32:21
|
something like that.
|
|
0:32:24
|
We'll also on the CUCM server need a SIP trunk
|
|
0:32:27
|
pointing to CUPS. It needs to be a
|
|
0:32:29
|
CUP publish trunk, so we need to enable in CUCM
|
|
0:32:34
|
or CCM call manager service parameters
|
|
0:32:38
|
that particular SIP trunk as the CUP publish trunk.
|
|
0:32:44
|
On CUCM under the system column, we need license capabilities
|
|
0:32:47
|
assignments for CUPS users and there's multiple
|
|
0:32:53
|
multiple status or I should say multiple entities that we can
|
|
0:32:56
|
define or enable for licensing. We can enable a single presence
|
|
0:33:01
|
in general which would be enough for the IP phone
|
|
0:33:03
|
messenger or if they're going to have a CUPC
|
|
0:33:06
|
soft or desk phone mode, they not only need presence, but
|
|
0:33:09
|
they also need CUPC licensing.
|
|
0:33:15
|
Again, the application server defined in CUCM under the system
|
|
0:33:18
|
column that should have already been done.
|
|
0:33:22
|
In terms of the personal communicator, the client that
|
|
0:33:25
|
does run on the Windows XP Utility machine
|
|
0:33:28
|
you should complete all of your integration before
|
|
0:33:31
|
trying to launch it.
|
|
0:33:32
|
I've actually said this at one point to log in with the
|
|
0:33:36
|
IP address of CUPS, not the host name just initially
|
|
0:33:40
|
to test and see if everything's working, I would probably
|
|
0:33:44
|
take that back at this point. You're going to need the fully
|
|
0:33:47
|
qualified domain name even if you're not using
|
|
0:33:49
|
DNS. You're going to need at least the host name
|
|
0:33:55
|
if the CUP server regardless of whether it's using DNS
|
|
0:33:58
|
or not, if the CUP server has only a host name set
|
|
0:34:02
|
then you will need to be able to log in from your
|
|
0:34:05
|
XP machine from the CUPC client with that host name
|
|
0:34:09
|
ultimately, so I used to say you could log in with the
|
|
0:34:12
|
IP address initially just to make sure that you could get
|
|
0:34:14
|
the integration, at this point I think that's probably just wasting
|
|
0:34:17
|
time, wasting a few seconds just to see if it'll log in because
|
|
0:34:21
|
with just the IP address, you really won't get the status
|
|
0:34:26
|
or presence updates from CUPS unless you change the host name
|
|
0:34:30
|
to an IP address in CUPS and reboot that
|
|
0:34:33
|
and I wouldn't really recommend that at this point. It's easy enough
|
|
0:34:36
|
on your XP test utility machine in the lab to open up Notepad
|
|
0:34:41
|
specifically go to start run and we'll do this in demo
|
|
0:34:45
|
and type notepad space c:\windows \system32\drivers\etsy\hosts
|
|
0:34:58
|
so open that host file and simply put in the host name
|
|
0:35:01
|
and IP address to resolve locally of that CUP server.
|
|
0:35:07
|
But another thing, again even if the CUP server isn't
|
|
0:35:10
|
running DNS, however, if the CUP server does have a domain
|
|
0:35:14
|
name like let's say it has cisco.com so maybe the
|
|
0:35:18
|
fully qualified domain name is cups7.cisco.com
|
|
0:35:23
|
then I would recommend in your host file on your XP
|
|
0:35:25
|
client machine to put in two lines. One with just the host name
|
|
0:35:31
|
resolving to the IP address of CUPS and another with the
|
|
0:35:34
|
fully qualified domain name also resolving to the same IP
|
|
0:35:37
|
address of CUPS, so you can resolve by host and/or
|
|
0:35:41
|
fully qualified domain name.
|
|
0:35:43
|
Then you'll log in with the user name and password that you
|
|
0:35:46
|
set in CUCM, CUPS is doing proxy authentication
|
|
0:35:50
|
you're actually logging in through CUCM, it's kind of
|
|
0:35:53
|
a joint effort. You're getting TFTP information on your CUPC
|
|
0:35:57
|
client for or from the CCM server. If you're logging in
|
|
0:36:02
|
with soft phone mode, you're actually logging into a download
|
|
0:36:07
|
the TFTP configuration from CCM server and
|
|
0:36:12
|
and all signaling is going back and forth between
|
|
0:36:15
|
CCM and if you're logging in for desk phone mode or
|
|
0:36:18
|
switch to control of that, then you're going through the
|
|
0:36:21
|
CUP server and CTI is being controlled to your desk phone.
|
|
0:36:28
|
You need to check to make sure both soft and desk phone
|
|
0:36:31
|
mode work. If I was only told to do one of those two
|
|
0:36:35
|
in the lab, I honestly would have as I mentioned
|
|
0:36:40
|
done so many repetitions in my self-study practice
|
|
0:36:42
|
that I would probably be just as quick, if not maybe even
|
|
0:36:49
|
quicker at going ahead and setting up soft phone and desk phone
|
|
0:36:54
|
as opposed to just setting up one or the other if I was only
|
|
0:36:58
|
instructed one or the other, so unless I was given any
|
|
0:37:01
|
restrictions not to, I would just go ahead and set up both.
|
|
0:37:06
|
I would recommend that you just be practiced, ready
|
|
0:37:09
|
and extremely quick proficient at setting up both soft phone and
|
|
0:37:13
|
desk phone control mode and that you cover your
|
|
0:37:16
|
basis, you're ready for whatever even if they only asked you one.
|
|
0:37:18
|
I would still do both.
|
|
0:37:20
|
If let's say they only asked me for soft phone mode for instance
|
|
0:37:24
|
and I went ahead and set up both, but I couldn't get desk phone
|
|
0:37:27
|
control to work, I wouldn't sit there and troubleshoot it
|
|
0:37:30
|
if they hadn't explicitly asked me to.
|
|
0:37:32
|
Now if it's kind of unclear if they're asking you to set up
|
|
0:37:35
|
soft phone or desk phone or possibly both, but you're not really sure
|
|
0:37:39
|
well, then I would -- one: you can always ask the proctor
|
|
0:37:43
|
for clarification and we'll talk a little bit more about how to
|
|
0:37:46
|
approach a proctor and how to get good information from them
|
|
0:37:48
|
in the section on strategy
|
|
0:37:51
|
but assuming that I didn't get great information back or
|
|
0:37:57
|
they weren't able to help me too much, then I would
|
|
0:37:59
|
go ahead and work on both.
|
|
0:38:02
|
Again, anything you're working on in the lab you shouldn't spend
|
|
0:38:04
|
too much time either configuring it or troubleshooting it
|
|
0:38:08
|
especially in relation to the point value.
|
|
0:38:12
|
For Unified Personal Communicator make sure that you use on the actual
|
|
0:38:15
|
client itself, the help and show server health to check
|
|
0:38:20
|
for any issues and we'll look at this and there's also some troubleshooting
|
|
0:38:22
|
tools that you can use on the actual CUP server to check for
|
|
0:38:27
|
desk phone control mode which is almost always the
|
|
0:38:29
|
mode that has the most issues or potential problems
|
|
0:38:36
|
and then also be sure that on the CUPC client under
|
|
0:38:40
|
Tools> Preferences that you use or it might be under
|
|
0:38:43
|
File Preferences actually that you enter the Voice mail
|
|
0:38:47
|
login information, so it's not enough just to enable IMAP
|
|
0:38:50
|
control and an IMAP profile on the connection, Unity Connection
|
|
0:38:55
|
server and CUP server respectively, but also on the CUPC client you of course
|
|
0:39:00
|
have to enter your user name and password,
|
|
0:39:04
|
Looking at the presence configuration checklist
|
|
0:39:09
|
there's a couple things about this, so one easy way to get
|
|
0:39:13
|
CUPC clients all of them to work with -- there's really
|
|
0:39:17
|
really actually both ways are quite easy if you ask me.
|
|
0:39:20
|
One way is to deal with inbound outbound access lists on
|
|
0:39:25
|
CUPC, now for servers that are being dynamically integrated
|
|
0:39:30
|
with the CUP server specifically the CCM Pub and Sub or any
|
|
0:39:36
|
subscriber servers in -- database subscriber servers I should say
|
|
0:39:40
|
CPE Call Processing Engine servers
|
|
0:39:43
|
related to CCM during the integration, there should
|
|
0:39:47
|
be explicit host allow statements both inbound and outbound
|
|
0:39:55
|
under the access list portion of the CUP server for each of
|
|
0:39:59
|
those call processing engines, each of those CUCM servers.
|
|
0:40:03
|
We will absolutely need to create an inbound and outbound access
|
|
0:40:08
|
list or entry for the Voice mail server so the Unity Connection
|
|
0:40:13
|
and it should be a host, so it shouldn't be a /24
|
|
0:40:18
|
for all the servers on the server subnet, I mean that's perfectly
|
|
0:40:22
|
fine I suppose if you have a dedicated standalone voice server
|
|
0:40:27
|
subnet in real life, but in the lab probably just easiest to put in
|
|
0:40:31
|
the host address of Unity Connection.
|
|
0:40:33
|
But in terms of the ability for all of the personal communicators
|
|
0:40:38
|
to speak back and forth with CUPS with the actual
|
|
0:40:42
|
CUP server, there's an easy way to create an entry
|
|
0:40:46
|
for inbound and outbound access lists called ALL, capital A, L, L
|
|
0:40:51
|
all caps
|
|
0:40:53
|
and this is basically a permit IP any any
|
|
0:40:56
|
and in a production network this would not be a very desired
|
|
0:41:01
|
thing to configure security wise
|
|
0:41:03
|
but it is one way to get it to work and certainly not too difficult
|
|
0:41:08
|
to do in the lab.
|
|
0:41:09
|
Another thing that's not too difficult and much more
|
|
0:41:11
|
secure is that per user
|
|
0:41:14
|
per end user back in CCM.
|
|
0:41:17
|
The users that will be assigned CUPS and CUPC licensing and
|
|
0:41:23
|
be allowed to have soft phone or desk phone control
|
|
0:41:27
|
whenever we're configuring those users and again, we'll do this
|
|
0:41:30
|
in the demo. Make sure that you not only configure
|
|
0:41:34
|
a password and confirm that password, but also configure
|
|
0:41:38
|
digest credentials and confirm those digest credentials.
|
|
0:41:43
|
It doesn't even have to be the same thing as the password
|
|
0:41:46
|
It's just that whatever the digest credential and confirm
|
|
0:41:49
|
have to be the same and they basically just have to
|
|
0:41:52
|
exist, but it's easy enough to have a password of cisco
|
|
0:41:55
|
so copy paste the password of cisco, confirm password cisco
|
|
0:41:59
|
digest credentials cisco, confirm digest credentials cisco
|
|
0:42:03
|
paste, paste, paste and you're done.
|
|
0:42:05
|
Then you don't have to have any inbound or outbound
|
|
0:42:09
|
access list entry for any one of the CUPC users that
|
|
0:42:14
|
has those digest credentials.
|
|
0:42:17
|
It's important to enter a domain name under the service
|
|
0:42:21
|
parameters for CUP server
|
|
0:42:23
|
but specifically the service parameters for proxy server
|
|
0:42:27
|
not the service parameter that says the presence agent.
|
|
0:42:32
|
Ok, so we'll take a look at that.
|
|
0:42:35
|
We need to add the CCM or CUCM gateway only the
|
|
0:42:38
|
Pub because we're only speaking back and forth
|
|
0:42:40
|
to the presence agents of the Pub and you really cannot
|
|
0:42:45
|
configure a redundant subscriber or anything like that.
|
|
0:42:50
|
And then to configure our soft phone desk phone settings for
|
|
0:42:52
|
CUPC and Voice mail integration.
|
|
0:42:57
|
So finally, before we move on to demo moving away from CUCM
|
|
0:43:01
|
and away from CUPS
|
|
0:43:04
|
and we talked about those for a while -- as I mentioned
|
|
0:43:08
|
they're really not difficult to do and we'll go over all the steps
|
|
0:43:11
|
in the demonstration, just wanted to make sure that everyone's clear
|
|
0:43:14
|
on everything so that's why we drew the conversation out just a little bit
|
|
0:43:18
|
but now looking to Cisco Unified Communication Manager
|
|
0:43:22
|
Express, so running on the IOS router, we do have the
|
|
0:43:25
|
ability to do presence.
|
|
0:43:28
|
Globally we configure under the sip-ua
|
|
0:43:31
|
we simply say presence enable.
|
|
0:43:35
|
Optionally, globally back again globally we can say presence enter and
|
|
0:43:40
|
just like in enterprise parameters in CUCM, we can optionally configure
|
|
0:43:44
|
BLF for history lists true. Here we can say presence call list
|
|
0:43:49
|
to not only allow speed dial, BLF speed dials to work
|
|
0:43:52
|
but also call history lists to work as well.
|
|
0:43:56
|
And again, just as a note on CUCM
|
|
0:43:59
|
not that this matters for the lab because the lab
|
|
0:44:01
|
only has 7965 phones
|
|
0:44:03
|
but just if you're practicing that with this on your own time
|
|
0:44:06
|
or you are -- maybe you have an older integration
|
|
0:44:13
|
and you're trying to get this to work on some older
|
|
0:44:15
|
phones, only Cisco type B phones support call history list or
|
|
0:44:21
|
-- well really, support BLF speed dials in general
|
|
0:44:24
|
and call history lists. It's really easy to tell
|
|
0:44:27
|
what a type B phone is. If it's got translucent buttons
|
|
0:44:30
|
to the side for the line buttons, then it's a type B phone.
|
|
0:44:34
|
So that includes 7941s and 61s
|
|
0:44:38
|
and newer, the 88s the 8900 series or 9900 series. It does not include
|
|
0:44:44
|
the 7940 so 4 0 or 7960
|
|
0:44:49
|
those have the solid line buttons not only do the
|
|
0:44:54
|
line buttons not have any BLF functionality, they don't have any
|
|
0:44:58
|
translucency, but you won't even get BLF to work with just
|
|
0:45:01
|
the little icon in the display and the call history lists do
|
|
0:45:05
|
not support it either for the same reason that the
|
|
0:45:08
|
call lists do not support the globalization. They
|
|
0:45:11
|
support localization, but they don't support globalization
|
|
0:45:14
|
that is looking back to the CUCM for the database of missed
|
|
0:45:19
|
calls and being able to therefore see the globalized number.
|
|
0:45:23
|
They look to their local phone for missed and received
|
|
0:45:26
|
calls and that's also the same reason why they
|
|
0:45:28
|
can't partake in call history lists, BLF speed dial call history
|
|
0:45:34
|
lists or BLF presence call history lists because they're looking
|
|
0:45:37
|
to a local copy. They're not looking back to the CUCM server
|
|
0:45:40
|
to see dynamic real time information.
|
|
0:45:44
|
Also the 7970s
|
|
0:45:47
|
although that is a zero at the end, that actually does
|
|
0:45:50
|
support -- it has translucent buttons to the side, it does support
|
|
0:45:54
|
BLF call history lists and speed dials. It is considered
|
|
0:45:57
|
a type B phone.
|
|
0:46:01
|
Back to CME
|
|
0:46:03
|
so here we just have a standard ephone DN
|
|
0:46:06
|
index two or tag two
|
|
0:46:08
|
number 3002
|
|
0:46:10
|
got a name on it and it has the allow watch.
|
|
0:46:13
|
So this allow watch is necessary for it to be
|
|
0:46:17
|
a presentity or a watchee the person being watched.
|
|
0:46:20
|
And then we have ephone 1
|
|
0:46:23
|
which is not -- it does not have a button mapped to
|
|
0:46:26
|
ephone 2 in terms of regular usage, its first button
|
|
0:46:30
|
is ephone DN 1 which is not pictured here
|
|
0:46:33
|
but then it's button 6 is set to watch W for watch
|
|
0:46:38
|
ephone DN 2
|
|
0:46:40
|
so we're watching DN 2, ephone DN 2 has allow watch
|
|
0:46:45
|
and globally we have presence enable.
|
|
0:46:48
|
Watch out or be aware I should say that there is
|
|
0:46:52
|
also -- so like we see here on ephone 1 we have button 1:1
|
|
0:46:56
|
6 W2, there's also 6 M2 to monitor to
|
|
0:47:00
|
that will not give you all the same functionality.
|
|
0:47:02
|
You may see some of the functionality in terms of
|
|
0:47:05
|
off hook, you might see go to a red state for your
|
|
0:47:09
|
translucent watched button line 6, but you won't see anything
|
|
0:47:13
|
like ringing.
|
|
0:47:16
|
And actually, that's one other note we'll go over
|
|
0:47:18
|
in the demo here next, but on CUCM we not only have
|
|
0:47:21
|
the ability for a BLF speed dial to watch the regular state changes
|
|
0:47:26
|
but if you scroll all the way over to the right on the
|
|
0:47:28
|
pop-up window like we'll see in just a moment
|
|
0:47:30
|
there is a tick box for call pickup and if we tick that
|
|
0:47:36
|
we'll not only see when a line goes from idle to busy
|
|
0:47:42
|
but if that line is ringing, we'll also see our translucent
|
|
0:47:46
|
BLF speed dial button flash rapidly to indicate that that other
|
|
0:47:50
|
line is ringing. Here on CME,
|
|
0:47:53
|
the 6 W2 as opposed to the 6 M2 will allow us to
|
|
0:47:58
|
see not only the line state normal, idle or busy, but
|
|
0:48:01
|
it will also allow us to see that ringing status as well.
|
