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.
Example if we make a "SIP" call to email@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.
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.
I have both my SIP and H.323 registering with the same URI which is firstname.lastname@example.org. 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.
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
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 'email@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 firstname.lastname@example.org and use a dynamic transform on the VCS for the UCM to VCS calls, or keep the devices registered as 'email@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.
For clairty I am the Cisco partner and I'm stuck
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 firstname.lastname@example.org: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.
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).
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.
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 email@example.com (H323 ID)
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 firstname.lastname@example.org.
If endpoint B dials 'email@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 'firstname.lastname@example.org'. 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?