In this installment, we are going to talk about "assumptions" and the difference between looking like an ass and getting points on the IE lab. The scenario is a question where Live Record is required. Specifically, the question states that a phone located at Site A (the site that also hosts the Unity Connection host) must be able to initiate a Live Record session and that the resulting recording should light their MWI lamp, etc. etc.
This is simple enough to configure. The potential downfall is how you test. Or, more accurately, what assumptions you make about how the proctor would test your success or failure in addressing the requirement. Let's be more specific about the requirements:
You have to make some assumptions about how the proctor will check your answer. Let's say you don't even notice the lack of a requirement here and/or you assume that you can test using any station. If you go down this path, I think you are in for a world of hurt.
For instance, what if you chose to validate your config by doing a Live Record with a PSTN station from Site A or one of the other IP phones at Site A. You complete your validation, find that everything works, and you pat yourself on the back. Feeling good, aren't you?
Now, what would happen if the proctor tests with a phone at Site B or Site C and the lab requires you always use G.729 when communicating between sites? What if, given the same codec requirement, the proctor tests with a TEHO call out of Site B's gateway?
If you failed to account for these alternative test scenarios then you will get a big goose egg. What I am getting at is the fact that when you initiative a Live Record session, you are creating a 3-way (or ad-hoc) conference. Which implies that you need a conference bridge media resource. If your standard config leaves the software conference resources in the default MRG or you put the conference resources in the Site A MRGL then the phones at Site A will have access to the software conference resources on the CUCM Pub/Sub (as provided for by IPVMS). This means that if you test with another Site A phone/gateway, your test will appear to succeed (assuming you have addressed the Unity Connection requirements).
However, software conference resources can only do G.711 and therein lies the problem. The question itself never says "add a conference resource to address this question" nor does it provide a specific call scenario that you need to support. Therefore, you have to assume any and all call scenarios are valid OR you need to ask the proctor to clarify. This gives you three possible outcomes:
If the answer is either 2 or 3, assume that the proctor is going to test with a call across the WAN. To account for this situation, you need to add a hardware conference resource to the mix. Specifically, you want to had a conference resource on your Site A gateway.
This is simple enough to configure. The potential downfall is how you test. Or, more accurately, what assumptions you make about how the proctor would test your success or failure in addressing the requirement. Let's be more specific about the requirements:
- Phone 2 at Site A must be able to initiate a Live Record session on it's primary line
- Site A Phone 2's primary line has a mailbox on the Unity Connection system
You have to make some assumptions about how the proctor will check your answer. Let's say you don't even notice the lack of a requirement here and/or you assume that you can test using any station. If you go down this path, I think you are in for a world of hurt.
For instance, what if you chose to validate your config by doing a Live Record with a PSTN station from Site A or one of the other IP phones at Site A. You complete your validation, find that everything works, and you pat yourself on the back. Feeling good, aren't you?
Now, what would happen if the proctor tests with a phone at Site B or Site C and the lab requires you always use G.729 when communicating between sites? What if, given the same codec requirement, the proctor tests with a TEHO call out of Site B's gateway?
If you failed to account for these alternative test scenarios then you will get a big goose egg. What I am getting at is the fact that when you initiative a Live Record session, you are creating a 3-way (or ad-hoc) conference. Which implies that you need a conference bridge media resource. If your standard config leaves the software conference resources in the default MRG or you put the conference resources in the Site A MRGL then the phones at Site A will have access to the software conference resources on the CUCM Pub/Sub (as provided for by IPVMS). This means that if you test with another Site A phone/gateway, your test will appear to succeed (assuming you have addressed the Unity Connection requirements).
However, software conference resources can only do G.711 and therein lies the problem. The question itself never says "add a conference resource to address this question" nor does it provide a specific call scenario that you need to support. Therefore, you have to assume any and all call scenarios are valid OR you need to ask the proctor to clarify. This gives you three possible outcomes:
- The proctor says that you only need to account for local calls within a region.
- The proctor says something like 'what would a CCIE do' or 'How would you do this in production'
- You decide to not ask and assume the worst case
If the answer is either 2 or 3, assume that the proctor is going to test with a call across the WAN. To account for this situation, you need to add a hardware conference resource to the mix. Specifically, you want to had a conference resource on your Site A gateway.
The Take Away...
The mock lab that "inspired" this installment was not a Cisco lab. So, it is possible Cisco will give you the necessary clues. However, I think that unlikely for every question in the real lab.
The first take away is that you may need to read beyond the question and make some logical assumptions. For configurations that will be tested by placing/receiving calls ask yourself the question: "do the question requirements state a specific call scenario"? If yes, then that is all you need to worry about. If not, test the most complicated variation to validate your config.
The second take away could be that you should "hide" the media resources until you are specifically asked to use them. Why? Because you don't want false positives. If you pre-stage your MRGLs then you can assign MRGs once you specifically determine what is needed. To "hide" the media resources, simply stick them in a MRG that has no MRGL buddies.
I suppose a third take away could be to ask the proctor if a question is unclear. I have found that the proctor (at least the one in RTP) are approachable but they are restricted in what they can say. You have to keep your questions in the realm of clarification.
Thanks for reading. If you have time, post a comment!
No comments:
Post a Comment