This installment of the "I shoulda' check that..." series is focused on an issue I found when testing a completed lab session. I have absolutely no idea if the "broken scenario" would have been tested by a real proctor or not, but I do know that I technically violated a requirement.
In my mock lab, I had a phone line which, at one point, was provisioned for voicemail. The phone line was attached to a CUCM station and two of the voicemail requirements for this line were:
There were other requirements, but they are not relevant to the issue I uncovered during testing.
Later on in the same lab, I had a Unified Mobility requirement where, among other things, any calls to a specific station line should immediately ring a "mobile" phone (programmed on the PSTN station). The target line in this Single Number Reach (SNR) or Mobile Connect scenario was the same station line that had the aforementioned voicemail requirements.
When testing the voicemail feature (pre-SNR config) on the station line, I had no issues. All was well with the world. Later on, I validated the SNR configuration. Again, everything operated normally. However, when I did a full validation on my lab I found that the 2nd voicemail requirement was a big FAIL. When I called the station line, my "mobile" phone rang out. This would be just fine if the behavior didn't violate the voicemail requirement, which was: If the phone line is busy (i.e. on a call) a new call to the directory number should be immediately redirected to voicemail.
In my mock lab, I had a phone line which, at one point, was provisioned for voicemail. The phone line was attached to a CUCM station and two of the voicemail requirements for this line were:
- Unanswered calls should forward to voicemail after 20 seconds
- If the phone line is busy (i.e. on a call) a new call to the directory number should be immediately redirected to voicemail
There were other requirements, but they are not relevant to the issue I uncovered during testing.
Later on in the same lab, I had a Unified Mobility requirement where, among other things, any calls to a specific station line should immediately ring a "mobile" phone (programmed on the PSTN station). The target line in this Single Number Reach (SNR) or Mobile Connect scenario was the same station line that had the aforementioned voicemail requirements.
When testing the voicemail feature (pre-SNR config) on the station line, I had no issues. All was well with the world. Later on, I validated the SNR configuration. Again, everything operated normally. However, when I did a full validation on my lab I found that the 2nd voicemail requirement was a big FAIL. When I called the station line, my "mobile" phone rang out. This would be just fine if the behavior didn't violate the voicemail requirement, which was: If the phone line is busy (i.e. on a call) a new call to the directory number should be immediately redirected to voicemail.
The issue here is that Mobile Connect / SNR leverages a shared-line between the real IP phone and the Remote Destination Profile to do its job. As a shared line, there are certain directory number settings that only apply to a specific appearance on a specific device. One of those settings happens to be the Busy Trigger, which just so happens to be the key parameter when addressing how calls should be treated when a line is active/busy.
By default, the Busy Trigger on a Remote Destination Profile line appearance is "2". Since we were required to immediate redirect to voicemail when a line is busy, our trigger on all appearances of that line must be "1".
By default, the Busy Trigger on a Remote Destination Profile line appearance is "2". Since we were required to immediate redirect to voicemail when a line is busy, our trigger on all appearances of that line must be "1".
The primary take away here is that you must pay attention to how individual testing requirements on the lab may affect or be effected by other requirements or features. The secondary take away (in my opinion, anyway) is that it is better to do your validation after you complete all (or most) of the lab requirements/configurations.
In-line validation is helpful in some cases but when you are dealing with tight time constraints, it is best to avoid the trap of validating every individual lab requirement as you complete them. In the example above, if I ate up 8 minutes to validate voicemail and another 8 minutes to validate Mobility then all I did was waste 16 minutes because I am still losing points somewhere. I'd much rather have those 16 minutes to add to a pool of 60 - 120 minutes and do a more thorough final check.
Thanks for reading. If you have time, post a comment!
Very helpful article. I'll be attacking my CCIE V. early next year, your blog will be a must read.
ReplyDeleteCheers
Steve
Wow, great post.
ReplyDelete