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

Interworking what decides if it occurs?

Hello

My environment consists of C20's / C40's TC 5.1.2 all registering to a single 2 node cluster of VCS running 7.1. The codec's have both SIP and H.323 turned on and the VCS will route calls for either H.323 or SIP.

My general understanding was that if interworking can be avoided during call setup then the call will proceed with like protocals. So if I called an endpoint using it's SIP uri or its H.323 alias, during the signaling phase of the call, the enpoints would decide which protocal they would like to use to communicate and they "Should" pick the same if they both support them and the call should "not" be interworked.

For our environment it seems as though the VCS search rules dictate the protocal that is being used.

See post https://supportforums.cisco.com/thread/2160010

Example if we make a "SIP" call to alias@example.com. We use the standard rule 48 for h.323 calls where the @example.com is striped, if there is a corresponding H.323 id found then the second part of the call leg call proceeds as H.323, and it interworked. If i disable rule 48 then rule 50 is matched which takes any alias and re-appends the @example.com and the call proceeds as a SIP to SIP call.

So my questions are:

Is my understanding of when a call should be interworked wrong?

Any ideas on how I can resolve this, so that calls internal calls are not interworked if they dont' have to be.

8 REPLIES
Gold

Re: Interworking what decides if it occurs?

Ryan,

you will get the most streamlined behavior if you register your devices on SIP and H323 with the same URI, there shouldn't normally be any good reason not to do so in any case.

With devices registering on H323 and SIP with the same URI, you shouldn't have to strip/add domains in your search rules or with transforms.

The VCS will always prefer to keep a call within its original call protocol, but this of course requires that the called alias matches a device which is registered with that alias in the protocol which the call was placed with.

Would you mind clarifying why you have an "H323" search rule which strips the domain off of the dialled alias, and a separate "SIP" search rule, rather than using a single AnyAlias type rule for your LocalZone?

Keep in mind that if you want presence to work for H323 and SIP devices, they must be registered with an URI-based alias, such as firstname.lastname@domain.

- Andreas

New Member

Re: Interworking what decides if it occurs?

I have both my SIP and H.323 registering with the same URI which is systemname@example.com. The e.164 is a numeric 4 digit number because we have a SIP trunk going to our Callmanager and we made the Codec's part of our 4 digit dialplan.

As for Clarity on why we have separate rules, I'm open to idea's for streamlining based on your suggestion. If I did a single rule based on AnyAlias type for my local zone, Would this rule allow users to still dial between codec's just by entering the 4 digt e.164 number.

Ryan

Interworking what decides if it occurs?

the e164 (at least seen from the old Tandberg perspecitve) is always only a h323 address.

Means, if you call from cucm the number it would be an interworked=traversal call unless

you use something like enum or numerically register the endpoints instead of using a alphanumeric user part.

And yes, also the order of search rules have an impact

All together It depends on your deployment and your integration requirements what will be the right answer to your issue.

What do you think abot contacting your Cisco TelePresence partner, he will be able to assist you to find the best dialplan and setup fitting your needs.

Please remember to rate helpful responses and identify

Gold

Re: Interworking what decides if it occurs?

The AnyAlias rule for your LocalZone would allow calling between devices using the E164 since that is one of the registered aliases of said devices.

When you state that the systems are registered as 'systemname@example.com', does that mean the literal name of the device? To be able to call native SIP-SIP from UCM to the VCS you would either have to SIP register your devices as e164@example.com and use a dynamic transform on the VCS for the UCM to VCS calls, or keep the devices registered as 'systemname@example.com' and have a device-specific VCS transform for each device (which would be a huge administrative task) or use ENUM lookup as Martin suggests.

- Andreas

New Member

Re: Interworking what decides if it occurs?

Hi Martin

For clairty I am the Cisco partner and I'm stuck

Andreas,

Yes I have the systems registered a the Literal name of the device. I have the e.164 as a 4 digit number ex: 3004. Calls from CUCM come in as 3004@vcscluster.example.com:5060. I have a single rule that takes anything @vcscluster.example.com:5060 and converts it to @example.com. Then rule 48 strips the @example.com and the call proceeds.

I think everything would work fine if I can prevent my C-series codecs from registering their System name as an alternate e.164 alais.

Gold

Re: Interworking what decides if it occurs?

Ryan,

it shouldn't matter that the C-series codec registers its system name as an H323 ID in addition to the URI it is registering on H323 and SIP?

The rule which strips @example.com is fine but doing so will induce an interworked call (Which is fine in itself, the VCS-C has 100 traversal call licenses anyways. Is there any specific reason you want to prohibit such kind of interworking?

For calls between the devices registered to your VCS, simply register them on SIP and H323 with the same URI and the calls will not get interworked (Unless you dial the E164 number in SIP, in which the calling device will append its own SIP domain which will then get stripped off again in the VCS and match the E164 registration of the device, inducing an interworked call).

- Andreas

New Member

Re: Interworking what decides if it occurs?

Hi Andreas,

It's not so much that I want to prohibit interworking, I guess i'm just trying to understand why it's interworking. I'm trying to apply theory to practice. It was my understanding that if VCS can avoid using interworking then it will. So I have 2 codec's that can do both SIP and H.323, one would think that along the way during the setup, that this would be established and the call would flow with like protocals. In my customers case this isn't happening and I'm trying to understand that's all.

Ryan

Gold

Re: Interworking what decides if it occurs?

Ryan,

the VCS will keep a call in its original call protocol whenever possible, but this requires that the destination alias matches a registered alias in the same protocol.

For instance, endpoint A is registered as follows:

H323: 1234 (E.164 number) and endpointa@example.com (H323 ID)

SIP: endpointa@example.com

On the VCS, there is an AnyAlias search rule for the local zone with priority 50, and a regex search rule that strips off '@example.com' with priority 51.

Endpoint B is registered on SIP only as endpointb@example.com.

If endpoint B dials 'endpointa@example.com', VCS searches using the AnyAlias search rule and matches the SIP registration of endpoint A, call remains in SIP.

If endpoint B dials '1234', the endpoint itself will append '@example.com' and send a SIP INVITE to the VCS for '1234@example.com'. VCS searches using the AnyAlias search rule and does not get a match. VCS then searches using the regex search rule (removing '@example.com'), matches '1234' with the E164/H323 registration of endpoint A which results in an interworked SIP > H323 call from endpoint B to endpoint A.

Can you explain in more detail the call scenario where you are seeing interworking when you aren't expecting it?

Thanks,

Andreas

356
Views
0
Helpful
8
Replies
CreatePlease to create content