WEBVTT

00:00:00.000 --> 00:00:03.409 align:middle line:90%


00:00:03.409 --> 00:00:06.818 align:middle line:90%
[AUDIO LOGO]

00:00:06.818 --> 00:00:09.750 align:middle line:90%


00:00:09.750 --> 00:00:11.950 align:middle line:90%
Hello, and welcome to INE.

00:00:11.950 --> 00:00:13.350 align:middle line:84%
Today in this
video, we will look

00:00:13.350 --> 00:00:21.330 align:middle line:84%
at task 2.3, where we would
be doing calling to the PSTN

00:00:21.330 --> 00:00:22.870 align:middle line:90%
basically dial plan.

00:00:22.870 --> 00:00:24.660 align:middle line:84%
So we have a
requirement which says

00:00:24.660 --> 00:00:27.630 align:middle line:84%
we need to configure HQ to
satisfy the following dial plan

00:00:27.630 --> 00:00:28.440 align:middle line:90%
requirements.

00:00:28.440 --> 00:00:32.280 align:middle line:84%
Access code for all PSTN
calls is going to be 9.

00:00:32.280 --> 00:00:35.970 align:middle line:84%
All calls to PSTN must
be forwarded to SME

00:00:35.970 --> 00:00:38.340 align:middle line:90%
from the HQ UCM.

00:00:38.340 --> 00:00:42.870 align:middle line:84%
SME must forward all calls to
the peer of redundant CUBE's.

00:00:42.870 --> 00:00:44.830 align:middle line:84%
If you remember in
the earlier task,

00:00:44.830 --> 00:00:48.900 align:middle line:84%
we had configured R1 and R2 to
be redundant voice gateways,

00:00:48.900 --> 00:00:50.490 align:middle line:90%
so redundant CUBE's.

00:00:50.490 --> 00:00:54.690 align:middle line:84%
And SME must forward the
calls to those boxes.

00:00:54.690 --> 00:00:57.420 align:middle line:84%
Basically, through those
box to box devices.

00:00:57.420 --> 00:01:01.590 align:middle line:84%
All calls calling and
called from the HQ UCM

00:01:01.590 --> 00:01:05.340 align:middle line:84%
must be forwarded
to SME as e164.

00:01:05.340 --> 00:01:09.780 align:middle line:84%
SME must send e164 to
the redundant CUBES.

00:01:09.780 --> 00:01:12.870 align:middle line:84%
The redundant cubes
must translate e164.

00:01:12.870 --> 00:01:16.320 align:middle line:84%
Numbers into the format
required by PSTN.

00:01:16.320 --> 00:01:18.810 align:middle line:84%
Use the following
parameters on SME,

00:01:18.810 --> 00:01:21.450 align:middle line:84%
the trunk name is given to
us, the route group name

00:01:21.450 --> 00:01:25.380 align:middle line:84%
is given to us, and the route
list name is given to us.

00:01:25.380 --> 00:01:30.090 align:middle line:84%
Then HQ site must be able
to dial local 7-digit PSTN

00:01:30.090 --> 00:01:33.660 align:middle line:84%
numbers by dialing the
access code 9 followed

00:01:33.660 --> 00:01:36.450 align:middle line:90%
by any 7-digit number.

00:01:36.450 --> 00:01:38.820 align:middle line:84%
The first digit
after the access key

00:01:38.820 --> 00:01:42.390 align:middle line:84%
could be any digit from 2
to 9, while the remaining

00:01:42.390 --> 00:01:44.370 align:middle line:90%
digits could be anything.

00:01:44.370 --> 00:01:47.760 align:middle line:84%
The HQ site must be able
to dial long distance,

00:01:47.760 --> 00:01:51.450 align:middle line:84%
basically national calls,
which is 10-digit PSTN numbers

00:01:51.450 --> 00:01:55.470 align:middle line:84%
by dialing 9 as the
access code followed by 1,

00:01:55.470 --> 00:01:58.200 align:middle line:84%
followed by 3-digit
area code, and then

00:01:58.200 --> 00:02:00.570 align:middle line:90%
7-digit subscriber number.

00:02:00.570 --> 00:02:03.840 align:middle line:84%
The first digit of the area
code and the subscriber number

00:02:03.840 --> 00:02:06.900 align:middle line:90%
must be any digits from 2 to 9.

00:02:06.900 --> 00:02:09.419 align:middle line:84%
The remaining area code
and subscriber number

00:02:09.419 --> 00:02:11.039 align:middle line:90%
could be anything.

00:02:11.039 --> 00:02:15.840 align:middle line:84%
HQ site must also be able to
dial international PSTN numbers

00:02:15.840 --> 00:02:21.180 align:middle line:84%
by dialing the access code
9 followed by 011 followed

00:02:21.180 --> 00:02:25.290 align:middle line:84%
by variable digits with
or without the pound sign

00:02:25.290 --> 00:02:27.830 align:middle line:90%
at the end.

00:02:27.830 --> 00:02:30.080 align:middle line:84%
All outbound calls
must be serviced

00:02:30.080 --> 00:02:33.020 align:middle line:84%
by the previously created
route pattern, which

00:02:33.020 --> 00:02:35.220 align:middle line:90%
was the backslash plus bang.

00:02:35.220 --> 00:02:38.240 align:middle line:84%
PSTN expects the
following called numbers.

00:02:38.240 --> 00:02:41.330 align:middle line:84%
For local and
national calls, PSTN

00:02:41.330 --> 00:02:45.500 align:middle line:84%
expects 1 followed by
3-digit area code and then

00:02:45.500 --> 00:02:47.280 align:middle line:90%
7-digit subscriber number.

00:02:47.280 --> 00:02:48.950 align:middle line:84%
So basically for
the called number,

00:02:48.950 --> 00:02:52.040 align:middle line:90%
the PSTN expects 11 digits.

00:02:52.040 --> 00:02:56.240 align:middle line:84%
For international calls, the
PSTN expects 011 followed

00:02:56.240 --> 00:02:58.430 align:middle line:90%
by any variable digits.

00:02:58.430 --> 00:03:01.940 align:middle line:84%
For the calling number, the
PSTN for local and national

00:03:01.940 --> 00:03:07.700 align:middle line:84%
expects the calls to come
without any plus sign or 1,

00:03:07.700 --> 00:03:11.060 align:middle line:90%
which means 10-digit number.

00:03:11.060 --> 00:03:14.120 align:middle line:84%
For international calls,
we must send the plus

00:03:14.120 --> 00:03:17.940 align:middle line:84%
followed by country code and
then the 10-digit number.

00:03:17.940 --> 00:03:20.700 align:middle line:90%
Now, this is our requirement.

00:03:20.700 --> 00:03:23.000 align:middle line:90%
So let's quickly go and do this.

00:03:23.000 --> 00:03:26.220 align:middle line:84%
Now, as per our
requirement, first of all,

00:03:26.220 --> 00:03:29.390 align:middle line:84%
we need to send e164
to SME as the calling,

00:03:29.390 --> 00:03:32.460 align:middle line:90%
and e164 as the caller to SME.

00:03:32.460 --> 00:03:36.950 align:middle line:84%
SME will also send e164 as
the calling and the called

00:03:36.950 --> 00:03:40.190 align:middle line:84%
down to the redundant
CUBES, and the CUBE

00:03:40.190 --> 00:03:43.910 align:middle line:84%
would do all the changes
required as for the PSTN

00:03:43.910 --> 00:03:46.650 align:middle line:90%
and forwarded down to the PSTN.

00:03:46.650 --> 00:03:48.420 align:middle line:90%
So quickly go and build this.

00:03:48.420 --> 00:03:52.010 align:middle line:84%
So I will start this off by
configuring the HQ site first,

00:03:52.010 --> 00:03:56.490 align:middle line:84%
then we will build SME, and then
we will configure the CUBES.

00:03:56.490 --> 00:03:58.830 align:middle line:90%
So let's go and do this.

00:03:58.830 --> 00:04:03.320 align:middle line:84%
So I have my HQ
call manager here.

00:04:03.320 --> 00:04:05.930 align:middle line:84%
Let's go and create
some partitions.

00:04:05.930 --> 00:04:09.270 align:middle line:84%
That's the first thing
that I'm going to do.

00:04:09.270 --> 00:04:12.180 align:middle line:84%
So I am going to create
a partition here,

00:04:12.180 --> 00:04:16.940 align:middle line:84%
which is going to be based on
the calls that I need to make.

00:04:16.940 --> 00:04:20.570 align:middle line:84%
So my first partition
is going to be--

00:04:20.570 --> 00:04:22.490 align:middle line:84%
I think I just need
one partition, which is

00:04:22.490 --> 00:04:24.335 align:middle line:90%
going to be called as PT-PSTN.

00:04:24.335 --> 00:04:27.610 align:middle line:90%


00:04:27.610 --> 00:04:28.985 align:middle line:90%
So let's click on Add New.

00:04:28.985 --> 00:04:43.380 align:middle line:90%


00:04:43.380 --> 00:04:46.920 align:middle line:84%
So let's make this
partition called as PT-PSTN,

00:04:46.920 --> 00:04:47.970 align:middle line:90%
and let's save this.

00:04:47.970 --> 00:04:50.770 align:middle line:90%


00:04:50.770 --> 00:04:53.690 align:middle line:84%
Now, if you remember
in the earlier task,

00:04:53.690 --> 00:04:57.550 align:middle line:84%
I believe it was
intersite 2.1, we

00:04:57.550 --> 00:05:01.300 align:middle line:84%
had created a CSS
for the phones.

00:05:01.300 --> 00:05:04.780 align:middle line:84%
My phone had the device
CSS, CSS phones, which

00:05:04.780 --> 00:05:07.180 align:middle line:90%
had the partition PT-Intersite.

00:05:07.180 --> 00:05:09.730 align:middle line:84%
So in that CSS, I
would give my phones

00:05:09.730 --> 00:05:13.250 align:middle line:84%
access to this new
partition that I created,

00:05:13.250 --> 00:05:15.760 align:middle line:90%
which is PT-PTSN.

00:05:15.760 --> 00:05:18.100 align:middle line:84%
So now my phones can
dial PT-Intersite,

00:05:18.100 --> 00:05:19.960 align:middle line:84%
which is intersite
calling, and they

00:05:19.960 --> 00:05:22.390 align:middle line:84%
can dial the PSTN,
which will basically

00:05:22.390 --> 00:05:24.770 align:middle line:90%
route through the SME.

00:05:24.770 --> 00:05:26.870 align:middle line:90%
Let's save this.

00:05:26.870 --> 00:05:29.660 align:middle line:84%
The next thing that I would
do is create some translation

00:05:29.660 --> 00:05:30.780 align:middle line:90%
patterns.

00:05:30.780 --> 00:05:36.920 align:middle line:84%
So let's go and go to
Translation Pattern,

00:05:36.920 --> 00:05:38.848 align:middle line:84%
and let's create some
translation patterns.

00:05:38.848 --> 00:05:40.640 align:middle line:84%
How many translation
patterns would I need?

00:05:40.640 --> 00:05:44.270 align:middle line:84%
One for local, one for national,
and two for international,

00:05:44.270 --> 00:05:47.000 align:middle line:84%
one with the pound,
one without the pound.

00:05:47.000 --> 00:05:51.950 align:middle line:84%
So let's create one partition--
one translation pattern.

00:05:51.950 --> 00:05:54.460 align:middle line:84%
So for the local calls,
as for the question,

00:05:54.460 --> 00:05:57.940 align:middle line:84%
we must dial 9, which is
the access code followed

00:05:57.940 --> 00:06:01.180 align:middle line:84%
by 7 digit, where
the first digit is

00:06:01.180 --> 00:06:03.130 align:middle line:90%
going to be from 2 to 9.

00:06:03.130 --> 00:06:08.390 align:middle line:84%
So let's create a box bracket
2-9, and then six dots.

00:06:08.390 --> 00:06:11.500 align:middle line:90%
So 1, 2, 3, 4, 5, 6.

00:06:11.500 --> 00:06:16.480 align:middle line:90%
This would go to PT-PTSN.

00:06:16.480 --> 00:06:19.212 align:middle line:84%
The calling search
space is going to be--

00:06:19.212 --> 00:06:20.920 align:middle line:84%
if you look at the
question, the question

00:06:20.920 --> 00:06:24.790 align:middle line:84%
states that we must use the
previously created single route

00:06:24.790 --> 00:06:28.370 align:middle line:84%
pattern which we had created
earlier for intersite.

00:06:28.370 --> 00:06:30.160 align:middle line:84%
And if you remember,
that route pattern

00:06:30.160 --> 00:06:34.700 align:middle line:84%
was in the partition PT-SRP,
which is single route pattern.

00:06:34.700 --> 00:06:37.390 align:middle line:84%
So I need this translation
pattern to have access

00:06:37.390 --> 00:06:38.690 align:middle line:90%
to that partition.

00:06:38.690 --> 00:06:42.480 align:middle line:84%
So this would go into a
CSS single route pattern.

00:06:42.480 --> 00:06:44.360 align:middle line:84%
I need the outside
dial tone because now

00:06:44.360 --> 00:06:46.130 align:middle line:84%
I'm dialing the
PSTN, I'm dialing

00:06:46.130 --> 00:06:48.500 align:middle line:90%
the 9 as the access code.

00:06:48.500 --> 00:06:51.710 align:middle line:84%
Calling number needs to
change from four digits

00:06:51.710 --> 00:06:55.800 align:middle line:90%
to e164 and the calling number.

00:06:55.800 --> 00:06:58.770 align:middle line:90%
So I would strip off the 9.

00:06:58.770 --> 00:07:05.760 align:middle line:84%
So I would strip off
the 9 and prefix +1408.

00:07:05.760 --> 00:07:11.868 align:middle line:84%
So now my called becomes
+14082/9 dot dot dot dot dot

00:07:11.868 --> 00:07:13.410 align:middle line:90%
dot.

00:07:13.410 --> 00:07:14.310 align:middle line:90%
Let's save this.

00:07:14.310 --> 00:07:19.290 align:middle line:90%


00:07:19.290 --> 00:07:21.350 align:middle line:90%
It says that the only--

00:07:21.350 --> 00:07:25.070 align:middle line:90%


00:07:25.070 --> 00:07:29.210 align:middle line:84%
add failed-- only one dot
is permitted per expression.

00:07:29.210 --> 00:07:31.480 align:middle line:84%
Or in fact, you know
what, this is not a dot.

00:07:31.480 --> 00:07:34.160 align:middle line:84%
This should be X because
this is call manager.

00:07:34.160 --> 00:07:38.090 align:middle line:90%
So 1, 2, 3, 4, 5, 6.

00:07:38.090 --> 00:07:41.280 align:middle line:90%
Let's save this.

00:07:41.280 --> 00:07:43.980 align:middle line:84%
So my local translation
pattern is done.

00:07:43.980 --> 00:07:46.640 align:middle line:84%
Let's copy this and create
one more translation

00:07:46.640 --> 00:07:49.250 align:middle line:90%
pattern for national calls.

00:07:49.250 --> 00:07:52.250 align:middle line:84%
Now, as for the requirement,
for national calls

00:07:52.250 --> 00:07:55.910 align:middle line:90%
I would dial 9 followed by 1.

00:07:55.910 --> 00:08:00.860 align:middle line:84%
Then the area code which is 3
digits and then the subscriber

00:08:00.860 --> 00:08:02.510 align:middle line:90%
code which is 7 digits.

00:08:02.510 --> 00:08:07.190 align:middle line:84%
The area code first digit
should be from 2-9, 2 to 9.

00:08:07.190 --> 00:08:09.680 align:middle line:84%
And the subscriber first
digit should be from 2 to 9.

00:08:09.680 --> 00:08:11.650 align:middle line:90%
So this would be 9.1[2-9]XX.

00:08:11.650 --> 00:08:15.980 align:middle line:90%


00:08:15.980 --> 00:08:21.840 align:middle line:84%
Then again [2-9]
1, 2, 3, 4, 5, 6.

00:08:21.840 --> 00:08:23.460 align:middle line:90%
So this is for national.

00:08:23.460 --> 00:08:26.130 align:middle line:84%
So as for the
question, I must dial 9

00:08:26.130 --> 00:08:29.190 align:middle line:84%
as the access code
followed by 1.

00:08:29.190 --> 00:08:31.650 align:middle line:84%
Then the area code,
which is 3 digits where

00:08:31.650 --> 00:08:34.320 align:middle line:90%
the first digit is from 2 to 9.

00:08:34.320 --> 00:08:36.549 align:middle line:84%
And then I have the
subscriber number,

00:08:36.549 --> 00:08:39.030 align:middle line:84%
which is 7 digits where
the first number is again

00:08:39.030 --> 00:08:40.679 align:middle line:90%
from 2 to 9.

00:08:40.679 --> 00:08:42.309 align:middle line:90%
This would again go to PSTN.

00:08:42.309 --> 00:08:45.000 align:middle line:84%
So only my phones have access
to this translation pattern.

00:08:45.000 --> 00:08:48.330 align:middle line:84%
This translation pattern has
access to the CSS single route

00:08:48.330 --> 00:08:51.240 align:middle line:84%
pattern, which means it would
hit the route pattern which is

00:08:51.240 --> 00:08:53.550 align:middle line:90%
the backslash +!.

00:08:53.550 --> 00:08:56.280 align:middle line:84%
And the backslash plus
bang we had done earlier

00:08:56.280 --> 00:08:58.420 align:middle line:90%
from the earlier task.

00:08:58.420 --> 00:09:00.990 align:middle line:84%
So all we need now
here, the calling number

00:09:00.990 --> 00:09:02.910 align:middle line:90%
will change back to e164.

00:09:02.910 --> 00:09:11.820 align:middle line:84%
The called I will do a PreDot
And so I am stripping the 9,

00:09:11.820 --> 00:09:17.270 align:middle line:84%
and I would just do a PreDot
and a prefix digit for plus.

00:09:17.270 --> 00:09:19.940 align:middle line:84%
So now my called number,
9 gets stripped off,

00:09:19.940 --> 00:09:25.436 align:middle line:84%
my called number becomes
+1[2-9]XX [2-9]XXXXXX.

00:09:25.436 --> 00:09:28.900 align:middle line:90%


00:09:28.900 --> 00:09:32.080 align:middle line:84%
Let's make one more
for international now.

00:09:32.080 --> 00:09:34.600 align:middle line:84%
Now, for international,
let's copy this again.

00:09:34.600 --> 00:09:37.600 align:middle line:90%


00:09:37.600 --> 00:09:44.260 align:middle line:84%
First, I will make it
with the pound so 9011.!

00:09:44.260 --> 00:09:45.565 align:middle line:90%
and then the pound.

00:09:45.565 --> 00:09:48.300 align:middle line:90%


00:09:48.300 --> 00:09:51.600 align:middle line:90%
And what do I need to strip off?

00:09:51.600 --> 00:09:54.410 align:middle line:90%
I need to strip off--

00:09:54.410 --> 00:09:56.880 align:middle line:84%
I could strip off
as per the question,

00:09:56.880 --> 00:09:58.940 align:middle line:84%
it says that for
international calls,

00:09:58.940 --> 00:10:03.230 align:middle line:90%
I must send 011 to the PSTN.

00:10:03.230 --> 00:10:07.670 align:middle line:84%
However, the question also
states that HQ cluster must

00:10:07.670 --> 00:10:12.390 align:middle line:84%
send to SME e164, so you
should not send 011 to SME.

00:10:12.390 --> 00:10:14.910 align:middle line:84%
So I will strip
off the 011 also,

00:10:14.910 --> 00:10:17.660 align:middle line:90%
so 9011 has been stripped off.

00:10:17.660 --> 00:10:22.860 align:middle line:90%
And what would I prefix?

00:10:22.860 --> 00:10:26.540 align:middle line:84%
So calling number becomes
e164, called is PreDot,

00:10:26.540 --> 00:10:30.920 align:middle line:90%
and I would do a plus.

00:10:30.920 --> 00:10:34.340 align:middle line:84%
So PreDot-- In fact, it
should be PreDot Trailing.

00:10:34.340 --> 00:10:40.460 align:middle line:84%
#, so which is
PreDot Trailing. #.

00:10:40.460 --> 00:10:42.470 align:middle line:84%
Because I want to
remove the 9011,

00:10:42.470 --> 00:10:47.120 align:middle line:84%
and I want to remove the
hash sign or the pound sign.

00:10:47.120 --> 00:10:49.180 align:middle line:84%
So that's my 9011
with the pound.

00:10:49.180 --> 00:10:51.820 align:middle line:90%


00:10:51.820 --> 00:10:55.630 align:middle line:84%
I'm just doing a prefix of plus
because it strips off the 9011,

00:10:55.630 --> 00:10:59.320 align:middle line:84%
and then all the digits would
have a plus at the start.

00:10:59.320 --> 00:11:04.420 align:middle line:84%
Let's copy this again one more
without the pound, so 9011

00:11:04.420 --> 00:11:06.640 align:middle line:90%
without the pound.

00:11:06.640 --> 00:11:10.180 align:middle line:84%
Now, this again calling
number would be e164,

00:11:10.180 --> 00:11:15.250 align:middle line:84%
called would be a
PreDot with a plus sign.

00:11:15.250 --> 00:11:16.120 align:middle line:90%
Let's save this.

00:11:16.120 --> 00:11:18.910 align:middle line:84%
There's one more thing
that you need to do.

00:11:18.910 --> 00:11:21.040 align:middle line:84%
Because this one does
not have a pound,

00:11:21.040 --> 00:11:23.680 align:middle line:84%
we must go and remove
the urgent priority.

00:11:23.680 --> 00:11:25.900 align:middle line:84%
Because if you don't
remove the urgent priority,

00:11:25.900 --> 00:11:30.350 align:middle line:84%
the minute you dial 9011
and then the first digit,

00:11:30.350 --> 00:11:32.990 align:middle line:84%
the call manager is going
to try to route that call.

00:11:32.990 --> 00:11:35.380 align:middle line:84%
So we need to remove the
urgent priority for it

00:11:35.380 --> 00:11:37.310 align:middle line:90%
to collect all the digits.

00:11:37.310 --> 00:11:40.750 align:middle line:84%
So only for without
the pound we need

00:11:40.750 --> 00:11:42.220 align:middle line:90%
to remove the urgent priority.

00:11:42.220 --> 00:11:45.580 align:middle line:84%
For your local calls,
for your national calls,

00:11:45.580 --> 00:11:48.040 align:middle line:84%
for your international
calls with the pound,

00:11:48.040 --> 00:11:50.170 align:middle line:84%
we do not need to
remove urgent priority.

00:11:50.170 --> 00:11:53.800 align:middle line:84%
But for the international
calls without the pound,

00:11:53.800 --> 00:11:56.620 align:middle line:84%
we do need to remove
the urgent priority.

00:11:56.620 --> 00:11:58.490 align:middle line:90%
Let's save this.

00:11:58.490 --> 00:12:02.860 align:middle line:84%
So now I have all my translation
patterns which is created,

00:12:02.860 --> 00:12:04.930 align:middle line:84%
and what's going
to happen now is

00:12:04.930 --> 00:12:11.350 align:middle line:84%
that the call manager is going
to send that call to the SME.

00:12:11.350 --> 00:12:14.050 align:middle line:84%
So all I need to do now
is configure the SME.

00:12:14.050 --> 00:12:18.040 align:middle line:84%
I don't really need to configure
anything on the HQ cluster

00:12:18.040 --> 00:12:20.360 align:middle line:84%
anymore because
everything else is done.

00:12:20.360 --> 00:12:24.290 align:middle line:84%
So how is the flow going
to be on the HQ cluster?

00:12:24.290 --> 00:12:33.250 align:middle line:84%
So phone dials let's say, a
local call., He dials 95151111

00:12:33.250 --> 00:12:35.510 align:middle line:90%
which is the PSTN local number.

00:12:35.510 --> 00:12:39.770 align:middle line:84%
So when he dials 95151111,
the phones device

00:12:39.770 --> 00:12:45.440 align:middle line:84%
CSS, CSS phones which contains
the partition PT-PSTN,

00:12:45.440 --> 00:12:49.000 align:middle line:84%
so it hits the translation
pattern for the local calls.

00:12:49.000 --> 00:12:53.050 align:middle line:84%
The calling number becomes
e164, called becomes e164.

00:12:53.050 --> 00:12:55.330 align:middle line:84%
And because the
translation pattern

00:12:55.330 --> 00:12:57.580 align:middle line:84%
has access to CSS
single route pattern,

00:12:57.580 --> 00:12:59.290 align:middle line:90%
it goes to the route pattern.

00:12:59.290 --> 00:13:00.970 align:middle line:84%
The route pattern
if you remember

00:13:00.970 --> 00:13:02.950 align:middle line:84%
from the earlier
task of intersite,

00:13:02.950 --> 00:13:05.590 align:middle line:90%
it points to the SIP trunk.

00:13:05.590 --> 00:13:09.820 align:middle line:84%
The SIP trunk removes the
plus from the called number

00:13:09.820 --> 00:13:16.280 align:middle line:84%
and forwards it
across to the SME.

00:13:16.280 --> 00:13:23.080 align:middle line:84%
Let's go back and let's
see what else we need.

00:13:23.080 --> 00:13:30.330 align:middle line:84%
I believe that's the only
thing we need on HQ cluster.

00:13:30.330 --> 00:13:33.620 align:middle line:90%
So here is my phone.

00:13:33.620 --> 00:13:45.540 align:middle line:84%
So if you look at the
phone which is Tony Stark,

00:13:45.540 --> 00:13:50.970 align:middle line:84%
he has the device CSS, CSS
phones which you can see here.

00:13:50.970 --> 00:13:51.940 align:middle line:90%
This goes.

00:13:51.940 --> 00:13:54.750 align:middle line:84%
When he dials the
number 95151111,

00:13:54.750 --> 00:13:58.080 align:middle line:84%
it hits the translation
pattern, which

00:13:58.080 --> 00:14:00.840 align:middle line:84%
is the one for local
calls, which is this one.

00:14:00.840 --> 00:14:02.310 align:middle line:90%
It hits this one.

00:14:02.310 --> 00:14:06.150 align:middle line:84%
Phone has access to PT-PSTN
because of this device CSS

00:14:06.150 --> 00:14:09.000 align:middle line:84%
and the calling number
changes to this.

00:14:09.000 --> 00:14:13.470 align:middle line:90%
Called number changes to +1408.

00:14:13.470 --> 00:14:16.860 align:middle line:90%
Then it goes to--

00:14:16.860 --> 00:14:19.470 align:middle line:84%
because the transition button
has access to CSS single route

00:14:19.470 --> 00:14:23.710 align:middle line:84%
pattern, it goes to
the route pattern.

00:14:23.710 --> 00:14:27.400 align:middle line:84%
The route pattern
matches the backslash +!

00:14:27.400 --> 00:14:28.930 align:middle line:90%
That we had created earlier.

00:14:28.930 --> 00:14:33.350 align:middle line:84%
It matches this and sends
it to the SIP trunk.

00:14:33.350 --> 00:14:42.070 align:middle line:84%
Now, on the SIP trunk if
you look at the SIP trunk,

00:14:42.070 --> 00:14:43.495 align:middle line:90%
this is the SIP trunk to SME.

00:14:43.495 --> 00:14:44.870 align:middle line:84%
On the SIP trunk,
if you remember

00:14:44.870 --> 00:14:47.800 align:middle line:84%
we had applied some
call transformation.

00:14:47.800 --> 00:14:50.895 align:middle line:84%
If you see here in
the outbound, we

00:14:50.895 --> 00:14:52.880 align:middle line:84%
had applied called
party transformation,

00:14:52.880 --> 00:14:56.660 align:middle line:84%
so it goes to called
party transformation.

00:14:56.660 --> 00:14:59.270 align:middle line:84%
In the called party
transformation we have no rule

00:14:59.270 --> 00:15:03.740 align:middle line:84%
that matches +1408202
as the called number.

00:15:03.740 --> 00:15:06.050 align:middle line:90%
Or +14085151111.

00:15:06.050 --> 00:15:07.730 align:middle line:84%
It does not match
that because we

00:15:07.730 --> 00:15:11.330 align:middle line:84%
had a rule here for
intercept which was only

00:15:11.330 --> 00:15:15.050 align:middle line:90%
matching backslash +.8303.

00:15:15.050 --> 00:15:17.600 align:middle line:84%
So it's not going to
match this called rule,

00:15:17.600 --> 00:15:20.000 align:middle line:84%
and it will not strip
off the plus, which

00:15:20.000 --> 00:15:26.360 align:middle line:84%
means SME is going to get e164
number as the calling and e164

00:15:26.360 --> 00:15:29.090 align:middle line:84%
as the called so
with the plus sign.

00:15:29.090 --> 00:15:30.020 align:middle line:90%
He would receive that.

00:15:30.020 --> 00:15:32.930 align:middle line:84%
And that meets the
requirement of the question

00:15:32.930 --> 00:15:35.750 align:middle line:84%
because we're not stripping
off the plus for PSTN calls.

00:15:35.750 --> 00:15:38.690 align:middle line:84%
We were only stripping
off the plus for calls

00:15:38.690 --> 00:15:41.100 align:middle line:84%
to intersite as
per earlier task.

00:15:41.100 --> 00:15:43.310 align:middle line:84%
But in this task, we
are not stripping off

00:15:43.310 --> 00:15:46.370 align:middle line:90%
the plus towards the SME.

00:15:46.370 --> 00:15:48.850 align:middle line:90%
Now, let's go to the SME.

00:15:48.850 --> 00:15:54.070 align:middle line:84%
On the SME, I would
create two partitions.

00:15:54.070 --> 00:15:56.880 align:middle line:84%
So let's create a
partition on SME.

00:15:56.880 --> 00:16:00.023 align:middle line:90%


00:16:00.023 --> 00:16:01.190 align:middle line:90%
In fact, just one partition.

00:16:01.190 --> 00:16:05.180 align:middle line:84%
We could use the same partition
for HQ or site B, so just one

00:16:05.180 --> 00:16:06.260 align:middle line:90%
partition, which is PTSN.

00:16:06.260 --> 00:16:08.920 align:middle line:90%


00:16:08.920 --> 00:16:12.370 align:middle line:90%
So let's go to Add New.

00:16:12.370 --> 00:16:14.590 align:middle line:84%
Create a new partition
called PT-PSTN.

00:16:14.590 --> 00:16:17.940 align:middle line:90%


00:16:17.940 --> 00:16:20.060 align:middle line:90%
Save.

00:16:20.060 --> 00:16:22.970 align:middle line:84%
When the call comes in
from HQ cluster to SME,

00:16:22.970 --> 00:16:26.000 align:middle line:84%
it's going to hit
the SIP trunk of HQ.

00:16:26.000 --> 00:16:39.950 align:middle line:84%
So I need to go to my CSS on the
SME, which is inbound from HQ

00:16:39.950 --> 00:16:44.580 align:middle line:84%
and give him access
to PSTN also now.

00:16:44.580 --> 00:16:47.080 align:middle line:84%
So call coming in from
HQ on the SIP trunk,

00:16:47.080 --> 00:16:52.930 align:middle line:84%
that SIP trunk will have access
to site B as well as PSTN.

00:16:52.930 --> 00:16:59.230 align:middle line:84%
Next thing what I'm going
to do is create my SIP trunk

00:16:59.230 --> 00:17:01.870 align:middle line:90%
to the CUBE.

00:17:01.870 --> 00:17:08.239 align:middle line:84%
Now, my SIP trunk to the
CUBE is going to point to--

00:17:08.239 --> 00:17:11.130 align:middle line:90%


00:17:11.130 --> 00:17:16.890 align:middle line:84%
I believe in task 2.2 when we
configured the redundant CUBE,

00:17:16.890 --> 00:17:22.270 align:middle line:84%
the redundant peer, when we
did that, we had given an IP

00:17:22.270 --> 00:17:24.230 align:middle line:90%
address, a virtual IP address.

00:17:24.230 --> 00:17:26.319 align:middle line:84%
So you should point to
the virtual IP address,

00:17:26.319 --> 00:17:28.700 align:middle line:84%
not to the physical IP
address of the router.

00:17:28.700 --> 00:17:32.830 align:middle line:84%
So if I go back to my let's
say, router 1, and let's

00:17:32.830 --> 00:17:36.900 align:middle line:90%
also access router 2.

00:17:36.900 --> 00:17:43.120 align:middle line:84%
And look at router 1's
show run interface gig 1.

00:17:43.120 --> 00:17:46.900 align:middle line:90%
This is my LAN side, I believe.

00:17:46.900 --> 00:17:53.300 align:middle line:84%
Let's do a show IP
interface brief.

00:17:53.300 --> 00:17:59.140 align:middle line:84%
So show run interface gig, which
is the LAN side towards HQ.

00:17:59.140 --> 00:18:03.320 align:middle line:90%


00:18:03.320 --> 00:18:11.440 align:middle line:84%
I need to do enable, and let's
do a show run interface gig 1.

00:18:11.440 --> 00:18:14.770 align:middle line:84%
As you can see that my redundant
IP address or my virtual IP

00:18:14.770 --> 00:18:18.010 align:middle line:90%
address is 11.102.64.150.

00:18:18.010 --> 00:18:20.830 align:middle line:84%
My physical IP is
151, but I would not

00:18:20.830 --> 00:18:22.810 align:middle line:84%
use the physical
IP because we have

00:18:22.810 --> 00:18:25.210 align:middle line:90%
configured redundant VCUBES.

00:18:25.210 --> 00:18:28.030 align:middle line:84%
So both from the call
manager's perspective

00:18:28.030 --> 00:18:32.270 align:middle line:84%
or from SME's perspective,
R1 and R2 are one router.

00:18:32.270 --> 00:18:36.610 align:middle line:84%
So I need to go back
to my SME, and I

00:18:36.610 --> 00:18:41.740 align:middle line:84%
will create a SIP trunk to this
redundant virtual IP address.

00:18:41.740 --> 00:18:42.490 align:middle line:90%
Let's do that.

00:18:42.490 --> 00:18:46.500 align:middle line:90%


00:18:46.500 --> 00:18:47.000 align:middle line:90%
Next.

00:18:47.000 --> 00:18:49.970 align:middle line:90%


00:18:49.970 --> 00:18:52.990 align:middle line:84%
Let's name this as
SIP-TRUNK-TO-VCUBE.

00:18:52.990 --> 00:18:59.470 align:middle line:90%


00:18:59.470 --> 00:19:01.900 align:middle line:84%
Device pool would
be the default one.

00:19:01.900 --> 00:19:06.010 align:middle line:90%
Lets do run on all active nodes.

00:19:06.010 --> 00:19:12.700 align:middle line:84%
And there is no inbound
CSS requirement.

00:19:12.700 --> 00:19:14.220 align:middle line:90%
Let's go out and--

00:19:14.220 --> 00:19:16.810 align:middle line:90%


00:19:16.810 --> 00:19:18.820 align:middle line:84%
There is no called
party transformation

00:19:18.820 --> 00:19:21.580 align:middle line:84%
because he's receiving
e164 as calling number

00:19:21.580 --> 00:19:23.140 align:middle line:90%
and called number.

00:19:23.140 --> 00:19:27.100 align:middle line:84%
And I'm sending out
to VCUBE on e164

00:19:27.100 --> 00:19:29.620 align:middle line:90%
as calling and e164 as called.

00:19:29.620 --> 00:19:31.600 align:middle line:84%
I am not making
any changes, so I

00:19:31.600 --> 00:19:33.970 align:middle line:84%
don't need to apply any
called party transformation

00:19:33.970 --> 00:19:35.780 align:middle line:90%
or calling body transformation.

00:19:35.780 --> 00:19:39.970 align:middle line:84%
So all I would do
is point here saying

00:19:39.970 --> 00:19:46.120 align:middle line:84%
11.102.64.150, which is
a virtual IP address.

00:19:46.120 --> 00:19:51.220 align:middle line:84%
Default SIP security profile
and default SIP profile.

00:19:51.220 --> 00:19:54.450 align:middle line:90%
Let's save this.

00:19:54.450 --> 00:19:57.196 align:middle line:84%
And then let's
reset our settings.

00:19:57.196 --> 00:20:04.440 align:middle line:90%


00:20:04.440 --> 00:20:05.480 align:middle line:90%
Let reset this.

00:20:05.480 --> 00:20:09.710 align:middle line:90%


00:20:09.710 --> 00:20:13.010 align:middle line:84%
Now, one thing we
need to look at

00:20:13.010 --> 00:20:16.760 align:middle line:84%
is if you look at the
question, the question clearly

00:20:16.760 --> 00:20:24.610 align:middle line:84%
stated that my trunk name
should be SME-PSTN on the SME.

00:20:24.610 --> 00:20:27.460 align:middle line:84%
I didn't have to create
a trunk on HQ towards SME

00:20:27.460 --> 00:20:29.410 align:middle line:84%
because that was
already done earlier

00:20:29.410 --> 00:20:34.840 align:middle line:84%
from the earlier task of
intersite section task 2.1.

00:20:34.840 --> 00:20:36.220 align:middle line:84%
So I don't have
to create a trunk

00:20:36.220 --> 00:20:38.740 align:middle line:90%
on HQ cluster towards SME.

00:20:38.740 --> 00:20:40.420 align:middle line:90%
That was already done.

00:20:40.420 --> 00:20:43.450 align:middle line:84%
On the SME, I need to
make a trunk towards PTSN,

00:20:43.450 --> 00:20:44.830 align:middle line:90%
towards the VCUBE.

00:20:44.830 --> 00:20:47.980 align:middle line:84%
And that didn't exist, but
the name has been given to us,

00:20:47.980 --> 00:20:49.790 align:middle line:90%
and we use some different name.

00:20:49.790 --> 00:20:52.730 align:middle line:84%
So obviously, we would
lose points with that.

00:20:52.730 --> 00:20:55.240 align:middle line:84%
So I should go
back and modify it

00:20:55.240 --> 00:20:57.460 align:middle line:84%
to be matching the name
as per the question

00:20:57.460 --> 00:20:59.800 align:middle line:84%
because you don't want to
make that silly mistake where

00:20:59.800 --> 00:21:00.717 align:middle line:90%
you lose points--

00:21:00.717 --> 00:21:02.800 align:middle line:84%
where everything is working
as per the requirement

00:21:02.800 --> 00:21:05.870 align:middle line:84%
but because you gave the
wrong name, you lost points.

00:21:05.870 --> 00:21:09.500 align:middle line:84%
So let's go and change
this name to SME-PSTN.

00:21:09.500 --> 00:21:16.830 align:middle line:90%


00:21:16.830 --> 00:21:18.490 align:middle line:84%
Description doesn't
really matter

00:21:18.490 --> 00:21:21.390 align:middle line:90%
but the name should be SME-PSTN.

00:21:21.390 --> 00:21:38.050 align:middle line:90%


00:21:38.050 --> 00:21:41.125 align:middle line:90%
Let's go back and check.

00:21:41.125 --> 00:21:44.980 align:middle line:90%


00:21:44.980 --> 00:21:48.550 align:middle line:84%
We need to go and
change it again.

00:21:48.550 --> 00:21:56.870 align:middle line:84%
This would be me
SME-PSTN and save.

00:21:56.870 --> 00:22:00.880 align:middle line:90%


00:22:00.880 --> 00:22:09.410 align:middle line:84%
Let's reset this again, and
now create your route group.

00:22:09.410 --> 00:22:18.690 align:middle line:90%


00:22:18.690 --> 00:22:19.700 align:middle line:90%
So create a route group.

00:22:19.700 --> 00:22:24.550 align:middle line:84%
The name of the route group
should be RG-SME-PSTN so

00:22:24.550 --> 00:22:32.710 align:middle line:90%
RG-SME-PSTN and save.

00:22:32.710 --> 00:22:36.350 align:middle line:90%


00:22:36.350 --> 00:22:38.420 align:middle line:90%
Let's now create our route list.

00:22:38.420 --> 00:22:43.290 align:middle line:90%


00:22:43.290 --> 00:22:45.290 align:middle line:90%
The name was RL-SME-PSTN.

00:22:45.290 --> 00:22:57.380 align:middle line:90%


00:22:57.380 --> 00:22:59.850 align:middle line:84%
And then finally,
once we've done that,

00:22:59.850 --> 00:23:02.030 align:middle line:84%
let's also enable run
on all active nodes.

00:23:02.030 --> 00:23:04.185 align:middle line:84%
This is something
that you should do.

00:23:04.185 --> 00:23:04.685 align:middle line:90%
Let's save.

00:23:04.685 --> 00:23:09.260 align:middle line:90%


00:23:09.260 --> 00:23:10.610 align:middle line:90%
We need to add the route group.

00:23:10.610 --> 00:23:14.140 align:middle line:90%


00:23:14.140 --> 00:23:16.640 align:middle line:84%
Again, we are not doing standard
local route groups, so just

00:23:16.640 --> 00:23:18.555 align:middle line:90%
select your group directly.

00:23:18.555 --> 00:23:19.055 align:middle line:90%
Save.

00:23:19.055 --> 00:23:27.820 align:middle line:90%


00:23:27.820 --> 00:23:30.480 align:middle line:90%
And run on all active nodes.

00:23:30.480 --> 00:23:33.430 align:middle line:90%


00:23:33.430 --> 00:23:35.800 align:middle line:84%
Next thing we need to do
is create a route pattern.

00:23:35.800 --> 00:23:39.870 align:middle line:90%


00:23:39.870 --> 00:23:47.275 align:middle line:84%
Here I will create just one
route pattern backslash +!.

00:23:47.275 --> 00:23:49.870 align:middle line:90%


00:23:49.870 --> 00:23:53.230 align:middle line:84%
This would go into PT-PSTN
which means when the call comes

00:23:53.230 --> 00:23:57.580 align:middle line:84%
in from HQ cluster,
the SIP trunk of HQ

00:23:57.580 --> 00:24:01.420 align:middle line:84%
cluster, the trunk which
is between HQ and SME,

00:24:01.420 --> 00:24:05.380 align:middle line:84%
that trunk inbound CSS has
access to PT-PSTN, which means

00:24:05.380 --> 00:24:07.420 align:middle line:84%
it goes to the route
pattern, and this

00:24:07.420 --> 00:24:12.040 align:middle line:84%
would route the call to the
VCUBE which is RL-SME-PSTN.

00:24:12.040 --> 00:24:14.890 align:middle line:90%


00:24:14.890 --> 00:24:17.830 align:middle line:84%
Let's enable urgent priority
because we don't want the call

00:24:17.830 --> 00:24:19.600 align:middle line:90%
to wait on the SME.

00:24:19.600 --> 00:24:21.550 align:middle line:90%
Let's save this.

00:24:21.550 --> 00:24:23.440 align:middle line:84%
No changes in the
calling and called

00:24:23.440 --> 00:24:26.290 align:middle line:84%
because SME is getting
e164 as the calling

00:24:26.290 --> 00:24:30.340 align:middle line:84%
and e164 as the
called, so no changes

00:24:30.340 --> 00:24:32.650 align:middle line:90%
are required on the SME.

00:24:32.650 --> 00:24:35.830 align:middle line:84%
All I need to do is do an urgent
priority because otherwise when

00:24:35.830 --> 00:24:37.750 align:middle line:84%
you make the call,
it'll go to the SME,

00:24:37.750 --> 00:24:41.050 align:middle line:84%
and it will wait there for
it to timeout before sending

00:24:41.050 --> 00:24:44.650 align:middle line:90%
the call to the VCUBE.

00:24:44.650 --> 00:24:47.610 align:middle line:90%
Let's say, OK.

00:24:47.610 --> 00:24:49.920 align:middle line:84%
And once this is done,
all we need to do now

00:24:49.920 --> 00:24:54.630 align:middle line:84%
is configure R1 and
R2 for dial peers.

00:24:54.630 --> 00:24:58.500 align:middle line:84%
Let's now go to R1
and start with R1.

00:24:58.500 --> 00:25:04.860 align:middle line:84%
The first thing that I would
do is voice service voip.

00:25:04.860 --> 00:25:12.630 align:middle line:84%
Here I will do no IP address
trusted authenticate and mode

00:25:12.630 --> 00:25:17.940 align:middle line:84%
border-element
license capacity 500.

00:25:17.940 --> 00:25:23.490 align:middle line:84%
And allow connections
SIP to SIP.

00:25:23.490 --> 00:25:26.570 align:middle line:84%
And make sure you
enabled redundancy.

00:25:26.570 --> 00:25:29.370 align:middle line:90%


00:25:29.370 --> 00:25:39.770 align:middle line:84%
I believe the command is
redundancy-group and the group

00:25:39.770 --> 00:25:40.270 align:middle line:90%
name.

00:25:40.270 --> 00:25:42.880 align:middle line:84%
If you remember, we had
configured the redundancy group

00:25:42.880 --> 00:25:46.070 align:middle line:90%
number as 1.

00:25:46.070 --> 00:25:48.755 align:middle line:90%
So redundancy-group 1.

00:25:48.755 --> 00:25:51.680 align:middle line:90%


00:25:51.680 --> 00:25:55.820 align:middle line:84%
It says the user-specified
RG1 one is already associated

00:25:55.820 --> 00:25:59.000 align:middle line:90%
with the VOICE B2B HA.

00:25:59.000 --> 00:26:00.030 align:middle line:90%
Let's go and check.

00:26:00.030 --> 00:26:09.330 align:middle line:84%
Show run section
voice service voip,

00:26:09.330 --> 00:26:12.420 align:middle line:84%
so I already have the
redundancy-group 1.

00:26:12.420 --> 00:26:17.432 align:middle line:84%
Next thing what I would do
is create some dial peers.

00:26:17.432 --> 00:26:19.140 align:middle line:84%
Now, the first thing
what I'm going to do

00:26:19.140 --> 00:26:21.540 align:middle line:84%
is I'm going to
create an inbound dial

00:26:21.540 --> 00:26:24.870 align:middle line:84%
peer because we don't really
want to match the default dial

00:26:24.870 --> 00:26:27.420 align:middle line:90%
peer.

00:26:27.420 --> 00:26:29.730 align:middle line:84%
Because again, if you match
the default dial peer,

00:26:29.730 --> 00:26:31.800 align:middle line:84%
it's not a good thing to
match the default peer

00:26:31.800 --> 00:26:38.430 align:middle line:84%
because it does not really
have any DTMF or any

00:26:38.430 --> 00:26:39.550 align:middle line:90%
of the features.

00:26:39.550 --> 00:26:42.270 align:middle line:84%
So what we should do is
create an inbound dial peer

00:26:42.270 --> 00:26:43.890 align:middle line:84%
and then create an
outbound dial peer.

00:26:43.890 --> 00:26:46.680 align:middle line:84%
Inbound dial peer would be
the one coming from SME.

00:26:46.680 --> 00:26:49.200 align:middle line:84%
So when the call comes
in from SME to the VCUBE,

00:26:49.200 --> 00:26:51.360 align:middle line:84%
it's going to match
that inbound dial peer.

00:26:51.360 --> 00:26:53.130 align:middle line:84%
So first thing what
I'm going to do

00:26:53.130 --> 00:26:58.790 align:middle line:84%
is create a voice class that
matches my inbound dial peer

00:26:58.790 --> 00:27:03.420 align:middle line:90%
based on the calling number.

00:27:03.420 --> 00:27:06.800 align:middle line:84%
So if the calling number
is HQ, if HQ is calling in

00:27:06.800 --> 00:27:08.932 align:middle line:90%
or if site B is calling in.

00:27:08.932 --> 00:27:10.640 align:middle line:84%
Right now we don't
really care about site

00:27:10.640 --> 00:27:12.170 align:middle line:90%
B. We only care about HQ.

00:27:12.170 --> 00:27:17.360 align:middle line:84%
So let's say, let's get a
voice class e164-patent-map.

00:27:17.360 --> 00:27:19.360 align:middle line:90%
Let's say, 1,000.

00:27:19.360 --> 00:27:28.010 align:middle line:84%
Here I will say e164
+1408202 dot dot dot dot.

00:27:28.010 --> 00:27:34.940 align:middle line:84%
So if it matches calling
number as +1408202XXXX,

00:27:34.940 --> 00:27:38.270 align:middle line:84%
then it's going to
match this pattern map.

00:27:38.270 --> 00:27:42.530 align:middle line:84%
So create one voice class
e164 pattern map which

00:27:42.530 --> 00:27:44.090 align:middle line:90%
matches the calling number.

00:27:44.090 --> 00:27:47.180 align:middle line:90%
Create a dial peer.

00:27:47.180 --> 00:27:52.130 align:middle line:84%
Dial-peer voice let's
say, 1,000 voip.

00:27:52.130 --> 00:27:56.890 align:middle line:84%
Here I would say
session protocol SIP.

00:27:56.890 --> 00:28:02.874 align:middle line:84%
And incoming calling
based on e164--

00:28:02.874 --> 00:28:05.680 align:middle line:90%


00:28:05.680 --> 00:28:08.530 align:middle line:84%
calling based on
e164-pattern-map-1,000.

00:28:08.530 --> 00:28:14.050 align:middle line:84%
So this dial peer is going to
match if the calling number is

00:28:14.050 --> 00:28:16.090 align:middle line:90%
from HQ.

00:28:16.090 --> 00:28:19.500 align:middle line:84%
And if it matches
what do we want to do?

00:28:19.500 --> 00:28:24.030 align:middle line:84%
We want-- now, you can
define the codex if you want.

00:28:24.030 --> 00:28:26.580 align:middle line:90%
You can define DTMF if you want.

00:28:26.580 --> 00:28:31.890 align:middle line:84%
Let's say, I define
codec g711ulaw.

00:28:31.890 --> 00:28:37.170 align:middle line:84%
I can define things
like DTMF relay.

00:28:37.170 --> 00:28:39.870 align:middle line:84%
Now again, in the lab exam,
because the question really

00:28:39.870 --> 00:28:43.230 align:middle line:84%
does not say anything about
the DTMF, what I would suggest

00:28:43.230 --> 00:28:48.270 align:middle line:84%
is use the RTP NTE and
use maybe sip-kpml.

00:28:48.270 --> 00:28:52.160 align:middle line:90%


00:28:52.160 --> 00:28:53.932 align:middle line:84%
Again, if you use
these two things,

00:28:53.932 --> 00:28:55.640 align:middle line:84%
you would not have a
problem, whether you

00:28:55.640 --> 00:29:00.410 align:middle line:84%
have UCCX or Unity or any
other applications coming in

00:29:00.410 --> 00:29:02.700 align:middle line:90%
because they all support that.

00:29:02.700 --> 00:29:06.800 align:middle line:84%
So I would suggest use
rtp-nte and sip-kpml.

00:29:06.800 --> 00:29:08.540 align:middle line:84%
You don't really
have to define this

00:29:08.540 --> 00:29:10.670 align:middle line:84%
at this point of time
as per this question,

00:29:10.670 --> 00:29:13.430 align:middle line:84%
but again, once we reach Unity
Connection, at some point,

00:29:13.430 --> 00:29:16.250 align:middle line:84%
you'll have to come
back to your dial peers

00:29:16.250 --> 00:29:19.650 align:middle line:90%
and add these later on.

00:29:19.650 --> 00:29:21.890 align:middle line:90%
So we don't really want that.

00:29:21.890 --> 00:29:25.800 align:middle line:90%


00:29:25.800 --> 00:29:30.000 align:middle line:84%
And let's also define our
binder control and media.

00:29:30.000 --> 00:29:38.480 align:middle line:84%
So that's going to be
voice class sip bind

00:29:38.480 --> 00:29:46.940 align:middle line:84%
control to gig 1 interface
bind control source-interface

00:29:46.940 --> 00:29:47.630 align:middle line:90%
as gig 1.

00:29:47.630 --> 00:29:50.210 align:middle line:84%
Now see, I could give
this bind command

00:29:50.210 --> 00:29:51.710 align:middle line:90%
under voice service VoIP.

00:29:51.710 --> 00:29:55.130 align:middle line:84%
However, it's not
recommended because if you

00:29:55.130 --> 00:29:57.530 align:middle line:84%
look at the diagram
carefully, we

00:29:57.530 --> 00:30:02.870 align:middle line:84%
have SME connecting to
the voice side, the LAN

00:30:02.870 --> 00:30:05.270 align:middle line:90%
side of R1 and R2.

00:30:05.270 --> 00:30:07.730 align:middle line:84%
And we have PSTN
doing a SIP trunk

00:30:07.730 --> 00:30:10.610 align:middle line:90%
to the WAN side of R1 and R2.

00:30:10.610 --> 00:30:14.000 align:middle line:84%
So if I do it under
voice service VoIP

00:30:14.000 --> 00:30:16.340 align:middle line:84%
I would have a problem
because one of them

00:30:16.340 --> 00:30:19.910 align:middle line:84%
is going to fail because my
bind control and media is

00:30:19.910 --> 00:30:21.030 align:middle line:90%
with the wrong interface.

00:30:21.030 --> 00:30:23.360 align:middle line:84%
So what I'm going to do is
on the inbound interface,

00:30:23.360 --> 00:30:27.650 align:middle line:84%
I'm using a different interface
for bind control and media,

00:30:27.650 --> 00:30:31.580 align:middle line:84%
and for WAN interface, I would
use a different interface

00:30:31.580 --> 00:30:36.170 align:middle line:90%
for the control and media.

00:30:36.170 --> 00:30:40.360 align:middle line:84%
So let's do one more,
which is for my media--

00:30:40.360 --> 00:30:44.260 align:middle line:84%
bind media
source-interface gig 1.

00:30:44.260 --> 00:30:47.545 align:middle line:84%
Gig 1 Is my LAN side interface,
which you can see here.

00:30:47.545 --> 00:30:50.150 align:middle line:90%


00:30:50.150 --> 00:30:52.190 align:middle line:90%
So I think we've done--

00:30:52.190 --> 00:30:53.350 align:middle line:90%
let's disable VAD.

00:30:53.350 --> 00:30:55.040 align:middle line:90%
VAD is bad.

00:30:55.040 --> 00:31:01.700 align:middle line:84%
So all we've done right now is
we did voice service VoIP Then

00:31:01.700 --> 00:31:10.480 align:middle line:84%
we did, I believe, map 1000--
show run pipe section map 1000

00:31:10.480 --> 00:31:13.270 align:middle line:90%
and dial peer.

00:31:13.270 --> 00:31:16.090 align:middle line:90%
We made an inbound dial peer.

00:31:16.090 --> 00:31:20.050 align:middle line:90%


00:31:20.050 --> 00:31:22.340 align:middle line:90%
There should be no space.

00:31:22.340 --> 00:31:25.310 align:middle line:90%
So this is what we did so far.

00:31:25.310 --> 00:31:33.050 align:middle line:84%
Let's copy this exactly
the same thing on R2.

00:31:33.050 --> 00:31:42.820 align:middle line:90%
Let's go to R2 and paste this.

00:31:42.820 --> 00:31:45.390 align:middle line:84%
So do it on both the
routers, even though they

00:31:45.390 --> 00:31:49.020 align:middle line:84%
are redundant vCUBEs the
configuration does not

00:31:49.020 --> 00:31:54.660 align:middle line:84%
replicate, so you have to
configure on both sides.

00:31:54.660 --> 00:31:57.800 align:middle line:90%
Let's go back to R1.

00:31:57.800 --> 00:31:59.930 align:middle line:84%
So now my inbound
dial peer is going

00:31:59.930 --> 00:32:02.743 align:middle line:84%
to match if the call
comes in from HQ site.

00:32:02.743 --> 00:32:04.160 align:middle line:84%
Next thing what
I'm going to do is

00:32:04.160 --> 00:32:07.160 align:middle line:84%
match outbound for local
calls and national calls

00:32:07.160 --> 00:32:08.730 align:middle line:90%
and international calls.

00:32:08.730 --> 00:32:11.180 align:middle line:84%
So for local calls,
what's the requirement?

00:32:11.180 --> 00:32:17.270 align:middle line:84%
The requirement is that
when the call comes in,

00:32:17.270 --> 00:32:20.690 align:middle line:84%
on the inbound
call leg, outbound

00:32:20.690 --> 00:32:26.210 align:middle line:84%
send to PSTN calling
number should be 10 digits,

00:32:26.210 --> 00:32:30.230 align:middle line:90%
and called should be 11 digits.

00:32:30.230 --> 00:32:33.170 align:middle line:84%
That's the requirement,
which we can read back

00:32:33.170 --> 00:32:35.540 align:middle line:90%
in the task requirements.

00:32:35.540 --> 00:32:41.650 align:middle line:84%
If you read back
here, PSTN for called

00:32:41.650 --> 00:32:44.950 align:middle line:90%
expects 1 followed by 10 digits.

00:32:44.950 --> 00:32:47.470 align:middle line:84%
For calling, for
local and national,

00:32:47.470 --> 00:32:50.960 align:middle line:84%
it expects without the plus
or one, which means 10 digits.

00:32:50.960 --> 00:32:52.870 align:middle line:90%
So calling should be 10 digits.

00:32:52.870 --> 00:32:57.070 align:middle line:90%
Called should be 11 digits.

00:32:57.070 --> 00:32:58.760 align:middle line:90%
That's a requirement.

00:32:58.760 --> 00:33:02.830 align:middle line:84%
So let's first go and create
a dial peer dial peer voice,

00:33:02.830 --> 00:33:10.110 align:middle line:84%
let's say, 10 voip, where
session protocol would be SIP.

00:33:10.110 --> 00:33:16.330 align:middle line:84%
Session target is going
to be your SIP ITSP,

00:33:16.330 --> 00:33:22.980 align:middle line:84%
which is going to be a
PSTN, ipv4157.26.1.11,

00:33:22.980 --> 00:33:27.280 align:middle line:90%
which is the PSTN publisher.

00:33:27.280 --> 00:33:33.170 align:middle line:84%
Next thing I would
say let's match--

00:33:33.170 --> 00:33:38.110 align:middle line:84%
so this pattern should match
based on destination pattern.

00:33:38.110 --> 00:33:40.000 align:middle line:90%
And what are we dialing?

00:33:40.000 --> 00:33:46.060 align:middle line:84%
We are dialing-- we are getting
on the inbound call leg,

00:33:46.060 --> 00:33:47.770 align:middle line:90%
we are getting E.164.

00:33:47.770 --> 00:33:56.710 align:middle line:84%
So let's create-- let's do
destination e164-pattern-map.

00:33:56.710 --> 00:33:58.360 align:middle line:90%
Let's say 10.

00:33:58.360 --> 00:34:01.840 align:middle line:84%
It's not defined yet,
so let's define that.

00:34:01.840 --> 00:34:24.670 align:middle line:84%
Voice class e164-pattern-map 10,
and say E.164 +1[2-9]..[2-9] 1,

00:34:24.670 --> 00:34:27.550 align:middle line:90%
2, 3, 4, 5, 6.

00:34:27.550 --> 00:34:35.830 align:middle line:84%
So if my destination is anything
+1408 or +1972 or anything,

00:34:35.830 --> 00:34:39.520 align:middle line:84%
if it's plus 1 and then the area
code and then the subscriber

00:34:39.520 --> 00:34:42.429 align:middle line:90%
number, it will match this.

00:34:42.429 --> 00:34:47.020 align:middle line:84%
Go back to your dial
peer, dial peer 10,

00:34:47.020 --> 00:34:52.219 align:middle line:84%
and say destination
e164-pattern-map 10.

00:34:52.219 --> 00:34:55.719 align:middle line:84%
So this will match
if my called number

00:34:55.719 --> 00:35:03.590 align:middle line:84%
is plus 1, area code, subscriber
ID, or subscriber number.

00:35:03.590 --> 00:35:09.140 align:middle line:84%
Next thing that I would
do is do my voice class.

00:35:09.140 --> 00:35:15.440 align:middle line:84%
So voice class sip bind
control to interface gig--

00:35:15.440 --> 00:35:19.000 align:middle line:90%
I believe it's gig 2--

00:35:19.000 --> 00:35:23.410 align:middle line:84%
source interface gig 2, which
is a [INAUDIBLE] interface.

00:35:23.410 --> 00:35:24.715 align:middle line:90%
Same thing for media.

00:35:24.715 --> 00:35:27.640 align:middle line:90%


00:35:27.640 --> 00:35:29.350 align:middle line:90%
And define your codecs.

00:35:29.350 --> 00:35:32.110 align:middle line:84%
So codec is going to
be, let's say, G.711.

00:35:32.110 --> 00:35:35.380 align:middle line:84%
Again, I highly recommend
that you use G.711

00:35:35.380 --> 00:35:40.930 align:middle line:84%
because there is no
transcode-- all the routers are

00:35:40.930 --> 00:35:41.870 align:middle line:90%
virtual routers.

00:35:41.870 --> 00:35:45.100 align:middle line:84%
So it doesn't really support
you having a transcoder.

00:35:45.100 --> 00:35:49.450 align:middle line:84%
So since there is no transcoder
support in the lab exam,

00:35:49.450 --> 00:35:51.760 align:middle line:84%
G.711 would be the
safest bet for you

00:35:51.760 --> 00:35:55.570 align:middle line:84%
to use because all your other
applications support G.711.

00:35:55.570 --> 00:35:57.250 align:middle line:90%
UCCX supports G.711.

00:35:57.250 --> 00:35:59.110 align:middle line:90%
Unity Connection supports G.711.

00:35:59.110 --> 00:36:02.020 align:middle line:84%
So it would be safe
for you to use G.711.

00:36:02.020 --> 00:36:14.090 align:middle line:84%
So codec g711 dtmf-relay
rtp-nte and sip-kpml, no VAD.

00:36:14.090 --> 00:36:20.160 align:middle line:84%
I believe that should be
enough for making calls.

00:36:20.160 --> 00:36:21.510 align:middle line:90%
Let's, in fact, test it out.

00:36:21.510 --> 00:36:23.090 align:middle line:90%
So if I check right now.

00:36:23.090 --> 00:36:32.090 align:middle line:84%
Let's do a show run section
map 10 pipe dial-peer voice

00:36:32.090 --> 00:36:33.620 align:middle line:90%
10 voip.

00:36:33.620 --> 00:36:38.320 align:middle line:90%


00:36:38.320 --> 00:36:40.370 align:middle line:84%
If you see, this is
what I configured.

00:36:40.370 --> 00:36:45.640 align:middle line:84%
So if the called
number is E.164,

00:36:45.640 --> 00:36:50.090 align:middle line:84%
which it matches
on the inbound, it

00:36:50.090 --> 00:36:52.490 align:middle line:84%
would match the dial
peer on the outbound,

00:36:52.490 --> 00:36:56.150 align:middle line:84%
because destination is based
on the E.164 pattern map.

00:36:56.150 --> 00:36:59.480 align:middle line:84%
And once it matches, I
need to make some changes

00:36:59.480 --> 00:37:03.200 align:middle line:84%
to the calling and the called,
which I haven't done right now.

00:37:03.200 --> 00:37:05.300 align:middle line:84%
But I will test
my calling first.

00:37:05.300 --> 00:37:10.160 align:middle line:90%
Let's do a debug ccsip messages.

00:37:10.160 --> 00:37:13.440 align:middle line:84%
And let's try making
an outbound call.

00:37:13.440 --> 00:37:20.680 align:middle line:84%
So let's go back to Jabber1,
go back to my Tony Stark,

00:37:20.680 --> 00:37:24.790 align:middle line:90%
and let's dial 95151111.

00:37:24.790 --> 00:37:27.200 align:middle line:90%
What should happen?

00:37:27.200 --> 00:37:32.750 align:middle line:84%
The call should, from
the HQ publisher,

00:37:32.750 --> 00:37:34.670 align:middle line:84%
it should match the
translation pattern.

00:37:34.670 --> 00:37:38.060 align:middle line:84%
The phone CSS sends it
to translation pattern,

00:37:38.060 --> 00:37:41.870 align:middle line:84%
matches that, calling number
becomes E.164, called becomes

00:37:41.870 --> 00:37:46.010 align:middle line:84%
E.164, goes to route
pattern, goes to SIP trunk,

00:37:46.010 --> 00:37:49.190 align:middle line:84%
does not strip off the plus
from the called number,

00:37:49.190 --> 00:37:50.790 align:middle line:90%
and forwards it to SME.

00:37:50.790 --> 00:37:55.430 align:middle line:84%
So SME gets calling number
as E.164 and called as E.164.

00:37:55.430 --> 00:37:59.600 align:middle line:84%
Next, the SME sends it
down to PSTN to, in fact,

00:37:59.600 --> 00:38:02.450 align:middle line:90%
the CUBEs R1 and R2.

00:38:02.450 --> 00:38:05.030 align:middle line:90%
On R1 and R2--

00:38:05.030 --> 00:38:10.190 align:middle line:90%
on R1, it will first match--

00:38:10.190 --> 00:38:16.820 align:middle line:84%
let's do show run section
dial-peer and map 10.

00:38:16.820 --> 00:38:21.770 align:middle line:84%
So it will first match dial
peer 1000 on the inbound.

00:38:21.770 --> 00:38:22.850 align:middle line:90%
Why will it match that?

00:38:22.850 --> 00:38:29.510 align:middle line:84%
Because it says here that
incoming calling is E.164

00:38:29.510 --> 00:38:33.680 align:middle line:84%
pattern map 1000, which if
the calling number is +1408,

00:38:33.680 --> 00:38:36.220 align:middle line:90%
so it will match this dial peer.

00:38:36.220 --> 00:38:39.580 align:middle line:84%
Then, on the
outbound call leg, it

00:38:39.580 --> 00:38:44.830 align:middle line:84%
would match dial peer 10 because
of the destination pattern,

00:38:44.830 --> 00:38:47.530 align:middle line:84%
being the
e164-pattern-map 10, which

00:38:47.530 --> 00:38:50.770 align:middle line:84%
says if the called
number is E.164 again,

00:38:50.770 --> 00:38:55.141 align:middle line:84%
then match this and
forward it out to PSTN.

00:38:55.141 --> 00:38:58.840 align:middle line:84%
So it should match, but
obviously, the call may work.

00:38:58.840 --> 00:39:00.550 align:middle line:90%
The call may not work.

00:39:00.550 --> 00:39:01.660 align:middle line:90%
Will we get points?

00:39:01.660 --> 00:39:03.220 align:middle line:84%
No, because right
now, I would be

00:39:03.220 --> 00:39:05.920 align:middle line:84%
sending E.164 to
PSTN as the calling

00:39:05.920 --> 00:39:09.190 align:middle line:90%
and E.164 as the called to PSTN.

00:39:09.190 --> 00:39:15.410 align:middle line:84%
Let's go and dial this and
say call, and go back to R1

00:39:15.410 --> 00:39:16.970 align:middle line:90%
and check my debug.

00:39:16.970 --> 00:39:28.445 align:middle line:84%
If you see anything, debug
ccsip messages terminal monitor.

00:39:28.445 --> 00:39:32.420 align:middle line:90%


00:39:32.420 --> 00:39:34.310 align:middle line:90%
So I see something here.

00:39:34.310 --> 00:39:37.610 align:middle line:84%
Let's analyze this
debug message.

00:39:37.610 --> 00:39:38.750 align:middle line:90%
Did the call work?

00:39:38.750 --> 00:39:39.810 align:middle line:90%
I don't really know.

00:39:39.810 --> 00:39:41.547 align:middle line:90%
Let's go and check on the PSTN.

00:39:41.547 --> 00:39:42.380 align:middle line:90%
Let's go to Jabber3.

00:39:42.380 --> 00:39:45.850 align:middle line:90%


00:39:45.850 --> 00:39:46.820 align:middle line:90%
It did work.

00:39:46.820 --> 00:39:51.910 align:middle line:84%
And if you see, the calling
number is E.164 number.

00:39:51.910 --> 00:39:59.660 align:middle line:84%
Let me go and answer
this, and go back to R1,

00:39:59.660 --> 00:40:03.605 align:middle line:84%
and do an un all, and
disconnect my call.

00:40:03.605 --> 00:40:10.440 align:middle line:90%


00:40:10.440 --> 00:40:13.590 align:middle line:90%
And let's look at the debug.

00:40:13.590 --> 00:40:15.150 align:middle line:90%
Scroll back all the way up.

00:40:15.150 --> 00:40:29.710 align:middle line:90%


00:40:29.710 --> 00:40:33.060 align:middle line:84%
All right, so I
received an invite

00:40:33.060 --> 00:40:36.130 align:middle line:84%
from the SME, which
you can see here.

00:40:36.130 --> 00:40:37.530 align:middle line:90%
This is the SME IP address.

00:40:37.530 --> 00:40:40.870 align:middle line:90%


00:40:40.870 --> 00:40:43.420 align:middle line:90%
Called number is E.164.

00:40:43.420 --> 00:40:45.970 align:middle line:90%
Called number is E.164.

00:40:45.970 --> 00:40:48.760 align:middle line:84%
So that meets the
requirement that HQ

00:40:48.760 --> 00:40:51.650 align:middle line:84%
is sending to SME calling
and called as E.164.

00:40:51.650 --> 00:40:56.350 align:middle line:84%
SME is sending down to R1 as
E.164, calling and called.

00:40:56.350 --> 00:41:00.280 align:middle line:90%
Then I send-- trying back up--

00:41:00.280 --> 00:41:03.190 align:middle line:90%
I send the invite ahead to PSTN.

00:41:03.190 --> 00:41:07.480 align:middle line:84%
So I am sending to PSTN
E.164 as the called,

00:41:07.480 --> 00:41:10.210 align:middle line:90%
and calling also as E.164.

00:41:10.210 --> 00:41:12.770 align:middle line:84%
That does not meet the
requirements of the question.

00:41:12.770 --> 00:41:15.177 align:middle line:84%
So even though my call
works, it does not

00:41:15.177 --> 00:41:16.760 align:middle line:84%
meet the requirements
of the question.

00:41:16.760 --> 00:41:18.010 align:middle line:90%
So I need to go and modify it.

00:41:18.010 --> 00:41:21.400 align:middle line:84%
So I would create some
voice translation rules now.

00:41:21.400 --> 00:41:25.610 align:middle line:84%
So let's go back and create
some voice translation rules.

00:41:25.610 --> 00:41:27.100 align:middle line:84%
So the first thing
that I would do

00:41:27.100 --> 00:41:30.220 align:middle line:84%
is create a voice
translation rule.

00:41:30.220 --> 00:41:32.590 align:middle line:84%
So voice
translation-rule-- let's

00:41:32.590 --> 00:41:35.680 align:middle line:84%
say rule number 10, which
will match the calling.

00:41:35.680 --> 00:41:36.700 align:middle line:90%
So rule number one--

00:41:36.700 --> 00:41:39.790 align:middle line:90%


00:41:39.790 --> 00:41:50.520 align:middle line:84%
if the calling is backslash plus
1 backslash, let's make a set--

00:41:50.520 --> 00:41:56.460 align:middle line:90%
2-9 backslash.

00:41:56.460 --> 00:41:59.820 align:middle line:90%
Close your parentheses.

00:41:59.820 --> 00:42:04.860 align:middle line:90%
Then change it to backslash 1.

00:42:04.860 --> 00:42:06.280 align:middle line:90%
So what am I doing here?

00:42:06.280 --> 00:42:07.530 align:middle line:90%
What am I saying?

00:42:07.530 --> 00:42:15.894 align:middle line:84%
I am saying that if the number
starts with plus 1 and then 2-9

00:42:15.894 --> 00:42:17.790 align:middle line:90%
dot dot--

00:42:17.790 --> 00:42:20.160 align:middle line:90%
and that's inside a set--

00:42:20.160 --> 00:42:22.660 align:middle line:90%
replace that with your set.

00:42:22.660 --> 00:42:25.650 align:middle line:84%
So now, if you notice,
I don't give dollar

00:42:25.650 --> 00:42:28.630 align:middle line:84%
sign, which means it could
be any number of digits.

00:42:28.630 --> 00:42:32.130 align:middle line:84%
But it has to start with
plus 1 and then 2-9,

00:42:32.130 --> 00:42:34.480 align:middle line:90%
and then any variable digits.

00:42:34.480 --> 00:42:36.780 align:middle line:90%
So what is going to happen here?

00:42:36.780 --> 00:42:38.580 align:middle line:90%
If I go and test this rule--

00:42:38.580 --> 00:42:47.980 align:middle line:84%
test voice translation-rule
number 10, if I test this--

00:42:47.980 --> 00:42:53.640 align:middle line:84%
let's say, if the calling
number is +14082022003,

00:42:53.640 --> 00:42:58.440 align:middle line:84%
this replaces it
with 4082022003.

00:42:58.440 --> 00:43:00.820 align:middle line:90%
So calling number is good.

00:43:00.820 --> 00:43:05.760 align:middle line:84%
Let's now go and do exactly
the same thing for called.

00:43:05.760 --> 00:43:09.900 align:middle line:84%
Let's create a new rule
voice translation-rule number

00:43:09.900 --> 00:43:20.430 align:middle line:84%
11, where rule number 1 says if
the called is backslash plus 1,

00:43:20.430 --> 00:43:37.830 align:middle line:84%
and let's make a set again, 2-9
backslash close parentheses,

00:43:37.830 --> 00:43:39.990 align:middle line:84%
the only difference here
from the earlier rule

00:43:39.990 --> 00:43:46.660 align:middle line:84%
would be I would take this
plus inside my parentheses.

00:43:46.660 --> 00:43:48.960 align:middle line:84%
So look at the difference
between the two rules.

00:43:48.960 --> 00:43:51.700 align:middle line:90%


00:43:51.700 --> 00:43:54.230 align:middle line:84%
Because the requirement
is we must send 11 digits,

00:43:54.230 --> 00:43:56.260 align:middle line:90%
so I need to retain the 1.

00:43:56.260 --> 00:44:01.200 align:middle line:84%
So what I'm saying
here is backslash plus,

00:44:01.200 --> 00:44:04.360 align:middle line:84%
so plus, and then I
have the set here.

00:44:04.360 --> 00:44:08.560 align:middle line:90%
The set says 1 2-9 dot dot.

00:44:08.560 --> 00:44:10.970 align:middle line:84%
So this could be any
number of digits,

00:44:10.970 --> 00:44:15.400 align:middle line:84%
but it has to start with
plus 1, 2-9, and then

00:44:15.400 --> 00:44:16.420 align:middle line:90%
any variable digits.

00:44:16.420 --> 00:44:19.030 align:middle line:90%


00:44:19.030 --> 00:44:20.870 align:middle line:84%
We need to replace
it with the set.

00:44:20.870 --> 00:44:28.090 align:middle line:84%
So let's go back here and
replace it with backslash 1.

00:44:28.090 --> 00:44:30.700 align:middle line:84%
So the effect of this,
if I test this rule--

00:44:30.700 --> 00:44:37.570 align:middle line:84%
test voice translation
rule 11 +14085151111,

00:44:37.570 --> 00:44:40.630 align:middle line:84%
which is the PSTN local number,
if I'm dialing this number,

00:44:40.630 --> 00:44:45.790 align:middle line:84%
it will replace it
with 14085151111.

00:44:45.790 --> 00:44:48.730 align:middle line:84%
So I'm retaining the
one in the called,

00:44:48.730 --> 00:44:52.910 align:middle line:84%
and I'm not retaining
the one in the calling.

00:44:52.910 --> 00:44:56.170 align:middle line:84%
Now let's create a voice
translation profile.

00:44:56.170 --> 00:45:07.410 align:middle line:84%
So voice translation-profile--
let's name this LOCAL-NATIONAL,

00:45:07.410 --> 00:45:15.790 align:middle line:84%
and say translate calling
as 10 and called as 11.

00:45:15.790 --> 00:45:17.650 align:middle line:90%
Go back to your dial peer.

00:45:17.650 --> 00:45:22.540 align:middle line:84%
So dial-peer voice 10-- this
was your outbound dial peer.

00:45:22.540 --> 00:45:24.190 align:middle line:84%
Apply your voice
translation rule--

00:45:24.190 --> 00:45:32.250 align:middle line:84%
so translation-profile outgoing
would be LOCAL-NATIONAL.

00:45:32.250 --> 00:45:35.160 align:middle line:90%


00:45:35.160 --> 00:45:36.780 align:middle line:90%
That's it.

00:45:36.780 --> 00:45:37.570 align:middle line:90%
It should work.

00:45:37.570 --> 00:45:38.950 align:middle line:90%
Let's go and test it again.

00:45:38.950 --> 00:45:43.710 align:middle line:84%
I would do a debug
ccsip messages

00:45:43.710 --> 00:45:53.300 align:middle line:84%
and go back and make
that call 95151111.

00:45:53.300 --> 00:45:57.440 align:middle line:84%
If I look at PSTN, I
should receive a call here,

00:45:57.440 --> 00:46:00.080 align:middle line:84%
but let's go back to R1 and
look at the debug messages.

00:46:00.080 --> 00:46:11.160 align:middle line:90%


00:46:11.160 --> 00:46:13.365 align:middle line:84%
I will go back here
and answer the call.

00:46:13.365 --> 00:46:14.490 align:middle line:90%
Look at the calling number.

00:46:14.490 --> 00:46:16.350 align:middle line:90%
It's 10 digits now.

00:46:16.350 --> 00:46:18.490 align:middle line:90%
Let's answer this.

00:46:18.490 --> 00:46:24.065 align:middle line:84%
And before I end this, let's
do un all and go back and end

00:46:24.065 --> 00:46:24.565 align:middle line:90%
the call.

00:46:24.565 --> 00:46:27.610 align:middle line:90%


00:46:27.610 --> 00:46:33.765 align:middle line:84%
Let's go back to R1
and analyze our debug.

00:46:33.765 --> 00:46:39.360 align:middle line:90%


00:46:39.360 --> 00:46:45.900 align:middle line:84%
So we have calling
number coming from SME

00:46:45.900 --> 00:46:50.460 align:middle line:84%
is E.164 calling and called,
which you can see here.

00:46:50.460 --> 00:46:55.590 align:middle line:84%
When it forwards to the PSTN,
it changes the calling number

00:46:55.590 --> 00:47:01.440 align:middle line:84%
to 10 digits, called number to
11 digits, which you can see,

00:47:01.440 --> 00:47:03.790 align:middle line:84%
and that meets the
requirement of the question.

00:47:03.790 --> 00:47:07.620 align:middle line:84%
So with this, we've basically
done with local and national.

00:47:07.620 --> 00:47:09.420 align:middle line:84%
I should be able to
call national also.

00:47:09.420 --> 00:47:11.580 align:middle line:90%
Let's try the national also.

00:47:11.580 --> 00:47:19.367 align:middle line:84%
Let's go back here
and dial 919725252222.

00:47:19.367 --> 00:47:20.700 align:middle line:90%
Now how do you know this number?

00:47:20.700 --> 00:47:24.300 align:middle line:84%
You can go back to your
Jabber3, which is your PSTN,

00:47:24.300 --> 00:47:26.880 align:middle line:84%
and look at your
phone numbers here.

00:47:26.880 --> 00:47:29.130 align:middle line:90%
It's +19725252222.

00:47:29.130 --> 00:47:33.190 align:middle line:84%
So let's go back
here and dial that.

00:47:33.190 --> 00:47:36.840 align:middle line:84%
So I'm dialing with 9,
which is the access code, 1,

00:47:36.840 --> 00:47:40.832 align:middle line:90%
and then 9725252222.

00:47:40.832 --> 00:47:42.540 align:middle line:90%
Let's dial that.

00:47:42.540 --> 00:47:45.630 align:middle line:90%
It should ring on the PSTN.

00:47:45.630 --> 00:47:47.530 align:middle line:90%
Give it a few seconds.

00:47:47.530 --> 00:47:50.520 align:middle line:84%
There is a bit of
delay, but again,

00:47:50.520 --> 00:47:59.560 align:middle line:84%
this is only because we are
using virtual routers as a V/Q.

00:47:59.560 --> 00:48:02.410 align:middle line:84%
So, as you can see, I have
the incoming call coming in.

00:48:02.410 --> 00:48:04.060 align:middle line:84%
Calling number is
10 digits, which

00:48:04.060 --> 00:48:05.870 align:middle line:84%
meets the requirement
of the question.

00:48:05.870 --> 00:48:07.930 align:middle line:90%
And I am able to--

00:48:07.930 --> 00:48:08.980 align:middle line:90%
I see video.

00:48:08.980 --> 00:48:11.860 align:middle line:84%
I see video, and if
I do Control-Shift-S,

00:48:11.860 --> 00:48:13.930 align:middle line:90%
I should see the audio also.

00:48:13.930 --> 00:48:17.210 align:middle line:90%
It's using G.711.

00:48:17.210 --> 00:48:21.300 align:middle line:84%
Now, one thing that
I want to point out

00:48:21.300 --> 00:48:28.530 align:middle line:84%
is if you go back here and
analyze this debug ccsip

00:48:28.530 --> 00:48:33.070 align:middle line:84%
messages, when the
call came in from SME,

00:48:33.070 --> 00:48:36.220 align:middle line:84%
there was no SDP because, by
default, the call manager does

00:48:36.220 --> 00:48:38.090 align:middle line:90%
delayed alpha.

00:48:38.090 --> 00:48:42.770 align:middle line:84%
Once I send the invite
to PSTN from the CUBE,

00:48:42.770 --> 00:48:44.750 align:middle line:84%
it was delayed over
because the dial peer also

00:48:44.750 --> 00:48:47.270 align:middle line:90%
has delayed alpha by default.

00:48:47.270 --> 00:48:51.950 align:middle line:84%
When the PSTN
picked up the call,

00:48:51.950 --> 00:48:59.150 align:middle line:84%
the PSTN call manager sent
200 OK to my router, which

00:48:59.150 --> 00:48:59.900 align:middle line:90%
you can see here.

00:48:59.900 --> 00:49:02.270 align:middle line:84%
And because the PSTN in
the 200 OK because delayed

00:49:02.270 --> 00:49:05.150 align:middle line:84%
alpha in the 200
OK, I would see SDP,

00:49:05.150 --> 00:49:09.500 align:middle line:84%
which means I see all the
codecs that PSTN supports.

00:49:09.500 --> 00:49:13.070 align:middle line:84%
So PSTN sends all of
this list of codecs.

00:49:13.070 --> 00:49:19.280 align:middle line:84%
When the CUBE sends that to
SME, look at the sent 200 OK.

00:49:19.280 --> 00:49:26.990 align:middle line:84%
He sends only G.711 because
I have hardcoded codec G.711

00:49:26.990 --> 00:49:28.580 align:middle line:90%
on my dial peer.

00:49:28.580 --> 00:49:34.190 align:middle line:84%
So call coming from HQ to
SME-- no SDP, delayed alpha.

00:49:34.190 --> 00:49:38.150 align:middle line:84%
SME to CUBE-- no
SDP, delayed alpha.

00:49:38.150 --> 00:49:41.390 align:middle line:84%
CUBE to PSTN-- no
SDP, delayed alpha.

00:49:41.390 --> 00:49:46.610 align:middle line:84%
PSTN and picks up the call,
200 OK comes back to R1

00:49:46.610 --> 00:49:52.370 align:middle line:84%
with a list of codecs, and
R1 replaces all the list

00:49:52.370 --> 00:49:56.840 align:middle line:84%
of codecs with G.711 because
he's hardcoded with G.711

00:49:56.840 --> 00:50:00.740 align:middle line:84%
and sends to SME that
we only support G.711.

00:50:00.740 --> 00:50:04.490 align:middle line:84%
So obviously, the SME
acknowledges back with G.711,

00:50:04.490 --> 00:50:09.050 align:middle line:90%
and my call is G.711.

00:50:09.050 --> 00:50:12.080 align:middle line:84%
Now if you want that the
CUBE does not participate

00:50:12.080 --> 00:50:15.350 align:middle line:84%
in the codecs selection,
you just want him to go pass

00:50:15.350 --> 00:50:17.780 align:middle line:84%
through, you could go
back to your dial peer,

00:50:17.780 --> 00:50:23.090 align:middle line:84%
both your inbound and outbound
dial peer, dial-peer voice 10--

00:50:23.090 --> 00:50:25.640 align:middle line:90%
I believe it was voice 1000--

00:50:25.640 --> 00:50:30.570 align:middle line:84%
and you could say could
basically say SDP pass through.

00:50:30.570 --> 00:50:37.750 align:middle line:84%
So what I could do is say
voice class voice-class

00:50:37.750 --> 00:50:44.080 align:middle line:90%
sip pass-thru content sdp.

00:50:44.080 --> 00:50:47.330 align:middle line:84%
And same thing I would
do for dial-peer 10,

00:50:47.330 --> 00:50:51.610 align:middle line:84%
which is the outbound,
say content SDP.

00:50:51.610 --> 00:50:54.890 align:middle line:90%
Look at the difference now.

00:50:54.890 --> 00:51:05.780 align:middle line:84%
So if I do debug ccsip messages
and make the call again--

00:51:05.780 --> 00:51:09.430 align:middle line:90%
let's say, 95151111.

00:51:09.430 --> 00:51:15.535 align:middle line:84%
Make the call-- go back
here and accept the call.

00:51:15.535 --> 00:51:30.220 align:middle line:90%


00:51:30.220 --> 00:51:33.630 align:middle line:90%
Oh, wait, this is less digits--

00:51:33.630 --> 00:51:55.540 align:middle line:90%
95151111.

00:51:55.540 --> 00:51:57.790 align:middle line:90%
Let's accept this call.

00:51:57.790 --> 00:52:02.290 align:middle line:90%
Go back to R1 and do and un all.

00:52:02.290 --> 00:52:05.790 align:middle line:90%
And let's end this call.

00:52:05.790 --> 00:52:07.180 align:middle line:90%
And let's analyze this.

00:52:07.180 --> 00:52:09.330 align:middle line:84%
So again, if I look
here, you would

00:52:09.330 --> 00:52:13.620 align:middle line:84%
notice that when I
received the call,

00:52:13.620 --> 00:52:17.040 align:middle line:84%
there was no SDP from the call
manager of HQ towards SME,

00:52:17.040 --> 00:52:20.850 align:middle line:84%
and from SME to CUBE,
there was no SDP.

00:52:20.850 --> 00:52:23.730 align:middle line:84%
Let's scroll all the way
up to where it starts from.

00:52:23.730 --> 00:52:24.970 align:middle line:90%
So it starts from here.

00:52:24.970 --> 00:52:28.590 align:middle line:90%
So received invite-- no SDP.

00:52:28.590 --> 00:52:32.760 align:middle line:90%
Sent invite to the PSTN--

00:52:32.760 --> 00:52:34.440 align:middle line:90%
no SDP.

00:52:34.440 --> 00:52:40.500 align:middle line:84%
Received 200 OK, which
is here, from the PSTN

00:52:40.500 --> 00:52:44.540 align:middle line:90%
with list of codecs.

00:52:44.540 --> 00:52:49.250 align:middle line:84%
Sent 200 OK to SME,
which you can see here,

00:52:49.250 --> 00:52:52.040 align:middle line:90%
with all the list of codecs.

00:52:52.040 --> 00:52:55.070 align:middle line:84%
So now, the SME and
the HQ call manager,

00:52:55.070 --> 00:52:59.030 align:middle line:84%
they have choices
of choosing a codec

00:52:59.030 --> 00:53:02.390 align:middle line:84%
because earlier, it was
the CUBE who was basically

00:53:02.390 --> 00:53:04.680 align:middle line:90%
changing the codec.

00:53:04.680 --> 00:53:06.798 align:middle line:90%
So you could do SDP pass-thrus.

00:53:06.798 --> 00:53:08.840 align:middle line:84%
Again, the question does
not really require this,

00:53:08.840 --> 00:53:10.280 align:middle line:90%
so read the question carefully.

00:53:10.280 --> 00:53:13.430 align:middle line:84%
My question does not require,
so if you do it, no problem.

00:53:13.430 --> 00:53:15.810 align:middle line:90%
If you don't do it, no problem.

00:53:15.810 --> 00:53:18.260 align:middle line:84%
So with this local and
national call is done,

00:53:18.260 --> 00:53:21.230 align:middle line:84%
the only thing left now
is international calls.

00:53:21.230 --> 00:53:25.920 align:middle line:84%
So let's quickly do the
international calls now.

00:53:25.920 --> 00:53:31.100 align:middle line:84%
So before I do dial
peers for international,

00:53:31.100 --> 00:53:34.520 align:middle line:84%
what I'm going to do is just
copy-paste all of the configs

00:53:34.520 --> 00:53:38.520 align:middle line:84%
that I did on R2 because I don't
really want to forget that.

00:53:38.520 --> 00:53:43.550 align:middle line:84%
So let's go and do
a show run section

00:53:43.550 --> 00:53:49.520 align:middle line:90%
map 10 pipe type dial peer.

00:53:49.520 --> 00:54:00.740 align:middle line:84%
And let's copy this all the way
from here, go to R2, and let's

00:54:00.740 --> 00:54:07.820 align:middle line:84%
paste that so that we have
exactly the same configs

00:54:07.820 --> 00:54:09.470 align:middle line:90%
on both the routers.

00:54:09.470 --> 00:54:13.160 align:middle line:84%
Now let's go into calls
for international.

00:54:13.160 --> 00:54:16.580 align:middle line:84%
Now for international,
what does it state?

00:54:16.580 --> 00:54:18.890 align:middle line:90%
Calls coming from HQ to SME--

00:54:18.890 --> 00:54:23.960 align:middle line:84%
E.164 as calling, E.164 as
called, SME to the CUBE,

00:54:23.960 --> 00:54:27.050 align:middle line:84%
E.164 as calling,
E.164 as called.

00:54:27.050 --> 00:54:32.120 align:middle line:84%
However, from the CUBE to
PSTN, calling should be E.164.

00:54:32.120 --> 00:54:38.810 align:middle line:84%
Called should be 011, and
then the country code and then

00:54:38.810 --> 00:54:41.880 align:middle line:84%
the area and the
subscriber number.

00:54:41.880 --> 00:54:43.980 align:middle line:84%
Let's go and
quickly verify that.

00:54:43.980 --> 00:54:49.160 align:middle line:84%
So for international,
for called,

00:54:49.160 --> 00:54:53.060 align:middle line:84%
send 011 followed by
any variable digits,

00:54:53.060 --> 00:54:57.440 align:middle line:84%
and for calling, plus followed
by country code followed by 10

00:54:57.440 --> 00:55:00.200 align:middle line:90%
digit number, which is E.164.

00:55:00.200 --> 00:55:01.500 align:middle line:90%
That's a requirement.

00:55:01.500 --> 00:55:03.170 align:middle line:84%
So the first thing
that I will do

00:55:03.170 --> 00:55:08.210 align:middle line:84%
is create an outbound
dial peer, which

00:55:08.210 --> 00:55:14.390 align:middle line:84%
is going to match based
on called numbers.

00:55:14.390 --> 00:55:17.930 align:middle line:84%
Now which outbound
international numbers do I have?

00:55:17.930 --> 00:55:21.080 align:middle line:84%
Now I could actually
add everything,

00:55:21.080 --> 00:55:22.880 align:middle line:84%
but again, in the
lab exam, I'm just

00:55:22.880 --> 00:55:25.520 align:middle line:84%
going to be specific
to what international

00:55:25.520 --> 00:55:26.690 align:middle line:90%
calls I have to make.

00:55:26.690 --> 00:55:30.240 align:middle line:84%
For example, if you look at
the PSTN, we have Hong Kong,

00:55:30.240 --> 00:55:34.940 align:middle line:84%
which is +852, and we
have UK, which is +44.

00:55:34.940 --> 00:55:36.770 align:middle line:90%
So I'll just make two.

00:55:36.770 --> 00:55:41.600 align:middle line:84%
What I'm going to do is create
a voice translation rule,

00:55:41.600 --> 00:55:47.230 align:middle line:84%
let's say 21, which
we'll say rule number 1.

00:55:47.230 --> 00:55:53.470 align:middle line:84%
If the call comes in
from backslash +852,

00:55:53.470 --> 00:55:55.650 align:middle line:90%
let's make a set--

00:55:55.650 --> 00:56:00.610 align:middle line:90%
852.

00:56:00.610 --> 00:56:06.640 align:middle line:90%
Replace it with 011 backslash 1.

00:56:06.640 --> 00:56:11.020 align:middle line:84%
And rule number two would
say, if the call comes

00:56:11.020 --> 00:56:22.240 align:middle line:84%
in for destine 4 plus 44, then
replace it with 011 set 1.

00:56:22.240 --> 00:56:23.950 align:middle line:90%
So what does this actually mean?

00:56:23.950 --> 00:56:25.510 align:middle line:90%
Let's do a test--

00:56:25.510 --> 00:56:31.060 align:middle line:84%
test voice translation-rule
21 if the called number is

00:56:31.060 --> 00:56:35.950 align:middle line:90%
+44208--

00:56:35.950 --> 00:56:37.840 align:middle line:84%
I don't know what
the PSTN number is.

00:56:37.840 --> 00:56:39.800 align:middle line:90%
Let's go and check.

00:56:39.800 --> 00:56:46.390 align:middle line:84%
So on the PSTN, let's look at
the PSTN number, +4420854544.

00:56:46.390 --> 00:56:53.490 align:middle line:90%
Let's go back to R1.

00:56:53.490 --> 00:56:56.490 align:middle line:90%
So 2085554444.

00:56:56.490 --> 00:57:01.380 align:middle line:84%
If this is the called number,
then replace it with 01144,

00:57:01.380 --> 00:57:04.450 align:middle line:84%
which is the country code,
and then the variable digits,

00:57:04.450 --> 00:57:06.810 align:middle line:90%
which is 2085554444.

00:57:06.810 --> 00:57:13.380 align:middle line:84%
If the call comes in from
+852, if the call destined,

00:57:13.380 --> 00:57:19.090 align:middle line:84%
the called number, is
+85225353333, which is, again,

00:57:19.090 --> 00:57:26.190 align:middle line:84%
the PSTN number, change
it to 01185225353333.

00:57:26.190 --> 00:57:30.700 align:middle line:84%
Let's now go and create a
voice translation profile.

00:57:30.700 --> 00:57:33.300 align:middle line:90%


00:57:33.300 --> 00:57:35.490 align:middle line:90%
So voice translation profile--

00:57:35.490 --> 00:57:38.100 align:middle line:90%
let's name this international.

00:57:38.100 --> 00:57:46.332 align:middle line:90%
And where should we apply this?

00:57:46.332 --> 00:57:55.340 align:middle line:84%
This should be applied
on the incoming--

00:57:55.340 --> 00:57:56.900 align:middle line:90%
on the inbound dial peer.

00:57:56.900 --> 00:58:00.230 align:middle line:84%
So what I'm going to do
actually is I will apply this

00:58:00.230 --> 00:58:03.360 align:middle line:84%
to the inbound dial peer
that we had done earlier,

00:58:03.360 --> 00:58:07.400 align:middle line:84%
which was dial peer 1000 so on
the incoming, when I get it,

00:58:07.400 --> 00:58:11.030 align:middle line:84%
I will change it to 011,
and on the outbound,

00:58:11.030 --> 00:58:12.680 align:middle line:90%
I will match it with 011.

00:58:12.680 --> 00:58:13.970 align:middle line:90%
Let's do that.

00:58:13.970 --> 00:58:18.770 align:middle line:84%
Let's do this as a
translation profile from SME,

00:58:18.770 --> 00:58:23.420 align:middle line:90%
and say translate call 21.

00:58:23.420 --> 00:58:26.030 align:middle line:84%
And then go back
to your dial peer

00:58:26.030 --> 00:58:31.310 align:middle line:84%
1000, which was your
incoming dial peer,

00:58:31.310 --> 00:58:41.370 align:middle line:84%
and say translation
profile incoming from SME.

00:58:41.370 --> 00:58:46.260 align:middle line:84%
So if you look at my show run
section voice translation-rule

00:58:46.260 --> 00:58:54.360 align:middle line:84%
21, what I'm saying is if
the called number is +852,

00:58:54.360 --> 00:58:57.360 align:middle line:84%
because E.164 is coming
in as a called number,

00:58:57.360 --> 00:59:02.130 align:middle line:84%
or if the colored number is
+44, then I have applied this

00:59:02.130 --> 00:59:05.670 align:middle line:84%
in the profile
called as from SME.

00:59:05.670 --> 00:59:12.060 align:middle line:84%
And then I went to my
dial peer 1000, which

00:59:12.060 --> 00:59:15.100 align:middle line:90%
was my incoming dial peer--

00:59:15.100 --> 00:59:16.560 align:middle line:90%
let's look at that--

00:59:16.560 --> 00:59:18.000 align:middle line:90%
which was my incoming dial peer.

00:59:18.000 --> 00:59:21.690 align:middle line:84%
I said the translation
profile, which

00:59:21.690 --> 00:59:23.860 align:middle line:84%
I believe I applied here--
translation profile.

00:59:23.860 --> 00:59:27.780 align:middle line:84%
So when the call comes in,
only if the call is destined

00:59:27.780 --> 00:59:30.297 align:middle line:84%
to international,
it will change it,

00:59:30.297 --> 00:59:32.130 align:middle line:84%
because I'm only matching
two rules in that.

00:59:32.130 --> 00:59:34.020 align:middle line:90%
Rule one is matching Hong Kong.

00:59:34.020 --> 00:59:36.930 align:middle line:90%
Rule two is matching UK.

00:59:36.930 --> 00:59:40.530 align:middle line:84%
If it is going to
local calls, it

00:59:40.530 --> 00:59:42.810 align:middle line:84%
will still match this
dial peer, but no changes

00:59:42.810 --> 00:59:46.140 align:middle line:84%
happens to the caller
ID number for local.

00:59:46.140 --> 00:59:48.900 align:middle line:84%
If it's going national, it will
still match this dial here,

00:59:48.900 --> 00:59:52.710 align:middle line:84%
but no changes happens to the
called number for national.

00:59:52.710 --> 00:59:58.410 align:middle line:84%
Only for international, which
is for Hong Kong and for UK,

00:59:58.410 --> 01:00:02.710 align:middle line:84%
it would match this and change
it to 011 and then the country

01:00:02.710 --> 01:00:03.210 align:middle line:90%
code.

01:00:03.210 --> 01:00:06.480 align:middle line:84%
Now for the outbound dial
peer, what I would do is create

01:00:06.480 --> 01:00:10.320 align:middle line:90%
an E.164--

01:00:10.320 --> 01:00:14.430 align:middle line:90%
voice-class e164-pattern-map.

01:00:14.430 --> 01:00:16.770 align:middle line:90%
Let's put this as 20.

01:00:16.770 --> 01:00:21.540 align:middle line:84%
And then I would match
E.164 match 011t--

01:00:21.540 --> 01:00:26.890 align:middle line:84%
so anything that
begins with 011.

01:00:26.890 --> 01:00:30.370 align:middle line:84%
And let's go and
then change it to--

01:00:30.370 --> 01:00:32.410 align:middle line:90%
let's go and create a dial peer.

01:00:32.410 --> 01:00:35.890 align:middle line:90%
So dial peer, voice--

01:00:35.890 --> 01:00:39.340 align:middle line:90%
let's put this as 20 voip.

01:00:39.340 --> 01:00:41.830 align:middle line:90%
Session protocol would be SIP.

01:00:41.830 --> 01:00:48.220 align:middle line:84%
Session target would
be IPv4:157.26.1.11.

01:00:48.220 --> 01:00:56.220 align:middle line:84%
My destination would
be e164-pattern-map 20.

01:00:56.220 --> 01:01:02.430 align:middle line:84%
And voice-class sip
pass-thru content sdp.

01:01:02.430 --> 01:01:05.880 align:middle line:84%
So call managers will
handle the SDP part.

01:01:05.880 --> 01:01:15.870 align:middle line:84%
And then voice-class sip bind
control source interface gig 2,

01:01:15.870 --> 01:01:17.430 align:middle line:90%
which is my WAN interface.

01:01:17.430 --> 01:01:18.645 align:middle line:90%
Same thing for media.

01:01:18.645 --> 01:01:22.540 align:middle line:90%


01:01:22.540 --> 01:01:23.740 align:middle line:90%
You can give the codec.

01:01:23.740 --> 01:01:26.230 align:middle line:84%
It doesn't really matter because
we're doing SDP pass-thru,

01:01:26.230 --> 01:01:29.155 align:middle line:84%
so it doesn't really matter
if I give this or not.

01:01:29.155 --> 01:01:32.210 align:middle line:90%


01:01:32.210 --> 01:01:40.690 align:middle line:84%
And DTMF would be
rtp-nte and sip kpml.

01:01:40.690 --> 01:01:43.330 align:middle line:90%
And VAD is bad.

01:01:43.330 --> 01:01:44.360 align:middle line:90%
That's it.

01:01:44.360 --> 01:01:47.600 align:middle line:84%
That's all it should work now
my outbound call should work.

01:01:47.600 --> 01:01:51.160 align:middle line:84%
So let's do a debug
ccsip messages

01:01:51.160 --> 01:01:56.170 align:middle line:84%
and go back to my
Tony Stark and let's

01:01:56.170 --> 01:02:09.480 align:middle line:84%
dial 901185225353333, which
is the PSTN Hong Kong number.

01:02:09.480 --> 01:02:15.870 align:middle line:84%
Let's dial this and
look back at the PSTN.

01:02:15.870 --> 01:02:17.400 align:middle line:90%
And I should receive a call.

01:02:17.400 --> 01:02:28.410 align:middle line:90%
Calling number should be E.164.

01:02:28.410 --> 01:02:33.720 align:middle line:84%
So here, I see that the
calling number is still

01:02:33.720 --> 01:02:37.260 align:middle line:90%
10 digits, which is wrong.

01:02:37.260 --> 01:02:39.960 align:middle line:90%
It should be E.164.

01:02:39.960 --> 01:02:44.670 align:middle line:84%
Let's, in fact, answer
this, then go back to R1,

01:02:44.670 --> 01:02:50.270 align:middle line:84%
and let me do un all
and disconnect the call.

01:02:50.270 --> 01:02:57.650 align:middle line:84%
Let me go back and disconnect
this call and look back at R1.

01:02:57.650 --> 01:03:00.590 align:middle line:90%
So if I look at R1 now--

01:03:00.590 --> 01:03:01.970 align:middle line:90%
and let's scroll back up.

01:03:01.970 --> 01:03:10.360 align:middle line:90%


01:03:10.360 --> 01:03:16.150 align:middle line:84%
All right, so I have
received invite from SME.

01:03:16.150 --> 01:03:19.180 align:middle line:90%
Called was E.164.

01:03:19.180 --> 01:03:21.040 align:middle line:90%
Calling was E.164.

01:03:21.040 --> 01:03:22.120 align:middle line:90%
So that's good.

01:03:22.120 --> 01:03:26.530 align:middle line:84%
When I sent to the PSTN,
called changed to 011,

01:03:26.530 --> 01:03:29.020 align:middle line:84%
which was as per the
request of the PSTN,

01:03:29.020 --> 01:03:31.840 align:middle line:90%
and calling was E.164.

01:03:31.840 --> 01:03:33.250 align:middle line:90%
So that's good.

01:03:33.250 --> 01:03:41.230 align:middle line:84%
When the PSTN sent back
200 OK, he sent SDP,

01:03:41.230 --> 01:03:43.240 align:middle line:84%
and because of SDP
pass-thru, I would

01:03:43.240 --> 01:03:46.600 align:middle line:84%
forward ahead the
information to SME,

01:03:46.600 --> 01:03:50.080 align:middle line:84%
and SME would forward
that to HQ cluster.

01:03:50.080 --> 01:03:51.670 align:middle line:84%
And the publisher
would send back

01:03:51.670 --> 01:03:56.200 align:middle line:84%
an acknowledgment of which
codec he is looking at.

01:03:56.200 --> 01:03:58.450 align:middle line:84%
But the point what
I'm trying to see here

01:03:58.450 --> 01:04:02.560 align:middle line:84%
is even though on the PSTN
side, in the display on Jabber,

01:04:02.560 --> 01:04:08.230 align:middle line:84%
I saw 10 digits, but that's
probably a bug with Jabber not

01:04:08.230 --> 01:04:11.470 align:middle line:90%
to do with the PSTN--

01:04:11.470 --> 01:04:17.290 align:middle line:84%
not to do with my configuration
because if I look at the debug

01:04:17.290 --> 01:04:20.290 align:middle line:90%
message, I am sending 011.

01:04:20.290 --> 01:04:22.150 align:middle line:84%
Let me, in fact, go
back to my Jabber

01:04:22.150 --> 01:04:27.400 align:middle line:84%
and let's change this to
852, and let's go and remake

01:04:27.400 --> 01:04:30.034 align:middle line:90%
that call--

01:04:30.034 --> 01:04:38.550 align:middle line:84%
to 9011852-- let's remake
that call and see here.

01:04:38.550 --> 01:04:39.300 align:middle line:90%
What do we see?

01:04:39.300 --> 01:04:53.360 align:middle line:84%
We should see,
actually, E.164 number.

01:04:53.360 --> 01:04:55.150 align:middle line:84%
So even though I'm
seeing a 10-digit here,

01:04:55.150 --> 01:04:56.860 align:middle line:84%
but that's not
really not the case

01:04:56.860 --> 01:04:59.320 align:middle line:84%
because look at your
debug ccsip messages.

01:04:59.320 --> 01:05:07.750 align:middle line:84%
In that, R1 is sending 011
in the called and plus E.164

01:05:07.750 --> 01:05:08.860 align:middle line:90%
as the calling.

01:05:08.860 --> 01:05:10.030 align:middle line:90%
So my job is done.

01:05:10.030 --> 01:05:14.200 align:middle line:84%
What PSTN does with his side,
whether he converts it back

01:05:14.200 --> 01:05:16.240 align:middle line:84%
to 10 digits, we
don't really care.

01:05:16.240 --> 01:05:19.090 align:middle line:84%
What the lab exam cares
about is what are you

01:05:19.090 --> 01:05:20.560 align:middle line:90%
sending to the PSTN.

01:05:20.560 --> 01:05:23.690 align:middle line:84%
With that, we've met all of the
requirements of the question.

01:05:23.690 --> 01:05:26.000 align:middle line:84%
There's one thing that
still needs to be done,

01:05:26.000 --> 01:05:29.380 align:middle line:84%
which is I need to copy-paste
the same configs on R2.

01:05:29.380 --> 01:05:32.030 align:middle line:84%
Be extremely careful--
do not forget that.

01:05:32.030 --> 01:05:38.660 align:middle line:84%
So let's go back and see show
run section voice translation.

01:05:38.660 --> 01:05:42.670 align:middle line:84%
So I have all of these
voice translation rules.

01:05:42.670 --> 01:05:54.410 align:middle line:84%
I'm just going to
repaste everything on R2,

01:05:54.410 --> 01:05:55.570 align:middle line:90%
and then go back to R1.

01:05:55.570 --> 01:06:00.390 align:middle line:90%


01:06:00.390 --> 01:06:02.565 align:middle line:90%
Show run section map--

01:06:02.565 --> 01:06:06.410 align:middle line:90%


01:06:06.410 --> 01:06:09.620 align:middle line:84%
which is I have
three E.164 maps.

01:06:09.620 --> 01:06:11.045 align:middle line:90%
Let's copy that as well.

01:06:11.045 --> 01:06:19.220 align:middle line:90%


01:06:19.220 --> 01:06:24.160 align:middle line:84%
And then let's go to
show run section voice

01:06:24.160 --> 01:06:26.680 align:middle line:90%
translation-profiles.

01:06:26.680 --> 01:06:28.810 align:middle line:84%
I believe we copied
the profiles.

01:06:28.810 --> 01:06:30.220 align:middle line:90%
Yes, we did.

01:06:30.220 --> 01:06:33.640 align:middle line:84%
Let's copy the dial peer--
show run section dial-peer.

01:06:33.640 --> 01:06:36.780 align:middle line:90%


01:06:36.780 --> 01:06:38.490 align:middle line:84%
Just make sure you
copy everything.

01:06:38.490 --> 01:06:45.610 align:middle line:90%


01:06:45.610 --> 01:06:47.130 align:middle line:90%
So we're done.

01:06:47.130 --> 01:06:50.700 align:middle line:84%
The same thing what you should
do is always shut down R1

01:06:50.700 --> 01:06:53.400 align:middle line:90%
and test it from R2 as well.

01:06:53.400 --> 01:06:57.000 align:middle line:84%
The calls should
work from R2 as well

01:06:57.000 --> 01:06:58.980 align:middle line:84%
because that's the
whole point of having

01:06:58.980 --> 01:07:02.550 align:middle line:84%
a V/Q redundancy,
application redundancy, which

01:07:02.550 --> 01:07:04.890 align:middle line:90%
was done in the earlier tasks.

01:07:04.890 --> 01:07:07.980 align:middle line:84%
With this, we've met all of
the requirements of this task.

01:07:07.980 --> 01:07:09.880 align:middle line:84%
I hope this video is
informative to you,

01:07:09.880 --> 01:07:12.410 align:middle line:90%
and thank you for watching.

01:07:12.410 --> 01:07:13.000 align:middle line:90%