choosing outgoing protocol at VCS

[Marko Laurits]

Hello,

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 100@example.com then VCS-E initiates the call to sip:100@example.com. When endpoint registered with H.323 dials the same URI, then the VCS-E initiates the call to h323:100@example.com. 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 something@example.com 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 @example.com with SIP disabled. Then search rules to forward traffic for @example.com to this zone. This does not work. SIP endpoints still make SIP calls to this zone.

What is the right way for doing it?

Thanks!

Marko
 

[Patrick Sparkman]

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.
 

[Marko Laurits]

I created search rules using regex to forward calls with destination .*@example.com 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.
 

[Patrick Sparkman]

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.

[Marko Laurits]

Hello,

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.
 

[Patrick Sparkman]

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.

[Nick Halbert-Lillyman]

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.

[Martin Koch]

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.

[Marko Laurits]

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 h323:100@example.com and h323:200@example.com. There is only A DNS record for example.com, no SRV records.

The problem is that it is also possible to dial sip:100@example.com or sip:200@example.com. 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 example.com 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 100@example.com then VCSE dials h323:100@example.com and call connects as expected. When an endpoint is connected by SIP protocol to our VCSE and dials the same address then VCSE dials sip:100@example.com and the call is connected to wrong destination.

Therefore I would like to create a rule in VCSE that when SIP endpoints dial something@example.com then VCS would try h323:something@example.com in first order.

Is it possible?
 

[Patrick Sparkman]

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.

[Marko Laurits]

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