Wednesday, February 5, 2014

Cisco TelePresence Endpoints and IP Address Dialing with CUCM

Cisco has been steering customers and partners to centralize all call processing on the Cisco Unified Communications Manager (CUCM). This includes video or we can call it telepresence, if you prefer. For deployments where the Cisco Video Communications Server (VCS) is in play with CUCM, Cisco has some general design guidance that is slanted to registering Cisco telepresence endpoints on the CUCM. The VCS being relegated to legacy endpoint registration, protocol interworking, and facilitating firewall traversal.

This is all well and good but there are gaps. One of those gaps is supporting the ability to dial an H.323 party by IP address. Dialing by IP address refers to the ability of an endpoint to set up a video session with a remote party by simply using the IP address. This method is natively supported by H.323 devices. SIP devices use a URI format for "dialing". While SIP URIs can certainly use an IP address as the suffix, that is not the focus here.

Background

Anyone who has spent time designing, implementing, or operating an IP video conferencing (IPVC) solution has, at some point, needed to deal with dialing by IP address. I won't take a guess on how prevalent this method of dialing is used today. I do know I have had to account for dialing by IP address on every deployment that I have worked on in the past 2 years where there was a need to support B2B or B2C communication. 

I am not a fan of dialing by IP address. I think it is an antiquated way of doing things akin to leveraging fax machines. For that matter, I think dialing people using phone numbers should be tossed aside as well. But that is a topic for another day.

Anyway, in general, I am on-board with Cisco's direction. I think it is much cleaner to consolidate all call processing functionality to the CUCM and treat services like the VCS as peripheral components that extend the call processing solution. 

That said, I am not really satisfied with the present state of the solution. It is still disjointed and fragmented. I am not entirely surprised, as this is a necessary side effect of a solution that is in transition. I just think that the gaps need to be addressed quicker and the workarounds provided need to be less clunky. 

An Example of a Sub-Optimal Workaround

A perfect example of "clunky" workarounds comes from the Cisco TelePresence Cisco Unified Communications Manager with Cisco VCS (SIP Trunk) deployment guide provides guidance on how one can support IP address dialing for endpoints registered to CUCM. This is provided in Appendix 6 of the current deployment guide (it was Appendix 8 in the X7.2 guide). 

The following is an excerpt from the deployment guide (Appendix 6):


Appendix 6: Additional information
IP address dialing

Unified CM cannot dial out to IP addresses, but the VCS can. To support IP address dialing from endpoints registered to Unified CM, we recommend the following procedure:
 1. Define a prefix to use for dialing the IP address, for example 8.
 2. Add a Route Pattern in Unified CM to match the prefix and send it via the SIP trunk to VCS.
 3. On VCS, add a search rule (or transform) with a regex to match, for example: 8(\d{3})(\d{3})(\d{3})(\d{3}).* and then replace it with \1.\2.\3.\4

This example regex matches an IP address dialed in the format of 12 digits (inserting the leading zeroes in each octet), so for example 64.102.6.247 would be dialed as prefix 8 followed by 064102006247. The replace string then inserts dots after the 3rd, 6th and 9th digits.

You gotta be kidding me! Technically, this works but it turns my stomach when I think of having the design conversation with the customer that needs this functionality. This customer just spent a decent chunk of change on a "world class" solution. They are most likely keen on making things simple for their end users. They are desperately trying to avoid scenarios where a dedicated IT resource is needed to place a call. And then I come at them with this mess? 

It is lame. I have no other word for it. The fact that someone put this in "print" kills me. Why? Well, can you imagine being a non-technical user stepping up to the plate and having to remember to convert an IP address, like 64.102.6.247), to a zero-padded address like 064102006247? 

Of all of the clunky options available, why would they use this one?  

So, What's Your Plan Wise Guy

There are a couple of options available but the unfortunate truth here is that none of them are perfect. Of course, if we are going to be forced into a goofy solution then I think there are better options than the one provided in the VCS deployment guide.  Some of the options I found are provided below. Not all of these are viable. I am just laying out what I came up with during a recent bout with this functional requirement.
Dual Stacked End Points

One obvious option is to provision telepresence endpoints to register to CUCM using SIP and to the VCS using H.323. Using this approach, one could set the endpoint to default to SIP and allow the end user to dial an H.323 endpoint using the convention: h323:64.102.6.247. 

The big issue here is that when your endpoint is configured for CUCM provisioning, H323 mode is disabled (see the TC7 release notes, page 5). So, you could only do this if you were registering the endpoint as a 3rd party SIP device on CUCM and I honestly don't see much value in doing that. I'd rather host the dual registration on the VCS. 

While we are talking about "dual stacks", we should also note that a H323 endpoint doesn't require a H323 gatekeeper (like the VCS) to dial by an IP address. Assuming that the IP address can be routed across the organization (or across the Internet, if applicable) and your corporate firewall policy doesn't get in the way (unlikely) then you could "dial direct", as it were. Definitely not a recommended approach.

Using SIP Route Patterns - Option 1

Another approach is to leverage a SIP URI like: ip@64.102.6.247.  On the CUCM, we can create a SIP Route Pattern with the specific IP address (or a subnet) and route it to the VCS. The "ip@" is essentially bogus and we will chop it off at the VCS.

Creating the SIP Route Pattern in CUCM is pretty straight forward. Go to Call Routing > SIP Route Pattern and add a new pattern. Set the Pattern Usage to IP Address routing and configure your IPV4 pattern. This can be a specific IP address or a subnet (x.x.x.x/y). Point the pattern to a route list that contains the route group provisioned with your VCS SIP trunk. You could add your VCS SIP trunk directly but that is just poor form.

On the VCS, I like to treat this call with a pre-search transform first. Go to VCS Configuration > Dial Plan > Transforms. Add a new transform and make sure the priority of the transform fits within the existing transforms (i.e. don't break anything). Set the pattern type to RegEx and the pattern string to ip@(.*)(:506[01]). Set the pattern behavior to Replace and the replace string to "\1" (without the quotes).

What is happening here is that the user will dial ip@64.102.6.247. The CUCM is provisioned to route calls to 64.102.6.247 to the VCS using a SIP routing rule. The CUCM will postfix a SIP port number on the end of the "To:" field in the SIP INVITE. The VCS is using a pre-search transform that will strip out the "ip@" and the SIP port (:5060 for TCP/UDP sessions and :5061 for TLS). You are left with a clean IP address.

You aren't done with the VCS because you also need a Search Rule that matches "Any IP Address" and sends it to a traversal zone that points to your VCS Expressway. You also want to use the "Indirect" mode for call routing to unknown IP addresses (VCS Configurations > Dial Plan > Configuration). 

On the VCS Expressway, you need enable the "Direct" mode for call routing to unknown IP addresses. You also want to enable protocol interworking (VCS Configuration > Protocols > Interworking). Last, but not least, make sure H.323 and SIP protocols are enabled. This is also provisioned under the VCS Configuration > Protocols menu.

Using SIP Route Patterns - Option 2

A variation of the previous options is to leverage SIP Route Patterns on CUCM but use domain routing instead of IP address routing. I use this option when the target IP address is unknown and you want to apply a solution that can adapt to any IP address. For this option, we use a bogus suffix or SIP domain and the pattern dialed by the user is something like: 64.102.6.247@ipdial.local.

On CUCM, we create a SIP Route Pattern with a pattern usage of Domain Routing. We then program the bogus domain (e.g. ipdial.local). Place the pattern in a partition, pick your VCS route list, and Bob's your uncle. If you had a default SIP Route Pattern (i.e. *.*) pointing to your VCS route list then that would work, as well.

Just like Option 1, we need to configure a pre-search transform rule on the VCS. For this rule the match type would be a RegEx pattern like  (.*)@ipdial.local.* and the replace string would be "\1" (without quotes). Again, we are left with just the IP address.

From here, the VCS and VCS Expressway configurations are the same as with Option 1.


Additional Pondering for Option 1

While I was writing this blog entry, I had another thought around option 1. From a format perspective, I feel that the SIP Route Patterns - Option 1 is a little more straightforward than Option 2. The problem I ran into when originally testing option 1 is that CUCM won't let you specify a SIP Route Pattern with a "default route" for any IP address. So, for example, 0.0.0.0/0 doesn't pass muster. In my case, I had to allow for any IP address destination.

To achieve a generic or default routing, you may be able to get away with is creating two SIP Route Patterns. One with the IP address pattern of 1.0.0.0/1 and a second one with 128.0.0.0/1. That may work but I'll need to test it out in the lab before I can say for sure. The patterns will be accepted by CUCM but I need to check to see if it interferes with intra-cluster SIP call routing. Anyway, just another thought.

Conclusion

At the end of the day, you have to pick an IP address dialing solution that can only be characterized as a compromise. I suppose the day is coming where we can all scoff at the people who are still using IP address dialing and guilt them until doing some big boy stuff. I thought that day had already come but I still get hit up for this requirement on my projects. 

I personally use the SIP Route pattern options. If I have a customer that has an existing process whereby calls to external IP addresses must be approved then Option 1 is workable. Otherwise, I use the bogus domain approach. Are they perfect? Not at all but they are way better than padding zeros in a dial string. I mean, seriously.


Thanks for reading. If you have time, post a comment!

23 comments:

  1. Great post, thanks! I am curious how you think people should dial if not by IP address or number. I assume that only leaves dialing by name, but how does that get resolved and where? Is that handled by TMS or CUCM in some way? Thanks again for the great blog and the time you obviously put into it.

    ReplyDelete
    Replies
    1. Thanks for the kind words. Personally, I would like to see the industry move to using 100% URI dialing across all media types and protocol stacks. This is native for SIP. For H323, endpoints and devices need to be compliant with H323v5 Annex O. Technically, you could use a URL h323-id on an endpoint that is H323v2 compliant but that doesn't guarantee that the endpoint (or GK, if applicable) will leverage DNS to resolve URIs for remote entities. That is one of the reasons Annex O was drafted.

      HTH.

      -Bill

      Delete
  2. Ahh, that makes sense now! So hopefully someday we'll get to "user@enterprise.com" dialing that will attempt to connect to a user on whichever device they choose, be it mobile, desk or video. Sort of like an enhanced single-number-reach if I am understanding this correctly. Hopefully we'll get there! Thank you for the blog; I always learn something even after 13 years with CUCM. -Mike

    ReplyDelete
  3. I've been dealing with this particular problem since we got our Cisco Telepresence system about six months ago. We've got TX9000s and EX units registered to CUCM and going out a VCS/VCS-E. I've been asked to set up a B2B call with three vendors so far. When I've asked them if they can dial a SIP URI each one of them has asked "what's a SIP URI?" :) They've all used either an IP address or the number@ip_address H323 format.

    I've been using a default SIP route on CUCM and a static Search rule on the VCS. Basically, I'd translate a bogus URI into the IP address or bridge number(111111@1.1.1.1) of that specific company.

    I'm looking for something more generic that I can train my users on that won't require me to add/change a rule each time. I'm thinking about ip@1.1.1.1.vid or 111111@1.1.1.1.vid substituting the actual addresses for 1s. What do you think?

    ReplyDelete
    Replies
    1. Your approach should be viable. You would want to test that out to make sure SIP domain rule matches. Since you are slapping the .vid on the end it should pass CUCM scrutiny and match a SIP domain route entry.

      On the VCS side, you will want to match the ip@(.*) first and then match on the generic digit (\d*)@(.*) or similar. Then you will have the generic URI dialing search rule.

      -Bill (@ucguerrilla)

      Delete
    2. Thanks for the advice, I ended up going with 1.1.1.1@video.example.com dialed from the endpoint then stripping off the @video.example.com at the VCS. Works great to call into H.323 bridges from our TX9000 rooms.

      Stupid question, We have a VCS and a VCS-E for traversal. I'm having trouble decoding the VCS-E rules. What do H.323 bridges generally dial to access a VCS from the internet? 111111@1.1.1.1 for example? How do you generally handle this.

      Delete
    3. Ideally, you work with your business partner or consumer and implement a solution that allows for URI/Alias dialing. For SIP, this is native. For H.323, your equipment needs to support H.323v5 Annex O and you have to provision DNS accordingly.

      Look at the following link for some background on Annex O: http://www.packetizer.com/ipmc/h323/whatsnew_v5.html

      URL/URI dialing is what I consider best practice. If this is not possible then you need to configure the fallback alias parameter on your VCS-E. Basically, you set this alias to something that can be routed internally. External H323 endpoints dial the IP address of your VCS-E. VCS-E routes to fallback alias.

      HTH.

      -Bill (@ucguerrilla)

      Delete
  4. Hi Bill, We always do a Video Conference with a Government Dept. They almost always give us a dial string for every conference and the dial string looks like this, IP##XXXXXXXXX We recently got a VCS-Control and a VCS-E. I just wanted to ask, what do I need to do to allow my endpoints and MCU to dial that kind of String? Thanks!

    ReplyDelete
    Replies
    1. You can approach this several ways. I am assuming that the receiving end is expecting a dial string of IP##XXXXXXXXX. This doesn't necessarily require your endpoints to use the same dial string if there is a portion of the XXXXXXXXX that is easily recognizable as belonging to a specific target. You can also define your own dialing prefix that users leverage when placing the call.

      Let's say that the pattern for this Gov Dept is always something like 222XXXXXX and that the 222 prefix is unique. Then your users (and MCU) would dial 222XXXXXX. Your VCS can apply a pre-search transform to stick the IP## in front of the dialed string. Then you can have a search rule pointing to your VCS that is looking for IP##.

      I also assume that your VCS-E has a neighbor relationship with the final destination. If so, then a search rule on the VCS-E can point IP##XXXXXXXXX to this neighbor zone.

      HTH. If not then we may need a more specific example.

      -Bill (@ucguerrilla)

      Delete
    2. Thank you so much Bill! We don't have any neighbor relationship with them. i will try to find out if we can establish one and find out too if there is some common digits that I can use as prefix.

      Delete
  5. Hello all, as a variant of this scenario, does anybody know if there is a way for CUCM to handle INCOMING SIP URI calls that do NOT come in via an existing trunk? aka extension@CUCM-IP (this happens to be for incoming twilio SIP calls - unfortunatly it has varying source IPs) thanks

    ReplyDelete
  6. Trying to get Jabber to function for IPhones and IPads in an environment with CUCM 10.5, with Video VCS 8.2 C+E but ni IM&P server. Will this work, or does the IM&P really have to be there ?

    ReplyDelete
    Replies
    1. Paul,

      Take a look at this link:

      http://www.cisco.com/c/en/us/support/docs/unified-communications/jabber-windows/116446-technote-product-00.html

      It provides information on deploying Jabber in Phone Only mode. I assume this capability has been preserved in the current releases of Jabber.

      HTH

      -Bill (@ucguerrilla)

      Delete
  7. Hi William,
    What is your preferred CUCM SIP route pattern to unknown domains?
    I have tested with Domain Routing using IPv4 pattern of "*" which seems to work ok, are there some limitations or situations this would not be a good idea?

    ReplyDelete
    Replies
    1. Damian,

      Can you please clarify your requirements? I want to make sure I am understanding the problem scenario.

      Thanks,
      Bill

      Delete
  8. Fantastic post. Clear, concise, and written as if meant for people to be reading it.

    I have been using an approach almost identical to Option 1 and it has been the cleanest way of implementing routing to external IP. Trying to come up with a similar concept for inbound, but it's been more complicated than expected as the calls come in from all sorts of clients/devices.

    ReplyDelete
  9. greate post, I'm now hitting VCS-E but still unable to call, but I compare calling from Movi ( working previously of course ) and from Jabber and i see in event log that passing call is via TLS and failing call from Jabber is using TCP. I think that must be an issue.

    Greetings
    M

    ReplyDelete
  10. I was trying to figure out a way around this also and was wondering if you create a route pattern to the sip trunk such as *! then i thought everything beginning with star would be sent to expressway and then create the transform on the expressway stripping the star all the user would have to do for example is dial *192.168.0.0
    would I be correct in this assumption?

    ReplyDelete
    Replies
    1. Unfortunately, this method won't work with standard route patterns.

      HTH.
      -Bill (@ucguerrilla)

      Delete
  11. Very interesting post, William! Thank you very much!
    I have a question though.
    I've been using Option#2 for IP dialing. I'm using Expressway-C/E pair (which is essentially the same VCS without registration support). I've set up a Traversal zone according to the configuration guides from cisco.com (but only for SIP).
    H323-SIP networking is on on both C and E as well as H323 and SIP.
    I'm able to call an IP address by SIP, but what if I want to call it by H.323?
    Should Expressway-E do the conversion? Is the destination is H323-only, how C/E will decide what to use? Where the conversion would take place?

    Thank you for your time.

    ReplyDelete
    Replies
    1. Alexey,

      Thanks for the comment and the question. I may require some clarification. If the H.323 setup message is first handled by your Core (Expressway-C) then you will want to keep it H.323 and that means your traversal zone for B2B video should be configured to allow H.323.

      If the setup message is a SIP invite but you want it to be a H.323 setup when it leaves the Edge (Expressway-E) then you can handle it a couple of different ways.

      (1) You can transform at the core to convert the search alias to the IP address format and then hit your local IP address rule at the Core. This will cause the Core to protocol conversion and you should enable H.323 on your traversal link.

      (2) Keep the alias in the format used for this workaround (e.g. 10.10.10.10@ipdial.local) at the Core, pass it through the traversal zone unaltered. Let the Edge deal with the transformation and then hit an IP Address search rule on the Edge. The Edge will then take care of the protocol conversation.

      I am not sure if there is a best practice on this one. I have done it both ways.

      HTH.

      -Bill (@ucguerrilla)

      Delete
    2. Thank you!
      I've found a Search history menu on VCS-E where it shows 2 attempts of placing the call: SIP and H.323.

      I've got yet another question about dialing by IP.
      I've implemented dialing by URI where the URI looks like info@example.com.
      But not every peer has a valid SRVs and what they do is they give us URIs like 1234@10.10.10.10 (domain part is an IP adress - the public one, of course).
      In this case I have to add IP SIP route pattern of 10.10.10.10 (as opposite for domain sip route pattern) on CUCM, otherwise CUCM cannot route that pattern and play "Your call cannot be completed as dialed" announcement.
      So why 2 separate sip route patterns (IP and domain) are needed in CUCM?
      And how VCS-E should route URIs like 1234@10.10.10.10 when it gets it: should it route them directly as if it is a call to an unknown IP, or use search rule to DNS zone and perform A record lookup for 10.10.10.10?

      Delete