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. 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: 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: Replace 20.20.20.20 by the IP address of your VCS Control and replace 10.10.10.10 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: Transforms configuration These are the search rules suggested to be applied on VCS Expressway: Replace 199.199.199.199 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: http://www.cisco.com/en/US/products/ps11337/products_installation_and_configuration_guides_list.html 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. ... View more

In my experience with Cisco Telepresence solutions, I have seen some issues related to SIP UDP timeout, mainly in environments with VCSE involving calls to internet. Some time ago I found a solution to fix that kind of issue without disabling SIP UDP in VCS (which is highly recommended by Cisco, but it is not possible in some cases because of interoperability issues). In this document I describe how to workaround with SIP UDP timeout issues when it is not possible to totally turn off SIP UDP. If you can disable SIP UDP, I don't recommend you to follow this document, you should go ahead and simply disable SIP UDP to avoid UDP timeout issues. About SIP UDP timeout In scenarios with VCS Control integrated with VCS Expressway via traversal zone, it is very common to have internal SIP endpoints calling external H323 endpoints by dialing IP address. In this kind of situation, VCS Expressway will have to interwork the call in order to allow SIP to H323 interoperability. But there is a issue in this kind of situation, because when VCSe receives the call invite from internal SIP endpoints, as the source endpoint is using SIP, VCSe will try to connect to the external endpoint firstly using SIP, then, if SIP fails, VCS will attempt to connect using H323, then the call will proceed properly because the remote endpoint is a H323 endpoint. However, when VCSe tries to connect using SIP, it will try SIP TLS, TCP and then UDP (if all the protocols are enable in the global SIP configuration), and here is the problem, when it tries UDP, VCS waits 30 seconds waiting for SIP UDP timeout before trying to use H323. The result will be, the user will wait about 30 seconds before his device starts ringing. Most users simply give it up. How to avoid SIP UDP timeout As I stated before, the best and highly recommended way to avoid SIP UDP timeout is simply disabling SIP UDP globally in VCS Expressway. However, if you need to keep SIP UDP enable for interoperability issues, then you can apply the following workaround to your environment: Create a second traversal zone with only H323 protocol enable (it requires one additional port to be opened on the firewall) Create a custom search rule for SIP protocol with destination Any IP address toward this new traversal zone The result of this configuration will be, every time an internal SIP endpoint tries to dial an external IP address, VCS Control will interwork the call before sending it to VCS Expressway, so VCSE will receive a H323 setup instead of a SIP INVITE, then it will first attempt to call using H323, so that it won't have to wait for SIP UDP timeout. If you know how to do that, just go ahead and apply this workaround to your environment. If you don't know or need suggestion, I am placing below an example configuration. Creating a second Traversal Zone You can establish a second traversal zone between VCS Control Expressway, however, as the traversall server (VCSe) identifies the traversal client by using the port number, you will have to define another H323 port (rather than 6001) for this new traversal zone. In my example, I will use the port number 6002 to establish the new zone. It is import to point that you will need to open this 6002 port in the firewall as well, allowing the traffic from VCS Control to VCS Expressway, just like you did for the common traversal zone using the properly ports. Traversal Zone configuration VCS Control Make sure that only H323 protocol is enable on this second traversal zone. Traversal Zone configuration VCS Expressway Make sure that only H323 protocol is enable on this second traversal zone. Creating a custom search rule for SIP protocol You have to create a custom search rule in VCS Control. This search rule must to be pointed to Traversal zone 2. The rule will match only SIP endpoints when they dial any external IP address: IMPORTANT: This search rule must to have priority over any another search rule towards the common Traversal Zone, otherwise, the call from SIP endpoints with destination IP address may not match this rule and the workaround is not going to work. Furthermore, it is important to point that, if you have search rules with destination Any IP Address pointing to your local zone in VCS Control, the above search rule must not have priority over these search rules towards local zone. Therefore, make sure you set a correct priority value for the search rule above, so that you can force interworking only for calls from internal SIP endpoints towards external H323 endpoints dialing IP address. Important considerations Again, try to disable SIP UDP protocol in VCS Expressway if possible, this is the better way to fix SIP UDP timeout issues. Only apply this method described here if you cannot disable SIP UDP protocol. VCS version x7.2 and later and required to implement this workaround Be aware that you will have to open an additional port on the firewall for the second traversal zone. And make sure that you choose a port number that is not being used for any current traversal zone in your VCS's This is not a official Cisco recommendation, this is a workaround suggested by a Cisco Telepresence specialist partner (me) From VCS x7 and later, SIP UDP protocol is disable by default Do not route any other search rule to the Traversal Zone 2, only the search rule suggested in this documment Paulo Souza Please rate useful documments and live comments if you have any doubt or suggestion. ... View more