History addresses as seen on a Jabber VC client lead to Traversal licence usage

[Chris Swinney]

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

[Chris Swinney]

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.

[Martin Koch]

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 :-)

[ahmashar]

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

[Chris Swinney]

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.

[Martin Koch]

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.

[Chris Swinney]

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:

• If the endpoint H.323 ID is NOT set, yet the E.164 number is set, Jabber will record the call as having come from “E.164@192.168.0.2”. This is fine as we have transforms in place that manipulate URI’s that look like E.164 numbers and strip off the IP address, then interwork the call and pass forward the H.323 call via E.164.
• If the H.323 is set to something WITHOUT a “@domain”, then the VCS will have to append its IP address to the H.323 ID as a SIP/Jabber client required a ‘valid’ URI, of sorts. SO the Jabber client sees “host@192.168.0.2”, however, this call can never be returned as there is no what for the VCS to determine its destination. The configured search rule will pass off the request to the Expressway, who in turn will pass it back and so forth. Whilst I understand that a dial plan may only be treating the symptoms of this search rule failure, we see no need that and endpoint will ever need to dial “anything@192.168.0.2” (or @IP_Address_VCS_Control) and so blocking such an attempt will work at least in the short term.
• If the H.323 ID has a full URI set, then the SIP /Jabber client will use this for the return call. In this case, the same search rule that failed above passes the URI through to the Expressway that then uses DNS to lookup the endpoint. Of course, the relies on DNS being correctly configured which unfortunately for us is something that is beyond our control as this is the responsibility of each site/institution. However, it does at least give the Jabber human user an idea of where the call came from – even if it cannot be returned.

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.