WEBVTT 00:00:00.000 --> 00:00:03.444 align:middle line:90% 00:00:03.444 --> 00:00:06.888 align:middle line:90% [AUDIO LOGO] 00:00:06.888 --> 00:00:09.840 align:middle line:90% 00:00:09.840 --> 00:00:11.993 align:middle line:90% Hello, and welcome to INE. 00:00:11.993 --> 00:00:13.410 align:middle line:84% Today, in this video, we will look 00:00:13.410 --> 00:00:18.780 align:middle line:84% at section 2, dial plan part 3, basically task 2.6. 00:00:18.780 --> 00:00:22.300 align:middle line:84% Here, we would look at inbound calling from the PSTN. 00:00:22.300 --> 00:00:26.790 align:middle line:84% So PSTN is going to try making a call to HQ site and to site B. 00:00:26.790 --> 00:00:29.100 align:middle line:84% So in this task, it says, inbound calling 00:00:29.100 --> 00:00:30.480 align:middle line:90% needs to be provisioned. 00:00:30.480 --> 00:00:32.729 align:middle line:84% Ensure the following requirements are met. 00:00:32.729 --> 00:00:36.480 align:middle line:84% Configure CUBE at HQ to route inbound PSTN 00:00:36.480 --> 00:00:39.750 align:middle line:90% calls to HQ and site B UCM. 00:00:39.750 --> 00:00:44.020 align:middle line:84% The CUBE should send these calls to HQ-SME 00:00:44.020 --> 00:00:46.060 align:middle line:90% for further processing. 00:00:46.060 --> 00:00:51.600 align:middle line:84% The PSTN sends 10 digit as the called number on inbound calls. 00:00:51.600 --> 00:00:55.170 align:middle line:84% The PSTN sends 10 digit as the calling number 00:00:55.170 --> 00:00:57.450 align:middle line:84% if it is calling from the US lines, which 00:00:57.450 --> 00:00:58.500 align:middle line:90% is line 1 and line 2. 00:00:58.500 --> 00:01:02.100 align:middle line:84% So if the PSTN is calling from line 1, which is HQ site, 00:01:02.100 --> 00:01:04.200 align:middle line:84% then the calling number would be 10 digits. 00:01:04.200 --> 00:01:08.310 align:middle line:84% If the PSTN is calling from line 2, which is site B line, 00:01:08.310 --> 00:01:10.710 align:middle line:84% again, the calling number would be 10 digits. 00:01:10.710 --> 00:01:14.730 align:middle line:84% However, if the PSTN is calling from line 3 or line 4, 00:01:14.730 --> 00:01:17.290 align:middle line:84% which is the Hong Kong and the UK site, 00:01:17.290 --> 00:01:18.780 align:middle line:84% it would be an international call. 00:01:18.780 --> 00:01:21.780 align:middle line:84% The calling number would be e.164. 00:01:21.780 --> 00:01:25.170 align:middle line:84% Called numbers for all calls, whether it's local, national, 00:01:25.170 --> 00:01:29.070 align:middle line:84% or international, called number is always 10 digits. 00:01:29.070 --> 00:01:32.130 align:middle line:84% And this is what the PSTN is sending. 00:01:32.130 --> 00:01:35.190 align:middle line:84% The CUBE must translate both calling 00:01:35.190 --> 00:01:40.830 align:middle line:84% and called to e.164 format before passing them on to SME. 00:01:40.830 --> 00:01:42.990 align:middle line:84% The SME should then forward these calls 00:01:42.990 --> 00:01:45.870 align:middle line:84% to the appropriate destinations in HQ 00:01:45.870 --> 00:01:50.310 align:middle line:84% and site B. Dialing instructions to call from HQ site-- 00:01:50.310 --> 00:01:55.710 align:middle line:84% to call HQ site from PSTN, dial 14082022XXX. 00:01:55.710 --> 00:02:02.310 align:middle line:84% And to call site B from PSTN, dial 19723033XXX. 00:02:02.310 --> 00:02:05.130 align:middle line:90% So this is our requirement. 00:02:05.130 --> 00:02:07.410 align:middle line:84% Now, if you remember, in the earlier task-- 00:02:07.410 --> 00:02:10.800 align:middle line:84% in all the earlier tasks, we had configured outbound dialing 00:02:10.800 --> 00:02:14.440 align:middle line:84% to PSTN, but we had never configured any inbound dialing. 00:02:14.440 --> 00:02:16.350 align:middle line:84% So at this point of time, PSTN would not 00:02:16.350 --> 00:02:20.670 align:middle line:84% be able to call HQ or site B. So let's quickly go and do 00:02:20.670 --> 00:02:21.187 align:middle line:90% this task. 00:02:21.187 --> 00:02:22.770 align:middle line:84% The first thing, what I'm going to do, 00:02:22.770 --> 00:02:28.170 align:middle line:84% is just quickly show you that we cannot make the inbound calls 00:02:28.170 --> 00:02:30.190 align:middle line:90% at this point of time. 00:02:30.190 --> 00:02:33.360 align:middle line:90% So here is where I have my PSTN. 00:02:33.360 --> 00:02:38.890 align:middle line:84% I have my site B. And I have my HQ site. 00:02:38.890 --> 00:02:44.640 align:middle line:84% So from the PSTN, if I dial, let's say, from line 1, 00:02:44.640 --> 00:02:53.910 align:middle line:84% if I dial 14082022003, which is Tony Stark, 00:02:53.910 --> 00:02:55.890 align:middle line:90% the call is going to fail. 00:02:55.890 --> 00:03:00.540 align:middle line:84% Now, obviously, let me go back to R1 because the PSTN is-- 00:03:00.540 --> 00:03:03.690 align:middle line:84% it has a SIP trunk to the CUBE, the call 00:03:03.690 --> 00:03:05.370 align:middle line:90% is going to go to the CUBE. 00:03:05.370 --> 00:03:07.025 align:middle line:84% The CUBE should receive that SIP call. 00:03:07.025 --> 00:03:08.400 align:middle line:84% But, obviously, the CUBE is going 00:03:08.400 --> 00:03:10.800 align:middle line:84% to drop it because there's no dial peers configured 00:03:10.800 --> 00:03:13.410 align:middle line:90% for inbound on the CUBE. 00:03:13.410 --> 00:03:15.390 align:middle line:84% So if I look back at-- let's say, at R1-- 00:03:15.390 --> 00:03:18.160 align:middle line:90% let me open up R1 and R2. 00:03:18.160 --> 00:03:20.930 align:middle line:90% 00:03:20.930 --> 00:03:28.280 align:middle line:90% And if I go back to R1 and do-- 00:03:28.280 --> 00:03:37.250 align:middle line:84% let's do a debug ccsip messages and make the call again 00:03:37.250 --> 00:03:38.360 align:middle line:90% form PSTN. 00:03:38.360 --> 00:03:41.770 align:middle line:90% 00:03:41.770 --> 00:03:45.418 align:middle line:84% You see that there is a-- the call is coming to the CUBE. 00:03:45.418 --> 00:03:46.960 align:middle line:84% But what is happening with that call? 00:03:46.960 --> 00:03:48.490 align:middle line:90% Let's go and check that. 00:03:48.490 --> 00:03:50.260 align:middle line:90% Let me go back and do-- 00:03:50.260 --> 00:03:51.160 align:middle line:90% end this call. 00:03:51.160 --> 00:03:56.110 align:middle line:84% And if I look back at the logs, I 00:03:56.110 --> 00:03:59.850 align:middle line:84% see an invite coming from the PSTN. 00:03:59.850 --> 00:04:02.290 align:middle line:90% Look at the called number. 00:04:02.290 --> 00:04:07.030 align:middle line:84% The called number is 10 digits as per the question. 00:04:07.030 --> 00:04:10.810 align:middle line:84% The PSTN always sends 10 digit as the called ID number. 00:04:10.810 --> 00:04:16.010 align:middle line:84% The calling number is also 10 digits, which you can see here. 00:04:16.010 --> 00:04:17.260 align:middle line:90% This is the called. 00:04:17.260 --> 00:04:18.880 align:middle line:90% And this is the calling. 00:04:18.880 --> 00:04:20.320 align:middle line:90% Even that is 10 digits. 00:04:20.320 --> 00:04:21.220 align:middle line:90% Why is it 10 digits? 00:04:21.220 --> 00:04:24.730 align:middle line:84% Because the PSTN is calling from line 1. 00:04:24.730 --> 00:04:28.510 align:middle line:84% Since the PSTN is calling from line 1, it's a local call. 00:04:28.510 --> 00:04:31.180 align:middle line:84% The calling number would be 10 digits. 00:04:31.180 --> 00:04:33.080 align:middle line:84% Again, this is ask per the question. 00:04:33.080 --> 00:04:35.710 align:middle line:84% What really happened with the call? 00:04:35.710 --> 00:04:38.860 align:middle line:84% If I look at-- if I go down, it says, trying. 00:04:38.860 --> 00:04:41.650 align:middle line:90% And then I see 404 not found. 00:04:41.650 --> 00:04:44.380 align:middle line:90% No matching outbound dial peer. 00:04:44.380 --> 00:04:46.840 align:middle line:84% Did we have a matching inbound dial peer? 00:04:46.840 --> 00:04:50.200 align:middle line:84% Yes, there's a built-in default dial peer 0. 00:04:50.200 --> 00:04:52.180 align:middle line:90% So it matches dial peer 0. 00:04:52.180 --> 00:04:55.040 align:middle line:84% And for outbound, there is no outbound dial peer. 00:04:55.040 --> 00:04:57.830 align:middle line:84% That's why we get this 404 not found. 00:04:57.830 --> 00:04:59.320 align:middle line:90% So two things we'll have to do. 00:04:59.320 --> 00:05:01.690 align:middle line:84% First, we don't want to match the dial peer 0. 00:05:01.690 --> 00:05:05.240 align:middle line:84% So we will create an inbound dial peer first. 00:05:05.240 --> 00:05:07.730 align:middle line:90% So let's go and do that. 00:05:07.730 --> 00:05:12.070 align:middle line:84% So I'm going to go to R1 and create 00:05:12.070 --> 00:05:17.360 align:middle line:84% a dial peer that matches based on the PSTN's calling number. 00:05:17.360 --> 00:05:20.380 align:middle line:84% So depending on what calls he's calling from, 00:05:20.380 --> 00:05:24.760 align:middle line:84% if he's calling from line 1 or line 2 or line 3 or line 4. 00:05:24.760 --> 00:05:28.330 align:middle line:84% So first, I will create a voice class. 00:05:28.330 --> 00:05:31.120 align:middle line:84% In the voice class, I would go and say, 00:05:31.120 --> 00:05:33.160 align:middle line:90% let's do an e.164 pattern map. 00:05:33.160 --> 00:05:36.100 align:middle line:84% And let's put this number as 2000. 00:05:36.100 --> 00:05:45.070 align:middle line:84% And here, I will say e.164 match the PSTN number +85225353333, 00:05:45.070 --> 00:05:49.130 align:middle line:84% which is PSTN's line 3, the Hong Kong number. 00:05:49.130 --> 00:05:52.100 align:middle line:84% Then I will match PSTN's international number, 00:05:52.100 --> 00:06:00.540 align:middle line:90% which is e.164 +442085554444. 00:06:00.540 --> 00:06:02.610 align:middle line:90% That's the PSTN's line 4. 00:06:02.610 --> 00:06:04.260 align:middle line:90% Why am I matching the e.164? 00:06:04.260 --> 00:06:05.770 align:middle line:84% Because if you look at the question, 00:06:05.770 --> 00:06:09.060 align:middle line:84% the question says that the PSTN for calling number, 00:06:09.060 --> 00:06:14.040 align:middle line:84% it is always sending e.164 if it is coming from Hong Kong 00:06:14.040 --> 00:06:18.540 align:middle line:84% line, which is line 3, or if it's coming from line 4, which 00:06:18.540 --> 00:06:20.140 align:middle line:90% is your UK line. 00:06:20.140 --> 00:06:22.350 align:middle line:84% But if it's coming from line 1 or line 2, 00:06:22.350 --> 00:06:23.850 align:middle line:90% it's a local or national call. 00:06:23.850 --> 00:06:27.030 align:middle line:90% It is always sending 10 digits. 00:06:27.030 --> 00:06:31.540 align:middle line:84% So I'm matching the calling number of the PSTN. 00:06:31.540 --> 00:06:34.420 align:middle line:84% So PSTN is calling from four lines. 00:06:34.420 --> 00:06:35.490 align:middle line:90% One is the Hong Kong. 00:06:35.490 --> 00:06:36.630 align:middle line:90% One is the UK. 00:06:36.630 --> 00:06:38.730 align:middle line:90% And then one is the HQ site. 00:06:38.730 --> 00:06:42.000 align:middle line:84% And because for HQ calling number he's sending 10 digits, 00:06:42.000 --> 00:06:46.290 align:middle line:84% I would match 10 digits, 4085151111, 00:06:46.290 --> 00:06:48.840 align:middle line:90% which is the line 1 of PSTN. 00:06:48.840 --> 00:06:55.440 align:middle line:84% And then I would match e.164 9725252222, 00:06:55.440 --> 00:06:58.360 align:middle line:90% which is line 2 of the PSTN. 00:06:58.360 --> 00:07:03.210 align:middle line:84% So I made an e.164 pattern map, which you can see here, 00:07:03.210 --> 00:07:06.690 align:middle line:90% show run section map 2000. 00:07:06.690 --> 00:07:09.240 align:middle line:84% I made an e.164 pattern map that matches 00:07:09.240 --> 00:07:12.150 align:middle line:90% the calling number of the PSTN. 00:07:12.150 --> 00:07:17.400 align:middle line:84% Now, once I have this done, let's copy this on R2. 00:07:17.400 --> 00:07:20.100 align:middle line:84% We should do this simultaneously on both the routers 00:07:20.100 --> 00:07:23.850 align:middle line:84% because the configuration is not really replicated. 00:07:23.850 --> 00:07:29.490 align:middle line:84% So I'm going to go to R2 and do exactly the same thing, where 00:07:29.490 --> 00:07:33.690 align:middle line:84% I would paste the e.164 pattern map. 00:07:33.690 --> 00:07:37.890 align:middle line:84% Next thing, what I'm going to do is create an inbound dial peer 00:07:37.890 --> 00:07:40.170 align:middle line:84% because we don't want to match dial peer 0. 00:07:40.170 --> 00:07:43.060 align:middle line:84% So I am going to create an inbound dial peer. 00:07:43.060 --> 00:07:43.930 align:middle line:90% Let's do that. 00:07:43.930 --> 00:07:46.980 align:middle line:84% So for the inbound dial peer, I would say, 00:07:46.980 --> 00:07:57.660 align:middle line:84% dial peer voice 2000 VoIP, where session protocol would be SIP. 00:07:57.660 --> 00:08:02.310 align:middle line:84% And incoming calling number would 00:08:02.310 --> 00:08:05.790 align:middle line:84% be matched based on the e.164 pattern map 2000. 00:08:05.790 --> 00:08:08.460 align:middle line:84% So this dial peer is going to match if the call is 00:08:08.460 --> 00:08:09.540 align:middle line:90% coming from PSTN. 00:08:09.540 --> 00:08:13.120 align:middle line:84% So now dial peer 0 is not going to match. 00:08:13.120 --> 00:08:19.570 align:middle line:84% The next thing that I would do is define voice-class SIP 00:08:19.570 --> 00:08:23.170 align:middle line:84% pass-thru content SDP so that my CUBE does not 00:08:23.170 --> 00:08:27.310 align:middle line:84% participate in the codec selection or SDP, 00:08:27.310 --> 00:08:29.420 align:middle line:90% just does a pass-thru. 00:08:29.420 --> 00:08:31.930 align:middle line:84% And then bind my control and media, 00:08:31.930 --> 00:08:35.919 align:middle line:84% so voice-class SIP bind control source-interface gig 2, 00:08:35.919 --> 00:08:40.360 align:middle line:84% which is the one site interface towards PSTN. 00:08:40.360 --> 00:08:48.250 align:middle line:84% And also for the media, you can define your DTMF 00:08:48.250 --> 00:08:49.450 align:middle line:90% if you want to. 00:08:49.450 --> 00:08:52.713 align:middle line:90% DTMF-relay RTP-NTE SIP-KPML. 00:08:52.713 --> 00:08:54.880 align:middle line:84% Again, we don't really need to do that because we've 00:08:54.880 --> 00:08:57.040 align:middle line:90% done content pass-thru SDP. 00:08:57.040 --> 00:08:59.620 align:middle line:90% And let's also disable VAD. 00:08:59.620 --> 00:09:02.110 align:middle line:90% VAD is bad. 00:09:02.110 --> 00:09:05.320 align:middle line:84% So now this dial peer is going to match on the inbound. 00:09:05.320 --> 00:09:08.650 align:middle line:84% Dial peer 0 is not going to match. 00:09:08.650 --> 00:09:11.060 align:middle line:84% Now we need to create-- is my call going to work still? 00:09:11.060 --> 00:09:11.560 align:middle line:90% No. 00:09:11.560 --> 00:09:14.650 align:middle line:84% Because when the call comes in, instead of dial peer 0, 00:09:14.650 --> 00:09:17.500 align:middle line:84% it's going to match dial peer 2000 now. 00:09:17.500 --> 00:09:21.800 align:middle line:84% However, the outbound dial peer, we have not created, 00:09:21.800 --> 00:09:27.840 align:middle line:84% which basically means that the call is going to fail. 00:09:27.840 --> 00:09:30.160 align:middle line:84% We would get a 404 not found because there's 00:09:30.160 --> 00:09:31.630 align:middle line:90% no outbound dial peer. 00:09:31.630 --> 00:09:34.840 align:middle line:84% So what I'm going to do is I'll create an outbound dial peer. 00:09:34.840 --> 00:09:37.000 align:middle line:84% But before that, if you read the question, 00:09:37.000 --> 00:09:39.070 align:middle line:84% the question states that the CUBE 00:09:39.070 --> 00:09:41.860 align:middle line:84% must translate the calling and the called 00:09:41.860 --> 00:09:45.050 align:middle line:90% and send e.164 to SME. 00:09:45.050 --> 00:09:49.670 align:middle line:84% So what I'm going to do is on the inbound dial peer itself, 00:09:49.670 --> 00:09:58.910 align:middle line:84% I will transform the calling and the called to e.164. 00:09:58.910 --> 00:10:02.960 align:middle line:90% So let's go and do that. 00:10:02.960 --> 00:10:06.490 align:middle line:84% First of all, let me copy this dial peer to R2. 00:10:06.490 --> 00:10:11.470 align:middle line:90% Show run section 2000 VoIP. 00:10:11.470 --> 00:10:14.140 align:middle line:84% So copy-paste at the same time so that you don't really 00:10:14.140 --> 00:10:16.490 align:middle line:90% forget anything. 00:10:16.490 --> 00:10:17.720 align:middle line:90% Go back to R2. 00:10:17.720 --> 00:10:21.180 align:middle line:90% And let's paste that. 00:10:21.180 --> 00:10:24.090 align:middle line:84% Next, we will go back and create a voice translation 00:10:24.090 --> 00:10:26.320 align:middle line:90% rule that matches the called. 00:10:26.320 --> 00:10:29.430 align:middle line:84% So what I'm going to do is I will transform 00:10:29.430 --> 00:10:33.070 align:middle line:90% all the called to e.164 first. 00:10:33.070 --> 00:10:35.190 align:middle line:90% So let's do that. 00:10:35.190 --> 00:10:41.430 align:middle line:84% Voice translation rule, let's put this as 2000, 00:10:41.430 --> 00:10:46.560 align:middle line:84% where rule number 1 is going to be-- 00:10:46.560 --> 00:10:48.900 align:middle line:84% what is the PSTN sending for all called, 00:10:48.900 --> 00:10:52.050 align:middle line:84% whether it's coming from local, national, or international? 00:10:52.050 --> 00:10:56.010 align:middle line:84% As per the question, all called numbers coming from PSTN 00:10:56.010 --> 00:10:57.100 align:middle line:90% is 10 digits. 00:10:57.100 --> 00:10:59.820 align:middle line:84% So we need to change that to e.164. 00:10:59.820 --> 00:11:05.380 align:middle line:84% So all I'm going to do is say, backslash plus, 00:11:05.380 --> 00:11:07.150 align:middle line:90% where I would say-- 00:11:07.150 --> 00:11:08.590 align:middle line:90% no, in fact, not backslash plus. 00:11:08.590 --> 00:11:18.810 align:middle line:84% I would say anything that begins with 2-9, 00:11:18.810 --> 00:11:25.810 align:middle line:84% replace that or add plus 1 and & sign. 00:11:25.810 --> 00:11:27.390 align:middle line:90% So what am I doing here? 00:11:27.390 --> 00:11:34.040 align:middle line:84% I am saying that anything that begins with 2-9, 00:11:34.040 --> 00:11:37.640 align:middle line:84% change or prefix plus 1 to it, and then-- 00:11:37.640 --> 00:11:39.570 align:middle line:90% and add the remaining numbers. 00:11:39.570 --> 00:11:43.855 align:middle line:84% So let's say if the called number was coming from PSTN 00:11:43.855 --> 00:11:54.570 align:middle line:84% as 4082032003, that would change to +14082022003. 00:11:54.570 --> 00:11:55.820 align:middle line:90% Let's, in fact, test this out. 00:11:55.820 --> 00:11:58.910 align:middle line:90% 00:11:58.910 --> 00:12:04.180 align:middle line:84% So I would say, test voice translation rule, 00:12:04.180 --> 00:12:05.920 align:middle line:90% rule number 2000. 00:12:05.920 --> 00:12:10.570 align:middle line:84% If the called number is 4082022003, 00:12:10.570 --> 00:12:12.910 align:middle line:90% it changes that to e.164. 00:12:12.910 --> 00:12:14.710 align:middle line:90% What about the calling? 00:12:14.710 --> 00:12:18.940 align:middle line:84% For the calling, anyway for international, 00:12:18.940 --> 00:12:20.823 align:middle line:90% PSTN was sending e.164. 00:12:20.823 --> 00:12:22.490 align:middle line:84% So I don't have to do anything for that. 00:12:22.490 --> 00:12:26.380 align:middle line:84% But for the local and HQ site, for HQ and site B site, 00:12:26.380 --> 00:12:29.180 align:middle line:84% the calling number being sent was 10 digits. 00:12:29.180 --> 00:12:31.490 align:middle line:90% Look at the question again. 00:12:31.490 --> 00:12:33.040 align:middle line:84% If you read the question, it says 00:12:33.040 --> 00:12:38.770 align:middle line:84% that the PSTN sends 10 digit as the calling number for calls 00:12:38.770 --> 00:12:42.310 align:middle line:84% originated from US PSTN line, which is line 1 and line 2. 00:12:42.310 --> 00:12:45.940 align:middle line:84% So I need to change the calling number for HQ site 00:12:45.940 --> 00:12:48.700 align:middle line:84% for line 1 and line 2, not for international. 00:12:48.700 --> 00:12:50.350 align:middle line:84% For international, for calling, I 00:12:50.350 --> 00:12:52.960 align:middle line:84% don't have to do anything because anyway, the PSTN is 00:12:52.960 --> 00:12:54.580 align:middle line:90% sending e.164. 00:12:54.580 --> 00:12:59.110 align:middle line:84% But for calling for US PSTN lines, which 00:12:59.110 --> 00:13:01.270 align:middle line:84% is line 1 and line 2 for HQ and site B, 00:13:01.270 --> 00:13:02.870 align:middle line:90% PSTN was sending 10 digits. 00:13:02.870 --> 00:13:05.200 align:middle line:90% So I need to change that. 00:13:05.200 --> 00:13:07.100 align:middle line:84% Now, the best part is if you use-- 00:13:07.100 --> 00:13:10.930 align:middle line:84% if you see this, the way I have defined my translation rule, 00:13:10.930 --> 00:13:12.980 align:middle line:90% it matches the calling also. 00:13:12.980 --> 00:13:19.090 align:middle line:84% So all I do is go to voice translation profile. 00:13:19.090 --> 00:13:23.110 align:middle line:84% And let's say I name this as PSTN, 00:13:23.110 --> 00:13:27.670 align:middle line:90% say, translate called to 2000. 00:13:27.670 --> 00:13:30.430 align:middle line:84% So all my called, because the PSTN 00:13:30.430 --> 00:13:34.390 align:middle line:84% is sending 10 digits for called, everything changes to e.164. 00:13:34.390 --> 00:13:37.570 align:middle line:84% For calling, we had to change it for HQ and site 00:13:37.570 --> 00:13:41.170 align:middle line:84% B, line 1 and line 2, because he was sending 10 digits. 00:13:41.170 --> 00:13:45.100 align:middle line:84% For line 3 and 4, which was Hong Kong and UK, 00:13:45.100 --> 00:13:47.710 align:middle line:90% PSTN was anyway sending e.164. 00:13:47.710 --> 00:13:52.270 align:middle line:84% So I just do translate calling 2000. 00:13:52.270 --> 00:13:54.350 align:middle line:90% So I use the same rule. 00:13:54.350 --> 00:13:57.951 align:middle line:90% So what's going to happen if I-- 00:13:57.951 --> 00:14:01.920 align:middle line:84% if-- for example, let's say, if I do a test, voice 00:14:01.920 --> 00:14:10.230 align:middle line:84% translation rule 2000, if the called number is 4082022003, 00:14:10.230 --> 00:14:12.030 align:middle line:90% it changes to e.164. 00:14:12.030 --> 00:14:18.120 align:middle line:84% If the called number is 9723033003, 00:14:18.120 --> 00:14:22.710 align:middle line:84% which is site B, Steve Rogers, it changes to e.164. 00:14:22.710 --> 00:14:24.780 align:middle line:90% So for called, it's changing. 00:14:24.780 --> 00:14:26.400 align:middle line:90% Let's test calling. 00:14:26.400 --> 00:14:33.210 align:middle line:84% If the call comes from PSTN coming from 4085151111, 00:14:33.210 --> 00:14:37.050 align:middle line:84% which is PSTN's line 1, it changes the calling also 00:14:37.050 --> 00:14:38.610 align:middle line:90% to e.164. 00:14:38.610 --> 00:14:45.120 align:middle line:84% If the call comes from 9725252222, 00:14:45.120 --> 00:14:49.320 align:middle line:84% which is PSTN's line 2, it changes the calling to e.164. 00:14:49.320 --> 00:14:57.930 align:middle line:84% But if the call comes from Hong Kong, which is +85225353333, 00:14:57.930 --> 00:15:01.710 align:middle line:84% it does not match that rule because it doesn't need 00:15:01.710 --> 00:15:04.410 align:middle line:84% to match because this starts with the plus sign. 00:15:04.410 --> 00:15:07.440 align:middle line:84% It doesn't match anything beginning with 2-9. 00:15:07.440 --> 00:15:09.450 align:middle line:90% It actually begins with plus. 00:15:09.450 --> 00:15:11.410 align:middle line:84% But we don't really need to change anything. 00:15:11.410 --> 00:15:13.743 align:middle line:84% We don't need to match that because anyway, the PSTN was 00:15:13.743 --> 00:15:17.960 align:middle line:84% sending e.164 for the calling for international. 00:15:17.960 --> 00:15:19.410 align:middle line:84% So if I was dialing from Hong Kong 00:15:19.410 --> 00:15:21.960 align:middle line:84% from PSTN line, which is line 3, he 00:15:21.960 --> 00:15:24.600 align:middle line:84% was anyway sending e.164 as the calling. 00:15:24.600 --> 00:15:28.440 align:middle line:84% Only called was being sent as 10 digits for all calls. 00:15:28.440 --> 00:15:33.900 align:middle line:84% But calling for Hong Kong and site B, or Hong Kong and UK, 00:15:33.900 --> 00:15:35.245 align:middle line:90% he was sending e.164. 00:15:35.245 --> 00:15:37.710 align:middle line:84% For HQ and site B, he was sending 10 digits. 00:15:37.710 --> 00:15:42.240 align:middle line:84% We translated HQ and site B calling numbers to e.164. 00:15:42.240 --> 00:15:46.830 align:middle line:84% Now, all I do is go to my dial peer-- 00:15:46.830 --> 00:15:52.200 align:middle line:84% inbound dial peer 2000 and say translation-profile incoming 00:15:52.200 --> 00:15:53.790 align:middle line:90% PSTN. 00:15:53.790 --> 00:15:54.880 align:middle line:90% That's it. 00:15:54.880 --> 00:15:57.810 align:middle line:84% So now my incoming should change. 00:15:57.810 --> 00:16:01.050 align:middle line:84% Both calling and called should change to e.164. 00:16:01.050 --> 00:16:04.500 align:middle line:90% Let's copy this on R2. 00:16:04.500 --> 00:16:08.800 align:middle line:84% Let's do a show run section rule 2000 first. 00:16:08.800 --> 00:16:12.685 align:middle line:90% Let's copy this on R2. 00:16:12.685 --> 00:16:17.620 align:middle line:90% 00:16:17.620 --> 00:16:22.420 align:middle line:84% Then let's copy the translation profile to show run section 00:16:22.420 --> 00:16:24.040 align:middle line:90% profile PSTN. 00:16:24.040 --> 00:16:26.620 align:middle line:90% 00:16:26.620 --> 00:16:27.915 align:middle line:90% So let's copy this. 00:16:27.915 --> 00:16:33.280 align:middle line:90% 00:16:33.280 --> 00:16:38.500 align:middle line:84% Then let's go to dial peer voice 2000 00:16:38.500 --> 00:16:44.450 align:middle line:84% and say translation profile incoming PSTN. 00:16:44.450 --> 00:16:46.210 align:middle line:90% So inbound dial peer is done. 00:16:46.210 --> 00:16:48.280 align:middle line:84% The inbound dial peer matches based 00:16:48.280 --> 00:16:51.010 align:middle line:90% on the calling number of-- 00:16:51.010 --> 00:16:54.070 align:middle line:84% based on the e.164 pattern map 2000 that we created. 00:16:54.070 --> 00:16:57.700 align:middle line:84% And so dial peer 2000 matches based on that. 00:16:57.700 --> 00:17:00.590 align:middle line:84% Once it matches based on the translation profile, 00:17:00.590 --> 00:17:03.670 align:middle line:84% the calling and the called numbers change to e.164. 00:17:03.670 --> 00:17:06.859 align:middle line:84% Now I need to create the outbound dial peer. 00:17:06.859 --> 00:17:12.190 align:middle line:84% So for the outbound dial peer, all I would do is create-- 00:17:12.190 --> 00:17:13.900 align:middle line:90% let's go back to R1-- 00:17:13.900 --> 00:17:19.720 align:middle line:84% create an e.164 pattern map, so voice plus e.164 pattern map. 00:17:19.720 --> 00:17:21.130 align:middle line:90% Let's say 30. 00:17:21.130 --> 00:17:25.400 align:middle line:84% And here, I would match HQ site and site B site's extensions. 00:17:25.400 --> 00:17:34.840 align:middle line:84% So that's going to be e.164 +14082022... 00:17:34.840 --> 00:17:41.560 align:middle line:90% And +19723033.... 00:17:41.560 --> 00:17:44.890 align:middle line:90% So I'm matching HQ and site B. 00:17:44.890 --> 00:17:47.680 align:middle line:84% Next, I'll create a dial peer, dial 00:17:47.680 --> 00:17:54.700 align:middle line:84% peer voice 30 VoIP, where session protocol would be SIP. 00:17:54.700 --> 00:18:01.725 align:middle line:84% Session target would be my SME, which is 11.100.64.14. 00:18:01.725 --> 00:18:03.100 align:middle line:84% If you don't know the IP address, 00:18:03.100 --> 00:18:06.130 align:middle line:84% you can always go back to your Active Directory DNS machine 00:18:06.130 --> 00:18:08.120 align:middle line:90% and check the FQDN. 00:18:08.120 --> 00:18:10.420 align:middle line:84% If your router 1 is able to reach the DNS server, 00:18:10.420 --> 00:18:12.490 align:middle line:84% you can put the FQDN here, or you 00:18:12.490 --> 00:18:14.980 align:middle line:84% can go and check the IP address of your SME 00:18:14.980 --> 00:18:19.020 align:middle line:90% and put that IP address here. 00:18:19.020 --> 00:18:22.120 align:middle line:84% This dial peer will match based on the destination, 00:18:22.120 --> 00:18:25.950 align:middle line:84% not destination pattern but destination e.164 pattern 00:18:25.950 --> 00:18:27.090 align:middle line:90% map 30. 00:18:27.090 --> 00:18:34.170 align:middle line:84% So if the destination pattern is HQ site, which is +14082022xxx, 00:18:34.170 --> 00:18:39.960 align:middle line:84% or site B site, +19723033xxx or 3..., 00:18:39.960 --> 00:18:42.660 align:middle line:84% then it matches this outbound dial peer. 00:18:42.660 --> 00:18:52.800 align:middle line:84% Let's do a voice class SIP pass-thru content SDP. 00:18:52.800 --> 00:18:58.500 align:middle line:84% Let's also do a voice class SIP bind control. 00:18:58.500 --> 00:19:00.240 align:middle line:84% Source interface would be the LAN inside 00:19:00.240 --> 00:19:02.070 align:middle line:90% interface towards me. 00:19:02.070 --> 00:19:04.230 align:middle line:90% And media would also be that. 00:19:04.230 --> 00:19:07.300 align:middle line:90% 00:19:07.300 --> 00:19:10.150 align:middle line:90% And let's disable the VAD. 00:19:10.150 --> 00:19:12.970 align:middle line:84% You can define DTMF again if you want to, 00:19:12.970 --> 00:19:16.840 align:middle line:90% DTMF-relay RTP-NTE SIP-KPML. 00:19:16.840 --> 00:19:18.440 align:middle line:90% That's it. 00:19:18.440 --> 00:19:19.700 align:middle line:90% R1 is ready. 00:19:19.700 --> 00:19:21.920 align:middle line:90% Let's copy this on R2 as well. 00:19:21.920 --> 00:19:26.290 align:middle line:84% Let's do a show run section map 30. 00:19:26.290 --> 00:19:27.800 align:middle line:90% Let's copy this. 00:19:27.800 --> 00:19:34.470 align:middle line:90% 00:19:34.470 --> 00:19:36.990 align:middle line:84% And then let's copy the dial peer 30. 00:19:36.990 --> 00:19:43.290 align:middle line:90% Show run section 30 VoIP. 00:19:43.290 --> 00:19:44.835 align:middle line:90% And let's copy this. 00:19:44.835 --> 00:19:49.300 align:middle line:90% 00:19:49.300 --> 00:19:50.910 align:middle line:90% All right, so our CUBEs-- 00:19:50.910 --> 00:19:53.140 align:middle line:90% both the CUBEs are configured. 00:19:53.140 --> 00:19:56.730 align:middle line:84% Now let's try making the call from PSTN again. 00:19:56.730 --> 00:19:58.800 align:middle line:84% Again, the call is going to fail. 00:19:58.800 --> 00:20:02.490 align:middle line:84% Earlier, R1 and R2, they were sending the 404 back 00:20:02.490 --> 00:20:05.460 align:middle line:84% to PSTN because they don't have an outbound dial peer. 00:20:05.460 --> 00:20:08.903 align:middle line:84% This time, R1 and R2, they have an outbound dial peer. 00:20:08.903 --> 00:20:10.320 align:middle line:84% So they would send the call-- they 00:20:10.320 --> 00:20:11.820 align:middle line:90% would route the call to SME. 00:20:11.820 --> 00:20:16.590 align:middle line:84% It's the SME who's going to send back 404 not found because SME 00:20:16.590 --> 00:20:18.220 align:middle line:90% has not been configured yet. 00:20:18.220 --> 00:20:25.860 align:middle line:84% So let's go back to the PSTN, which is here. 00:20:25.860 --> 00:20:38.730 align:middle line:84% And I'll go back to R1 and do a debug ccsip messages 00:20:38.730 --> 00:20:43.600 align:middle line:90% and go back to PSTN and redial. 00:20:43.600 --> 00:20:45.670 align:middle line:84% This time, I do have an outbound dial peer. 00:20:45.670 --> 00:20:47.870 align:middle line:90% Let's check what happens. 00:20:47.870 --> 00:20:50.330 align:middle line:90% Let's do an un all. 00:20:50.330 --> 00:20:53.900 align:middle line:84% Go back and disconnect that call. 00:20:53.900 --> 00:20:56.000 align:middle line:90% If I scroll back here and check. 00:20:56.000 --> 00:20:59.360 align:middle line:90% 00:20:59.360 --> 00:21:09.410 align:middle line:84% So I received the invite from the PSTN when the calling-- 00:21:09.410 --> 00:21:12.890 align:middle line:84% called was 10 digits, as per the question. 00:21:12.890 --> 00:21:18.840 align:middle line:84% Called or calling was 10 digits, which you can see here. 00:21:18.840 --> 00:21:20.930 align:middle line:84% So calling and called was 10 digits. 00:21:20.930 --> 00:21:22.280 align:middle line:90% What did I do? 00:21:22.280 --> 00:21:26.600 align:middle line:84% I sent the invite ahead to SME, but I 00:21:26.600 --> 00:21:31.160 align:middle line:84% changed the called to e.164 and the calling 00:21:31.160 --> 00:21:34.170 align:middle line:84% to e.164, which is as per the requirement of the question. 00:21:34.170 --> 00:21:36.050 align:middle line:90% So I sent the invite to SME. 00:21:36.050 --> 00:21:41.970 align:middle line:84% The SME sent back "trying" and then "404 not found" because, 00:21:41.970 --> 00:21:44.220 align:middle line:84% again, the SME doesn't know how to route that call 00:21:44.220 --> 00:21:47.430 align:middle line:84% to the respective call managers, HQ or site B. 00:21:47.430 --> 00:21:49.260 align:middle line:90% So I need to configure SME. 00:21:49.260 --> 00:21:51.585 align:middle line:90% So let's now go to SME. 00:21:51.585 --> 00:21:54.560 align:middle line:90% 00:21:54.560 --> 00:21:56.760 align:middle line:90% And let's open up Firefox. 00:21:56.760 --> 00:22:04.340 align:middle line:90% 00:22:04.340 --> 00:22:11.830 align:middle line:90% And let's go to HQ, SME. 00:22:11.830 --> 00:22:18.570 align:middle line:90% 00:22:18.570 --> 00:22:19.380 align:middle line:90% Dismiss this. 00:22:19.380 --> 00:22:20.235 align:middle line:90% And let's log in. 00:22:20.235 --> 00:22:23.210 align:middle line:90% 00:22:23.210 --> 00:22:28.130 align:middle line:84% Administrator, C1iC0123, C is uppercase, exclamation. 00:22:28.130 --> 00:22:30.630 align:middle line:90% So log in with the password. 00:22:30.630 --> 00:22:33.540 align:middle line:84% And the first thing that I'm going to do here 00:22:33.540 --> 00:22:36.090 align:middle line:90% is create a new partition. 00:22:36.090 --> 00:22:54.520 align:middle line:90% 00:22:54.520 --> 00:22:56.310 align:middle line:90% So a new partition. 00:22:56.310 --> 00:23:00.670 align:middle line:90% 00:23:00.670 --> 00:23:05.940 align:middle line:84% Let's name this partition as partition inbound from PSTN. 00:23:05.940 --> 00:23:16.780 align:middle line:90% 00:23:16.780 --> 00:23:18.880 align:middle line:90% So PT-INBOUND-PSTN. 00:23:18.880 --> 00:23:24.535 align:middle line:90% 00:23:24.535 --> 00:23:25.035 align:middle line:90% Save. 00:23:25.035 --> 00:23:27.630 align:middle line:90% 00:23:27.630 --> 00:23:31.230 align:middle line:84% If I look at all my partitions, the PT-PSTN 00:23:31.230 --> 00:23:33.480 align:middle line:84% was for outbound to PSTN, which we 00:23:33.480 --> 00:23:34.770 align:middle line:90% had done in the earlier task. 00:23:34.770 --> 00:23:36.520 align:middle line:84% So right now, I'm creating a new partition 00:23:36.520 --> 00:23:37.890 align:middle line:90% called PT-INBOUND-PSTN. 00:23:37.890 --> 00:23:51.260 align:middle line:84% Let's create a new CSS, CSS-INBOUND-PSTN. 00:23:51.260 --> 00:23:56.040 align:middle line:90% 00:23:56.040 --> 00:23:58.260 align:middle line:84% And let's put that partition inside that. 00:23:58.260 --> 00:24:08.980 align:middle line:90% 00:24:08.980 --> 00:24:12.190 align:middle line:84% Next, what I'm going to do is I am going 00:24:12.190 --> 00:24:15.850 align:middle line:90% to create a route pattern-- 00:24:15.850 --> 00:24:16.990 align:middle line:90% two route patterns. 00:24:16.990 --> 00:24:18.280 align:middle line:90% One to go to HQ. 00:24:18.280 --> 00:24:21.460 align:middle line:84% One to go to site B. This is what 00:24:21.460 --> 00:24:24.460 align:middle line:84% I have from all the earlier tasks right now. 00:24:24.460 --> 00:24:26.260 align:middle line:90% Let's create a new partition-- 00:24:26.260 --> 00:24:35.890 align:middle line:84% a new route pattern, which says, backslash +1408.2022XXX. 00:24:35.890 --> 00:24:38.710 align:middle line:84% So if you are going to the HQ site, 00:24:38.710 --> 00:24:42.145 align:middle line:84% put this in the partition of inbound PSTN. 00:24:42.145 --> 00:24:44.845 align:middle line:84% And gateway is going to be go to HQ. 00:24:44.845 --> 00:24:47.380 align:middle line:90% 00:24:47.380 --> 00:24:48.920 align:middle line:90% OK, let's put Urgent Priority. 00:24:48.920 --> 00:24:51.950 align:middle line:90% We don't want him waiting here. 00:24:51.950 --> 00:24:55.350 align:middle line:90% And say, OK. 00:24:55.350 --> 00:24:58.020 align:middle line:84% There's one additional thing I'm going to do. 00:24:58.020 --> 00:25:04.350 align:middle line:84% Now, my HQ site phone's extension is four digits. 00:25:04.350 --> 00:25:08.520 align:middle line:84% What am I sending to-- from SME to HQ call manager? 00:25:08.520 --> 00:25:12.270 align:middle line:90% I am sending e.164. 00:25:12.270 --> 00:25:14.420 align:middle line:84% So, obviously, the call is not going 00:25:14.420 --> 00:25:17.870 align:middle line:84% to be routed by the HQ UCM because the extensions have 00:25:17.870 --> 00:25:18.510 align:middle line:90% four digits. 00:25:18.510 --> 00:25:23.750 align:middle line:84% So I need to strip off the e.164 to four digits. 00:25:23.750 --> 00:25:27.350 align:middle line:84% Now, either I can go and do that on HQ site, 00:25:27.350 --> 00:25:30.530 align:middle line:84% or I can be smart about it in the lab exam. 00:25:30.530 --> 00:25:34.100 align:middle line:84% If you remember, we-- there was a task 00:25:34.100 --> 00:25:36.230 align:middle line:84% where we had configured intersite 00:25:36.230 --> 00:25:37.710 align:middle line:90% in one of the earlier videos. 00:25:37.710 --> 00:25:40.820 align:middle line:84% We had configured intersite between HQ and site B. 00:25:40.820 --> 00:25:45.920 align:middle line:84% And in that, we were prefixing it 00:25:45.920 --> 00:25:51.290 align:middle line:84% to the calls coming from site B to HQ and from HQ to site B. 00:25:51.290 --> 00:25:53.660 align:middle line:84% And on HQ and site B, we had already 00:25:53.660 --> 00:25:57.200 align:middle line:84% done some translation patterns, which was stripping off 00:25:57.200 --> 00:26:00.960 align:middle line:90% 82022XXX to only four digits. 00:26:00.960 --> 00:26:06.870 align:middle line:84% So what I'm going to do is strip off the +1408 and prefix, 00:26:06.870 --> 00:26:09.200 align:middle line:90% so do a PreDot and prefix 8. 00:26:09.200 --> 00:26:12.110 align:middle line:90% 00:26:12.110 --> 00:26:14.720 align:middle line:84% So what happens to my called number now? 00:26:14.720 --> 00:26:18.110 align:middle line:84% The called number, which was coming from CUBE to SME, 00:26:18.110 --> 00:26:20.120 align:middle line:90% was coming as e.164. 00:26:20.120 --> 00:26:22.790 align:middle line:84% On the SME, it matches this route pattern. 00:26:22.790 --> 00:26:27.740 align:middle line:84% And the route pattern strips off the +1408 and then makes 00:26:27.740 --> 00:26:34.100 align:middle line:84% the called number as 82022XXX and routes the call to HQ UCM. 00:26:34.100 --> 00:26:37.730 align:middle line:84% On HQ UCM, we had already configured a translation 00:26:37.730 --> 00:26:40.980 align:middle line:84% pattern in the intersite, when we had done intersite, 00:26:40.980 --> 00:26:45.860 align:middle line:84% which basically strips off 82022XXX to 2XXX 00:26:45.860 --> 00:26:47.430 align:middle line:90% only, to four digits. 00:26:47.430 --> 00:26:49.730 align:middle line:84% So I don't have to configure anything on HQ. 00:26:49.730 --> 00:26:52.940 align:middle line:84% If I don't do this, then I'll have to go to HQ 00:26:52.940 --> 00:26:58.540 align:middle line:84% and configure a new translation pattern that strips off e.164 00:26:58.540 --> 00:26:59.930 align:middle line:90% to four digits. 00:26:59.930 --> 00:27:02.410 align:middle line:90% I would have to do that. 00:27:02.410 --> 00:27:06.450 align:middle line:84% So I'm just being smart by reusing the earlier task 00:27:06.450 --> 00:27:08.700 align:middle line:90% to actually make the call work. 00:27:08.700 --> 00:27:11.910 align:middle line:90% It just saves a lot of time. 00:27:11.910 --> 00:27:12.570 align:middle line:90% Let's do OK. 00:27:12.570 --> 00:27:19.140 align:middle line:90% 00:27:19.140 --> 00:27:26.660 align:middle line:84% Let's do one more, Add New, which goes to site B. 00:27:26.660 --> 00:27:32.510 align:middle line:90% Backslash +1972.3033XXX. 00:27:32.510 --> 00:27:34.430 align:middle line:90% This goes in inbound PSTN. 00:27:34.430 --> 00:27:40.290 align:middle line:84% Gateway would be site B. Let's do Urgent Priority 00:27:40.290 --> 00:27:46.400 align:middle line:84% and do a PreDot to my called number and prefix 8. 00:27:46.400 --> 00:27:47.240 align:middle line:90% Save this. 00:27:47.240 --> 00:27:50.920 align:middle line:84% Calling number, nothing is changing. 00:27:50.920 --> 00:27:54.580 align:middle line:84% So calling number, CUBE had replaced the 10 digits 00:27:54.580 --> 00:27:56.110 align:middle line:90% to e.164. 00:27:56.110 --> 00:27:59.170 align:middle line:84% So all the calling numbers was e.164. 00:27:59.170 --> 00:28:04.630 align:middle line:84% So SME is going to send calling number as e.164 to HQ site 00:28:04.630 --> 00:28:07.150 align:middle line:84% or to site B site, but the called number 00:28:07.150 --> 00:28:14.800 align:middle line:84% is going to be 82022XXX or 8972 or 83033XXX to site B. 00:28:14.800 --> 00:28:17.860 align:middle line:84% And site B and HQ are going to strip off the four digits 00:28:17.860 --> 00:28:21.190 align:middle line:90% and keep only four digits. 00:28:21.190 --> 00:28:22.215 align:middle line:90% Let's save this. 00:28:22.215 --> 00:28:30.460 align:middle line:90% 00:28:30.460 --> 00:28:32.990 align:middle line:84% Looks like I'm not able to save it for some reason. 00:28:32.990 --> 00:28:35.900 align:middle line:90% 00:28:35.900 --> 00:28:41.230 align:middle line:90% Let's do a copy of this. 00:28:41.230 --> 00:28:42.000 align:middle line:90% So Copy. 00:28:42.000 --> 00:28:47.560 align:middle line:90% 00:28:47.560 --> 00:28:54.940 align:middle line:90% This changes to +19723033XXX. 00:28:54.940 --> 00:28:59.270 align:middle line:90% So 1972 gets stripped off. 00:28:59.270 --> 00:29:04.050 align:middle line:84% And this points to site B cluster. 00:29:04.050 --> 00:29:08.230 align:middle line:90% And PreDot is there. 00:29:08.230 --> 00:29:10.190 align:middle line:84% So for some reason, I'm not able to save it. 00:29:10.190 --> 00:29:11.930 align:middle line:90% I think it's to do with Firefox. 00:29:11.930 --> 00:29:13.900 align:middle line:84% So in case if when you are practicing this lab 00:29:13.900 --> 00:29:16.750 align:middle line:84% or doing this task, if you have the same issue, 00:29:16.750 --> 00:29:20.800 align:middle line:84% either just close your browser and just reopen it 00:29:20.800 --> 00:29:25.040 align:middle line:84% or use Chrome and try it with that. 00:29:25.040 --> 00:29:28.150 align:middle line:90% Let's go back to HQ SME. 00:29:28.150 --> 00:29:35.400 align:middle line:90% 00:29:35.400 --> 00:29:36.620 align:middle line:90% And let's log in. 00:29:36.620 --> 00:29:51.200 align:middle line:90% 00:29:51.200 --> 00:29:54.290 align:middle line:84% In the meanwhile, I'll show you those patterns 00:29:54.290 --> 00:29:56.940 align:middle line:84% that we had created in the intersite. 00:29:56.940 --> 00:29:58.235 align:middle line:90% So if you look at HQ site-- 00:29:58.235 --> 00:30:15.530 align:middle line:90% 00:30:15.530 --> 00:30:18.130 align:middle line:90% let's go back to Route Pattern. 00:30:18.130 --> 00:30:23.390 align:middle line:90% 00:30:23.390 --> 00:30:24.430 align:middle line:90% Let's do a Find. 00:30:24.430 --> 00:30:29.520 align:middle line:90% 00:30:29.520 --> 00:30:30.480 align:middle line:90% Let's do Add New. 00:30:30.480 --> 00:30:33.740 align:middle line:90% 00:30:33.740 --> 00:30:42.730 align:middle line:84% Backslash +1972.3033XXX goes to PSTN inbound. 00:30:42.730 --> 00:30:49.040 align:middle line:84% Gateway would be site B. Urgent Priority. 00:30:49.040 --> 00:30:53.650 align:middle line:90% And PreDot with prefixing 8. 00:30:53.650 --> 00:30:54.850 align:middle line:90% And let's save this. 00:30:54.850 --> 00:31:03.380 align:middle line:90% 00:31:03.380 --> 00:31:07.120 align:middle line:84% So once this is saved, if I look back at HQ site-- 00:31:07.120 --> 00:31:10.180 align:middle line:84% and let's log into Administration. 00:31:10.180 --> 00:31:12.860 align:middle line:90% 00:31:12.860 --> 00:31:15.560 align:middle line:84% And if you remember, on HQ site, we 00:31:15.560 --> 00:31:19.290 align:middle line:84% had a translation pattern, which we had created, 00:31:19.290 --> 00:31:25.310 align:middle line:84% which strips off 82022XXX to 2XXX. 00:31:25.310 --> 00:31:29.280 align:middle line:84% So we don't have to configure HQ site or site B site. 00:31:29.280 --> 00:31:30.960 align:middle line:90% Let me quickly show you that. 00:31:30.960 --> 00:31:37.080 align:middle line:90% 00:31:37.080 --> 00:31:39.155 align:middle line:84% So Call Routing, Translation Pattern. 00:31:39.155 --> 00:31:41.990 align:middle line:90% 00:31:41.990 --> 00:31:43.620 align:middle line:90% Let's do Find. 00:31:43.620 --> 00:31:47.540 align:middle line:84% So on HQ site, we had created 202.2XXX, 00:31:47.540 --> 00:31:48.860 align:middle line:90% which is inbound from SME. 00:31:48.860 --> 00:31:52.640 align:middle line:84% When the call comes in from SME, it strips off the 8202.2XXX 00:31:52.640 --> 00:31:54.020 align:middle line:90% to only 2XXX. 00:31:54.020 --> 00:31:58.320 align:middle line:84% So call should route to the phones, 00:31:58.320 --> 00:32:00.530 align:middle line:90% which is four digit extension. 00:32:00.530 --> 00:32:02.830 align:middle line:90% Let's go back to my SME. 00:32:02.830 --> 00:32:04.580 align:middle line:84% There's one more thing that we need to do. 00:32:04.580 --> 00:32:05.765 align:middle line:90% Go back to your SIP trunk. 00:32:05.765 --> 00:32:14.080 align:middle line:90% 00:32:14.080 --> 00:32:18.370 align:middle line:84% The SIP trunk that we have towards the CUBE, 00:32:18.370 --> 00:32:21.790 align:middle line:84% we need to give that SIP trunk access to the new CSS 00:32:21.790 --> 00:32:25.510 align:middle line:84% that we created because that CSS has access to the partition 00:32:25.510 --> 00:32:28.960 align:middle line:84% inbound from PSTN, which has the two route patterns. 00:32:28.960 --> 00:32:35.050 align:middle line:84% So under SME-PSTN, in the inbound Calling Search Space, 00:32:35.050 --> 00:32:38.380 align:middle line:84% I would give him access to inbound PSTN. 00:32:38.380 --> 00:32:41.160 align:middle line:90% Let's save this. 00:32:41.160 --> 00:32:44.780 align:middle line:90% So now call comes from PSTN. 00:32:44.780 --> 00:32:47.210 align:middle line:84% Let's say if the call is coming from PSTN line 1, 00:32:47.210 --> 00:32:48.890 align:middle line:90% calling number is 10 digits. 00:32:48.890 --> 00:32:50.300 align:middle line:90% Called is 10 digits. 00:32:50.300 --> 00:32:52.910 align:middle line:84% It matches on the CUBE dial peer 2000, 00:32:52.910 --> 00:32:54.770 align:middle line:90% which is the inbound dial peer. 00:32:54.770 --> 00:32:57.650 align:middle line:84% It changes the calling and called to e.164, 00:32:57.650 --> 00:33:01.520 align:middle line:84% matches the outbound dial peer 30, and routes the call to SME. 00:33:01.520 --> 00:33:05.180 align:middle line:84% So SME gets e.164 as the calling number and called number. 00:33:05.180 --> 00:33:09.080 align:middle line:84% SME, on the inbound CSS, has access to those two route 00:33:09.080 --> 00:33:11.810 align:middle line:84% patterns, changes the called number 00:33:11.810 --> 00:33:18.950 align:middle line:84% from e.164 to 82022XXX or 830333XXX 00:33:18.950 --> 00:33:24.020 align:middle line:84% and routes the call to HQ or site B. Let's reset this. 00:33:24.020 --> 00:33:26.300 align:middle line:84% We must reset this whenever we make any changes. 00:33:26.300 --> 00:33:31.492 align:middle line:90% 00:33:31.492 --> 00:33:32.200 align:middle line:90% Let's close this. 00:33:32.200 --> 00:33:35.210 align:middle line:84% And let's try making the call again. 00:33:35.210 --> 00:33:42.000 align:middle line:84% So from here, I am going to dial HQ site. 00:33:42.000 --> 00:33:46.040 align:middle line:84% And if I look at Tony Stark now, he gets the call from PSTN. 00:33:46.040 --> 00:33:47.750 align:middle line:90% Inbound dialing is working. 00:33:47.750 --> 00:33:50.870 align:middle line:84% And I see e.164 number as the calling number. 00:33:50.870 --> 00:33:54.440 align:middle line:84% Called was changed to four digits, not by SME. 00:33:54.440 --> 00:33:57.140 align:middle line:90% SME changes it to 82022XXX. 00:33:57.140 --> 00:33:58.520 align:middle line:90% It comes to HQ cluster. 00:33:58.520 --> 00:34:02.690 align:middle line:84% HQ cluster strips of the 8202 and sends the four digit 00:34:02.690 --> 00:34:04.670 align:middle line:90% to the respective phone. 00:34:04.670 --> 00:34:10.610 align:middle line:84% So I'm able to make that call from PSTN to now HQ site. 00:34:10.610 --> 00:34:13.730 align:middle line:90% Let's try from PSTN to site B. 00:34:13.730 --> 00:34:21.360 align:middle line:84% So 19723033003, which is Steve Rogers. 00:34:21.360 --> 00:34:26.880 align:middle line:84% And let's check here on site B. On site B, 00:34:26.880 --> 00:34:29.610 align:middle line:84% also, I'm getting the call from HQ PSTN, 00:34:29.610 --> 00:34:32.080 align:middle line:90% which is line 1 of PSTN. 00:34:32.080 --> 00:34:34.560 align:middle line:90% So it is a national call. 00:34:34.560 --> 00:34:36.760 align:middle line:90% And the call works. 00:34:36.760 --> 00:34:40.500 align:middle line:84% So with this, we've basically configured all the requirements 00:34:40.500 --> 00:34:43.230 align:middle line:84% of this task, where we provisioned 00:34:43.230 --> 00:34:47.760 align:middle line:84% inbound calling from PSTN to the respective sites. 00:34:47.760 --> 00:34:49.780 align:middle line:84% I hope this video was informative to you. 00:34:49.780 --> 00:34:52.490 align:middle line:90% And thank you for watching. 00:34:52.490 --> 00:34:53.000 align:middle line:90%