|
0:00:14
|
Let's go ahead and get into our tasks for today.
|
|
0:00:18
|
So, for module 6, 6.1
|
|
0:00:23
|
we'll begin by taking a look at IOS MTP
|
|
0:00:26
|
and we're instructed to provision both
|
|
0:00:29
|
the corporate headquarter router 1
|
|
0:00:31
|
and branch 1 which is router 2 routers
|
|
0:00:34
|
to support media termination point services
|
|
0:00:37
|
for up to 50 concurrent sessions.
|
|
0:00:40
|
However we're instructed to use any DSPs to accomplish this task
|
|
0:00:46
|
and to enable support on this MTPs for both
|
|
0:00:48
|
RSVP protocol, which we've looked at control admission control
|
|
0:00:54
|
and trusted relay point. What's trusted relay point?
|
|
0:00:58
|
Take a look at what that is.
|
|
0:01:02
|
So, taking a look at our corporate headquarter router,
|
|
0:01:09
|
let's begin by dumping in the configuration T
|
|
0:01:14
|
and in order to begin anything related to DSP farm,
|
|
0:01:19
|
we did mention that we DSP services DSP farm on the voice card, right?
|
|
0:01:25
|
But wait a minute, we were instructed not to use any DSPs to accomplish this task.
|
|
0:01:31
|
So we don't need to and don't want to do anything with
|
|
0:01:35
|
DSP farm or DSP services DSP farm
|
|
0:01:39
|
anything at all on the voice card interface because we're not using any DSPs.
|
|
0:01:45
|
So, now we need to take a look at
|
|
0:01:47
|
alright what do we need for DSP farm commands
|
|
0:01:51
|
Well, we've got the ability to create transcoder, conference bridge, we don't see
|
|
0:01:58
|
MTP though well that's because DSP farm conference bridge
|
|
0:02:03
|
and DSP farm transcoder
|
|
0:02:06
|
were the old commands that were used for the old PVDM
|
|
0:02:10
|
original generation one.
|
|
0:02:13
|
PVDM1 even though they were just called PVDMs.
|
|
0:02:18
|
So we don't use those commands if we're not dealing with
|
|
0:02:22
|
the original gen one PVDMs. For PVDM2s we create
|
|
0:02:27
|
DSP farm profiles.
|
|
0:02:30
|
So we assign a tag, profile ID
|
|
0:02:33
|
and then we have the ability to configure conference
|
|
0:02:37
|
MTP or media termination point
|
|
0:02:40
|
and transcoding. Well let's configure MTP
|
|
0:02:45
|
We could have security, but we're not dealing with security
|
|
0:02:49
|
We have a module all of its own.
|
|
0:02:52
|
Now we see so far resource provider not registered.
|
|
0:02:56
|
So in other words
|
|
0:02:58
|
the provider that's going to be or the
|
|
0:03:01
|
person that's gonna be providing the resources
|
|
0:03:04
|
to us CUCM server isn't yet registered.
|
|
0:03:08
|
So we have to do that and those are related to
|
|
0:03:11
|
the Skinny or SCCP commands
|
|
0:03:14
|
seeing as all DSP farm resources
|
|
0:03:19
|
are registered to CUCM servers
|
|
0:03:23
|
using, of course, their proprietary and very flexible
|
|
0:03:28
|
scalable because it's proprietary, they can add anything they want to it
|
|
0:03:31
|
protocol. So we'll get into that in just a little bit.
|
|
0:03:37
|
For right now we're in our DSP farm profile and we can
|
|
0:03:42
|
actually let's go ahead and do show run
|
|
0:03:45
|
pipe 2 section for DSP farm
|
|
0:03:51
|
And we that by default, we've got
|
|
0:03:54
|
a single Codec of G.711ulaw and it shut down
|
|
0:03:58
|
Any DSP farm profile that you create will be shut down by default.
|
|
0:04:03
|
Now we can only have one codec
|
|
0:04:05
|
active at any one time in an MTP
|
|
0:04:10
|
if we're not using any sort of
|
|
0:04:12
|
DSP resources, really just MTPs
|
|
0:04:16
|
If we need to have multiple codecs in sort of an MTP
|
|
0:04:20
|
That's where we have to get into the idea of a transcoder.
|
|
0:04:25
|
So a transcoder, hopefully everyone understands
|
|
0:04:28
|
that just for basic refresher
|
|
0:04:31
|
is the ability to take any codec
|
|
0:04:38
|
or hopefully we'll actually discuss which ones can be
|
|
0:04:41
|
transcoded to which others
|
|
0:04:43
|
but a certain type of a codec, be it voice
|
|
0:04:46
|
codecs or be then video codecs
|
|
0:04:49
|
and take them and transfer them
|
|
0:04:53
|
or transpose them is actually a better way to say it
|
|
0:04:56
|
typically refers to music but we can
|
|
0:04:58
|
transpose them into another codec
|
|
0:05:00
|
|
|
0:05:07
|
Codec being compress and decompress.
|
|
0:05:15
|
So transcoding is going from one codec
|
|
0:05:17
|
to another codec. It could even be going from
|
|
0:05:20
|
one codec to the same codec but a different sampling rate.
|
|
0:05:24
|
It's possible that using the theorem that was used to sample
|
|
0:05:30
|
the audio source or possibly the video source
|
|
0:05:33
|
but they were at a different rates, so maybe for a voice
|
|
0:05:38
|
G.729 for instance we might have a
|
|
0:05:41
|
20 millisecond sampling rate on one G.729 stream
|
|
0:05:45
|
and a 30 millisecond sampling rate on another
|
|
0:05:49
|
audio stream. Another G.729 stream. So that needs a transcoder.
|
|
0:05:56
|
Sometimes that can be done in an MTP if they're the same
|
|
0:06:00
|
actual codec. CUCM has its own MTPs
|
|
0:06:06
|
for every server in the cluster that you enable the
|
|
0:06:10
|
IP voice media streaming app service on
|
|
0:06:15
|
it has four media resources
|
|
0:06:17
|
all we'll talk about and show it today.
|
|
0:06:19
|
Annunciator, Conference Bridge, MTP and Music on Hold server.
|
|
0:06:25
|
These MTPs can only
|
|
0:06:28
|
speak G.711ulaw or G.711alaw
|
|
0:06:33
|
The MTPs on the IOS router can only speak one at a time
|
|
0:06:37
|
However we do have the ability to change
|
|
0:06:42
|
what codec that is. So right now by default, it's G.711ulaw
|
|
0:06:47
|
If we're gonna use it over the WAN especially for RSVP
|
|
0:06:50
|
Which talked about in terms of call admission control
|
|
0:06:53
|
or we do actually have to terminate the media
|
|
0:06:57
|
then we will probably, over the WAN
|
|
0:06:59
|
choose the G.729 codec
|
|
0:07:02
|
So transcoders deal with transcoding
|
|
0:07:05
|
between codecs. Changing format, changing
|
|
0:07:10
|
not only codecs but sampling rates
|
|
0:07:16
|
MTPs, first of all, transcoders
|
|
0:07:19
|
can not only perform transcoding but they can act also
|
|
0:07:24
|
as an MTP so they can be both functions.
|
|
0:07:28
|
However the converse is not true.
|
|
0:07:30
|
An MTP cannot act as a transcoder.
|
|
0:07:34
|
It can only support one codec at a time or pass through
|
|
0:07:37
|
which essentially means that we're not
|
|
0:07:39
|
changing anything with the codec, we just need to
|
|
0:07:43
|
have the resources of an MTP
|
|
0:07:46
|
But what is an MTP, a media termination point.
|
|
0:07:50
|
The ability exist there to terminate media.
|
|
0:07:56
|
Terminate the RTP stream, in order to provide what?
|
|
0:08:01
|
Well a lot of things, we typically say supplementary services.
|
|
0:08:05
|
What are supplementary services really mean?
|
|
0:08:08
|
Let's get into some of the documentation and take a look.
|
|
0:08:14
|
So here's the link that we have, on the desktop by default.
|
|
0:08:20
|
Now, you know actually, if we're looking for the SRND
|
|
0:08:24
|
that is actually a PDF on the desktop, so
|
|
0:08:27
|
probably will go back to the PDFs simply because
|
|
0:08:30
|
all the other documentation
|
|
0:08:32
|
administration guide, system guide
|
|
0:08:35
|
Features and services guide where we can find some good information
|
|
0:08:38
|
is certainly there for you to search for
|
|
0:08:43
|
for you to navigate to, I should better say.
|
|
0:08:45
|
But the SRNDs, CUCM SRND
|
|
0:08:49
|
the CUCME or Call Manager Express SRND
|
|
0:08:54
|
and the QOS SRND are all gonna be PDFs on your desktop.
|
|
0:08:58
|
That much is guaranteed.
|
|
0:09:00
|
So if we take a look and we jump down to the media resources
|
|
0:09:04
|
we've got information about
|
|
0:09:06
|
voice termination in general, this is where we can get into looking at
|
|
0:09:10
|
the Codecs
|
|
0:09:17
|
|
|
0:09:24
|
As we scroll down and we take a look at
|
|
0:09:29
|
voice termination, this is where we can
|
|
0:09:32
|
in the SRND find out information about
|
|
0:09:35
|
medium and high complexity codecs, flex that we just talked about.
|
|
0:09:39
|
DSP resources or voice termination
|
|
0:09:42
|
These are the things that we've looked at
|
|
0:09:45
|
DSP resources on hardware platform IOS platform based on the
|
|
0:09:49
|
C5510 chipset which is what we have for our PVDM2
|
|
0:09:53
|
Continued
|
|
0:09:56
|
various other chipsets, 5421 so that's an older
|
|
0:10:00
|
PVDM2. 549 that's an older PVDM1
|
|
0:10:08
|
542, so these are DSPs under directly
|
|
0:10:11
|
on a network module and actually the 55
|
|
0:10:14
|
or 5421 is directly on modules as well.
|
|
0:10:22
|
We're not gonna go on all those, we looked at all those
|
|
0:10:26
|
to some degree. We get into audio conferencing
|
|
0:10:30
|
We get into video conferencing secure transcoding
|
|
0:10:34
|
We just talked about information about transcoding
|
|
0:10:37
|
and I'm gonna provide links to all of these individual sections
|
|
0:10:43
|
Transcoding resources or we're looking at some hardware
|
|
0:10:45
|
and then we'll look at MTP. The idea of MTP
|
|
0:10:49
|
is that accepts two full duplex media streams
|
|
0:10:52
|
It bridges those streams together
|
|
0:10:54
|
and allows them to be set up and torn down independently
|
|
0:10:58
|
and that gives us the ability to have
|
|
0:11:01
|
what we call supplementary services. So what are these supplementary services
|
|
0:11:05
|
They can be a number of different things.
|
|
0:11:08
|
So they can be re-packetization of a stream.
|
|
0:11:11
|
So for instance taking G.711alaw to G.711ulaw
|
|
0:11:15
|
They're the same codec, G.711
|
|
0:11:17
|
It's just the formation
|
|
0:11:21
|
of the alaw versus ulaw that were
|
|
0:11:24
|
that we're using to re-packetize an existing codec.
|
|
0:11:29
|
DTMF converstion. This is something that a number
|
|
0:11:32
|
of people forget about that needs an MTP to occur.
|
|
0:11:37
|
If we've got two different types of DTMF
|
|
0:11:40
|
So let's say we've got a DTMF relay
|
|
0:11:43
|
which is name to left the advance
|
|
0:11:45
|
a.k.a RFC2833, sometimes that's how is referred to
|
|
0:11:50
|
routers or even in CUCM
|
|
0:11:53
|
These are a method of sending DTMF
|
|
0:11:56
|
from one point end point to another
|
|
0:11:58
|
after the call has been established but the tones are actually sent as
|
|
0:12:01
|
packet data so it's out of band in a sense
|
|
0:12:05
|
but they're using the RTP stream.
|
|
0:12:07
|
So what they are not doing, is they're not sending
|
|
0:12:12
|
in a H.225 or H.245 more specifically header
|
|
0:12:17
|
or H.323, they're not sending a SIP
|
|
0:12:21
|
signalling or SIP notifier or something like that
|
|
0:12:25
|
They are not sending using the
|
|
0:12:28
|
signaling protocol. They're actually sent in the RTP stream
|
|
0:12:32
|
but they're are not audio sampled
|
|
0:12:34
|
So this is not the same thing as in-band Cisco proprietary RTP
|
|
0:12:40
|
or Cisco RTP for DTMF relay. This is not in-band
|
|
0:12:45
|
This is true out of band but it's in the RTP streams
|
|
0:12:49
|
because of that, we actually have to terminate the RTP
|
|
0:12:52
|
in order to get the information out. So it's sent in the data payload
|
|
0:12:58
|
sent as out of band reliable 1s and 0s
|
|
0:13:04
|
versus being sampled by the audio codec which would
|
|
0:13:07
|
meet with complete disaster if the audio codec was G.729 for instance
|
|
0:13:11
|
It doesn't have wide enough frequency spectrum to handle
|
|
0:13:15
|
the dual tone multi frequency range
|
|
0:13:20
|
We also have keypad or keypress mark up language
|
|
0:13:23
|
By the way, I should mention NTE or RC2833 is
|
|
0:13:27
|
supported in both SIP and H.323
|
|
0:13:33
|
KPML (Key Press Markup Language) is just supported for SIP
|
|
0:13:39
|
we have SIP unsolicited notify
|
|
0:13:42
|
So it's a SIP notify message but it was not
|
|
0:13:45
|
requested or solicited by either
|
|
0:13:50
|
side but already has a call up
|
|
0:13:52
|
So it's an unsolicited notifier. It wasn't requested but it will
|
|
0:13:55
|
accept to notify. We also have
|
|
0:13:59
|
H.245 signal and H.245 alphanumeric
|
|
0:14:03
|
So these are H.323 specific
|
|
0:14:06
|
KPML and unsolicited notify are SIP specific
|
|
0:14:13
|
H.245 is of course the media
|
|
0:14:15
|
control protocol use to negotiate H.323
|
|
0:14:18
|
after an H.225 call setup message
|
|
0:14:22
|
has been established. We'll look more of that tomorrow with gateways and trunks
|
|
0:14:26
|
and we'll look more at it as well with gatekeeper
|
|
0:14:34
|
But H.245 also provide the
|
|
0:14:36
|
out of band channel or DTMF transport.
|
|
0:14:40
|
Now, most people use H.245 alphanumeric
|
|
0:14:43
|
in their DTMF relay command. However the single method
|
|
0:14:47
|
actually carries more information about the DTMF event such as the duration.
|
|
0:14:51
|
So it's gonna be a better choice to always use H.245 signal
|
|
0:14:55
|
if you're choosing an out of band something other than
|
|
0:14:59
|
DTMF NTE
|
|
0:15:03
|
Name Telephony Events or RFC2833 depending on house reference.
|
|
0:15:07
|
Keep in mind, if we're using NTE we must have a MTP
|
|
0:15:14
|
So if both sides support H.245 signal, that's better.
|
|
0:15:18
|
Because we do not need an MTP
|
|
0:15:20
|
if we're just going from, let's say, an H.323 gateway
|
|
0:15:24
|
that supports H.245 signal and they all do
|
|
0:15:28
|
and a, let's say the CUCM
|
|
0:15:32
|
H.323 gateway page or H.225 trunk page
|
|
0:15:37
|
They support H.245 signal
|
|
0:15:40
|
so why would we use something that
|
|
0:15:43
|
requires an MTP when both sides support the same thing
|
|
0:15:46
|
and it's not in an RTP packet
|
|
0:15:51
|
It limits the necessity or invoking
|
|
0:15:57
|
additional CPU intensive or just even in general
|
|
0:16:01
|
extensive and limited resources
|
|
0:16:06
|
there's Cisco's proprietary RTP
|
|
0:16:10
|
gateway's support this but CUCM does not support it.
|
|
0:16:14
|
It's not supported by CUCM but is supported on the IOS gateway.
|
|
0:16:17
|
and then the Skinny control protocol, it actually
|
|
0:16:22
|
supports out of band DTMF itself.
|
|
0:16:27
|
So mainly we need an MTP if we're using
|
|
0:16:32
|
either some form of an in-band or
|
|
0:16:34
|
name telephony events RC2833 or for going between the two.
|
|
0:16:41
|
So this is gonna go in and I'm not gonna read the whole thing of course to you
|
|
0:16:45
|
It actually tells you which phones based on the Skinny stack
|
|
0:16:49
|
or the SIP stack for various types of phone support
|
|
0:16:53
|
for various methods. By the way, most Skinny phones
|
|
0:16:56
|
do support at least the newer ones, not the older ones. Actually conference bridge as well
|
|
0:17:02
|
or the conferencing phone rather do support name telephony events
|
|
0:17:07
|
So both sides are supporting NTE
|
|
0:17:10
|
then we typically don't need an MTP
|
|
0:17:13
|
as long as both sides would support it.
|
|
0:17:17
|
But anytime we have a desperate type of DTMF relay, then we're going to need it.
|
|
0:17:24
|
Also we need MTPs (Media Termination Point)
|
|
0:17:28
|
if we want to provide SIP
|
|
0:17:31
|
early offer in outgoing messages
|
|
0:17:35
|
So note that they're not
|
|
0:17:37
|
MTP resources are not required for incoming invite message
|
|
0:17:42
|
whether they contain an intial offer or not. So,
|
|
0:17:46
|
we'll talk about more about this tomorrow but just very briefly
|
|
0:17:49
|
SIP early offer versus SIP delayed media
|
|
0:17:53
|
those can be somewhat analogous to
|
|
0:17:56
|
H.225 fast start
|
|
0:18:00
|
is analogous to SIP early media
|
|
0:18:04
|
versus H.225 slow start
|
|
0:18:06
|
which is somewhat analogous to SIP delayed media.
|
|
0:18:11
|
or early offer. So the idea of
|
|
0:18:16
|
an early offer or a fast start just means that
|
|
0:18:20
|
in the initial setup message
|
|
0:18:23
|
for SIP that would be the 100 trying message
|
|
0:18:25
|
for H.225 it would be the setup message
|
|
0:18:28
|
we're going to describe DTMF and codec capabilities
|
|
0:18:32
|
and hope that the other side can really fall in line
|
|
0:18:37
|
with what we're requesting and if so
|
|
0:18:40
|
we don't need to negotiate anything.
|
|
0:18:43
|
if we're initiating from the CUCM side and early offer, we need an MTP.
|
|
0:18:50
|
But note that the initial offer is limited to G.711 only so
|
|
0:18:53
|
if you wanna support G.729 over a SIP trunk
|
|
0:18:56
|
which became available in CUCM 7.0
|
|
0:18:59
|
in fact we'll show tomorrow. Then you do need to
|
|
0:19:07
|
to not use your SIP early offer.
|
|
0:19:09
|
and again it's using a resource and MTP might want to reserve
|
|
0:19:14
|
In the lab, you're gonna do what you're told but
|
|
0:19:16
|
you are going to probably be given information
|
|
0:19:19
|
as we've mention many times
|
|
0:19:23
|
You're gonna be given tasks related to
|
|
0:19:27
|
how something should be accomplished
|
|
0:19:30
|
not what to do and also
|
|
0:19:33
|
using wording that specifies the capabilities
|
|
0:19:39
|
of what they're asking you to do. So if they said setup a SIP trunk
|
|
0:19:44
|
use any codec, do not use MTPs
|
|
0:19:49
|
for instance you wouldn't be able to do
|
|
0:19:52
|
SIP early offer. You also wouldn't be able to
|
|
0:19:54
|
support G.729. G.729 does require an MTP.
|
|
0:19:59
|
And we'll talk more tomorrow about
|
|
0:20:01
|
we're gonna talk a lot more tomorrow of that MTPs
|
|
0:20:03
|
because they relate very heavily as you can see already
|
|
0:20:08
|
even just in our initial discussion today, they
|
|
0:20:11
|
relate very heavily back and forth to gateways and trunks.
|
|
0:20:17
|
Whether they're provisioned manually and forced or automatically negotiated.
|
|
0:20:24
|
So it gives a lot of information about
|
|
0:20:30
|
MTPs when they're needed, configuring DTMF
|
|
0:20:33
|
looking at H.323 trunks and gateways
|
|
0:20:36
|
looking at the necessity for
|
|
0:20:38
|
MTP regarding supplementary services
|
|
0:20:41
|
Cisco Call Manager uses
|
|
0:20:46
|
internally with its Skinny end points which Skinny was
|
|
0:20:49
|
based on H.323 as well actually taking a look at
|
|
0:20:52
|
sample of that today with media and annunciator
|
|
0:21:00
|
the CUCM server uses
|
|
0:21:03
|
the H.245ecf
|
|
0:21:06
|
or empty capabilities set
|
|
0:21:09
|
However there are many end points such as CME
|
|
0:21:14
|
that or gateways that use by default
|
|
0:21:19
|
H.450, H.450.2 or H.450.3
|
|
0:21:23
|
or supplementery services being call hold or call transfer
|
|
0:21:27
|
Don't call me to whether 450.2 is
|
|
0:21:30
|
hold and 450.3 is transfer. I believe that's the way it is but
|
|
0:21:33
|
could be the opposite way around and then H.450.12
|
|
0:21:37
|
being the description of which
|
|
0:21:41
|
what subset of H.450 we're gonna be using
|
|
0:21:43
|
those came around a lot later than CUCM
|
|
0:21:46
|
or time call manager celsius. I had then
|
|
0:21:51
|
develop and deployed and so
|
|
0:21:53
|
they've continued to use a very reliable
|
|
0:21:56
|
capabilities set within their Skinny endpoints
|
|
0:21:59
|
and by default out to gateways however
|
|
0:22:03
|
H.450 can be used, it's just that CUCM won't support it so we can
|
|
0:22:07
|
that's actually we'll get into a few weeks, the queued module.
|
|
0:22:14
|
But an MTP can be required
|
|
0:22:19
|
if the other side does not support ECS
|
|
0:22:22
|
So let's say we're talking a CME over a trunk.
|
|
0:22:26
|
And we're actually gonna have an entire
|
|
0:22:28
|
deep dive module just on
|
|
0:22:30
|
CUCM to call manager express, CUCME
|
|
0:22:34
|
internetwork cause there's so much
|
|
0:22:36
|
can be discussed there and so many possibilities for failure
|
|
0:22:39
|
but so many obviously possibility for success
|
|
0:22:43
|
configured right. We have enough to cover the entire day.
|
|
0:22:46
|
But let's just say a CME is
|
|
0:22:49
|
not wanting to or
|
|
0:22:51
|
call managers wanting to do a call holder transfer
|
|
0:22:54
|
to a call on a CME over an H.323 trunk
|
|
0:22:57
|
Call manager doesn't support the H.450.3 for the transfer
|
|
0:23:02
|
We will invoke an MTP so that we can
|
|
0:23:07
|
provide H.245 capabilities over the side
|
|
0:23:12
|
being the ECS CME speaks that with the
|
|
0:23:17
|
CCM compatible command. Take a look at the later but
|
|
0:23:24
|
important point being that we need the media
|
|
0:23:26
|
termination point if we wanna provide services to something that
|
|
0:23:29
|
cannot essentially redirect that transfer.
|
|
0:23:32
|
So one of the things about H.450.3
|
|
0:23:35
|
with transfer is that it actually goes back
|
|
0:23:38
|
to the original endpoint and says redirect to your call
|
|
0:23:41
|
somewhere else versus empty capability set
|
|
0:23:45
|
just does this open logical or close logical channel, we'll all see.
|
|
0:23:50
|
So it's not actually redirecting
|
|
0:23:54
|
the originating gateway
|
|
0:23:56
|
and the terminating gateway, we're originating and terminating endpoints
|
|
0:23:59
|
to the new transfer. It's not saying to the originating gateway
|
|
0:24:04
|
redirect over to the new terminating gateway
|
|
0:24:08
|
it's essentially needing an MTP to
|
|
0:24:11
|
terminate that media and provide a hair pin
|
|
0:24:16
|
450 enchances the capabilities up.
|
|
0:24:19
|
But we need an MTP
|
|
0:24:21
|
if we're using call hold and tranfer for
|
|
0:24:24
|
between multiple CMEs and a call manager.
|
|
0:24:28
|
If we're just going between one
|
|
0:24:31
|
call manager and one CME, we're not
|
|
0:24:34
|
using between multiple call managers and multiple CME clusters
|
|
0:24:38
|
talking about three separate clusters end points at this point
|
|
0:24:41
|
We're only involving two separate end points
|
|
0:24:43
|
and we don't need an MTP to provide
|
|
0:24:46
|
services as long as it's Cisco IOS gateway
|
|
0:24:51
|
Cisco IOS router which of course CME runs on
|
|
0:24:55
|
If we're using outbound fast connect, just like if we're doing
|
|
0:24:59
|
SIP early media
|
|
0:25:03
|
then an MTP is required
|
|
0:25:05
|
However for inbound fast start just like with
|
|
0:25:08
|
a SIP early media invite
|
|
0:25:11
|
to us the CUCM, we do not need an MTP.
|
|
0:25:16
|
So again, it's very important to consider
|
|
0:25:20
|
what is necessary in terms of resources
|
|
0:25:24
|
certainly when you're deploying live customer or internal networks
|
|
0:25:29
|
but then also in terms of specifically
|
|
0:25:33
|
what is supported, when is an MTP needed
|
|
0:25:36
|
in the case of CCIE voice where they're going to word things very specifically
|
|
0:25:41
|
that will test your knowledge if when something would be needed.
|
|
0:25:45
|
As we mentioned as both endpoints are
|
|
0:25:47
|
SIP NTE is used, no MTP is required
|
|
0:25:52
|
when one endpoint is SIP and supports the other
|
|
0:25:57
|
both KPML (Key Press Markup Language)
|
|
0:26:01
|
or Key Pad Markup Language as some people refer to as
|
|
0:26:03
|
and name telephony events but the other endpoint is not SIP such as H.323
|
|
0:26:07
|
typically DTMF is sent as KPML
|
|
0:26:10
|
and the H.245 is used on the trunk
|
|
0:26:14
|
and no MTP is actually required for this DTMF.
|
|
0:26:19
|
One side is SIP that supports NTE, the other is not SIP
|
|
0:26:23
|
H.245 is used on the trunk
|
|
0:26:25
|
then an available MTP is out catered for the call
|
|
0:26:28
|
Again, it's good to read through this and understand
|
|
0:26:33
|
what is the best practice configuration
|
|
0:26:37
|
when what is needed, I'm not gonna read every single thing but
|
|
0:26:41
|
I will provide the links and again this is just one more reason to read
|
|
0:26:46
|
every single one of the 1094
|
|
0:26:50
|
basically 1100 pages in the SRND. It's packed with all good information.
|
|
0:26:55
|
Now looking at a trusted relay points
|
|
0:26:59
|
So a trusted relay point
|
|
0:27:01
|
is an MTP, actually first
|
|
0:27:03
|
before I go on to enhanced MTP functions
|
|
0:27:07
|
does anyone have questions so far
|
|
0:27:09
|
about what MTPs are in general?
|
|
0:27:14
|
So an MTP terminates media
|
|
0:27:18
|
We know that much. We know it's typically used for supplementary services.
|
|
0:27:22
|
What is this new thing called a trusted relay point?
|
|
0:27:26
|
Well a trusted relay point, is an MTP. It does terminate the media
|
|
0:27:31
|
it can be inserted into a media stream to act as a control point for that stream
|
|
0:27:37
|
and the idea, the main reason behind it that we would use
|
|
0:27:43
|
is as a QOS enforcement mechanism
|
|
0:27:47
|
or also for voice security
|
|
0:27:51
|
and then one other thing is
|
|
0:27:54
|
or traversing, let's say firewall that
|
|
0:27:59
|
or even VRFs (Virtual Routing and Forwarding), virtual routing instances
|
|
0:28:05
|
within an IOS router or between IOS routers with
|
|
0:28:09
|
typically between IOS routers VRS would be MPLS
|
|
0:28:13
|
So if we have VRFs in our data center, if we have
|
|
0:28:17
|
some form of maybe an ASA
|
|
0:28:20
|
That one we whiteboard this may help to communicate be a little better
|
|
0:28:27
|
We're not gonna be looking at MTPs today other than
|
|
0:28:30
|
we were given a task to configure one but we're not going to
|
|
0:28:34
|
well we might just for a test
|
|
0:28:38
|
but let's say we have a phone here and a phone over here
|
|
0:28:47
|
and this phone is in the sales department
|
|
0:28:50
|
1001 and this phone is in the
|
|
0:28:54
|
research and development
|
|
0:28:57
|
department, its extension 59
|
|
0:29:03
|
and there's actually a, first of all, all of these are a part
|
|
0:29:10
|
of the same CUCM cluster
|
|
0:29:18
|
they're all one CUCM cluster. But, there's a firewall
|
|
0:29:26
|
in between these phones. Now let's say this is a large
|
|
0:29:30
|
company and this sales phone here actually represents
|
|
0:29:34
|
450 phones on this side
|
|
0:29:43
|
and this R and D phone actually represents
|
|
0:29:47
|
7600 phone
|
|
0:29:55
|
We've just got an immense amount of phones
|
|
0:29:58
|
in between or either side of this firewall.
|
|
0:30:06
|
So somewhere the CUCM pub and subset
|
|
0:30:10
|
but those really aren't too relevant here to what we're doing
|
|
0:30:13
|
in terms of when calls flow, well actually let's draw the CUCM pub and sub
|
|
0:30:19
|
probably we have multiple servers at this point
|
|
0:30:24
|
So sub 1, sub 2, sub 3, we really don't need the pub because
|
|
0:30:33
|
these are the three CPEs that are going to be used for signaling back and forth
|
|
0:30:40
|
and so they're gonna provide Skinny based signaling
|
|
0:30:52
|
and back and forth between each other. They're providing their ICCS signaling
|
|
0:31:00
|
So we can pro calls in the firewall for three subscribers
|
|
0:31:05
|
or maybe the're sitting in some sort of a
|
|
0:31:10
|
subnet or not subnet but DMZ that has a
|
|
0:31:13
|
security rights to everywhere. Well we could use to your PC even for those.
|
|
0:31:17
|
So the idea with TRP if we want media
|
|
0:31:21
|
the flow between this phones
|
|
0:31:24
|
signaling always goes back and forth between the end points
|
|
0:31:28
|
and the CUCM servers, right? Never goes between the end points
|
|
0:31:32
|
even if they speak the same protocol, never
|
|
0:31:36
|
but the media typically goes directly
|
|
0:31:42
|
the RTP stream. Before we had that firewall there,
|
|
0:31:46
|
it would just go directly back and forth, I just don't wanna erase it.
|
|
0:31:50
|
And that's where the RTP stream needs to flow.
|
|
0:31:54
|
However, the only problem is, we've got this firewall on the way.
|
|
0:32:04
|
So, since we've got this firewall on the way,
|
|
0:32:09
|
we need to be able to somehow traverse the firewall.
|
|
0:32:13
|
Now, I could open up the IP address range and subnet for
|
|
0:32:17
|
7600 phones over here and 4500 phones over here
|
|
0:32:23
|
times the fact that for TDP RTP ports
|
|
0:32:31
|
I have 16384
|
|
0:32:49
|
to 16767
|
|
0:32:55
|
or actually to 32767.
|
|
0:33:00
|
So I've got 16000+ ports
|
|
0:33:05
|
I've got 16000+ ports times
|
|
0:33:09
|
roughly 8000 phones, that's a lot of
|
|
0:33:16
|
holes in my firewall. Even if I can summarize those
|
|
0:33:20
|
with groups and aimed objects,
|
|
0:33:23
|
I just probably don't want to as a security administrator.
|
|
0:33:27
|
So instead, I say that even for phones
|
|
0:33:31
|
that are talking to each other, they need to invoke special entity
|
|
0:33:40
|
called an MTP (Media Termination Point)
|
|
0:33:42
|
that's used as a trusted relay point.
|
|
0:33:47
|
So it's kind of a special MTP called a trusted relay point
|
|
0:33:57
|
So now, all of that traffic can be terminated on that MTP
|
|
0:34:04
|
You know what I need to do? I need to open up the MTP
|
|
0:34:08
|
or maybe I have one MTP on either side, I only need to open
|
|
0:34:12
|
those 16000 possible ports for that one MTP
|
|
0:34:17
|
at one trusted relay point.
|
|
0:34:20
|
So this allows me to traverse firewalls
|
|
0:34:23
|
much more easily traverse NAT and PAT
|
|
0:34:28
|
traverse whether it's ASA, Cisco IOS firewalls
|
|
0:34:32
|
to be able to traverse VRFs
|
|
0:34:36
|
could be able to deal with one side being
|
|
0:34:38
|
secure RTP, the other side being non-secure RTP
|
|
0:34:43
|
not that that's necessarily a great thing, because you've kind of
|
|
0:34:48
|
That will be the idea of security, at least you have it on one side of your
|
|
0:34:53
|
one side of your communication,
|
|
0:34:55
|
maybe the more important side, the R and D or something
|
|
0:34:59
|
highly confidential
|
|
0:35:04
|
But we have the ability to provide this
|
|
0:35:07
|
media termination point even for internal phones or internal gateways
|
|
0:35:13
|
So that's the important thing is, by default, internal phones
|
|
0:35:16
|
don't use MTPs when talking to each other unless of course as we mentioned
|
|
0:35:20
|
we're dealing with DTMF but then again, we can deal with that in CUCM
|
|
0:35:28
|
So, for all media, we have the ability to
|
|
0:35:32
|
traverse this trusted relay point.
|
|
0:35:38
|
We also have an annunciator
|
|
0:35:41
|
and an annunciator is what typically provides us with
|
|
0:35:44
|
error messages such as,
|
|
0:35:48
|
"Your call cannot be completed as dialed please check the number and call again."
|
|
0:35:51
|
or "You've exceeded your precedence level"
|
|
0:35:53
|
or whatever the messages that we choose
|
|
0:35:55
|
when we block a call, we'll take a look at that today.
|
|
0:35:58
|
But one important thing to note
|
|
0:35:59
|
is that the device must be capable since the
|
|
0:36:03
|
annunciator actually uses Skinny messages
|
|
0:36:09
|
to initiate that RTP stream
|
|
0:36:13
|
the device must be capable of SCCP to utilize the speecher
|
|
0:36:19
|
It's capable of supporting G.711alaw and ulaw and
|
|
0:36:23
|
G.729 wide band without any transcoding
|
|
0:36:25
|
but it has to be a Skinny end point that it's talking to
|
|
0:36:29
|
So what does this mean? SIP phones don't get annunciator.
|
|
0:36:33
|
MGCP gateways, don't get annunciator.
|
|
0:36:40
|
Goes on and tells us a little more about the annunciator, the RSVP agent
|
|
0:36:44
|
very similar to the
|
|
0:36:49
|
very similar to trusted relay point but for a totally different reason
|
|
0:36:54
|
we mention this briefly, or we mention this more
|
|
0:36:58
|
actually I should say we'll mention it briefly here
|
|
0:37:00
|
but we mention in depth when we talk about Call Admission Control
|
|
0:37:04
|
So if I've got a phone here at headquarters
|
|
0:37:10
|
and I've got a phone over here at Branch 1
|
|
0:37:15
|
and I have my, this is connected to LAN
|
|
0:37:24
|
of course connected to its LAN, got a router here
|
|
0:37:33
|
Headquarter router
|
|
0:37:40
|
and we've got a frame relay or some sort of WAN connection
|
|
0:37:44
|
and I wanna provide call admission control
|
|
0:37:48
|
does the media path already have to traverse
|
|
0:37:54
|
this link in order to get to the branch 1 phone?
|
|
0:38:03
|
MTP rather RTP
|
|
0:38:16
|
that RTP traffic already has to traverse
|
|
0:38:19
|
this router or if this is redundant, resilient routers
|
|
0:38:22
|
multiple pass, it has to traverse some IP path. So the MTP
|
|
0:38:26
|
or the RTP traffic, the Real Time Protocol media
|
|
0:38:30
|
already flowing accross some router in order to get to the other side.
|
|
0:38:37
|
If it is, will it hurt us to simply terminate this media here
|
|
0:38:44
|
and terminate it on the other side. If all we're doing is
|
|
0:38:49
|
repacketizing it in the exact same codec
|
|
0:38:53
|
in the exact same signaling rate or
|
|
0:38:59
|
or sampling rate rather, 30milliseconds, what have you?
|
|
0:39:04
|
We're not really using that many resources just to terminate the media
|
|
0:39:09
|
and repacketize it at the same exact codec and sampling rate.
|
|
0:39:14
|
That same DTMF. So it doesn't really hurt, who do that
|
|
0:39:20
|
because on the router, we can run MTP and either
|
|
0:39:24
|
hardware which does hurt because it causes DSP resources
|
|
0:39:27
|
or we can do it as our first task as instructed and we're getting ready to
|
|
0:39:32
|
actually configure in software. So not to use any DSP resources
|
|
0:39:38
|
but instead to use the command, we're gonna look at maximum session
|
|
0:39:41
|
software which is only available for MTP in IOS
|
|
0:39:45
|
So we're not using any hardware DSP resources here
|
|
0:39:52
|
we're doing it all in IOS software, so it's a
|
|
0:39:54
|
little bit of additional CPU, little little bit of a light and see
|
|
0:39:58
|
but not anything noticeable, it's negligible
|
|
0:40:02
|
but the ability or the reason that we wanna do this
|
|
0:40:06
|
is because we can use that terminated media to trigger
|
|
0:40:16
|
the RSVP reservation protocol or bandwidth
|
|
0:40:26
|
call admission control. So we trigger that on both sides
|
|
0:40:39
|
to provide our path and signaling messages
|
|
0:40:47
|
back and forth for RSVP to determine
|
|
0:40:52
|
is there enough bandwidth to allow
|
|
0:40:55
|
the call to continue. We don't actually with RSVP
|
|
0:40:58
|
we mention this with QOS
|
|
0:41:01
|
at least with the dip serve model, we do not actually reserve
|
|
0:41:05
|
the physical bandwidth as the data plan
|
|
0:41:07
|
we only reserve the bandwidth as it's related to the control plan
|
|
0:41:11
|
as it relates to call being controlled and allowed back and forth.
|
|
0:41:16
|
But that's the idea of why we would want to use
|
|
0:41:19
|
an MTP with RSVP capabilities
|
|
0:41:25
|
Now, if two end points actually require
|
|
0:41:33
|
RSVP capabilities and a trusted relay point
|
|
0:41:37
|
then first an MTP
|
|
0:41:41
|
that's configured as both, supporting both is attempted to be found.
|
|
0:41:47
|
So sometimes it could be a good idea especially if you're using TRPs
|
|
0:41:52
|
in any former fashion to have your RCPs capable of TRP as well.
|
|
0:41:58
|
We already mention the IP voice media streaming at
|
|
0:42:00
|
being the service that provides four
|
|
0:42:02
|
built-in software functionality
|
|
0:42:06
|
If careful to considerations, the situations that
|
|
0:42:08
|
require these resources because they place a load
|
|
0:42:10
|
CPU load on the servers that are running them
|
|
0:42:15
|
typically we will want Music on Hold, unicast or multicast and annunciator
|
|
0:42:20
|
but software conference briding and software MTP
|
|
0:42:24
|
software MTP can be a fine thing if we don't have enough IOS
|
|
0:42:29
|
software resources but it's probably better to use those
|
|
0:42:33
|
software conference bridging is typically something we will not want to do
|
|
0:42:38
|
I must word just desperate again these two software conference bridge and MTP
|
|
0:42:44
|
in the CUCM IP media streaming app
|
|
0:42:46
|
only support the G.711ulaw and G.711alaw protocols or codecs.
|
|
0:42:52
|
Do not support G.729
|
|
0:42:55
|
Music on Hold and annunciator do support G.729 in wide band.
|
|
0:43:01
|
So again, this is where and gets into capabilities
|
|
0:43:05
|
for PVDMs, PVDM2s based on your hardware and so forth.
|
|
0:43:09
|
So it's a good idea to read through that and certainly understand that information.
|
|
0:43:15
|
|
