Showing results for 
Search instead for 
Did you mean: 

VCS - Dial plan example configuration to avoid interworking


VCS provides a gateway functionality that allows interoperability between endpoints using different protocols, either SIP/H323 protocols or even IPv4/IPv6 protocols. In general, this gateway feature of VCS works very well in most cases, but there are some cases where interworking SIP/H323 may cause issues and strange behaviors, depending upon which endpoints are involved on the call and the features negotiated.

In my experience with VCS deployments, I have seen some scenarios where interworking causes some problems, most of them are involving third party endpoints, mainly old endpoints, I have seen issues involving encryption negotiation, DTMF interoperability, strange negotiation errors and some isolated problems. This kind of problem is very common when using VCS Expressway to internet integration, where the customer may want to have conferences with so many different companies with so many different type of video systems.

Considering the possibility of having problems related to SIP/H323 interworking (what does not happen in most cases), I am sharing this document to suggest a dial plan configuration that avoids SIP/H323 interworking as long as possible. In some cases, interworking will be really required, but in many situations it can be avoided in the dial plan level. So this example configuration suggests a dial plan that avoids interworking but still allows it as fallback option when it is really required.

Example topology


In this example configuration, all the endpoints that support both SIP and H323 protocol must to register to VCS Control using both procotols. If only one single protocol is supported by an internal endpoint, then interworking will be really required when calling external endpoints. Only endpoints that support one single protocol must to register this way, like Jabber for Telepresence, for example.

Note that, in this scenario, there are no external systems registered to VCS Expressway, therefore the dial plan configuration for VCSe does not consider local registered endpoints for VCSe.

Number plan design

This is a number plan design example for the suggested topology above. Note that I am considering numeric address for all the internal endpoints, except Jabber for Telepresence. This is a very common dial plan usage.

VCS number plan design avoid interworking.png

Note that, as this example considers a numeric address dial plan, for H323 ID address, I suggest to configure the same display name configured for SIP display name, so that H323 ID will be used only for display purposes and not for dialing.

Dial Plan configuration

The logic used in this document to avoid interworking is based upon the parameter "protocol" in the search rules configuration, which allows us to define which source protocols will match the search rule. Using this parameter, we can establish that, for example, only SIP endpoints will be able to reach certain route, so we can force a routing configuration that will avoid interworking.

Note that this document only describes the search rules and tranforms configuration for that example topology provided here, if your environment has different components and requirements, you should consider this documment as a base and then make the proper adjustments to implement your environment correctly.

VCS Control

Search Rules configuration

These are the search rules suggested to be applied on VCS Control:

Search rule configuration VCS Control avoid interworking.png

Using this search rules design, VCS will route the call considering the protocol of the source endpoint. If the source endpoints is SIP, VCS will try to route the call by using SIP and searching for the destination with URI address, If the source endpoints is H323, VCS will try to route the call by using H323 and searching for the destination with address without URI. If those search rules don't match the call attempt, VCS will use the common search rules which do not consider the source protocol to route the calls, so VCS will try to find the endpoint searching by a URI destination (SIP address) and then will try to find the destination searching only by the number (H323 e164 alias).

Therefore, the interworking will happen only in the following scenarios:

  • Internal Jabber For Telepresence + Any external H323 endpoints
  • Internal CTS/TX + Any external H323 endpoints

All the other call scenarios should not have interwoking being applied.

Transforms configuration

These are the search rules suggested to be applied on VCS Control:

Tranforms configuration VCS Control avoid interworking.png

Replace by the IP address of your VCS Control and replace by the IP address of your CUCM. If you have a CUCM cluster, you apply the string (.*)@10.10.10.(10|15).* for example, that will match ".10" and ".15" IP address end.

VCS Expressway

Search Rules configuration

These are the search rules suggested to be applied on VCS Expressway:

Search rule configuration VCS Expressway avoid interworking.png

Transforms configuration

These are the search rules suggested to be applied on VCS Expressway:

Tranforms configuration VCS Expressway avoid interworking.png

Replace by the external IP address of your VCS Expressway.

Additional adjustments

Default call protocol: As the example topology in this documment only has single protocol endpoints that support SIP, so I suggest to configure all your internal endpoints to use the default protocol as SIP, including MCU and TP Server when dialing out from the conference, this way, the interworking behavior will be totally avoided for the local calls, only SIP protocol will be used locally. Furthermore, it is important to setup phonebook entries that contains the dialing entries for SIP protocol as well. H323 protocol will be used only for calls involving external endpoints.

MCU registration prefix: In this documment, I am assuming that MCU prefix for registration is not being used, once we need to have MCU registering its numeric IDs to VCS using the same number for H323 and SIP registration, when using registration prefix, only H323 registration will have the prefix added to the number, so the numeric ID registered to VCS will be different and may not match the dial plan example suggested here, so that additional search rule adjustments may be required.

Important considerations

Here are some important notes about this documment:

Requirements: VCS version X7.2 and later are required to implement this method. Before starting the configuration, make sure that you have the correct VCS software version.

About this dial plan configuration example: The dial plan example shown in this document is a basic example. In some scenarios, additional configuration may be need depending upon how your telepresence infrastructure looks like. Therefore, I don't suggest you to simply copy and paste the configuration described here, rather than this, use this documment as base and implement your own configuration according to the requirements that you have in your environment.

About this documment: This doc only describes the search rules and transforms configuration for this simple VCS topology, however, many another configuration are required to make the whole solution work, and it is not described in this documment. You should consider the oficial VCS configuration guides in order to implement all the configuration required. Here you will find the VCS configuration guides provided by Cisco:

I am providing an excel file that contains all the tables described on this documment.

Paulo Souza

Please rate useful documments and live comments if you have any doubt or suggestion.

Daniel Isham

Fantastic Paul, thank you very much for this!

Community Member

Perfect! Thank you for your tips and congratulations for achieving this solution.


Well explained. Thanks.



Technical Community Manager

Kjetil Ree
Cisco Employee

A very good guide, Paulo!

A minor point you should consider improving: In the network topology diagram and sometimes in the text, you say "Jabber" when you mean to refer to "Jabber Video". This could be confusing to some readers (as they are different products!), so I would recommend to always include "Video".


Paulo Souza
Rising star

Hi Kjetil,

Thanks for your feedback. In the whole document, I used the term "Jabber for Telepresence", but I missed that point on the topology where I used only "Jabber". I have fixed that. Thanks.

Paulo Souza

Cheng Chen

Wonderful, This is a great help to me , Thanks!


Very useful doc. Thanks man.


Thanks for the document. I have a question though: If  both end points support h323 and sip, then why not use only one  protocol. This will certainly eliminate the need for interworking. Why do we want to use both protocol to achive the same thing?

Paulo Souza
Rising star

Hi Ayodeji,


Thanks for your comment. I understand what you mean, however, the idea is to enable both protocols to avoid interworking and not to create a scenario where interworking will be done often.


If you look to the topology, you will realize that the demo environment is integrated to internet, that means, you will have all sorts of endpoints on internet making conferences with your internal endpoints, so that  you wont have control on which protocols your external users have. Therefore, if you enable one single protocol on your internal endpoints, SIP for example, you will have to use interworking when calling an external H323 endpoint. However, if your internal endpoint uses SIP and H323, you can call the external endpoint using H323 and thus avoiding interworking.


Using one single protocol is useful when you have an internal environment with no access to internet. However, when making conference with the external world, you may want to keep both protocols to avoid interworking.


This logic is mostly applied when you receive calls from internet. Using my dial plan suggestion, no matter wich protocol the external endpoint is using, you will be able to avoid interworking as long as possible.




Paulo Souza


Recognize Your Peers
Content for Community-Ad