CCIE Collaboration Bootcamp Week 1 Scenarios

CCIE Collab 10-Day Bootcamp – Lab Scenarios Rev 0.15

Copyright © INE www.INE.com 1

INE’s CCIE Collaboration Bootcamp Week 1 – Lab Scenarios

Topology Overview The topology for INE’s CCIE Collaboration Bootcamp is made up of 9 “racks” of equipment. Along with a lab partner, you will be assigned a rack number 1 – 9, which will be referenced throughout this document as X. Any reference to X in should be replaced with your rack number that you are assigned. Within any given rack, you and your lab partner will by referenced throughout this document as Y. Any reference to Y in should be replaced with your lab partner number. Once assigned a lab partner (based on who you are sitting closest to), please determine amongst yourselves who will be partner 1 and who will be partner 2. Please refer to the topology diagram as you consider that each rack consists of the following hardware/software and that each lab partner will have his/her own:

• 1 x Unified Communications Cluster (UCM) with Publisher & two Subscribers • 1 x Unity Connection server (CUC) • 1 x IM and Presence server (IM&P) • 2 or 3 ‘Sites’ including all gear at those sites: (Site A, Site B, Site C, Site D)

o WAN Router w/ GE/Serial WAN interfaces o Voice gateway w/ T1/E1 PSTN interfaces and SIP Trunk(s) o 7961 and 9971 IP phones o Jabber client(s)

Shared equipment between partners includes the following:

• 1 x Contact Center Express server (UCCX) • 1 x Unity Express SREs (CUE) • 1 x PSTN UCM Cluster • 1 x PSTN 7961 Phone • 1 x PSTN Jabber client • 1 x Cloud MS Active Directory / DNS • 1 x Cloud VCS • 1 x Cloud JabberVideo client • 1 x MPLS WAN router

The lab scenarios in this document are meant to be worked on collaboratively with your assigned lab partner. Feel free to divide the work however you choose, for example one of you being responsible for overall SiteA/Cluster1 and the other being responsible for SiteB/Cluster2. Many of the technologies covered in these scenarios, such as EL-CAC, Jabber Federation, ILS, etc., require the clusters and devices to work in pairs in order to build a successful configuration so play nice ☺.



Accessing the Routers and Switches Access to the routers and switches’ CLI is through regular telnet access over the Internet. To login to these devices, simply telnet to racks.ine.com with any terminal software of your choice, such as PuTTY or SecureCRT. When the login prompt appears enter the username/password corackX/corackX based on which rack you have been assigned in class this week, and you will be presented with “AS>” prompt for further navigation. At this point, type ‘show host’ and after you find a list of host names, simply type the name of a single host to be connected to that device’s console port. It is recommended that you open multiple windows (and script/predefine these in PuTTY or SecureCRT for the remainder of class time). All server, desktop and device usernames/passwords will be admin/C1sc0123.

Accessing the Jabber Windows Desktops Access to the Windows machines where Jabber is installed is through Windows Remote Desktop Connection (RDP), which can be accessed from your members.ine.com account, by clicking on the Rack Rental navigation to the left, and then clicking on the Remote Desktop tab in the right pane. Usernames/passwords for Windows are also admin/C1sc0123.

Do not make any changes to the MGMT NIC or you will lock yourself out of the VM, but feel free to make whatever other changes you want to on these machines, as their disks are non-persistent and will revert to the previous snapshot upon power cycling.



All devices management IP addresses are listed in the table below, for your reference.

Hostname Management IP SW1 11.11.11.10 R1 Lo0 11.11.11.1 R2 Lo0 11.11.11.2 R3 Lo0 11.11.11.3 R4 Lo0 11.11.11.4 Cluster 1 – UCM Publisher 11.60.1.10 Cluster 1 – UCM Subscriber 1 11.60.1.11 Cluster 1 – UCM Subscriber 2 11.60.1.12 Cluster 1 – IM&P Publisher 11.60.1.20 Cluster 1 – CUC Publisher 11.60.1.30 Cluster 1 – UCCX Publisher 11.60.1.40 Cluster 1 – Jabber 1 11.60.10.1 / DHCP Cluster 1 – Jabber 2 11.80.10.1 / DHCP Cluster 2 – UCM Publisher 11.70.1.10 Cluster 2 – UCM Subscriber 1 11.70.1.11 Cluster 2 – UCM Subscriber 2 11.70.1.12 Cluster 2 – IM&P Publisher 11.70.1.20 Cluster 2 – CUC Publisher 11.70.1.30 Cluster 2 – Jabber 3 11.70.10.1 / DHCP PSTN Cluster – UCM Publisher 11.50.1.10 PSTN Cluster – IM&P Publisher 11.50.1.20 Cloud AD/DNS 11.50.1.5 Cloud VCS 11.50.1.15 Cloud JabberVideo DHCP



Section 1 – Network Infrastructure Pre-Task Verification

• Briefly verify all base configurations for SW1, R1, R2, R3 and R4 against the initial configs in your dropbox folder of the same name. If anything looks off, or if you don’t have full routing connectivity, either run the reset for your rack, or just copy&paste in the missing bits.

1.1 VLANs

• Configure SW1, R2 and R3 with VLAN assignments by following both the information below as well as the provided lab diagram.

o Shared (SW1) VLANs: " VLAN 2-4 – MPLS WAN VLANs " VLAN 50 – PSTN Servers/Phones/Jabber

o SA (SW1) VLANs: " VLAN 60 – SA Clus1 Servers " VLAN 610 – SA Clus1 Jabber/Data " VLAN 611 – SA Clus1 Phones

o SB (SW1) VLANs: " VLAN 70 – SB Clus2 Servers " VLAN 710 – SB Clus2 Jabber/Data " VLAN 711 – SB Clus2 Phones

o SC VLANs: " VLAN 80 – SC Clus1 Servers " VLAN 810 – SC Clus1 Jabber/Data " VLAN 811 – SC Clus1 Phones

o SD VLANs: " VLAN 90 – SD Clus1 Servers " VLAN 910 – SD Clus1 Data " VLAN 911 – SD Clus1 Phones " VLAN 912 – SD Clus2 Phones

• Name the VLANs intuitively. • Ensure that every port that is connected to an IP Phone gets both the Voice and Data

VLANs. • Port identification is both on the diagram and can be confirmed using CDP.



1.2 CDP / LLDP-MED • Ensure CDP is enabled, tuned to send hellos every 5 seconds, and advertises the Voice

VLAN properly. • Configure LLDP-MED to discover neighbors on all devices that support it. Note that

LLDP is not extended via L2VPN. Use this to distinguish between directly connected rack phones and L2VPN phones throughout the rest of the labs.

1.3 NTP

• To ensure that all time is synchronized for all future traces and debugging (and you can be sure there will be plenty of debugging these next two weeks ☺), ensure that all devices have their time synchronized to R1’s loopback adapter, and that R1 has its time synchronized to the PSTN/WAN router.

• The PSTN/WAN router will only respond if R1’s NTP packets come from its loopback interface.

• Ensure all devices that have a hardware clock, save the NTP synchronized time to that hardware clock.

Site Timezone SA Los Angeles, US (GMT -8), DST=Yes SB New York City, US (GMT -5), DST=Yes SC Frankfurt, Germany (GMT +1), DST=Yes SD Sydney, AUS (GMT +10), DST=Yes



1.4 DHCP • Use the provided lab diagram for all IP addressing ranges. • Configure SA so that all IP phones get their IP addressing from the Clus1 UCM Pub.

o Do not hand out IP addresses with host IPs of .1 - .90 or .99 - .254. o TFTP should be set to Clus1 UCM Pub.

• Configure SB so that all IP phones get their IP addressing from the Clus2 UCM Pub. o Do not hand out IP addresses with host IPs of .1 - .90 or .99 - .254. o TFTP should be set to Clus2 UCM Pub.

• Configure SC so that all IP phones get their IP addressing from the local router. o Only hand out IP addresses with host IPs of .91 - .98. o TFTP should be set to Clus1 UCM Pub.

• Configure SD so that all IP phones get their IP addressing from the local router. o Only hand out IP addresses with host IPs of .91 - .98. o TFTP for phones in VLAN 911 should be set to Clus1 UCM Pub. o TFTP for phones in VLAN 912 should be set to Clus2 UCM Pub.

• All phones should have DNS server set to 11.50.1.5, and domain-name set to “ine.com”



Section 2 – UCM Server and Phone Initialization 2.1 BAT Import and IP Phone Creation

• From your class share folder, navigate to ‘base configs’. • Import proper BAT tar files into the appropriate UCM clusters (Clus1, Clus2). • Ensure “Select All”, “Overwrite Configuration”, and “Run Immediately” are all ticked

before beginning import. • This will give you a base for your IP phones and we will revisit the topic of IP phones in

just a bit. 2.2 Service Activation and UCM Groups

• Verify that all UCM Servers have the appropriate services activated. o Publisher in each cluster does not process calls, handle IPVMA or handle CTI. It

handles DB activities, MVA, Presence, and TFTP. o Both Subscribers in each cluster should process calls, handle IPVMA and CTI.

• Verify that UCM Servers and Server Group are setup properly. o UCM Server Group should have Sub1, then Sub2 handle registrations in that

order. • DNS will be used in all cases. Do not change UCM Server names or URIs in Enterprise

Parameters to use IP addressing, but rather leave them using FQDNs. 2.3 Date / Time Groups

• Create Date/Time Groups for the sites phones registered to your UCM Cluster to reflect each of the site’s timezones as referenced back in Task 1.4.

• Ensure that these DT Groups support SIP phones. 2.4 Regions

• Calls between IP phones and/or Jabber clients within any site should use G.711 codec. • Calls between IP phones inter-site should use iLBC codec (if supported).

o 9971 phones support iLBC, 7961 phones do not and may use G.729 (7965 phones used in actual lab do support iLBC).

• Calls between Jabber clients inter-site should use G.729 audio codec. Use the same Region for IP phones mentioned in previous bullet. Do not create a new region.

• Accomplish all of this without disabling or changing the any G.722-related fields in Service Parameters, Enterprise Parameters or Phone page.

• Video Calls between IP phones or Jabber clients within a site may use 512kbps whereas video calls between IP phones or Jabber clients inter-site may only use 128kbps.



2.5 Device Pools

• On both clusters create Device Pools for devices and Inter-Cluster Trunks as needed. • Name them with simple names such as:

o “SA” o “SB” o “SC” o “SD” o “ICT” o etc.

• Assign all attributes as required to DPs and assign DPs to respective Phones/Jabber/GW at each site as you create them.

2.6 LDAP Synchronization

• On both clusters, ensure that LDAP synchronization has already been established for users from the Active Directory on AD-DNS server into each UCM cluster using the following information:

o Server: ad.ine.com o Port: 389 (no SSL) o LDAP Bind User/Password: admin/C1sc0123 o LDAP Search Base: ou=universe,dc=ine,dc=com o Map the UCM "Directory URI" field to the LDAP "mail" field

• Ensure every user has the all of the proper roles allowing them to control only IP phones they are (or will be) associated to, as well as log in to the CCMUser page.

2.7 LDAP Authentication

• Enable Authentication from the same AD server using the same search base as above. • Verify that this works by logging out of "https://clus1-ucm-pub/ccmadmin" and logging in

to "https://clus1-ucm-pub/ccmuser" using the password “C1sc0123” for any user.



2.8 IP Phone Registration • Using CDP to find your MAC addresses, change the MAC addresses in all three UCM

clusters as necessary to allow your phones to register. • Take special note to see if your 7961 phones are model “7961” or model “7961G-GE”,

and if they are “G-GE”, then use the “Related Links” at the top right of the appropriate phone page to “Migrate Phone” to the proper phone model using the already-created BAT Phone Templates.

o Do this for the PSTN phone as well in the SME cluster if it is a “7961G-GE”. • Perform association between users and devices in three ways:

o End User Device Association o Phone Device OwnerID o DN/Line End User association

• Ensure all Lines have CallerID mapped to their respective <FirstName LastName>. • Use SCCP loads for 7961 phones and of course SIP loads for 9971 phones. • Test and ensure 9971 phones are able to make video calls between phones. • All devices are listed below, however we will create Jabber clients later.

SitePhone Cluster DN E164 Dir URI UserID FName LName SAP1 Clus1 1001 +1.323.503.1001 [email protected] tstark Tony Stark SAP2 Clus1 1002 +1.323.503.1002 [email protected] nfury Nick Fury Jabber1 Clus1 1003 +1.323.503.1003 [email protected] bbanner Bruce Banner SBP1 Clus2 2001 +1.212.661.2001 [email protected] vvdoom Victor von Doom SBP2 Clus2 2002 +1.212.661.2002 [email protected] llaufeyson Loki Laufeyson Jabber2 Clus2 2003 +1.212.661.2003 [email protected] meisenhardt Max Eisenhardt SCP1 Clus1 3001 +49.69.7721.3001 [email protected] cxavier Charles Xavier SCP2 Clus1 3002 +49.69.7721.3002 [email protected] srogers Steve Rogers Jabber3 Clus1 3002 +49.69.7721.3002 [email protected] srogers Steve Rogers SDP1 Clus1 4001 +61.2.2129.4001 [email protected] jhowlett James Howlett SDP2 Clus1 4002 +61.2.2129.4002 [email protected] todinson Thor Odinson SDP3 Clus2 4003 +61.2.2129.4003 [email protected] ooctavius Otto Octavius PSTN Phone PSTN Many Many [email protected] pparker Peter Parker



• Ensure when phones register at each site, they look (in every way) like this: SA Phones



SB Phones

SC Phones



SD Phones



2.9 Enhanced Location Call Admission Control – Cluster 1 • Ensure that the Location Bandwidth Manager is only running on Sub1 & Sub2. • Create locations to correspond with the diagram named:

o "SA" o "SC" o "SD"

• Configure a link with bandwidths between SA <-> SC as follows: o Audio = 2Mbps o UC Video = 8Mbps o Telepresence Video = 20Mbps

• Configure a link with bandwidths between SA <-> SD as follows: o Audio = Unlimited o UC Video = Unlimited o Telepresence Video = Unlimited

• Configure a link with bandwidths between SC <-> SD as follows: o Audio = 2Mbps o UC Video = 4Mbps o Telepresence Video = 10Mbps

• Configure weights so that UCM decides the effective route between SA and SD is via SC.

o Navigate to Cisco Unified Servicability > Tools > Locations > Effective Path to determine the effective path.

• Ensure that UCM allocates video bandwidth for Telepresence end units from the proper "Telepresence Video" pool instead of from the "UC Video" pool.

o (Note that you cannot test this as we have no EX or Codec units)



2.10 Enhanced Location Call Admission Control – Cluster 2 • Ensure that the Location Bandwidth Manager is only running on Sub1 & Sub2. • Create locations to correspond with the diagram named:

o "SA" o "SB" o "SD"

• Do not configure any links between SA <-> SC. • Do not configure any links between SC <-> SD. • Configure a link with bandwidths between SA <-> SB as follows:

o Audio = 5Mbps o UC Video = 20Mbps o Telepresence Video = 45Mbps

• Configure a link with bandwidths between SB <-> SD as follows: o Audio = 3Mbps o UC Video = 4Mbps o Telepresence Video = 15Mbps

• Configure a link with bandwidths between SA <-> SD as follows: o Audio = 3Mbps o UC Video = 4Mbps o Telepresence Video = 15Mbps

• Configure weights so that UCM decides the effective route between SA and SD is via SC.

o Navigate to Cisco Unified Servicability > Tools > Locations > Effective Path to determine the effective path.

• Ensure that UCM allocates video bandwidth for Telepresence end units from the proper "Telepresence Video" pool instead of from the "UC Video" pool.

o (Note that you cannot test this as we have no EX or Codec units) 2.11 Blended Site EL-CAC

• Configure both sides so that CLUS1-UCM-Sub1 and CLUS2-UCM-Sub1 are used as LBM Hub Servers.

• On both UCM clusters, create a single SIP Trunk pointing at both UCM Subs at the opposite cluster, following codec information given earlier.

• On Cluster 1, navigate to Cisco Unified Servicability > Tools > Locations > Effective Path to determine the effective bandwidth restrictions between SA <-> SD.

• On Cluster 2, navigate to Cisco Unified Servicability > Tools > Locations > Effective Path to determine the effective path to “SC”.

• Create a SIP ICT trunk between sites for testing, with a route pattern XXXX.



Section 3 – IM & Presence, Jabber and Federations 3.1 IM&P Server Integration

• Integrate each UCM cluster with its respective IM&P server. 3.2 Jabber Registration with Desktop Sharing

• Register Jabber clients with their respective IM&P/UCM clusters in softphone mode. • Ensure Jabber clients can send/receive IMs as well as perform screen sharing. • Ensure the “Jabber3” client can also register in deskphone mode, and remotely control

SCP2. 3.3 Jabber Special Configurations

• Ensure that photos are displayed next to both your own Jabber client userID as well as any other userIDs that are called and/or saved as favorites in the client.

• Photos can be found at the following URI: o http://ad.ine.com/dirpics/<userid>.png o Where <userid> should be dynamically replaced with each user’s userID.

• Ensure that SIP URI Dialing is supported from the Jabber client in both clusters. • Ensure specifically that the Jabber client Jabber3 has directory pictures, however does

not support SIP URI Dialing. 3.4 XMPP Federations

• Federate both IM&P servers together so that Jabber calls, IMs and screen sharing works properly between Jabber1 and Jabber2 clients.



Section 4 – Media Resources 4.1 Media Termination Points

• Register MTPs from each router listed to UCM clusters based on information from the following table.

• Ensure all MTPs have support for RSVP. • MTPs are not to use any DSP resources. • Ensure H.264 Video, BFCP and FECC works through each MTP.

Router Codecs UCM Cluster R1 G.711, G.729, iLBC Clus1, Clus2 R2 G.711, G.729, iLBC Clus1 R3 G.711, G.729, iLBC Clus1, Clus2

4.2 Transcoders

• Register Transcoders with 1 session only from each router listed to UCM clusters based on information from the following table.

• Ensure all Transcoders have support for RSVP. • Ensure transcoders can transcode from ANY codec listed to ANY other codec listed. • Ensure H.264 Video, BFCP and FECC works through each Transcoder.

Router Codecs UCM Cluster R1 G.711, G.729, iLBC Clus1, Clus2 R3 G.711, G.729, iLBC Clus1, Clus2

4.3 Audio-Only Conference Bridges

• Register Audio Conference Bridges with 1 session only and with 8 participants only from each router listed to UCM clusters based on information from the following table.

• Ensure that when a conference bridge is either entered or left, that a custom tone is played. Use whatever frequency and cadence you choose – as long as it is audibly noticeable.

Router Codecs UCM Cluster R2 G.711, G.729, iLBC Clus1



4.4 Video DSP Resources • Make sure routers support DSP resources dedicated to video as follows

o R1: 16% dedicated to Voice, 84% allowed for Video o R2: 32% dedicated to Voice, 68% allowed for Video o R3: 32% dedicated to Voice, 68% allowed for Video

4.5 Homogenous Video Conference Bridges

• Register Video Conference Bridges with 1 session only from each router listed to UCM clusters based on information from the following table.

Router Audio Codecs Video Codec/Resolution/Frame Rate/Bitrate UCM Cluster R2 G.711, G.729, iLBC H.264 / VGA / 30fps / 1Mbps Clus1 R3 G.711, G.729, iLBC H.264 / VGA / 30fps / 1Mbps Clus2 4.6 Heterogeneous Video Conference Bridges

• Register Video Conference Bridges with 1 session only from each router listed to UCM clusters based on information from the following table.

Router Audio Codecs Video Codec / Resolutions UCM Cluster R1 G.711, G.729, iLBC H.264 / CIF, 4CIF, VGA Clus1



4.7 Music on Hold • Use Multicast Music on Hold at all sites streaming at G.711. • Use multicast groups exactly as follows:

o Clus1 Sub1: 239.1.1.1 o Clus1 Sub2: 239.1.2.1 o Clus2 Sub1: 239.1.1.1 o Clus2 Sub2: 239.2.2.1

• Site D must not use any WAN bandwidth to play music, but must still be from a multicast source being R3.

o Make sure that the music is the exact same audio file played from UCM. • You must verify and prove that the music heard is actually mmoh and not umoh with

RTMT. o Open RTMT and perform what is necessary to obtain this information in

numerical format, and prove your work by taking a screenshot of RTMT while a mmoh is in progress.

o To take a screenshot from your Jabber1 RDP desktop, click start and begin typing “Snipping Tool”. Once open, simply click and hold down your mouse and drag the area you want to capture, and then when the captured image pops up, press save.

o Save to the desktop and name the file “MMoH.png”. 4.8 Media Resource Groups and Lists

• Provision MRGs and MRGLs such that each site uses resources in following order: o Do not register UCM software MTPs or Conference Bridges. You are not

permitted to place these software devices in any MRG to accomplish this. o Only use MTPs and Transcoders that are local (if available) to a given site. o Audio Bridges should be chosen by the MRM before Video Bridges, if they exist

within a given cluster. o Choose Homogeneous Video Bridges before Heterogeneous ones. o Audio and Video Bridges may be utilized across sites within the same cluster. o Ensure both MoH and Annunciator play for Sites A, B and C from Sub2 primarily,

and Sub1 as a backup source, however ensure that for site D, both clusters play MoH and Annunciator from Sub1 only.



4.9 RSVP-Agent Based CAC • Delete the syncing of EL-CAC between clusters. • Configure UCM to use RSVP-Agents to enforce CAC.

o Use the same bandwidth prescribed earlier in EL-CAC tasks (most restrictive between clusters where there is a discrepancy) and ensure this bandwidth is used for both MPLS and Frame Relay circuits.

• Continue to differentiate between audio and video calls. o You are not able to differentiate between UC Video and TelePresence Video, so

simply limit all video to previous UC Video speeds. 4.10 SIP E2E RSVP Pre-Conditions

• Ensure that as audio or video calls are placed between clusters that SIP pre-conditions ensure that RSVP maintains CAC, regardless of which sites calls are between.



Section 5 – PSTN TDM Gateways and Call Signaling 5.1 SA & SB PSTN Gateway

• Configure R1 as an ISDN gateway to the PSTN using the following information and ensure that both Clus1 and Clus2 can send calls to the PSTN through this gateway using SIP.

o T1: ESF and B8ZS o Clocking from provider o ISDN Switch Type: Primary-NI o Source all SIP traffic to UCM from Loopback0 and use a reliable transport. o Proper intra/inter-site codec and DTMF support must be preserved o All calls sent to both UCM clusters should rely on DNS to route the calls.

" You are not permitted to use the FQDN, only hostname in the dial-peer. o Ensure all calls sent to UCMs are load balanced between the two active Subs. o Ensure that both UCM clusters as well as R1 monitor the SIP availability to each

other and automatically shuts down the UCM Trunks or R1 dial-peers (respectively) if something is unavailable.

o Ensure that R1 uses early-offer back to UCM servers, and that UCMs also use early-offer when sending calls to R1, however without the need for an MTP.

5.2 SC PSTN Gateway

• Configure R2 as an ISDN gateway to the PSTN using the following information and ensure that Clus1 only can send calls to the PSTN through this gateway using MGCP.

o E1: HDB3 and CRC4 o Clocking from provider o ISDN Switch Type: Primary-Net5 o Compand type: u-law o Source all MGCP traffic to UCM from Loopback0 o Proper intra/inter-site codec and DTMF support must be preserved

5.3 SD PSTN Gateway

• Configure R3 as an ISDN gateway to the PSTN using the following information and ensure that Clus2 only can send calls to the PSTN through this gateway using MGCP.

o E1: HDB3 and CRC4 o Clocking from provider o ISDN Switch Type: Primary-Net5 o Compand type: u-law o Source all MGCP traffic to UCM from Loopback0 o Proper intra/inter-site codec and DTMF support must be preserved



Section 6 – Dial Plan Route Plan Description and Overall Guidelines

Feature SA SB SC SD City, Country Los Angeles, US New York, US Frankfurt,

Germany Sydney, Australia

Outside dial tone (Do not send to PSTN)

9 9 0 0

Country Code +1 +1 +49 +61 City/Area Code 323 212 69 2 Subscriber Digit Length 7 7 8 8 Total Digit Length (Including Country Code, City Code and Subscriber Digits)

11 11 12 11

National Call Prefix (Do send to PSTN)

1 1 0 0

International Call Prefix 011 011 00 0011 EMS Number 911 / 9911 911 / 9911 112 / 0112 112 / 0112

• Outside dial tone should be played immediately after the single Outside dial tone digit has been pressed for each site respectively. Any delay and points will be deducted.

• You must allow for any phone users to be able to terminate interdigit timeout on international number dialing using the “#” sign, in order to place the call immediately



How To Dial Into Each Site's GW From the PSTN Phone • Going off hook on a line labeled to be at the same site (same city) as the phone you are

dialing into, will result in the call coming in from ISDN as a “Subscriber” TON. • Going off hook on a line labeled to be at a site within the same country, but a different

city as the phone you are dialing into, will result in the call coming in from ISDN as a “National” TON.

o As a special exception to this – since we have no lines in same country/different cities from the two international sites, simply choose PSTN Line 5 and dial into either SC or SD and it will show TON as “National”.

• Going off hook on a line labeled to be at a site from a different country as the phone you are dialing into, will result in the call coming in from ISDN as an “International” TON.

• Choose your desired line to produce the TON required, and then simply dial beginning with the country code followed by area code, followed by subscriber digits.

• Abbreviated speed dials have also been programmed for the PSTN phone for your convenience.

o To use, stay on-hook, and press the digit indicated at the top right of each phone/jabber on your provided lab diagram and then press the softkey “AbbrDial”.

o These will dial only on the primary line, however once dialed, you may hang up, choose a new line, and press redial.



Section 6A – Inbound Dial Plan 6.1 Inbound Calling Number Globalization

• Globalize all calls coming inbound from the PSTN to gateways at all sites using the proper Full +E.164 numbering format for each site.

o For SiteA and SiteB, globalize the calls in IOS before sending to the UCM clusters.

• The preceding “0” coming into SC and SD from the PSTN should not be included in the globalized format of the number - drop this "0" before doing anything else to the number.

• The new globalized calling number should display at every IP phone when the user at any phone looks at the Call History (Missed/Placed/Received Calls).

6.2 Inbound Calling Number Localization

• Localize all calls inbound from the PSTN as they arrive at every IP phone. • Local (Subscriber) Calls:

o During inbound alerting, IP phones in the US sites (SA, SB) should display calling party numbers that are local to each site as 7 digits.

o During inbound alerting, IP phones in the non-US sites (SC, SD) should display calling party numbers that are local to that site as 8 digits.

• Long Distance (National) Calls: o During inbound alerting, IP phones in the US sites (SA, SB) should display

calling party numbers as 10 digits if that call is from the same country, but a different city/area code.

o During inbound alerting, IP phones SC should display calling party numbers as 11 digits if that call is from the same country, but a different city/area code. This means that the calling party number needs to have the national access code of "0" added back to the front of the geographic code.

o During inbound alerting, IP phones SD should display calling party numbers as 10 digits if that call is from the same country, but a different city/area code. This means that the calling party number needs to have the national access code of "0" added back to the front of the geographic code.

• International Calls: o During inbound alerting, IP phones in the US sites (SA, SB) should display

calling party numbers with all digits, including the country code and the preceding PSTN international access code of "011", if that call is from a different country

o During inbound alerting, IP phones in the non-US sites (SC, SD) should display calling party numbers as full +E164.



Section 6B – Outbound Dial Plan General Guidelines

• You are only permitted to create one Route Pattern for the next three tasks. • Ensure that the PSTN patterns you create globalize every Called Party Number to a

proper full +E164 number format before the call reaches the Route Pattern. • Ensure that the Calling and Called Party number are sent to the PSTN with the proper

Types as listed in the tables below (see next page). • These tables do not include the ‘outside dialtone’ prefix required and noted earlier.

o EMS numbers should be able to be dialed both with and without the prefix. • All calls should only go out their local gateway at this time.

6.3 SA and SB Outbound PSTN Dialing

Call Type PSTN Pattern Called # Format Displayed on Phone

Calling # Format Sent to PSTN

Calling/Called Party ToN

Emergency 911 (any) 10 ANI Digits Unknown Local [2-9]XX[2-9]XXXXXX 7 ANI Digits 7 ANI Digits Subscriber National/LD 1[2-9]XX[2-9]XXXXXX 10 ANI Digits 11 ANI Digits National International 011 + Variable length (any) CC+10 ANI Digits International

6.4 SC Outbound PSTN Dialing Call Type PSTN Pattern Called # Format

Displayed on Phone Calling # Format Sent to PSTN


Emergency 112 (any) 10 ANI Digits Unknown Local [1-8]XXXXXXX 8 ANI Digits 8 ANI Digits Subscriber National/LD 0[1-8]XXXXXXXXX 10 ANI Digits 10 ANI Digits National International 00 + Variable length (any) CC+10 ANI Digits International

6.5 SD Outbound PSTN Dialing Call Type PSTN Pattern Called # Format

Displayed on Phone Calling # Format Sent to PSTN


Emergency 112 (any) 9 ANI Digits Unknown Local [1-8]XXXXXXX 8 ANI Digits 8 ANI Digits Subscriber National/LD 0[1-8]XXXXXXXX 9 ANI Digits 9 ANI Digits National International 0011 + Variable length (any) CC+9 ANI Digits International



6.6 + Dialing and One-Button-Callback • Ensure that any user at any IP phone who views their “Missed Calls” can simply press

the "Dial" softkey to return any call. • You must maintain the proper Calling # of Digits and Type described by the previous

task.



Section 6C – Presence and InterCluster Dialing 6.7 Simple URI Dialing Between Clusters

• Create a SIP Route Pattern in both UCM Clus1 and Clus2 pointing all unresolved URIs for the RHS of “@ine.com” and route them to the UCM server at the opposite cluster.

• Create a BLF speed dial on button 3 of SA Phone 1 for the URI [email protected] • Create a BLF speed dial on button 3 of SD Phone 3 for the URI [email protected] • These buttons should allow calls to be made properly between clusters, video should

work, and when not making calls, these buttons should present proper BLF status. • Once verified working, delete your SIP Route Pattern on each UCM cluster to prepare

for the next task.

6.8 Inter-Cluster Lookup Service (ILS) • Dynamically propagate all SIP Directory URIs between UCM Clus1 and Clus2. • Clus1 should advertise all of its URIs with the route string “clus1.ine.com”. • Clus2 should advertise all of its URIs with the route string “clus2.ine.com”. • Verify URIs have been propagated between clusters and match the proper route string

from CLI (in UCM v10 you can do this from Route Plan Report, in v9.1, CLI is required). • Create SIP Route patterns – 1 for each site – containing the route string at the other

cluster site, and point these route patterns to SIP ICTs at the other cluster site. • Create a secondary Directory URI on SA Phone 1 Line 1 as [email protected] • Create a secondary Directory URI on SD Phone 3 Line 1 as

[email protected] • Add another BLF speed dial on each phone button 4 pointing to the new URIs defined

on the phones. • Ensure all URI BLF speed dials work properly.

6.9 Dialing to VCS and JabberVideo

• Now that you have ILS working properly, and all URIs are explicitly defined in each cluster, create a SIP Route Pattern in both UCM Clus1 and Clus2 pointing all unresolved URIs for the RHS of “@ine.com” and route them to the VCS server at vcs.ine.com.

• Dial [email protected] and ensure the JabberVideo client answers. • Assuming the previous task with ILS worked, you also should be able to dial from the

JabberVideo client to any URI that exists in Clus1 or Clus2.



Section 6D – Dynamic InterCluster Dialing and Failover 6.10 Automated Alternate Routing (AAR)

• Using +E164 numbers only, ensure that AAR reroutes to the DID of each phone properly.

6.11 Call Forward on Failure (CFUR)

• Using +E164 numbers only, ensure that CFUR reroutes to the DID of each SD phone properly.

o You will not be able to fully test this until you setup SRST at SD later. 6.12 Call Control Discovery over Service Advertisement Framework (CCD/SAF)

• Dynamically propagate all 4 digit DNs along with their E164 alternate PSTN aliases between UCM Clus1 and Clus2.

• Use R1 as your SAF Forwarder between clusters.



Section 7 – Troubleshooting 7.1 URI Dialing to PSTN Jabber for Windows

• In both UCM Clus1 and Clus2 create a route pattern for 901131! and route it to a SIP Trunk pointing to sme-ucm-pub.ine.com.

o You may not route through any CUBE. o Ensure calls leaving your UCM cluster have the called number formatted in the

+E164 format. • On the “JabberVideo” desktop, ensure the JabberVideo client is shut down, and open

the Jabber for Windows client. • Each student will perform this troubleshooting task, Clus1 on Jabber1 desktop and

Clus2 on Jabber2 desktop. • From the Jabber1 or Jabber2 client dial 901131207037333, then from RTMT on

Jabber1/Jabber2 pointed at Clus1 Sub1/Clus2 Sub1, find and copy only the SIP message that describes why the call is failing and paste this in a notepad++ file saved on your Jabber1/2 desktop and label it “PSTN SIP Call Fail.txt”. Include a single line of text in your own words at the top of the file that describes why you believe the call is failing (more than simply what the SIP message says).

7.2 Unified Border Element and SIP Normalization

• On both Clus1 and Clus2, create a new SIP Trunk pointing to CUBE running on R1, and specifically at the Loopback0 address.

• From R1 CUBE, reroute the previous route pattern 901131! to 11.11.11.5. • All SIP messages from R1 destined for 11.11.11.5 must originate from a new

Loopback1 interface with the IP address 11.11.11.11/32, or else the call will fail. o Do not break the previous task 5.1 that mandated SIP traffic for PSTN calls come

from Loopback0. • Each student will perform this troubleshooting task, Clus1 on Jabber1 desktop and

Clus2 on Jabber2 desktop. • From the Jabber1 or Jabber2 client dial 901131207037333.

o Make sure you answer this call on the Jabber for Windows client, not on the 7961 PSTN phone. The call should connect with video.

• Now, from RTMT on Jabber1/Jabber2 pointed at Clus1 Sub1/Clus2 Sub1, find and copy only the SIP message that describes what video resolution and bandwidth ended up as the final negotiation and paste this in a notepad++ file saved on your Jabber1/2 desktop and label it “PSTN SIP Video Negotiation.txt”. Include a single line of text in your own words at the top of the file that describes what video resolution and bandwidth ended up as the final negotiation.

CCIE Collaboration Bootcamp Week 1 Scenarios

Documents

Transcript of CCIE Collaboration Bootcamp Week 1 Scenarios