Tuesday, September 3, 2013

Enabling Local IP Address Dialing on a Cisco VCS Control

I recently fielded a question about IP address dialing and the Cisco Video Communications Server (VCS). It reminded me of a video design I put together a while ago and I have been meaning to put some more video / telepresence content on the blog. To that end, I figured I would share my approach to enabling IP address dialing with the Cisco VCS. 

Background

So, what do I mean by "IP Address Dialing"? Well, for those readers who have not worked with H.323 video deployments, it is the ability to place a point-to-point media call (audio and/or video) by simply specifying the IP address of the remote party. It was a fairly common configuration requirement when I first started doing video. It was also a common mechanism for setting calls with antiquated apps like NetMeeting (yeah, I went there).

One of the differences between H.323 and SIP is that H.323 supports direct dialing by IP address. Yes, a SIP invite can take the form of alias@10.10.10.10 (for example) but that isn't dialing by IP address. That is URI dialing with a DNS bypass (*grin*). Dialing by IP address is sometimes necessary when one of the endpoints involved in a video call is not registered with the call processing system.


Dialing By IP Call Flow - VCS

For the purposes of this discussion, we'll follow the basic topology in the following figure. 




In the above figure, "Endpoint B" and "Endpoint C" are not registered to either the VCS Control or Expressway. "Endpoint A" is registered to the VCS Control. Assuming that there are no other call processing agents in play and Endpoints B & C are H.323-only, then the only way for these endpoints to call each other is by using IP dialing.

I have seen posts on the Cisco Support Community describe this scenario as calls to/from an "unregistered" endpoint. I am fine with that description but the real question, from a VCS perspective, is whether the IP address of that endpoint is known or unknown.

The VCS consider an IP address to be known if one of the following is true:

  • The IP address is associated with a locally registered endpoint
  • The IP address falls within the range of an active sub-zone membership rule

Keeping this in mind, let's take a quick tour of the call flows and flesh out some of the configuration elements that come into play.


Calls to Intra-Net IP Addresses

Let's assume that "Endpoint B" is on your corporate network and, for whatever reason, it is not registered to your VCS Control system. Further, let's assume you want to allow "Endpoint A" and "Endpoint B" to call each other using IP dialing. How?

Well, there are two options here. 

Option 1: Treat the Remote Endpoint as "Unknown" and use the Direct routing method.

  • Go to VCS Configuration > Dial Plan > Configuration
  • Set the parameter "Calls to unknown IP addresses" to Direct

Option 2: Treat the Remote Endpoint as "Known".




  • Go to VCS Configuration > Local Zone > Subzone membership rules
  • Add a rule that specifies a subnetwork which encompasses the remote endpoint's IP address
  • Go to VCS Configuration > Dial Plan > Search Rules
  • Add a search rule with a match criteria of AnyIPAddress and a target zone of LocalZone
With Option 1, we are instructing the VCS to route calls using IP dialing directly. Which means that the VCS is going to start the TCP handshake with the IP address specified in the call setup message. We'll discuss the Indirect method later. The big assumption with Option 1 is that the remote system is not behind a firewall or on a private network that is not-reachable from the VCS.

The second option is to provision the VCS so that the "Endpoint B" IP address is considered known. Remember that the VCS considers any IP address that is included as part of a zone membership rule as known. Of course, as with any call routing policy, the VCS also requires a search rule so it knows what to do with the call setup request. Hence, the LocalZone search rule.

It is important to note that you can have the VCS Control provisioned to use the Indirect routing method for IP dialing to unknown IP addresses while also supporting IP dialing to known IP addresses at the same time. The configuration requirement is that you have at least two search rules with the match criteria of AnyIPAddress. One rule would cover the "intra-net" IP address ranges and a separate rule would "punt" to neighbor zones to find the destination. I typically recommend that these rules are configured with equal priority and, if that is not possible, that the LocalZone search rule is provisioned with a higher priority than neighbor zone search rules.


Calls to External IP Addresses

By default, the VCS (any VCS) will use the Indirect routing method to route calls to external (or unknown) IP addresses. Which means that the VCS will look to punt call setup to a neighbor. Of course, this requires that a search rule exists. It isn't enough to simply have the Indirect method for IP dialing specified. 

The typical configuration is to have the VCS Control provisioned to use the Indirect method and provision a search rule on the VCS with a match criteria of AnyIPAddress and a target zone that points to a traversal zone. Then the VCS Expressway (cluster or node) is provisioned to use the Direct method. While that is what I usually see, it is worth noting that the target zone can be any neighbor zone, it doesn't have to be a traversal zone. 

Calls from Unregistered IP Addresses

It is important to keep in mind that calls can flow in either direction. Further, when a call setup request from an "unregistered" device is received by an endpoint that has an active registration to a gatekeeper (i.e. VCS), it is expected that the registered endpoint is going to try to involve the gatekeeper.

When a VCS receives a H.225 SETUP message from an unregistered device, the VCS associates that device to the Default Zone. The Default Zone authentication policies are applied and the device is likely treated as "not authenticated". Why is this important? Well, if you are like me then you probably leverage authentication policies on your search rules and if you have a search rule that requires authentication then you could inadvertently (or intentionally?) block IP dialing from unregistered devices.

Of course, it isn't always that simple. The IP address of "Endpoint A" (in the above diagram) will most likely be a private IP address. In fact, in the diagram provided, it is implied that we are purposefully trying to hide the topology of the internal network. So, when "Endpoint C" wishes to reach "Endpoint A" the call would typically fail. As with anything else, we have some choices to make.

Fallback Alias

One way to facilitate an ingress call from "Endpoint C" is to use the "Fallback Alias" configuration on the VCS Expressway. The fallback alias is sued when the VCS receives an incoming call request where the destination is the IP address or domain of the VCS itself. You can set up a fallback alias to point to an automated attendant on your MCU or, if you have one, a video IP gateway. Basically, I like to punt those calls to an attendant application which allows the caller to either join a conference or put in an "extension" and route to the appropriate internal endpoint.

TCS4 - (not a fan)

I should note that most platforms support what is called a TCS4 delimiter to specify an alias along with an IP address as the destination in the H.225 setup message. This is a legacy convention carried over from H.320. With the caveat that the TCS4 delimiter itself does not follow a standard convention.

If I recall correctly, Polycom and LifeSize use the "##" string as a TCS4 delimiter while Tandberg (now Cisco) uses the "@". Though, I also recall that Codian gear (which was acquired by Tandberg, now Cisco) used "!" and older Tandberg gear used "*". But I may be fuzzy on the facts there. Anyway, to give an example of using a TCS4 delimiter, a Polycom endpoint can specify an E.164 alias AND do an IP address dial by using the destination address of: 10.10.10.10##54000. In this example, 54000 is the E.164 alias of some endpoint, MCU resource, or other super special "thing".

I'll be honest here. I tend to take the Indirect method when handling a requirement for TCS4 handling. Which is to say I punt! More specifically, I try to steer customers away from IP dialing as the "norm" and treat it as an exception. Then I recommend employing a solution that can front-end calls with an automated attendant for "extension" dialing. 

If you have no choice then I have seen configurations where you can use pattern matches on the VCS to catch the TCS4 delimiter and transform it to something that the VCS can route. So, 10.10.10.10##54000 can be translated to 54000@10.10.10.10. Maybe a pre-search transform like ^(.*)##(\d*)? that translates to \2@\1. Or something like that.

Conclusion

The scenario of IP dialing may seem odd to some readers. Particularly, if you are new to the game and are under the impression that everyone the world over loves SIP and is aggressively working to migrate away from H.323 to SIP. Yeah, well that is not universally true. At least not the "aggressive" part. The truth is video conferencing solutions are still ridiculously expensive and customers aren't inclined to throw something away that still works.

I can't speak for everyone but my experience is that it is very common to see a mixture of vendor products in a video solution. I rarely see a solution that is "all one vendor" end to end. More over, there always seems to be some legacy gear thrown into the mix which only supports H.323. Sometimes, that gear is owned by some department that wants the ability video call anywhere but doesn't want to be under the authoritative domain of an "official" call control system.

My recommendation to customers is that they should avoid IP address dialing as the general rule. In some instances, it can't be completely avoided and you just have to buck up and deal with it. In those cases, I recommend addressing the functional requirement with controlled methods. 

Fortunately, it isn't as common as it used to be. Unless of course you are dealing with a university or a healthcare organization that is associated to a university. Those folks know what I am talking about.


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

6 comments:

  1. Good helpful article. Intra (known) IP dialing now works. Trying the others soon.

    ReplyDelete
  2. Thanks for the article - previously missed the search rule and only had the subzone membership :|

    ReplyDelete
  3. Hi William,
    I tried to resolve TCS4 hash dialing in format IPaddress##number from VCS.

    The problem is, that VCS is representing # as %23 ASCII character and is adding its own domain (or IP) at the end. So when you try to dial IP##number, you will see in search transforms IP%23%23number@VCSdomain

    Solution can be creating pre-search transform (Configuration -> Dial Plan -> Transforms) as follows:

    Pattern type: Regex
    Pattern string: ^(.*)%23%23(\d*)(@.*)?
    Pattern behavior: Replace
    Replace string: \2@\1

    Btw. thanks for your helpful articles during long time ;-)

    Regards

    Lukas

    ReplyDelete
  4. Hi, we have some outside customers who only want to dial our internal endpoints by IP Address. Is there a way to setup mulitple IP's on expressway edge and have Fallback Alias routing each outside IP into a specific inside IP endpoint?

    Or can you elaborate on how the "auto attendant" would work?

    ReplyDelete
    Replies
    1. Matt,

      AFAIK, the Fallback Alias won't support mapping of multiple IPs to internal aliases.

      The auto attendant I was thinking of when I posted this was the AA functionality on the Cisco MCU and a similar functionality on the Tandberg IP Gateway. On the MCU, AAs can be provisioned to allow callers to create new conferences or join existing conferences. The IP Gateway product is no longer available.

      The MCU AA doesn't really address your use cases, as it is described. It would require that your internal endpoints join a conference and then external endpoints join that conference. Burning resources you may not want to use. I am not aware of a MCU AA feature that would allow for transfer to an endpoint from the MCU. I'd be curious enough to read recent release notes to see if that is available. Unlikely but maybe.

      If you have a Unity Connection system then I believe you could leverage the attendant functionality on that platform to accomplish your objective. Testing would be required but I think that you could do this:

      1. Use Fallback Alias on Edge to default to something like attendant@company.com.

      2. Route attendant@company.com to the Core.

      3. On the core, use a Search rule that matches attendant@company.com and transform the invite to use an E.164 number (or extension/DN). Ensure that interworking (SIP/H323) is enabled on Core.

      4. Unity answers the call and the caller enters an extension (not an IP address).

      In theory, this should work. Even if Unity's media stream is audio only. Once the call is redirected to an endpoint that supports video, SDP should handle the rest.

      If you don't have CUCM/Unity in your environment then the next thing I would explore is TCS4 or look for a 3rd party solution or, train the users to start using URI dialing.

      -Bill

      Delete
  5. Company X has deployed a VCS Control with a local zone and a traversal client zone. To facilitate
    external calls, VCS Expressway is deployed and traversal server zone is set up there. Video
    endpoints inside Company X have registered but are unable to receive calls from outside
    endpoints. Which option could be the cause of this issue?
    A. The access control list on the VCS Control must be updated with the IP for the external users.
    B. When a traversal zone is set up on VCS Control only outbound calls are possible.
    C. The local zone on the VCS Control does not have a search rule configured.
    D. The traversal zone on the VCS Control does not have a search rule configured.

    is the correct answer d? I have some doubts with this question

    ReplyDelete