04-11-2013 09:13 AM - edited 03-18-2019 12:55 AM
Hi All,
We have Jabber clients registered to a local VCS control/Expressway, and the VCSs offer SIP --> H.323 interworking. In general we use H.323 and transform H.323 E.164 numbers to Jabber SIP URIs. We also use FindMe to route a virtual E.164 number to dial multiple Jabber clients, thus customers can video call our helpdesk from their standards based (H.323) VC endpoints and we can answer on our Jabber clients.
However, when an external H.323 client calls, the History on the Jabber call list shows the client as "h.323_alias@IP_Address_of_VCS_Control". If the help desk user then tries to return the call, obviously they do not get connected (as the VCS has no idea of the registered alias), but something weird also happens. We see multiple call attempt on the VCSs failing with the error "Subscriber absent / Called party not registered" (which, I suppose, is also reasonably obvious), yet the number of calls placed would be numerous in a short amount of time (1-3 seconds) and effectively doesn't stop until all the traversal licenses have been used on the VCS Expressway.
Am I right in thinking that that calls from the Jabber client to "h.323_alias@IP_Address_of_VCS_Control" is effectivly being passed off from the Control to the Expressway, then back to the Control and so on? We do have Loop detection turned on on both the VCS Control and Expressway, but still the problem occurs. Is there anyway around this (perhaps a call policy simply stopping all call to "anything@IP_Address_of_VCS_Control", as this is not something we would not use in general)?
I also take it that unless the H.323 alias of the calling party is set to something like "alias@domain.com", then the IP address of VCS control will always be appended to the caller ID?
Any ideas or thoughts?
Chris
04-11-2013 09:48 AM
I "think" I might have answered my own question as I typed. Indeed the loop detection doesn't seem to function for the interworked SIP-->H.323 calls. You can see the initial SIP-H.323 call place, then the subsequent H.323-->H.323 call are placed until all traversal licenses are used - eventually the initial SIP--H.323 fails with Loop detected - but only after 50 traversal licence's are used. At the same to the interworked call is attempted, a SIP-SIP call it place - this fails almost immediately with a Loop Detected error.
However, I believe I have resolve the problem with the use of a call policy such that:
Source = .* (i.e. all authenticated users)
Destination = .*@IP_Address_Of_VCS
Action = Reject
For completeness, I put a second rule with the source blank (i.e. all unauthenticated users). It would be nice to be able to put the two into one rule, but I can't see a way of doing this.
The call is not "Forbidden" right at the outset. I can't see this having any negative impact, but please feel free to comment if you think otherwise.
It would still be nice to be able to return a call that has been received, but I think this might be down to the configuration of the calling CODEC.
04-12-2013 08:25 PM
In general the loop detection should also work on interworked calls,
but sure, maybe you have some old bg/gk or 3rd party sip proxy in the path
or do some additional search / transform patterns which lock something up.
Which version of the vcs do you use? Also tell your callers to use a proper uri incl a domain :-)
Please remember to rate helpful responses and identify
04-13-2013 04:18 AM
Hi,
it is not good idea to leave the continueous loop-detection problem unresolved. you can optimize your search rule and eliminate the loop detection by specifying where the call should be directly as oppose to use "Any" all over the place. Creating subzones and registering endpoints based some policy/category in those subzones, enables you to direct your calls via search rules towards one specific subzone rather than broadcasting, hence mutliply braodcasting via Any search rules create loops.
regards,
Ahmad
04-14-2013 03:06 PM
Hi Both,
Here is an example of the setup (simplified and addresses are not real).
Essentially 99% of our infrastructure uses H.323 with E.164 numbers that comply with the Global Dialling Scheme (GDS). External VCS Expressways and Boarder Controller have neighboured zones with the National Gatekeeper. E.164 lookup are passed from one zone to the next so that the H.323 client in "Site 2" can dial H.323 client in Site 1.
Of course, Jabber clients are SIP, but the VCS will interwork H.323 --> SIP so that H.323 client dialling the E.164 004411111100 will ring all Jabber clients in a group. The problem is that in the history of the Jabber client, the address that shows up is "MyCODEC@192.168.0.2". Obviously, this is NEVER going to be reached. If we have control over the system, we would configure the system name an H.323 ID to be something like "MyCODEC@site2.com" (although sometime it simply isn't possible due to restrictions on the number of characters), but in this case we don't.
Indeed, Ahrmad, one of the search rules targeting the traversal zone on the VCS Control forwards a call attempt to "MyCODEC@192.168.0.2" to the VCS Expressway, which in turn hands it back to the Control and so on. The Source is set to "Any" and the mode is also set to "Any alias". In general, we do not see the need to allow dialling via the Expressway (or Control) IP (i.e. 00441111100@1.1.1.1, or 00441111100@192.168.0.2) so implementing the Call Policy so stop and authenticated or unauthenticated calls to ".*@192.168.0.2" stops this loop.
04-14-2013 05:09 PM
Sure that call policy might kills the symptoms, but there might be some generic problems with the
search rules in addition.
The first step could be to see to improve the search rules and your addresses / dialplan.
Followed what could be done to improve the setup (like replace the old BK/GK with VCS), ...
But To be honest, to many devices, to many side effects, contact your Cisco Telepresence Partner
or an external consultant and get your network reviewed.
Please remember to rate helpful responses and identify
04-15-2013 05:34 AM
Hi Martin and thanks for the reply.
I had written a full response, but typically, the browser crashed!
After a bit of investigation, I have now noted three possible problems relating to the caller (source) ID as shown in Jabber’s history:
There may in fact be a fourth option where the H.323 ID contains an invalid URI, in which case it seems that the VCS replaces the whole thing with “iwf@192.168.0.2”, but again nothing can be done about this.
WRT to the old GK/BC, in the first instance this was the topology, however, I have checked with Pure VCS infrastructure and the same holds true. We have advised the site that the GK/BC is end of life, but again, the responsibility (and cost) is not apportioned to us.
I will look into the search rules and fully determine if any endpoint will ever require that a call be placed to “host@IP_Address_VCS_Control”, but I don’t think so.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide