Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

choosing outgoing protocol at VCS


We have a VCS-E server, endpoints are registered directly to it. Some endpoints are registered with SIP, some with H.323 protocol.

When endpoint registered with SIP dials to then VCS-E initiates the call to When endpoint registered with H.323 dials the same URI, then the VCS-E initiates the call to In case it is impossible to call by one protocol, it tries another.

There are addresses where we would like to specify the protocol manually. E.g. when an endpoint dials to the VCS should dial by H.323 first, no matter what protocol the endpoint uses. How to do it?

I created new DNS zone for with SIP disabled. Then search rules to forward traffic for to this zone. This does not work. SIP endpoints still make SIP calls to this zone.

What is the right way for doing it?



VIP Purple

You could create search rules

You could create search rules using regex for the addresses you'd like to limit to one protocol and set the rules priority to make one protocol higher than the other.  When creating the search rules, you can specify the protocol the rule applies to, ie: H323 or SIP.

New Member

I created search rules using

I created search rules using regex to forward calls with destination .* to zone Example.

The endpoint is registered to the VCS by SIP protocol.

When I disable SIP in zone Example, the call is not set up.

When I enable SIP in zone Example, the call is set up by using SIP protocol.

The aim is that VCS would dial the call by H.323 protocol and do SIP-H.323 traversal for the calls. I still have no success with that.

VIP Purple

Where is the calling endpoint

Where is the calling endpoint registered to, Control or Expressway?

What is the interworking set to on the Expressway?

Can you provide a copy of the a failed search history for a SIP-H323 call attempt?


I've known of some instances where if the endpoint is registered to the Control and needs to dial out to an H323 endpoint in a DNS Zone.  The call would fail because the interworking on the Expressway was set to only allow internworking for registered endpoints, because the endpoint was registered to the Control, the Expressway wouldn't interwork the call.  This is an assumption, since we don't have a copy of your search history, just from my experience of a similar call I've had in the past.

New Member

Hello,The calling endpoints


The calling endpoints are registered to Expressway, there is no VCSC involved.

H323 <-> SIP interworking mode is registered only.

Just for case, I made another test. From the SIP endpoint I called to an IP number of endpoint that accepts only H.323 calls. The call was successful, so the VCSE translates SIP to H.323 as expected. However, when I look Status -> Calls, the destination address is displayed as sip:x.x.x.x. So, for me it is complicated to figure out whether the call is actually SIP-SIP or SIP-H.323.

When I look Status -> Search History then I don't see the failed calls at all. And some recent calls are missing from the list either.

VIP Purple

Oh sorry, I forgot in your

Oh sorry, I forgot in your first post you had mentioned the endpoints were on your Expressway.  Well, without a search history, it would be hard to help determine the issue.  Try to see if you can get one and paste it here.

If you're missing some of the

If you're missing some of the failed H323-SIP calls on your search history, maybe those H323 registered endpoints are configured to dial "direct" rather than via gatekeeper (i.e. VCS)? Then the endpoints would be trying to go straight out to the internet so the VCS would never see the call and the call would fail because there's nothing to perform interworking, not to mention any firewalls that might be blocking the outgoing traffic.

I still do not really

I still do not really understand whats the challenge here.

In general the interworking is doing a good job and the only scenario where I see an issue would be

if the remote site would support h323 and sip but has a different number plan for both.

That would be not good anyhow and they should over think their deployment :-)

The VCS will always try to stick to the initiated protocol, so thats the wanted behavior?


Is this systems / domains you want to reach  you have control over or external ones?

If you have control different domains with different SRV records could help as well.


Like said here, with specific zones and search rules you should be able to handle that.

You might need to check your interworking setting.





Please remember to rate helpful responses and identify

New Member

I try to describe the

I try to describe the situation more clearly.

There are some external endpoints that can be connected by dialling h323:number@domain. For any case, I wouldn't publish real addresses, so let's say there are several endpoints, including and There is only A DNS record for, no SRV records.

The problem is that it is also possible to dial or The call connects but the call is not directed to the endpoint but default page of MCU.

I don't know whether it is a compatibility or misconfiguration problem but the is an external participant for us, so we don't have any control over them.

So, if an endpoint is connected by H.323 protocol to our VCSE and initiates the call to then VCSE dials and call connects as expected. When an endpoint is connected by SIP protocol to our VCSE and dials the same address then VCSE dials and the call is connected to wrong destination.

Therefore I would like to create a rule in VCSE that when SIP endpoints dial then VCS would try in first order.

Is it possible?

VIP Purple

It sounds like your dial plan

It sounds like your dial plan might need to be tweaked a little bit.  For instance, have same address be used on the same endpoint for both H323 and SIP.  Instead of having H323 be the endpoint and SIP be the MCU.

New Member

They are external partner for

They are external partner for us. We can't change their dial plan.

CreatePlease login to create content