October 21, 2009 Joe Rinehart, President, Seattle Cisco Users Group [email_address] Thinking Outside the “BOX”:  Applying ...
Agenda <ul><li>Introduction </li></ul><ul><li>What Exactly Are We Talking About? </li></ul><ul><li>Example of “Off the Wal...
Introduction <ul><li>Joe Rinehart, CCNP/DP/VP, CCIE#14256 </li></ul><ul><li>Senior Systems Engineer for Nexus </li></ul><u...
What Exactly Are We Talking About?
Example of “Off the Wall” Problem-Solving Party preparations for Tricia’s Birthday Party The Challenge: Prepare Mascarpone...
Example of “Off the Wall” Problem-Solving Searching the Kitchen, this is What I Found to Work With The Challenge: Prepare ...
Example of “Off the Wall” Problem-Solving In the Game Room, I Found A Drill & Attached the Beater Within Five Minutes the ...
Example of “Off the Wall” Problem-Solving After Using A Melon Ball Scoop the Eggs Were Done Moral of the Story: Never Unde...
Process For Producing Creative Solutions <ul><li>Three Distinct Stages Exist in Creative Problem-Solving: </li></ul><ul><l...
Prepare : Develop the Right Mindset <ul><li>BE WILLING TO FAIL (or be misunderstood) </li></ul><ul><li>“ We don't like the...
Prepare : Develop the Right Mindset <ul><li>“ The idea is interesting and well-formed, but in order to earn better than a ...
Prepare : Develop the Right Mindset <ul><li>Some Examples of My Own  Off the Wall  Solutions: </li></ul><ul><li>“ Faux” L3...
Prepare : Develop the Right Mindset <ul><li>Understand the Technology (& how it works) </li></ul><ul><li>Never Underestima...
Possibilities : Dream Up Solutions & Test Them <ul><li>Identify the problem you want to solve </li></ul><ul><ul><li>Detail...
Possibilities : Dream Up Solutions & Test Them <ul><li>Narrow the list of possibilities by asking the following questions:...
Narrow the Possibilities: Will it work?
Possibilities : Dream Up Solutions & Test Them <ul><li>Try to make it work </li></ul><ul><ul><li>The WORST place to experi...
Put In Production :  Diagramming Possible Implementation in “Real Life” <ul><li>Review, review, review! </li></ul><ul><ul>...
Put In Production :  Diagramming Possible Implementation in “Real Life”
Practical Example : 2-Way Radio Solution <ul><li>Customer: Hospital Medical Imaging Department </li></ul><ul><ul><li>Total...
Practical Example : 2-Way Radio Solution <ul><li>Potential Solutions </li></ul><ul><ul><li>Motorola 2-Way Radio Systems </...
Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul>
Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul><ul><ul><li>Cisco 7921 ...
Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul>PART# QTY DESCRIPTION C...
Practical Example : 2-Way Radio Solution <ul><li>Potential Issues </li></ul><ul><ul><li>Privacy, as voice traffic deals wi...
Practical Example : 2-Way Radio Solution <ul><li>Evaluation of Solution </li></ul><ul><ul><li>Will it work?  YES, Technica...
Wrap-Up/Q&A
Upcoming SlideShare
Loading in …5
×

Rinehart CIPTUG Technical Forum Presentation Abridged 10 21 2009

1,709 views

Published on

Innovation depends on our ability to apply &quot;out of the box&quot; problem solving to real-world situations.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,709
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • My wife Brenda and I surprised her best friend Tricia in Oklahoma for her 40 th Birthday party Brenda &amp; Tricia left to go attend one of her son’s football games The family was new in the house and many things were not yet unpacked I was left in change of some of the meal preparations I had the recipe but no mixer, so I had to come up with something
  • I searched the kitchen which didn’t help too much, though I did find the beaters to some mixer The broader search didn’t turn up a mixer I had a finite amount of time to get this done
  • There were no electrical appliances except for a coffee grinder, toaster, and espresso machine The drill was a variable speed device and worked FABULOUSLY in mixing the egg, cheese, and other ingredients
  • I scooped the egg mixture into the cooked egg halves using a melon ball scoop, dipping it in water to allow the mixture to come out easily This part of the process only took a few minutes, and the eggs turned out perfect; keep in mind I am NOT a cook nor do I consider it a strong suit The guests at the party loved the eggs, more for the flavor than anything else, but I was pretty jazzed about coming up with the whole solution
  • Creative Solutions do not happen in a vacuum but require the right conditions and begin with EXPANDED THINKING, requires a little bit of wild eyed optimism Actually creating the solution also requires management of ideas In the final analysis if all you do is dream then be a writer, solutions require that you put feet to your ideas
  • First and foremost, you have to be willing to fail, made fun of, or called all kinds of interesting names Understand that no one bats a thousand, expect a minimum of 50% fall out rate on ideas No wasted solutions, you may find parts of what you think was a bad idea to be core in another solution later Experimentation is really key here, good ideas grow out of “what if” questions The story of Cisco Systems is actually key to this, Len Bosack, Sandy Lerner, and Kurt Lougheed developed the first Cisco routers on the campus of Stanford Their home was the location of the first “assembly line” and when Stanford said NO to commercial production, they did it anyway; not everything they tried worked either but look at the state of the industry and business NOW Famous examples include the Beatles who were refused by Decca, Fred Smith, etc.
  • Fed Ex as a concept got a C grade when submitted The phone was regarded as a useless toy by Western Union, and now its current forms dominate the modern communications landscape Having a thick hide is REQUIRED to pull off creative solution designs Knowing how to NOT quit is also important
  • I spent a lot of my early years without the right resources or tools to get things done so it forced me to use creative workarounds to compensate Not every idea worked, I tried to create a steam pump to pull heat to my room in college and that was a huge failure In my CCIE studies I depended on very old equipment that often could not completely serve the exam, for instance I could not afford $3000 3550 switches at the time so I used a router and L2 switch to mimic most of what I needed to use At AT&amp;T I had a couple interesting crazy solutions, one was for a large retail company who wanted certain parts of the network be restricted to certain servers in the data center. AT&amp;T refused to do VLANs in the data center (one wonders why), so instead I created access lists and null routing to accomplish the same thing over the VPN tunnels. Ironically they liked that solution better One customer migrating from frame-relay to an IPSec VPN service never mentioned Novell IPX until the solution was going in; I suggested using the legacy Cisco routers to use GRE tunneling to transport the traffic until it was phased out. It was also a solution that was inelegant but helped in its own way Coffee Partners Hawaii owned Starbucks and Jamba Juice stores and wanted to have one DSL connection support Internet access and dual IPSec tunnels to Starbucks and Jamba Juice HQ’s for card processing. Using propietary security devices requires some unusual subnetting and ACL’s to provide that VPN backup to the AT&amp;T MPLS service was required and used a combination of HSRP, BGP, and EIGRP for correct failover and local Internet access Because I changed configurations in my lab environments often I wanted to create a program that would access the routers and switches in the lab via console access through terminal servers, open telnet/SSH, log in, write configurations to the NVRAM and then drop the connection. After fighting with the concept for a while I later learned that others had already accomplished that Many many of the crazy things I come up with do not work as intended or do not address the issues enough to be considered viable, I give these examples simply to give an idea of how willing you have to be to come up short Some ideas may qualify as nothing more than novelty items but can still be fun – call it a “mad scientist” inclination
  • Another CRITICAL element is understanding HOW the technology works from a technical standpoint. On one of my first UC installs, CUCM paging was not working correctly and the customer was facing about $3000 to upgrade the switch software from SMI to EMI so it would support multicast. The link between the 2811 and 3560 switch was a L3 routed port, but if it was made a trunk instead, then the EMI was not necessary to support paging. GREAT example of knowing how the technology actually works. Sometimes in the rush to get certified it is easy to lose the importance of how everything actually functions As kids we had unlimited imagination and creativity and no shame about using it. As adults we seem to forget how to “play” so to speak, to say nothing of creativity. Innovators are in a sense in touch with their “inner child” One of the reasons that hackers continue to create issues, viruses, and other challenges is because they are willing to ask “what if…” or “what does this do” questions instead of trying to always color inside the lines CHALLENGE assumptions, you will be surprised at the avenues it can open up
  • Once you have the right mindset for coming up with creative, off the wall ideas, you have to actually CREATE them. It starts not with wanting to come up with weird ideas but rather on addressing an actual need: KNOWING the issues marks the first step. Frequently, if not always, it is a business need rather than a technical need that you find yourself addressing, and requires peeling back the layers. CLARITY IS KEY HERE: Beware of assuming you understand the issue, it’s amazing how often you can find yourself answering questions that no one is asking The second step is the one where a lot of folks understandably go awry. List out EVERY POSSIBLE SOLUTION; don’t get caught up in how wild, impractical, or mildly insane it may sound. Don’t put a fence around things just yet, all in good time. What you often find is that this stimulates the creative juices in ways that just going for the solution first just cannot do. It’s not the destination that matters at this point, it is the journey. Take the time to consider every angle, possibility, or idea FIRST ! Roughly describe the potential solutions with as much detail as you can without getting too caught up in them; sketch it out, don’t draw a Mona Lisa! Think of this as the “Flood and Prune” methodology of PIM-DM!
  • After compiling as complete a list as you can, start narrowing the field a little bit by pruning things based on a series of questions The first is TECHNICAL in nature: Will it work? In the final analysis, no matter how cool or fun an idea may seem, if it does NOT function then it is worthless. Knowing why it may not work as needed from a technical standpoint is key here as well. This is the first and most important consideration to take a look at or there is no point. The second and equally important consideration is whether the solution(s) actually solve the problem and/or address the need. It may make a GREAT white paper, but at the end of the day of it doesn’t actually do what it is supposed to do then it is just as useless as a solution that does not work technically. Practicality is a major issue as well; if the intended solution cannot scale, costs too much or creates security holes, for example, then toss that one out as well. This one can be painful! The question of long vs. short term solutions is a big one. I have seen many many “I’ll just do this to get by for now” quick-fixes stay in place literally for years, well past the point that anyone who put it in place or remembers what it was for is even still around. If you DO use something as a short term fix make certain you go back to it and actually fix it at some point, the next person doing your job will THANK YOU! Supportability is a big deal as well, the whole question of TOTAL COST OF OWNERSHIP or operating a solution is groslly underestimated many times. CFO’s may like how cheap a solution is from a capital standpoint, but if it costs three times as many man hours to operate it, then it may be a poor solution Best Practices are helpful and save a lot of headache but this can be a place that good ideas are cast aside in the name of best practices; take care that it does not become an empty mantra that just thrown out every new idea just because it is different PAY ATTENTION to dependencies and potential drawbacks of certain solutions. If you can mitigate the issues without too much trouble, so be it, but if you create solutions that require constant babysitting or workarounds “keep fixing” then beware of going down that path. At the end of the questions you should have a couple viable ideas to work with, otherwise just go back to the drawing board a little bit
  • Once you have a direction, start trying it out…you may need to think things through a little more, and if so, this is the time to do it. The devil is in the details, so know what those details are and work with them As with new technologies and such, a pilot is always a great idea. If you do not have a lab, now would be the time to create one. Unless the solution(s) require it, use older, decommissioned, or surplus equipment works well for purposes of experimentation. Try to mimic the production environment in some form so that the test setup is close enough to the real thing sto be valuable I think actually writing out the equipment configuration is valuable, use notepad or a text editor. First of all, this helps spot typos, errors, transposed numbers or other obvious problems up front. It also gives you a great place to search if something is not working or having issues. It also has the effect of keeping the configuration fresh in your mind When you have the set-up functioning and working end to end, stress the systems to push the limits a little bit. If there are cracks in the ideas involved, this will be a way to find that out in a controlled environment, and also help prove out what you are after. Use show and debug commands as needed to measure what you are doing Have a test plan already thought out and follow it to a T; do not rely on a single set of data, but run it at least twice to make sure that it does actually work within certain parameters Document everything in detail; use that for later analysis and for use in crafting a broader solution on the production network
  • Go back and review everything; read your documentation thoroughly, and try to look at it objectively One of the greatest favors you can do for yourself is to have relationships with other great engineers, but make certain that you can share things with a level of trust; the last thing you want when you have come up with a cool solution to a problem is someone running off claiming it was their idea, or worse yet, to show up at a conference listening to someone do that Ask hard questions about the results; it’s better to scrap an idea than stubbornly hold on to it like it’s a first born child and find out later its not what you thought Create an action plan to apply the solution to the larger production network; even in this regard it might be a good idea to start out with a smaller pilot and see how things go: MEASURE TWICE, CUT ONCE!
  • The title of this presentation is the focus of the rest of our talk today, and the reason we are all here My wife is the Director of Medical Imaging at a Hospital in Bellevue, Washington, and she allowed me the opportunity to submit a Unified Communications Solution for a business issue in her department The TRANSPORTERS are a group within the department that move patients to and from exams and often on the move; coordinating t his aspect of patient care is highly critical and they were looking for ways to communicate with them and also empower communication with one another The hospital had a large installed base of Cisco switching infrastructure as well as 802.11a/b/g wireless access points running multiple SSID’s The end solution had to allow for 2-way radio type communication between the central dispatcher and the transporters as well as between themselves
  • Several possible solutions had already been contemplated by the Operations Manager, Mike Wade, with whom I was dealing A couple of the alternatives were expensive and could create additional support issues Using the process we discussed previously I thought about a way to use the UC520 platform with wireless phones to create a Push to Talk type of solution
  • The UC520 would ideally use a trunk to the access layer of the switching infrastructure but could also just use a single VLAN for voice (no data) The VLAN would ideally also map to a new BSSID using WPA2 for data protection The UC500 would act as DHCP server and no communication would be allowed to/from any device outside the VLAN Separate Ephone/Ephone DN’s could be used for each of the stations One 7942 phone would serve as the “base station” for the 7921 phones The paging-dn (IP address 239.1.1.1) would map to the PTT button on the 7921 phones When pressed, the transporter or dispatcher would speak into the microphone and be broadcast out to all stations, much as a 2 way radio Configuration details for this feature is available on www.uc500.com
  • Headsets would be used for transporters to use to listen/speak (VOX would not be possible but button would be pressed just as with 2 way radios) Channel would be simulated but mimic the functionality closely This was to be deployed in an all-Avaya environment and serve as a beach head for further Cisco UC solutions
  • This is the actual bill of materials for the proposed solution Installation costs would also be required since programming and staging would be required
  • None of these issues would be show stoppers but must be considered
  • This compares our previous paradigm to the solution In the final analysis the budget was set artificially low, I considered donating my time but was overruled by management
  • Rinehart CIPTUG Technical Forum Presentation Abridged 10 21 2009

    1. 1. October 21, 2009 Joe Rinehart, President, Seattle Cisco Users Group [email_address] Thinking Outside the “BOX”: Applying Creative Problem Solving to Communications
    2. 2. Agenda <ul><li>Introduction </li></ul><ul><li>What Exactly Are We Talking About? </li></ul><ul><li>Example of “Off the Wall” Problem-Solving </li></ul><ul><li>Process For Producing Creative Solutions </li></ul><ul><ul><li>Prepare: Develop the Right Mindset </li></ul></ul><ul><ul><li>Possibilities: Dream Up Solutions & Test Them </li></ul></ul><ul><ul><li>Put In Production: Diagramming Possible Implementation in “Real Life” </li></ul></ul><ul><li>Practical Example: Two-Way Radio Solution </li></ul><ul><li>Wrap Up/Q&A </li></ul>
    3. 3. Introduction <ul><li>Joe Rinehart, CCNP/DP/VP, CCIE#14256 </li></ul><ul><li>Senior Systems Engineer for Nexus </li></ul><ul><li>10+ Years in Networking & Telecommunications </li></ul><ul><li>AT&T for 5.5 Years </li></ul><ul><li>Lived in Northwest for 13 Years </li></ul><ul><li>Married with 5 Children </li></ul><ul><li>President of the Seattle Cisco Users Group </li></ul><ul><li>Outdoor Enthusiast </li></ul><ul><li>Science Fiction Writer </li></ul>
    4. 4. What Exactly Are We Talking About?
    5. 5. Example of “Off the Wall” Problem-Solving Party preparations for Tricia’s Birthday Party The Challenge: Prepare Mascarpone Eggs without a Mixer
    6. 6. Example of “Off the Wall” Problem-Solving Searching the Kitchen, this is What I Found to Work With The Challenge: Prepare Mascarpone Eggs without a Mixer
    7. 7. Example of “Off the Wall” Problem-Solving In the Game Room, I Found A Drill & Attached the Beater Within Five Minutes the Eggs Were Ready for Preparation
    8. 8. Example of “Off the Wall” Problem-Solving After Using A Melon Ball Scoop the Eggs Were Done Moral of the Story: Never Underestimate Creativity!
    9. 9. Process For Producing Creative Solutions <ul><li>Three Distinct Stages Exist in Creative Problem-Solving: </li></ul><ul><li>Prepare : Develop the Right Mindset </li></ul><ul><li>What You Do BEFORE Anything Else (train the brain) </li></ul><ul><li>Possibilities : Dream Up Solutions & Test Them </li></ul><ul><li>What You Do WHILE Creating Solutions (creative process) </li></ul><ul><li>Put In Production : Diagramming Possible Implementation in “Real Life” </li></ul><ul><li>What You Do AFTER the Creative Process (making it reproducible) </li></ul>
    10. 10. Prepare : Develop the Right Mindset <ul><li>BE WILLING TO FAIL (or be misunderstood) </li></ul><ul><li>“ We don't like their music, and guitar bands are finished.” (Decca Records on rejecting the Beatles in 1962) </li></ul><ul><li>http://money.cnn.com/2006/08/21/pf/whatittakes_sticktoguns.moneymag/index.htm </li></ul>
    11. 11. Prepare : Develop the Right Mindset <ul><li>“ The idea is interesting and well-formed, but in order to earn better than a “C” the idea must be feasible” (to Fred Smith, Founder of Fed-Ex) </li></ul><ul><li>http://money.cnn.com/2006/08/21/pf/whatittakes_sticktoguns.moneymag/index.htm </li></ul><ul><li>“ This ‘telephone” has too many shortcoming to be seriously considered a means of communication. The device is inherently of no value to us.” (Western Union, 1876) </li></ul><ul><li>http://money.cnn.com/2006/08/21/pf/whatittakes_sticktoguns.moneymag/index.htm </li></ul>
    12. 12. Prepare : Develop the Right Mindset <ul><li>Some Examples of My Own Off the Wall Solutions: </li></ul><ul><li>“ Faux” L3 Switch: 2912-XL with Router on a Stick </li></ul><ul><li>VLAN Workaround: ACL’s + Null Routing in DC </li></ul><ul><li>DSL VPN Backup for MPLS Service </li></ul><ul><li>Legacy Protocols Support IPX/Appletalk </li></ul><ul><li>Frame-Relay Cascaded Switches Using NNI </li></ul><ul><li>Shared Internet/VPN Access with Collocated Stores </li></ul><ul><li>Switch/Router Autoconfigurator Program </li></ul>
    13. 13. Prepare : Develop the Right Mindset <ul><li>Understand the Technology (& how it works) </li></ul><ul><li>Never Underestimate the Power of “Creative Expertise” </li></ul><ul><ul><li>As children we never lacked creativity or imagination </li></ul></ul><ul><ul><li>Innovators have learned to harness the power of creative problem solving </li></ul></ul><ul><ul><li>Hackers assault businesses by experimenting, exploiting aspects of technology </li></ul></ul><ul><ul><li>Asking the “What If” questions make all the difference! </li></ul></ul><ul><ul><li>Challenge Assumptions! </li></ul></ul>
    14. 14. Possibilities : Dream Up Solutions & Test Them <ul><li>Identify the problem you want to solve </li></ul><ul><ul><li>Detail out the issue(s), you cannot address what you do not clearly understand </li></ul></ul><ul><ul><li>Try to understand dependent issues </li></ul></ul><ul><ul><li>Spell out the situation in a single phrase if you can </li></ul></ul><ul><li>List out every possible solution, no matter how off the wall, strange or impractical </li></ul><ul><ul><li>Start off compiling every single possibility </li></ul></ul><ul><ul><li>Leave no option off the table </li></ul></ul><ul><ul><li>Most individuals don’t consider all possible options </li></ul></ul><ul><ul><li>Create the list FIRST, eliminate things LATER </li></ul></ul>
    15. 15. Possibilities : Dream Up Solutions & Test Them <ul><li>Narrow the list of possibilities by asking the following questions: </li></ul><ul><ul><li>Will it work? </li></ul></ul><ul><ul><li>Does it actually solve the problem? </li></ul></ul><ul><ul><li>Is it practical? </li></ul></ul><ul><ul><li>Is it a short term fix or a long term solution? </li></ul></ul><ul><ul><li>Is it supportable? </li></ul></ul><ul><ul><li>Does it conform to best design and operational practices? </li></ul></ul><ul><ul><li>What are the possible drawbacks or side effects? </li></ul></ul>
    16. 16. Narrow the Possibilities: Will it work?
    17. 17. Possibilities : Dream Up Solutions & Test Them <ul><li>Try to make it work </li></ul><ul><ul><li>The WORST place to experiment is on a “live body” </li></ul></ul><ul><ul><li>Best to avoid RGE’s (resume generating events) </li></ul></ul><ul><ul><li>Create a testing environment safe for “experiments” (reflect production environment) </li></ul></ul><ul><ul><li>Write configurations out in longhand (use notepad) </li></ul></ul><ul><ul><li>Find ways to stress the system set-up </li></ul></ul><ul><ul><li>Create & Execute a valid test plan (run twice) </li></ul></ul><ul><li>Document the results </li></ul><ul><ul><li>Carefully record your findings </li></ul></ul><ul><ul><li>Use your documentation for finalizing solutions </li></ul></ul>
    18. 18. Put In Production : Diagramming Possible Implementation in “Real Life” <ul><li>Review, review, review! </li></ul><ul><ul><li>Take a fresh look at the project from start to finish </li></ul></ul><ul><ul><li>Bounce things off other smart engineers you can TRUST </li></ul></ul><ul><ul><li>Ask critical questions about the results and usability of your solution: it may be cool, but does it serve a good purpose? </li></ul></ul><ul><li>Address any shortcomings or issues realistically </li></ul><ul><li>Create an action plan to actually use the solution where it applies </li></ul>
    19. 19. Put In Production : Diagramming Possible Implementation in “Real Life”
    20. 20. Practical Example : 2-Way Radio Solution <ul><li>Customer: Hospital Medical Imaging Department </li></ul><ul><ul><li>Total staff of over 100 </li></ul></ul><ul><ul><li>Performs 100,000 Total Exams Per Year </li></ul></ul><ul><ul><li>Constant Interest in Process Improvements </li></ul></ul><ul><li>Business Problem </li></ul><ul><ul><li>Communication between Transporters (staff who move patients to/from exams) and Dispatcher </li></ul></ul><ul><ul><li>Mobile nature of the staff required some type of wireless voice solution </li></ul></ul><ul><ul><li>Involved 4 Mobile and 1 fixed location employee </li></ul></ul>
    21. 21. Practical Example : 2-Way Radio Solution <ul><li>Potential Solutions </li></ul><ul><ul><li>Motorola 2-Way Radio Systems </li></ul></ul><ul><ul><li>Avaya Wireless IP Phones </li></ul></ul><ul><ul><li>Vocera Wireless Voice System </li></ul></ul><ul><ul><li>Cellular Phones </li></ul></ul><ul><ul><li>Nextel 2-Way Cellular Phones </li></ul></ul><ul><ul><li>Cisco Wireless Telephony System using UC520 and Cisco Unified Communications Manager Express </li></ul></ul>
    22. 22. Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul>
    23. 23. Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul><ul><ul><li>Cisco 7921 IP Phones with Belt Holster & Headset for Transporters </li></ul></ul><ul><ul><li>Cisco 7942 IP Phone as Simulated Base Station for Dispatcher </li></ul></ul><ul><ul><li>Cisco UC520 for Call Control & Bearer Traffic </li></ul></ul><ul><ul><li>G.711 Codec (for Simplicity) </li></ul></ul><ul><ul><li>Paging-DN Tied to PTT Button on 7921’s </li></ul></ul><ul><ul><li>Broadcast Paging Mimics Push to Talk Channel Functionality </li></ul></ul><ul><ul><li>Existing Network & WLAN used for IP Transport </li></ul></ul>
    24. 24. Practical Example : 2-Way Radio Solution <ul><li>Cisco UC520/CUCME-Based Solution Detail </li></ul>PART# QTY DESCRIPTION Call Control UC520-8U-4FXO-K9 1 8U CME Base, CUE and Phone FL w/4FXO, 1VIC SW-UC520-4.1.0 1 Unified Communications 520 4.1 MEMUC500-128CF 1 128MB CF for the Cisco Unified 500 Series PWR-UC500-220W 1 Cisco Unified 500 Desk Top Power Adapter 100-240VAC WIC-BLANK-PANEL 1 Blank WAN Interface Card Panel CAB-AC 1 Power Cord,110V CON-SNT-8U4FXO 1 SMARTNET 8X5XNBD 8U CME Base, CUE and Phone FL w 4FXO Cisco IP Phones CP-7921G-A-K9= 4 Cisco 7921G FCC; Battery/Power Supply Not Included CP-7921G-SW-K9-A 4 Cisco 7921G Software, FCC CP-BATT-7921G-STD= 4 Cisco 7921G Battery, Standard CP-PWR-7921G-NA= 4 Cisco 7921G Power Supply for North America CP-HOLSTER-7921G= 4 Cisco 7921G Belt Holster CP-7942G= 1 Cisco Unified IP Phone 7942, spare
    25. 25. Practical Example : 2-Way Radio Solution <ul><li>Potential Issues </li></ul><ul><ul><li>Privacy, as voice traffic deals with patient information </li></ul></ul><ul><ul><li>Potential quality issues if WLAN QoS is Poor </li></ul></ul><ul><ul><li>Additional complexity for IT Staff </li></ul></ul><ul><ul><li>Stations talking over one another </li></ul></ul><ul><ul><li>Network outages would force the system offline </li></ul></ul><ul><ul><li>Possible Scaling Issues (8 stations for base model) </li></ul></ul><ul><ul><li>Most Telephony Features Would Remain Unused (Voice Messaging, Station-to-Station Calling, PSTN access, etc.) </li></ul></ul>
    26. 26. Practical Example : 2-Way Radio Solution <ul><li>Evaluation of Solution </li></ul><ul><ul><li>Will it work? YES, Technically Sound </li></ul></ul><ul><ul><li>Does it actually solve the problem? YES </li></ul></ul><ul><ul><li>Is it practical? YES, Uses existing Infrastructure </li></ul></ul><ul><ul><li>Is it a short term fix or a long term solution? LTS </li></ul></ul><ul><ul><li>Is it supportable? YES, Though Adds to IT Load </li></ul></ul><ul><ul><li>Does it conform to best design and operational practices? YES, Requires Some Unique Settings </li></ul></ul><ul><ul><li>What are the possible drawbacks or side effects? Security, Cost, Training Staff, Embedded Avaya </li></ul></ul>
    27. 27. Wrap-Up/Q&A

    ×