Is it possible to search on domains via Jabber/TMS VC phonebook?

[Chris Swinney]

Hi,

We have Jabber clients provisioned via TMS, but also our TMS manages many different VCS Expressway/Control groups, with many different endpoints listed in many different domains. Whilst the Jabber clients are able to show all of the endpoints as shown the TMS phonebooks, it would appear that the search feature in jabber only searches the host park of the system name. Is there anyway to configure Jabber or TMS to show result matching on the domain part of the name?

I.e.

Registered endpoints in the phonenbook could be:

site1.vc@there.com

site1.vc@here.com

me.vc@nowhere.com

Searching for "vc" will show all results, but searching to "here" will show nothing.

Chris

[ahmashar]

Hi,

search is based on firstname lastname. have you configured and made the phonebook source for @here.com availble to for Jabber clients?

[Chris Swinney]

Hi Armad,

Not quite sure what you mean here by saying "have you configured and made the phonebook source for @here.com available to for Jabber clients". How can this be done?

The Jabber client can search for most endpoints that are registered to our TMS - which covers multiple VCSs across multiple different domains. Most of the endpoints we have are hardware based CODECs such as MXP 6000, C Series and Polycom units, and for the most part use H.323, with only a handful of Jabber clients at this moment in time. Its not that the Jabber clients can't search for the endpoint (they can) its just that I would like to also be able to enable searching based on the domain part of the endpoint name AS WELL as the host part.

As most of our endpoints are actually hardware based units, there is no 'First Name', 'Last Name', per se. However, a search result for a specific endpoint will throw up the 3 separate results:

• The H.323 alias
• The IP address
• The E.164 number

All this is great (although it would be even better if we could refine the results to just E.164 numbers, although this might impact URI searching if we were to expand our SIP endpoints and jabber clients in the future, so it really is fine as is), but still the user needs to know the HOST part of the endpoints registration. For us, it would actually be better to search by DOMAIN (each domain may have only a handful of registered endpoints)

Not sure if this make anything clearer or not!

Chris

[Martin Koch]

Hi Chris!

Not sure how you create your entries, but you also have the name of the system / jabber account,

so if you do some clever naming there, like

Name: Site 1 - here

uri (h323/sip): site1.vc@here.com

and then find here.

This could be the system name if you auto generate your entries or the display name field in probisioning or the title in the

manual phonebook, ...

If you have anyhow to sites which should not see each other you can also set up

different phonebooks for different groups so site 1.vc@here shows only up if you

are part of here, ...

[Chris Swinney]

We are only just venturing into PhoneBook and the intention at this moment in time is to help the Help Desk staff (as 99.9% of user utilise a separate booking system and we do not encourage point-to-point calls). However, this "may" change in future if more software jabber clients are utilised.

Still at this moment in time, we essentially have a Phone Book Source that imports "TMS Endpoint" from the base TMS System folder (i.e. ALL endpoints that are registered in TMS). ALL our endpoints system names are set up with domain names, and this is also set on the Systems H.323 ID. In any case, I tried to create a "Manual Entry" phone book source (added both SIP and H323 contact details, then attched to to an active Phone book.

- Yet, I still cannot search on domain name!

I can see the manual entries in the Jabber client, but only if I search on the infomation in the host potion of the address (or the entry name).

One other question - the search box you show an image of above looks completely different to the Jabber client we utilise. We do NOT use the UC Jabber client, but rather the Video Jabber client (4.5 or 4.6).

Message was edited by: Chris Swinney

[Chris Swinney]

Anoyingly, if I look directly on the VCS (to which the Jabber clients are provisioned from), I can see the relevant phonebooks in place, and if I run the search from there, I see results showing both host and domain hits.

I'm thinking this is now a limitation in the Jabber Video client....

Search 1 - OK

Search 2 on domain - Fail

Message was edited by: Chris Swinney

[Chris Swinney]

Hi Martin,

I see why you search succeeds - It because the term "here" is in the Display name "Site 1 - here", not because it is searching on the domain name.

I bet that if you remove that term from the display name and refresh the phonebooks, the search will fail.

[Martin Koch · Accepted solution]

Yes, but thats whay I say, if you need it put it in a field which can be found, like the the display name field.

You have a problem and that is a suitable workaround.

And if you really need to have the full domain incl the country code and not the start, then put the whole domain into it.

If you want a direct answer: "No thats not possible, file a feature request"

Not sure which answer is more handy for you ,-)

[Chris Swinney]

Martin Koch wrote:
Yes, but thats whay I say, if you need it put it in a field which can be found, like the the display name field.
You have a problem and that is a suitable workaround.
And if you really need to have the full domain incl the country code and not the start, then put the whole domain into it.

Thanks Martin. I misunderstood what you originally intended to say. Not sure how we would achieve this when using "TMS Endpoint" for the phonebook source as we currently do. All of the systems in TMS have their System Unit name and H.323 ID (and SIP URI where applicable) set to the full domain name. Are there any other fileds that are refered to in a search if using TMS Endpoints as a phone book source?

If you want a direct answer: "No thats not possible, file a feature request"
Not sure which answer is more handy for you ,-)

Ah. Yes this at least means that what I what to do can't be directly achieved. If there is a way I can find out how to work around the problem given the above senario, thet would be awsome, but othersie a feature request it is.