TMS Phone Book

[Dassaut Systemes NetSec]

I'm trying to setup a TMS (Telepresence Management Suite) server Phone Book and I have to say I am puzzled.

First of all there's almost no infromation at all on how to setup TMS Phone Books. Despite all menus and options avaible just for Phone Books on the TMS menus, the only documentation available is the "Installation and Getting Started" guide which just has 1 page on phone books... Isn't there any more indepths manual about that feature, describing in details the different options ?

I'd like to do something very basic: Pull the phone book from another TMS server.

Let's say I have 2 TMS: A & B.

devices that register on TMS A are in TMS A address book, devices registered on TMS B are in TMS B address book. What I want is TMS A & B to share their phone books.

I couldn't find any information on any manual on the web. In the TMS help I found in the "Manage Phone  Book  Sources"-"Adding a new phone  book  source" an explanation about the "Other TMS Phone Book" option:

Other TMS Phone  Book :

Import contacts from one Cisco  TMS Phone  Book  into another. This is useful for making nested Phone  Books.

I thought I found the solution as this is exactly what I want to do : nest the phone books between our TMS servers.

So in the TMS I created a new Phone Book Source and select the type as "Other TMS Phone Book".

But I was very surprise to see in the configuration options only for bandwith, the phone book were to put the number and the update frequency.

How the TMS is suppose to know which TMS it needs to pull the address book from without specifying an IP addres/server name ?!?!

I might be missing something very too obious but honestly can't figure it out and again the available documentation is not helpful at all...

In addition to this isn't there any documentation/white paper on nesting TMS servers (and integration with CTS-Manager) ?

[Magnus Ohm]

Hello

You cannot use a source directly from another TMS server like you are mentioning here. The Other TMS Phonebook is local only, you select an existing phonebook in the local TMS server and create a source based on that.

If you want two TMS's sharing the same phonebook source I suggest using a common H350 server as this makes it possible. OpenLDAP should be suiteable for this purpose since you need to export newly created entries on TMS 1 and TMS 2 to the common source and make TMS 1 import the new entries from TMS 2 and vice versa.

However from a TMS phonebook source creation point of view we assume you already have the H350 server setup and configured as support for this is not provided by Cisco. TMS is able to connect to it but it needs to be setup and configured to serve the purpose.

Once the source has been created you can add it a phonebook on both TMS servers as

This will make the TMS export all the entries added to the different sources added to that specific phonebook and at the same time import the contents of the source (H350 server). This will create a shared source between two or more TMS servers.

The other option would be to export the phonebook entries on one TMS to a file and import the file to the other TMS server, however this is less dynamic.

H.350 Directory

Search for H.350 commObjects and import them into phone books. Cisco TMS supports two-way synchronization, but does not support updating contacts in the H.350 directory not created by Cisco TMS.

Note:  If an incorrect number of entries is returned to your phone book source  from your ldap server, your server might be set up to return a limited  number of entries. The truncation happens at the ldap server, probably  because it does not implement the paged ldap extension. See your ldap  server documentation.

/Magnus

[daleritc]

I concur with what Magnus is saying about having more than one TMS in your network and sharing PBs with the use of H350 Directory Server or altenatively a File Based PB. And what I mean by two entirely different TMSs, is that each TMS is using their own SQL database (aka tmsng). However, we don't entirely recommend having more than TMS (one tmsng db) in the network. And we certainly don't encourage or recommend a mixture of TMS and CT Man...meaning we strongly recommend only having one TMS type 'management' tool in the network, i.e. either or but not both especially based on what your deploying and what fits your needs.

As far as documentation, we are improving our TMS documentation in the next major version release of TMS, aka TMS 14.1...coming out soon. There will be a new Install doc, Admin doc and improved online help (within TMS) and of course the ever important release notes.

[Dassaut Systemes NetSec]

Dale,

Thanks also for your feedback.

Regarding the design, is there any documentation anywhere about bast practices on TMS deployment ? I've been looking for such documentation for a while.

You are saying you don't recommend having multiple TMS, but what about widespread worlwide organizations ? You still recommend 1 single TMS ?

And If you don't recommend a mixture of CTS Manager and TMS how do you integrate legacy Telepresence with legacy Tandberg ? This is also an unclear topic as all Cisco documentations say something different. One of the documentation we were shown by Cisco's tech sales for inter-op architecture show both TMS server and CTS-Manager. Others like you seem to suggest talks about only CTS-Manager or TMS server.

[Dassaut Systemes NetSec]

Thanks for all the details. This was very helpful.

I will look at the H.350 directory.

I also thought the export/import of the TMS Phone Book through a file but although I have  found the import part by creating a "File Based Phone Book", I still haven't figured out the export part.

[daleritc]

Hi,

It would be nice to know exactly who you are since your user  name is quite 'general' but let me try and answer your questions, and  keep in mind I'm coming from a technical point of view vs. a marketing  one

As  far as best practice documentation with regards to TMS deployment, the  short answer is no but we're currently working with our tech writer team  so has to improve this area of our current documentation. And looking  at this from a deployment size point of view, i.e. small, medium and  large, the challenge is defining what is small, medium and large when it  comes to TMS, to include it's related extension products (e.g. TMSXE,  TMSPE) if those come into the picture as well. For example, you can't  simply measure it by the number of systems that will be in TMS. You also  need to consider the services as well, e.g. scheduling, monitoring,   phone books, sw upgrades, etc. Now for a large depolyment this may be a  no brainer...several hundred systems and using all of these services,  meaning you need these type of hw resources for both the web app and SQL  (e.g. cpu and memory requirments)...but it's really detemining the  requirements for the small and medium guys that is challenge since it  varies what they'll do and could change (moving target)...meaning it's  hard to determine when it's time for them to move up, e.g. move to an  external SQL server or increase their hw resources. At any rate, I hope  you get the picture but we are trying to put something together that  will help both our customers and partners.

As far as your other questions:

You are saying you don't recommend having multiple TMS, but what  about widespread worlwide organizations ?

You still recommend 1 single  TMS ?

Dale  says: I'm not saying you can't but since the TMS is all about the SQL  db (aka tmsng), this means that you will have in effect two  independently seperate TMSs on your network...meaning...and other than  PB challenges, you could also have scheduling challenges, the TMSs  'fighting' over systems (although this may be avoided by setting up your  TMS scans appropriately). In short, it could get messy and challenging.  And we do have worldwide organizations running a single TMS (one db),  to include Cisco

And If you don't recommend a mixture of CTS Manager and TMS  how do you integrate legacy Telepresence with legacy Tandberg ?

Dale  says: Define integrate? And by legacy Telepresence, I assume you mean  the CTS systems? In any case, and if my assumption is correct, then we  can currently schedule CTS systems registered to the CUCM in TMS today.  We can also monitor these systems in the CCC as well. In fact, we can  schedule and monitor any telepresence system that is registered to the  CUCM. However, TMS still has some gaps wrt CT Man but we are closing in  and TMS will be the scheduling and conference monitoring tool moving  forward.

This is  also an unclear topic as all  Cisco documentations say something  different. One of the documentation  we were shown by Cisco's tech sales  for inter-op architecture show both  TMS server and CTS-Manager. Others  like you seem to suggest talks  about only CTS-Manager or TMS server.

Dale says: I  think I know the document your talking about and it actually confused me  as well. And I think this was prepared by some marketing folks sometime  back when things were not as clear as they may be now. And I think what  they were trying to do in the document was to say "if you have this  kind of deployment", then you need this type "management and scheduling"  system....and it did seem to suggest a 'mixed' environment. However,  and again from a technical point of view and not a marketing one, it's  just not a good idea to try and have mulitiple scheduling tools in one  environment...in particular into a new deployment. Now I know there are  some customer 'corner cases' out there that do have both systems but the  reason for that was because of those gaps between TMS and CT Man at  that time, and they had deployments already and were extending their  telepresence portfolio to include the TANDBERG kit. But again, and as  discussed earlier, TMS has started to close in on most of those gaps and  will be the Telepresence scheduling and monitoring tool moving forward.

Hope this clarifies some and remember, I'm not a marketing guy

rgds,

Dale

[Matthieu LIENART]

Dave,

Sorry, I was too lazy to create a personal account so I was connecting with our corporate account.

Thanks for your very clear and detailed explanations. I wish I heard those before...

As you mention our challenge is that we have old Telepresence CTS (what I call the legacy), hundreds of Tandberg systems across the world of various generations, some registered on local TMS in some regions, some independent, we use WebEx, have traditional CUCM servers for VoIP... and we are asked to design, implement and deploy the infrastructure by ourselves to get all that communicate together as well as have people be able to join Telepresence from a jabber client on iPad...

I understand the challenges for Cisco to come-up with ready-to-use documentation for something like that but so is the challenge for us to understand how we will be able to get all these fancy technologies talk to each other and integrate as if it was one single system, the same way that Cisco advertise it.

Because for our management who looks at these promotions, the integration of Legacy CTS Telepresence, Tandberg video conference, VoIP, Webex and jabber is just a few mouse clicks away... like if we just had to enable the "integration" check box on all system and...voila...

anyway the information you provide are extremely helpful and disappointing at the same time as it means that the brand new TMS server your sales colleague sold me is useless.

Regarding the CTS-Manager vs TMS server. When you say "TMS has started to close in on most of those gaps and will be the Telepresence scheduling and monitoring tool moving forward" this is the impression I had looking at some of the technical documentation. Does that mean that the CTS Manager will be completely removed from the picture soon ?

[daleritc]

Hi Matthieu,

Nice to have a name now Let me just excerpt some of your comments:

"...disappointing at the same time as it means that the brand new TMS server your sales colleague sold me is useless."

Why is it useless when you can successfully add and schedule CTS (non-TANDBERG) that are registered to the CUCM to TMS? Do you have a "CUCM" centric call control or "VCS" centric call control? Meaning where and what call control are most of your EP systems registered to?

"Does that mean that the CTS Manager will be completely removed from the picture soon ?"

As I said in my original post, I'm not a product marketing guy. However, CTS Man will still be around for the forseeable future but the direction when it comes to scheduling, conference monitoring, etc will be TMS.

cheers,

Dale

[Matthieu LIENART]

I'm saying useless because from what you are saying it seems than 1 centralized TMS server is the most simple and recommended design and we already had 2 TMS servers in other regions.

Currently our CTS infrastructure and Tandberg infrastructure are completely independant. The CTS 3000 rooms being managed by CUCM for call control, CTS manager for reservation/scheduling and CTMS for multi-point sessions.

In some regions the Tandberg is managed by VCS for call control and multi-point sessions and TMS for reservation/scheduling. And in some regions like mine Tandberg were fully standalone and just purchased the VCS and TMS. But it looks like we should have better used one of the TMS of the other region.

[daleritc]

Hi Matthieu,

Ok, so your definitely "de-centralized", in particular on the TMS and VCS side of the house. And yes, for the region your in, an additional VCS may have been fine or necessary but you should of stuck with the single TMS in the other region, i.e. one TMS to rule them all

Now as far as the CUCM, CTS and CTMS side of the house, you could create a SIP trunk between the CUCM and VCS, then add your CUCM and CTS systems to TMS so has to be able to schedule them along side your systems (TANDBERG) registered to the VCS. However, the "odd man out here" is the CTMS since TMS does not support the CTMS. If this was a TS or if you have a TS in the mix, then you'd be good to go.

cheers,

Dale

[Matthieu LIENART]

Dale,

Thanks again for this very helpful information.

Just to wrap-up this discussion, if TMS

• "will be the Telepresence scheduling and monitoring tool moving forward"
  
• is not compatible with CTMS
  

it sounds like what we should converge to is

• one centralized TMS to manage both CTS endpoints and Tandberg/Telepresence endpoints
  
• get rid of our CTS-Manager (as scheduling/registration functions for both Telepresence and Tandberg will all be handled on the TMS)
  
• have the VCS control the Tandberg endpoints
  
• have the CUCM control the old CTS endpoints
  
• get rid of our CTMS which is not compatible with TMS
  

I have 2 remaining questions:

1. can the old CTS 3000 Telepresence endpoints use the Tandberg MCUs for multi-point conferencing (which is used by the endpoints on the TMS/Tandberg side) ?
   
2. Should the new Telepresence endpoints like SX20 be managed by the Telepresence CUCM or the Tandberg VCS for call control ?
   

[onur temel]

hi daleritc

I need a doc as  "TMS does not support the CTMS"?

where can I find?

thanks.