So today I decided that after I was done writing some curriculum that I was going to solve this bloody telepresence MCU issue that was not letting CUCM calls get pushed to the Codian MCU. If that last sentence just got you lost in the sauce let me explain a bit since the entire Voice realm is more than just voice over IP.
To start off, CCIE Collaboration is the new CCIE Voice. You essentially need to be able to understand, design, implement, and install an entire UC infrastructure to include video endpoints and WebEx technologies. the Codian MCU is part of that collaboration "stuff". In it's basic form it is a hardware conferencing unit that can host numbers that you dial into for both audio, video, and content sharing.
The MCU at work is an old 4505 Codian that isn't quite EOL yet, in fact they still sell 4500 series MCUs based on the Cisco website. I took a look today and was surprised to still see updates. Anyways, on with the actual problem and how it could help you in the event you also have to deal with interoperability.
Basically, from CUCM to the MCU is a path that is well defined and must be properly setup. A VCS is involved, and in this case it is a VCS-C since it is internal to the network and telepresence endpoints, jabber, and MCU meetings are all registered to this VCS. It is essentially a variant of CUCM in that things can register to it only as SIP or H.323. I won't get deep into VCS technology since there is much more to it than what I am explaining here.
The VCS-C is the control for anything not directly registered to the CUCM. In my case, telepresence devices like C40s, EX90s, etc. The CUCM has a SIP trunk to the VCS-C and a route pattern that is using that SIP trunk. Don't get lost yet! So from here, that SIP trunk dumps out at the VCS-C right? Well, now the VCS will do some pre-search transforms which basically are translation patterns for a VCS. They are applied first before any search rules are done. I hope I still haven't lost you!
Search rules are essentially patterns that are matched and then modified if needed before being sent out again, in my case, the Codian 4505 MCU. The problem that I spent most of the day on is why the call was failing. CUCM was routing the call but the VCS would poop everywhere. A endpoint directly registered to the VCS had no issues but then again, the search rules didn't need to apply since it knows what is locally registered much in the same way you don't need route patterns for local directory numbers on a CUCM.
I ended up just comparing the two calls, one that passed and one that failed. I could see the different immediately, the RegEx wasn't happening and it was leaving an IP address on the SIP URI. This would be ok if the MCU and VCS were talking like that but they aren't and reconfiguring everything is a big pain in the butt. Ultimately, the problem was that it wasn't matching the incoming string to the VCS because I was missing a 5. The 5 was supposed to be in the inside and not the outside of set 1. So I probably lost you with that last statement....
When I say Set 1 I mean (....), or the first set of parenthesis. If you passed CVOICE you should know what RegEx is as you had to do translation rules in the voice gateway. In it's basic form it essentially matches and replaces. Let me put a few examples.
Example 1:
/1234/ /5678/
In the above example I am matching anything with 1234 and replacing it with 5678. This is something you normally wouldn't do but in it's basic form it is easy to understand. Let me throw a monkey wrench in things.
/^1234$/ /5678/
So what the heck did I just do? In RegEx a ^ means that it must START with a 1 and the $ sign means that it must END with a 4. So, I am saying a pattern of 1234 will be replaced with 5678. It has to start with 1 and also include 2, 3, and 4 at the end with nothing extra. If its 13234 it won't work. I am defining 4 numbers to be replaced with 4 numbers, simple as that. Don't think into it to hard, it's only going to make the rest of this a pain in the ass. Think of it as a literal string.
Example 2:
/1\(....)/ /944\1/
So what is going on here you might ask? Well something that you need to understand about RegEx is that the / and \ are completely different. The \ means that the next character to follow does not have any special meaning. In this case the 1 at the very end is not a 1 but is referring to "set 1". So what is set 1? That is easy, the first set is the (....). That is what we call a set, and we can have as many as we need in RegEx but it can get complicated as all heck. So what is this pattern doing? Look below.
Original number: 12345 Replaced number: 9442345
What I did here was take the first string, rip off the 1 and save the last 4 digits to "set 1". The replace string prefixes on a 944 and uses set 1 to suffix the rest (2345), oh look I made a set without even trying.
To make a long story short, this kind of thing was hosed up in the VCS and a 5 was where the 1 is. Granted my RegEx was much longer and more complicated as I was using %ip% and so on but the point is, one little screwup with RegEx can throw everything out of alignment. I put the 5 inside the set and it got preserved thus keeping a 5 digit pattern for me and everything flowed well. I plan on doing an entire RegEx blog post sometime either this week or next week. I have been working 11-12 hour days and am extremely tired so I have been neglecting my blog a bit and I must apologize. If you want to learn more on translation rules and RegEx go here:
http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/61083-voice-transla-rules.html
That explains it pretty well but I sometimes find that breaking it down can help quite the bit too.
No comments:
Post a Comment